Migrating SharePoint to a new domain--do it the right way

David W - MSFT — Mon, 23 Jul 2018 13:51:53 GMT

I recently worked a case where the customer was having issues with getting the Distributed Cache running. When attempting to run a Register-CacheHost commandlet, they would get the following error: "The requested name is valid but no data of the requested type was found." To investigate further, we ultimately queried the Config database to check settings for the CacheConfigCluster:

SELECT * FROM dbo.CacheClusterConfig WHERE EntryType = 'hosts'

When we did this, we could see that servers with different domains than the current domain name were listed. It turns out the customer had attempted to migrate an existing farm to a new domain by changing account settings in SharePoint and SQL. While you might be able to get away with this for a single-server development environment (there are many blogs out there detailing how to do this), attempting to do this with a production and/or multi-server server farm is a very bad idea, and is in fact unsupported. Simply "moving" a SharePoint farm from one domain to another is actually not possible. SharePoint hard-codes server and account names, including domains, in the Configuration database. This is done in multiple tables. There is no way to modify these settings in a supported manner. Fundamentally, you must create a new farm in the target domain and move the existing content. At a high level, this involves the following steps:

Disconnect and rejoin servers to a new farm with new config database
Create new Service Applications using existing DBs when possible
Create new web applications
Deploy all the custom solutions and custom configuration
Mount the databases to respected web applications
Migrate the users from old domain to new domain

Setting Up a My Site Host On a Non-Root Site Collection

David W - MSFT — Wed, 11 Apr 2018 13:03:38 GMT

There are a number of reasons you may need to set up My Sites under an existing web application, rather than its own standalone web application. However, most of SharePoint's public documentation assumes your My Site Host will be on its own web app. It's completely supported to have the My Site Host under a different web application, but there are a few gotchas that can confuse or frustrate an admin when setting this up for the first time. Is this article, I'll go over the steps for configuring My Sites beneath the Site Collection of an existing web application. In this article I'll be setting up a My Site Host on a farm as follows: URL of web application: spsa2013 URL of My Site Host: spsa2013/sites/MySites URL for each user's My Site: spsa2013/sites/MySites/personal/username We'll assume that a site has already been set up on spsa2013. It is a requirement that all web applications have a root site.

Creating the My Site Host

You'll create the My Site Host in the standard way via Central Admin -> Application Management -> Create Site Collections In my example, you can see that I picked the spsa2013 Web Application, chose /sites/MySites for the URL, and selected the My Site Host template. You'll also need to choose a Primary Site Collection Administrator, then click OK.

Setting up Managed Paths

On the Web Application hosting the My Sites, we'll need to set up one new Explicit path for the My Site Host and one new Wildcard path for the individual My Sites to be placed under. It is critical that this is set up correctly. This is accomplished from Central Admin -> Manage Web Applications -> Managed Paths: The distinction here is that the My Site Host path (sites/mysites) has an explicit inclusion (since there is a site collection located at this URL) and the Personal path gets a wildcard inclusion (since there are site collections under this URL but no site at the sites/mysites/personal URL itself).

Setting up Self-Service Site Creation

This is handled from Central Admin -> Manage Web Applications -> Self-Service Site Creation: On this screen you need only to set Site Collections to On. You don't need to be concerned about the URL that is displayed, this is not used when My Sites are created. Additionally, if you have set up Quotas, you can select a quota to be used for My Sites at this time.

Configuring The My Site settings in the User Profile Service Application

The final step is accomplished via the User Profile Service Application, Central Admin -> Manage Service Applications -> User Profile Service Application. Then select Setup My Sites from the My Site Settings section on the bottom of the screen. Important items to note:

While the text box is not large enough to display the entire URL, note that the My Site Host location is set to the full My Site Host path we set up previously: spsa2013/sites/MySites/
In the Location field, you must include the full path specified when you created the wildcard Managed Paths, in this case sites/MySites/Personal. If you only put Personal in the field, SharePoint will attempt to create the My Sites at spsa2013/personal, and My Site creation will fail.

If you had previously entered invalid values or are changing the My Site location, you may need to restart the SharePoint Timer Service, as well as the User Profile Service Application app pool, for the changes to take effect. You should also exit and reopen your browser as the My Site URL can be cached.

Errors to look for

If the Managed Paths or Personal Site Location are not set up correctly, you may end up seeing something like the following in the Event Viewer logs. Note the incorrect URL path in the String1 parameter of the first message: - <Event xmlns="schemas.microsoft.com/win/2004/08/events/event">

- <System>

<EventID>5187EventID>

<Version>16Version>

<Level>2Level>

<Opcode>0Opcode>

<Keywords>0x4000000000000000Keywords>

<EventRecordID>358614EventRecordID>

<Channel>ApplicationChannel>

<Computer>spsa2013.contoso.comComputer>

System>

- <EventData>

<Data Name="string0">CONTOSO\AdministratorData>

<Data Name="string1">spsa2013/personal/administratorData>

<Data Name="string2">Microsoft.Office.Server.UserProfiles.PersonalSiteCreateConfigurationException: A failure was encountered while attempting to create the site, wildcard inclusion used to create personal sites does not exist. at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.<>c__DisplayClass2c.b__28() at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.CreateSite(String strSiteRelative, String strSiteFullUrl, Int32 overrideCompatLevel, Int32 lcid, SPContentDatabase contentDatabase)Data>

EventData>

Event>

- <System>

<EventID>8100EventID>

<Version>16Version>

<Level>2Level>

<Opcode>0Opcode>

<Keywords>0x4000000000000000Keywords>

<EventRecordID>358615EventRecordID>

<Channel>ApplicationChannel>

<Computer>spsa2013.contoso.comComputer>

System>

- <EventData>

<Data Name="string0">CONTOSO\AdministratorData>

<Data Name="string4">Microsoft.Office.Server.UserProfiles.PersonalSiteCreateConfigurationException: A failure was encountered while attempting to create the site, wildcard inclusion used to create personal sites does not exist. at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.<>c__DisplayClass2c.b__28() at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.CreateSite(String strSiteRelative, String strSiteFullUrl, Int32 overrideCompatLevel, Int32 lcid, SPContentDatabase contentDatabase) at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.CreatePersonalSiteWithSQM(SPSite mySiteHost, String mySitePortalUrl, Int32 overrideCompatLevel, Int32 lcid, SPContentDatabase contentDatabase) at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.<>c__DisplayClass23.b__1f() at Microsoft.Office.Server.UserProfiles.Helpers.RunWithUserProfileIdAsCorrelation(Guid userProfileId, CodeToRunWithCorrelation delegateToRunWithCorrelation) at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.CreateMySite(Int32 lcid, SPContentDatabase contentDatabase) at Microsoft.Office.Server.UserProfiles.SiteInstantiationWorkItemJobDefinition.ProcessWorkItemCoreInternal(SiteProvisioningTimerJobContext jobParameters, DateTime timeNow, UserProfile userprofile) at Microsoft.Office.Server.UserProfiles.Helpers.RunWithUserProfileIdAsCorrelation(Guid userProfileId, CodeToRunWithCorrelation delegateToRunWithCorrelation) at Microsoft.Office.Server.UserProfiles.SiteInstantiationWorkItemJobDefinition.ProcessWorkItemCore(SiteProvisioningTimerJobContext jobParameters) at Microsoft.Office.Server.UserProfiles.SiteInstantiationWorkItemJobDefinition.ProcessWorkItem(SiteProvisioningTimerJobContext timerJobCtx)Data>

EventData>

Event>

Don't filter out your Farm and Object Cache accounts in SharePoint's People Picker

David W - MSFT — Mon, 02 Apr 2018 15:20:16 GMT

I often have SharePoint cases where customers don't want their Object Cache accounts or Farm account to show up in the People Picker in SharePoint. While there are a variety of reasons people choose to do this, filtering these accounts out of People Picker is a bad idea. Internally, SharePoint code uses the People Picker code path for other account resolution purposes. Accounts that are filtered from People Picker won't be found by SharePoint's internal code in these instances. The most common place I've run into this issue is with SharePoint 2016's Fast Site Collection Creation code. By default, SharePoint 2016 uses Fast Site Collection Creation to speed up the My Site creation process (see here for more details). If the Farm Account cannot be found by the People Picker code, you will see a message like the following in the ULS logs:

Error in resolving user. User: 'contoso\farmaccount', ResolverInformation: 'SPActiveDirectoryPrincipalResolver, DomainName: 'contoso.com', DomainIsForest: 'False', DomainLoginName: '', CustomSearchQuery: '', CustomSearchFilter: '(&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(employeeID=*)(employeeNumber=*))(|(extensionAttribute12=*)(mail=*)(proxyAddresses=*)))', Timeout: '00:00:30', IncludeDistributionList: 'True''

If the Object Cache accounts (Portal Super User and Portal Super Reader) are filtered from the People Picker, you may experience seemingly random permissions issues with a message similar to the following in the ULS:

User Key aysye Unexpected User key value from token is not a user key so throwing. UserKey: 'i:0#.w|contoso\superreader'

The solution is to allow the accounts to be resolved in the People Picker. The following PowerShell commands may be used to check the current People Picker settings. You'll want to check the ActiveDirectoryCustomQuery and ActiveDirectoryCustomFilter properties:

$wa = Get-SPWebApplication $wa.PeoplePickerSettings

Object Cache accounts may be queried as follows:

$wa = Get-SPWebApplication $wa.Properties["portalsuperuseraccount"] $wa.Properties["portalsuperreaderaccount"]

David’s SharePoint Blog