STSADM MigrateUser and Move-SPUser Quirks

It's common for SharePoint administrators to get a request to update someone's name in SharePoint as a result of marriage.  The trusty STSADM migrateuser command has been around since MOSS 2007 as a method to update references from the old account to the new account.

In my experience, AD admins tend to rename existing accounts as opposed to creating new accounts and decommissioning old ones.  Once the account has been renamed, migrateuser can be used in the following fashion to update the SharePoint profile data:

stsadm.exe -o migrateuser -oldlogin domain\originaluserlogin -newlogin domain\newuserlogin

Sometimes this command will return a message "New user account does not have valid SID history.". If this is the case, you can add the -ignoresidhistory argument and cross your fingers that you get a response "Operation completed successfully."

If you do not get a successful message, you may instead see this:
Value cannot be null.
Parameter name: userProfileApplicationProxy

Many search results will point you towards verifying that you are a farm administrator, and of course you are in the farm administrator group, so you brush this off and move on.  Some results point towards a promising PowerShell command Move-SPUser:
Move-SPUser -Identity domain\originaluserlogin -NewAlias domain\newuserlogin

Unfortunately for me I recieved the error:
The parameterless Read method can only be used when this instance was initialized with an SPUser object.

Using Get-SPUser to store the user login in a $user variable to be passed into Move-SPUser returned yet another error:
You must specify a valid user object or user identity.

So the old user doesn't exist in the web anymore, yet when I view the user profile for the user in the User Profile Service in Central Administration, the old login name is still displayed next to all the updated profile information.  Somewhere the old login is still hanging around, so back to migrateuser!

The solution for me was indeed related to the account used to run the migrateuser command. Evidently being a farm administrator is not enough, you need to use the FARM Account.  To find out exactly what this account is, open up Central Administration and click on configure service accounts under the Security heading.

Select Farm Account from the drop down box, and the page will refresh and list an account name in the bottom drop down box.  This is the account you need to log in to the SharePoint server.  I tried using the Run As Another User command on the SharePoint Management Shell and that did not work, you will get a message Access Denied when you do that.  When you login to the server, right click SharePoint Management Shell and choose Run as Administrator.

Hopefully this time you will breathe a huge sigh of relief as you see the coveted Operation completed successfully message.

A quick way to bring down SharePoint 2010

Yesterday I was working through the steps to configure incoming email for my SharePoint 2010 farm.  After some testing, internal mail sent to SharePoint was being dropped into the correct document libraries, as intended.

But somewhere along the way, when configuring the SMTP service on the SharePoint machine to pick up files from the drop folder, I had hit a snag trying to change the SMTP domain from the default <servername> (which was not user friendly) to a more friendly @spmail.company.com.  The emails were being received in the default drop folder in the /mailroot and not in the custom drop folder I had configured on a data volume.

While experimenting with different solutions I had the (un)brilliant idea to add another http binding to the SharePoint Web Services IIS site for the host header spmail.company.com.  I must have been low on coffee at the time because I don't recall even making this change.  This apparently was a ticking timebomb because although SharePoint appeared to work just fine the rest of the day, I was greeted the next morning (no doubt after some nightly timer job bombed) by a nice correlation error on the SharePoint home page. Digging through log files on our WFE and App servers I found a myriad of errors:

WFE log:
system.nullreferenceexception: Object reference not set to an instance of an object.    at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties()

App log:
Request for security token failed with exception: System.ServiceModel.ServiceActivationException: The requested service, 'http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc/actas' could not be activated.

Viewing User Profile Service Application in Central Admin:
This User Profile Application's connection is currently not available. The Application Pool or User Profile Service may not have been started.

Now having had NUMEROUS issues with User Profile Service App in the past, my default is always to run IISRESET on the App and WFE machines. This time I refreshed my homepage and discovered the magic bullet didn't work this time.

Troubleshooting the User Service profile app led me down the same paths as many others, checking to make sure the farm account had to proper credentials to run the timer service, FIM services, and the app pool.  Everything checked out, except the profile synchronization service was hung at 'starting'.

I turned my attention to the STS app.  App pool checked out, IIS site checked out.  Then someone suggested opening the STS web service url on the App server to look for clues.  I was presented with this very helpful message:

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Checking the bindings for SharePoint Web Services site revealed the culprit. I removed the binding and checked SharePoint again and voila, immediately sites were working again.  I returned to Central Admin and the User Profile Synchronization service was no longer stuck at Starting and was not Started.

Lesson learned, don't tinker with SharePoint if your coffee level is running low, there is no telling what will happen during your caffeine blackout!

SharePoint 2010 - Sign in as a different user causes immediate 401 UNAUTHORIZED

While working among half a dozen SharePoint 2010 sites one day, spread through Internet Explorer 9 tabs, I was testing some security trimming on some new groups for a particular site. When I tried to sign in as another user, I was immediately given a blank white page that simply said 401 UNAUTHORIZED.

The only related information I could find on the web was a post referring to the error but without a suitable solution: http://www.3guysonsharepoint.com/?p=979

I fired up a session of Chrome and tried the same thing. The Login prompt was displayed and everything worked just fine. I returned to IE9 and tried to sign in as a different user on the other tabs I had open. All returned the 401 UNAUTHORIZED error.

I closed down all instances of IE9, cleared my cache, and fired it back up. This time all the sign in operations worked as expected. I'm not exactly sure which part of the IE session got out of whack, but starting fresh seemed to clear things up. Hopefully it's not a problem that will resurface.

Error with upgraded publishing site

Today I tried creating a new Welcome page on a site that has the publishing feature activated. The site was upgraded from 2007 to 2010 long ago with no hiccups. Suddenly just trying to create a new page threw a runtime error that required digging through the SharePoint Log with a correlation ID to find:

The site is not valid. The 'Pages' document library is missing.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: Microsoft.SharePoint.Publishing.InvalidPublishingWebException: The site is not valid. The 'Pages' document library is missing.

The Pages library is certainly on the site. Deactivating and re-activating the publishing features from the site collection and site features lists didn't seem to have any impact on the error. SharePoint engineer to the rescue: Stefan Goßner has your fix!

http://blogs.technet.com/b/stefan_gossner/archive/2011/09/15/common-error-the-site-is-not-valid-the-pages-document-library-is-missing-error.aspx

Digging into ReportServer Database

I was looking for some information about my ReportServer database and ran across a great script by Scott Hebert that displays a lot of useful information:

http://sqlninja.blogspot.com/2009/01/querying-reportserver-database.html

USE ReportServer

SELECT
         CatalogParent.Name ParentName,
         Catalog.Name ReportName,
         ReportCreatedByUsers.UserName ReportCreatedByUserName,
         Catalog.CreationDate ReportCreationDate,
         ReportModifiedByUsers.UserName ReportModifiedByUserName,
         Catalog.ModifiedDate ReportModifiedDate,
         CountExecution.CountStart TotalExecutions,
         ExecutionLog.InstanceName LastExecutedInstanceName,
         ExecutionLog.UserName LastExecutedUserName,
         ExecutionLog.Format LastExecutedFormat,
         ExecutionLog.TimeStart LastExecutedTimeStart,
         ExecutionLog.TimeEnd LastExecutedTimeEnd,
         ExecutionLog.TimeDataRetrieval LastExecutedTimeDataRetrieval,
         ExecutionLog.TimeProcessing LastExecutedTimeProcessing,
         ExecutionLog.TimeRendering LastExecutedTimeRendering,
         ExecutionLog.Status LastExecutedStatus,
         ExecutionLog.ByteCount LastExecutedByteCount,
         ExecutionLog.[RowCount] LastExecutedRowCount,
         SubscriptionOwner.UserName SubscriptionOwnerUserName,
         SubscriptionModifiedByUsers.UserName SubscriptionModifiedByUserName,
         Subscriptions.ModifiedDate SubscriptionModifiedDate,
         Subscriptions.Description SubscriptionDescription,
         Subscriptions.LastStatus SubscriptionLastStatus,
         Subscriptions.LastRunTime SubscriptionLastRunTime
   FROM
         dbo.Catalog
         JOIN         dbo.Catalog CatalogParent
         ON Catalog.ParentID = CatalogParent.ItemID
         JOIN
         dbo.Users ReportCreatedByUsers
         ON Catalog.CreatedByID = ReportCreatedByUsers.UserID
         JOIN         dbo.Users ReportModifiedByUsers
         ON Catalog.ModifiedByID = ReportModifiedByUsers.UserID
         LEFT JOIN
   (
   SELECT
            ReportID,
            MAX(TimeStart) LastTimeStart
      FROM
            dbo.ExecutionLog
      GROUP BY
            ReportID
   ) LatestExecution
         ON Catalog.ItemID = LatestExecution.ReportID
         LEFT JOIN   (
   SELECT
            ReportID,
            COUNT(TimeStart) CountStart
      FROM
            dbo.ExecutionLog
      GROUP BY
            ReportID
   ) CountExecution
         ON Catalog.ItemID = CountExecution.ReportID
         LEFT JOIN         dbo.ExecutionLog
         ON LatestExecution.ReportID = ExecutionLog.ReportID
      AND LatestExecution.LastTimeStart = ExecutionLog.TimeStart
         LEFT JOIN         dbo.Subscriptions
         ON Catalog.ItemID = Subscriptions.Report_OID
         LEFT JOIN         dbo.Users SubscriptionOwner
         ON Subscriptions.OwnerID = SubscriptionOwner.UserID
         LEFT JOIN         dbo.Users SubscriptionModifiedByUsers
         ON Subscriptions.ModifiedByID = SubscriptionModifiedByUsers.UserID
   ORDER BY
         CatalogParent.Name,
         Catalog.Name

Clean up your SharePoint Features

If you noticed my previous two posts, you'll see that I've run across some feature upgrade issues when moving from SharePoint 2007 to 2010, and then again when applying service pack 1 to SharePoint 2010.

Today I ran across a really nice tool to help remove references to the missing features that may cause issues during your upgrades: http://featureadmin.codeplex.com/

This tool is extremely fast, easy to use, and effective at removing missing/faulty features from SharePoint farms, web applications, site collections, and sites.

SharePoint SP1 aftereffects

If you are running the Enterprise version of SharePoint 2010, you may notice something missing after the upgrade to Service Pack 1.

The Customize Form button may be missing from the List Ribbon's Customize List section.  This button is only available in the Enterprise version of SharePoint and not in Foundation.

To get your button back, navigate to the Top Level Site Settings. Choose Site Collection Features and scroll down to find SharePoint Server Enterprise Site Collection features.  This feature enables InfoPath Forms Services which will enable the Customize Form button.

If you aren't at the Top Level Site Settings and instead find yourself at the Manage Site Features page for your site,  you will see a very similar feature named SharePoint Server Enterprise Site features, but this will not affect the Customize Form button.