by Martin Laukkanen | Dec 26, 2013 | Apps, How to, Project Online
I’ve been recently moving the last few components of my setup into the cloud and the last piece is decommissioning my development server, however not having full PowerShell access does place some limits on what can be done on Project Online so this particular error initially had me stumped:
Error occurred in deployment step ‘Install App for SharePoint’: Sideloading of apps is not enabled on this site.
On-premise that can be fixed as easily as:
Enable-SPFeature e374875e-06b6-11e0-b0fa-57f5dfd72085 –url http://server/PWA
(Source: http://blogs.msdn.com/b/josrod)
However as Tobias Lekman points out to do this on Office 365 or Project Online you need to use another method. Unfortunately the script you need: http://lekman.codeplex.com/releases/view/98505 appears to have an old GUID, so a slight modification is needed.
Steps to setup Project Online for App development
- First provision your PWA instance from the SharePoint Admin site, I’m going to use /sites/devpwa for this example.
- Download the Sideload.ps1 script.
- Open the script and replace the following line:
$sideLoadingGuid = new-object System.Guid "AE3A1339-61F5-4f8f-81A7-ABD2DA956A7D"
#Replace above line with:
$sideLoadingGuid = new-object System.Guid "e374875e-06b6-11e0-b0fa-57f5dfd72085"
- Now run the modified script and follow the prompts, for example:
Now your PWA site should look quite different:
Now you can deploy from Visual Studio without errors and debug as you would on-premise.
Note: Obviously you don’t want to do this on a Production PWA instance, for Production sites only ever use an App Catalog to deploy manually.
Office 365 developer subscription limit
Lastly, one thing that irritates me is that the O365 MSDN Dev subscription does not include Project Online! So please join me every opportunity you get to speak to your contacts in MS about fixing this serious omission!
by Martin Laukkanen | May 1, 2013 | How to, PowerShell, Project 2013
A few people have written about PowerShell provisioning of PWA in 2013, see here and here, both reference this TechNet source. However if you’re anything like me you might find these confusing! Coming from 2010 it seems that everything has changed, so after struggling a bit using the above three references trying to update my old automated PWA deployment scripts I figured that it can’t hurt to have one more guide online covering the process.
Look No Site Collection
Firstly though, one of the great things about 2013 is that PWA is now uncoupled from its Site Collection, basically /PWA no longer needs to be a Site Collection but can be any regular site.
Esoteric as that may sound it means that we no longer have this odd divide where Project data such as Project Sites live in various “SharePoint Intranet” site collections and PWA has to be in it’s own isolated space with different users, permissions, features, etc. Clearly this is geared towards supporting SharePoint permissions mode and generally making Project more SharePoint friendly, but combined with those nifty new license management features things become very much easier for many of us dealing with real world deployment scenarios.
This also has the added bonus of making it easier to provision PWA at the root site collection (in a more standard way – ick Site Collection host headers!).
Get to the setup
The challenge I had with the scripted setup links above was that they seemed to be missing something, for instance the TechNet article misses the whole site collection creation part and so then confuses things by splitting off into a separate article on creating PWA in an existing site collection? Is it just me or was that really confusing?
Anyway here’s my PowerShell script for provisioning a new PWA instance in a new Site Collection where the root site collection contains a Team Site and PWA is in the familiar location /PWA.
$SiteUrl = "https://"+$HostHeader
$PWASiteUrl = "https://"+$HostHeader+$PWAPath
$SiteCollectionOwner="i:0#.w|domain$($AdminUser)"
$SecondaryOwnerAlias=""
$PWADatabase="ProjectWebAppDB"
$DatabaseServer = "sqlservername"
$PWAAbbreviation = "PWAInstance1"
$svcApp = Get-SPServiceApplication | ? {$_.TypeName -eq 'Project Application Services'}
$webapp = Get-SPWebApplication -Identity $SiteUrl
Write-Host "Creating Project Server database:" $PWADatabase
New-SPProjectDatabase -Name $PWADatabase -ServiceApplication $svcApp `
-DatabaseServer $DatabaseServer -Tag $PWAAbbreviation `
-ErrorVariable err
if ( $err ) {
write-host "An Error Occured: " $err -ForegroundColor Red
break
}
Write-Host "Creating Team Site root for PWA" $SiteUrl " Owner:" $SiteCollectionOwner
$site = New-SpSite -url $SiteUrl `
-owneralias $SiteCollectionOwner `
-SecondaryOwnerAlias $SecondaryOwnerAlias `
-ErrorVariable err
if ( $err ) {
write-host "An Error Occured: " $err -ForegroundColor Red
break
}
Write-Host "Creating PWA Web: " $PWASiteUrl " Owner:" $SiteCollectionOwner
$web = New-SPweb -URL $PWASiteUrl -Template pwa#0
$web=Get-SPWeb $SiteUrl
$web.Properties["PWA_TAG"] = $PWAAbbreviation
$web.Properties.Update()
Write-host "Enabling PWASite features..."
Enable-SPFeature pwasite -URL $SiteUrl
I lifted that from my mass deployment script (woo 2,600 lines and counting) so after my little rant above please excuse me if I forgot to declare one of the variables or something.
Hope this helps someone!
This article is republished with permission here: EPMonDemand Blog
by Martin Laukkanen | Jul 1, 2011 | SharePoint 2010, Troubleshooting
Had some time today to upgrade my lab to SP1, and thought it worth a quick post here about my experience.
For many people SP1 will be the first update applied to Project Server and SharePoint 2010, so with up to a year or more of production use it’s very possible that some features / solutions have been installed and removed which might cause some problems for the SP1 install.
In my case on my development lab this was most certainly the case with literally dozens of (often half developed) solutions in various states of deployment!
So in this case you may have the configuration Wizard fail after SP1 setup with a message like this:
Upgrade Timer job is exiting due to exception: Microsoft.SharePoint.Upgrade.SPUpgradeException: Upgrade completed with errors. Review the upgrade log file located in C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14LOGSUpgrade-20110701-160359-545.log. The number of errors and warnings is listed at the end of the upgrade log file.
Digging into the log mentioned reveals something like:
[ERROR] [7/1/2011 4:17:20 PM]: The feature with Id d67567a3-4946-412f-9428-1ca6061a5189 is referenced in the database [WSS_Content], but is not installed on the current farm. The missing feature may cause upgrade to fail.
(A very helpful and surprisingly accurate message)
The problem as you can see is a missing feature, however using the standard PowerShell get-SPFeature commands don’t reveal anything. This is due to the solution already being uninstalled (or perhaps never installed in the case of a migrated database). Fortunately there is a solution:
Thanks Phil, using the provided scripts I was quickly able to identify and remove the offending feature. Once done a rerun of the PSCONFIG wizard (in my case using the command line “PSCONFIG –cmd upgrade –inplace b2b”) completes without errors.
Hope that helps someone else out there.
by Martin Laukkanen | Jun 3, 2011 | How to, Project 2010, SharePoint 2010
A common requirement for many SharePoint and Project Server deployments is to have an external facing interface using an alternate Forms based authentication method, the most common is using an ASP.NET SQL provider which since the 2007 version is the one of the simplest options. With 2010 however and Claims authentication this requires that you convert your existing Windows authenticated Web Applications to Claims based NTLM authentication, this process is well documented online for SharePoint 2010, however I have recently found that with Project Server 2010 a number of problems can be encountered.
Here is a typical error with the Project Details webpart after conversion:
[Hi Google: (An unknown error has occurred)]
In this blog I’m not going to cover the whole process of setting up Extranet access, I’ll leave it to you to read some of the other excellent blogs on the topic linked below. What I will cover is how to do the not-so-well documented parts.
To Start With: Procedure to Setup Extranet Access
The general procedure for extending a Project Server application for extranet users is something like this:
- Provision a ASP.NET SQL membership Provider.
- Extend the Web Application to add an Extranet zone.
- Configure the Claims membership providers in the web.config files.
References for these steps:
- MMohanty: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
- Geoff Varosky: http://gvaro.wordpress.com/2011/03/28/planning-and-configuring-extranets-in-sharepoint-2010part-1/
- Geoff Varosky: http://gvaro.wordpress.com/2011/04/01/planning-and-configuring-extranets-in-sharepoint-2010part-2/
If you have followed those steps discussed in the links, then when you will likely have found that you are seeing all sorts of security issues after changing your Classic Web App to Claims.
In short the error above originates from the procedure used to migrate the application to Claims:
(WARNING: Don’t use the above commands!)
Unfortunately this does not fully migrate the SharePoint application and from my experience will lead to errors such as the first one above.
Migrating the Web Application to Claims Without Issues
Fortunately Microsoft has a well documented procedure: http://technet.microsoft.com/en-us/library/gg251985.aspx
$WebAppName = "http:// yourWebAppUrl"
$account = "yourDomainyourUser"
$wa = get-SPWebApplication $WebAppName
Set-SPwebApplication $wa -AuthenticationProvider `
(New-SPAuthenticationProvider) -Zone Default
Note: that the above commands migrate ALL Web Applications sharing that URL, it is not possible to only migrate your Extended application!
That command will migrate the web application fully and prepare it for Claims authentication, and don’t forget the TechNet article discusses the need to update your portalsuperreaderaccount and portalsuperuseraccount accounts if they have been set, which can be done easily using the following commands:
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domainapppool"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|domainapppool"
$wa.Update()
Migrating Users to Re-enable Login
Once your Web App is in Claims mode then you will still need to migrate your AD users, this part is not so well documented.
Essentially you need to use the PowerShell command Move-SPUser to move all of your existing “DOMAINusername” users to the new Claims-NTLM identity “i0#.w|domainusername”.
Before you can do this you need to ensure that your admin user has permissions to access this site, this can be done from Central Admin by updating the Web Application Policy:
Add or re-add your user account (DOMAINadminuser) with Full Control to the web application in question, before proceeding with the following steps. (Note: the above Policy should now show your Admin user with the User Name like so; “i:0#.w|domainadminuser”)
Next, here is the command to migrate a single user:
Get-SPUser -web http://server/pwa -identity "DOMAINuser" | Move-SPUser -NewAlias "i:0#.w|domainuser" –IgnoreSID
The command will actually give the following error:
However if you then use Get-SPUser you will note that the account has actually been migrated.
So for my purposes I wrote the following script which will migrate all users without the claims prefix “i:0#.w|” (Yep ignore those errors!):
$UsersToMigrate = Get-SPUser -web http://server/pwa | `
where {$_.UserLogin –like ‘DOMAIN*’ }
ForEach ($user in $UsersToMigrate)
{
Get-SPUser -web http://server/pwa -identity $user | Move-SPUser `
-NewAlias ("i:0#.w|"+$user.UserLogin.toLower()) -IgnoreSID
}
After running the above, users should now be able to login to your migrated Web Application with any AD user!
If you see other errors running either that script or the above command by itself, make certain that you can do the following without errors:
Get-SPUser –web http://server/pwa
If not check your web policy again as above.
Finally Adding Your Claims Users to PWA
Now we have a fully migrated Claims-NTLM Web Application in addition to a newly created Extranet Claims Web Application which is attempting to use a Forms membership provider (SQL-MembershipProvider if you following the steps linked above).
The next steps are again well documented in the links above, configure your web.config files and then setup your SQL users.
The final problem you may face when attempting to add your new forms users to PWA, assuming (if using SQL that your ASPNETDB database permissions are correctly set) then adding the users to SharePoint will be easy using Site Actions – Site Permissions – Grant Permission, however what you will may see when attempting to add to Users to PWA is an error like the following:
(Error Message: The NT account specified is invalid. …)
This is because the user has not yet been added to the SharePoint site collection which fortunately is easy enough to fix, just add the user to SharePoint from Site Permissions first!
From Site Actions –> Site Permissions:
As long as SharePoint can find the user (make sure to use the full username!) then once you hit Ok the user identity will be added to the Site Collection, and then you will be able to add the user to PWA!
FYI if like me you like doing things in bulk here’s the PowerShell command to do the above:
New-SPUser -UserAlias "i:0#.f|SQLMembershipProvider|JaneDoe" -Web http://server/pwa -DisplayName "Jane Doe" -Email [email protected]
All done, enjoy your forms membership provider!
by Martin Laukkanen | Feb 23, 2010 | Development, SharePoint 2010
While diving deeper into the SharePoint 2010 PowerShell command-lets I realised that my last blog using a borrowed script based on 2007 was in need of a major update for 2010, so see here a version doing the same thing but with no use of STSADM (and thus no need to run as admin in 2008).
Warmup2.ps1
############################################################################
#WarmUp2.ps1 - Enumerates all web sites in web applications in a 2010
# SharePoint farm and opens each in a browser.
#Notes:
#-"get-webpage" function borrowed from:
# http://kirkhofer.wordpress.com/2008/10/18/sharepoint-warm-up-script/
#
#Assumptions:
#-Running on machine with WSS/MOSS 2010 installed
############################################################################
Add-PsSnapin Microsoft.SharePoint.PowerShell
$extrasitelistfile = 'c:ToolsWarmupwarmup-extrasites.txt'
function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
$wc = new-object net.webclient
if($cred -eq $null)
{
$cred = [System.Net.CredentialCache]::DefaultCredentials;
}
$wc.credentials = $cred;
return $wc.DownloadString($url);
}
#This passes in the default credentials needed. If you need specific
#stuff you can use something else to elevate basically the permissions.
#Or run this task as a user that has a Policy above all the Web
#Applications with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential("username","password","machinename")
$apps = get-spwebapplication -includecentraladministration
foreach ($app in $apps) {
$sites = get-spsite -webapplication $app.url
foreach ($site in $sites) {
write-host $site.Url;
$html=get-webpage -url $site.Url -cred $cred;
}
}
# Warm up other sites specified in warmup-extrasites.txt file (such as SSRS)
if (test-path $extrasitelistfile) {
$extrasites = get-content $extrasitelistfile
foreach ($site in $extrasites) {
write-host $site;
$html=get-webpage -url $site -cred $cred;
}
}
The script still retrieves a list of all sites in all web applications in the farm (including Central Admin) and additionally retrives a list of sites in a text file by default located in “C:ToolsWarmupwarmup-extrasites.txt”
Warmup-extrasites.txt
http://servername/ReportServer
Enjoy!
