Config Wizard Problem Installing Cumulative Update

This is actually why I started blogging.

Ran across this issue deploying the Feb 2012 CU update for a SharePoint 2010 customer;

[OWSTIMER] [SPUpgradeSession] [ERROR] [6/12/2013 2:46:34 PM]: Exception: Cannot drop the procedure ‘MSP_WEB_SR_DeleteUserData’, because it does not exist or you do not have permission.
Cannot drop the procedure ‘MSP_SECURITY_CREATE_PROJECT_OWNER’, because it does not exist or you do not have permission.
Cannot drop the procedure ‘MSP_DELETE_PROJECT_LOOKUP_TABLES’, because it does not exist or you do not have permission.

… (continues for a few hundred other lines)

 

Unfortunately a quick Google search came up with only the following; http://dzeee.net/sharepoint/post/2011/03/23/MOSS-2007-Feb-CU-2011-Installation-issues.aspx

Unfortunate because the proposed solution is to disable and recreate the specified service applications (Search in their case), now as I didn’t want to have to practically reinstall SharePoint this wasn’t going to happen.

 

Better Solution

Fortunately the the source above was onto something, the solution was simply to stop all related SharePoint Windows Services (not SharePoint services), so in my case stop:

  • Project Events Service
  • Project Queue Service
  • SharePoint Administration
  • SharePoint Timer
  • SharePoint Tracing
  • SharePoint User Code Host
  • SharePoint Server Search

Then run PSCONFIG from the command line:

psconfig.exe -cmd upgrade -inplace b2b -wait –force

 

PSConfig automatically starts any needed services, then at the end restarts the others with only the exception of the Project services which I had to start manually.

Manually removing a missing feature after Config Wizard error after SP1 install

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.

Extending Project Server 2010 for Extranet Users

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:

image

[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:

  1. Provision a ASP.NET SQL membership Provider.
  2. Extend the Web Application to add an Extranet zone.
  3. Configure the Claims membership providers in the web.config files.

References for these steps:

  1. MMohanty: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
  2. Geoff Varosky: http://gvaro.wordpress.com/2011/03/28/planning-and-configuring-extranets-in-sharepoint-2010part-1/
  3. 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:

image

(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:

image

 

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:

image

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:

image

(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:

image

image

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 jane@blah.com

 

All done, enjoy your forms membership provider!

Service Pack 1 Announced for Project and SharePoint 2010

The end of June is the date announced for the release of SP1 for Project, Project Server and SharePoint 2010, one new feature (or ‘fix’) that is very exciting is:

  • Multi-Browser Support for time entry in Project Web App – Post on 5/17
    • With SP1, Project Web App pages needed by team members to submit task status and timesheets are supported on FireFox, Safari, and Chrome.

Finally some support (albeit limited) for non-IE browsers!

Read more about SP1, here (Official Project Blog) and here (Office Sustained Engineering Blog).

Update 16/07:

Here’s a screenshot using Chrome:

 

Resetting Lost Permissions in Project Server 2010

I came across an unexplained issue recently with an ‘old’ Project Server 2010 customer, in short what happened was many of the permissions across the Project workspace sites were lost. Unfortunately the loss was triggered by performing a Playbooks (2010 version) backup of the server configuration which was even more concerning, considering that is such a commonly used tool.

In short we needed a way to restore all of the workspace site permissions to what they should be, without having to manually action each site.

 

Some background:

As it turns out Project Server 2010 has (once again) drastically changed the way that workspace site permissions are managed, fortunately changed for the better as now the behaviour is something like this:

  1. On first publish or creation of the workspace all appropriate users are granted permissions based on their group memberships and if they are a member of the project team. (Just as it previously worked)
  2. Subsequent publish jobs trigger another ‘Workspace Create’ job which now only adds new permissions but does not remove any existing ones, such as when a new team member is added to the plan. (This is similar to 2007 SP2)
  3. Active Directory Sync jobs trigger a permissions sync which acts just like #2.

The big differences are the following:

  1. During the sync NO permissions are removed. Thus correcting the old situation where an AD sync during business hours could result temporary permission losses.
  2. Manually changed permissions at the SharePoint level are respected. For instance if you remove a particular user from a SharePoint site, Project Server will not add it back in either of the standard permissions sync jobs above.

 

The Solution: To Restore All Permissions

As you may have found for yourself due to the new behaviour if a user is deleted from the SharePoint site, re-publishing a project will no longer fix the permissions. As such a new solution was needed in my case where permissions were lost across all sites:

  1. Create a new Project Server group containing all users.
  2. Assign My Organisation Category to that group.
  3. Assign Permission ‘View Project Site’ to My Organisation category.
  4. Save the new group (and wait for queue jobs to complete).
  5. Once confirmed permissions working delete the group (and again wait for the queue).

This will force a full refresh of the workspace site permissions across all users and all sites. Due the the new method of handling permissions it will only add each user with a minimum of ‘Reader’ unless they have another group which applies like Project Manager or Administrator, once you complete step 5 those unnecessary Readers will be removed, leaving only the correct permissions.

 

HTH,

Excel Services in a Multi-tenanted Environment

Following on from my previous post about Project Server and PerformancePoint in a multi-tenanted environment, realised that I had not told the whole story!

I neglected to include this when I wrote the above, Excel Services is another critical part of Project Server (more so than PerformancePoint really), and although it does have some support for Multi-tenancy it is far from perfect.

In short, when you configure Excel Services (no partitioning options are available) it does appear to honour subscriptions in the configuration, ie you can use a tenanted Secure Store to create Excel Services Application IDs, however the catch is that it will only talk to the Secure Store in the Default proxy group!

This presents a problem, as you read above PerformancePoint also only talks to the Default Secure Store, however unlike Excel Services PerformancePoint can not talk to a tenanted Secure Store app in the default group so you are left with a catch 22. Either both Excel Services and PerformancePoint can work together using a NON-tenanted default secure store, or one or the other cannot be installed!

*sigh*

If this stuff were simple we wouldn’t be here would we?