C:\Users\<userprofile>\AppData\Local\Packages\CmModernAppv.01_6c1zs6whsayrc\LocalState

Obviously, looking around the web...I didn't find any solid resolution right off the bat.

Here's how I resolved my particular issue:

1. The logs from the config manager setup program had the following which ended up not being very useful:

• Failed to create machine certificate on server MySQLServer
• Failed to create SQL server certificate on server
• Failed to create SQL server certificate remotely

2. On the SQL server, I found folders under the root of the C drive created by config manager with an SMS prefix

3. These folders contained a srvboot.log file that was more helpful. It contained the following errors:

• Failed to grant access to user (MySQLServer account)
• Failed to grant permission to certificate.
• Failed to create machine self-signed certificate.

4. I look at the SQL servers certificate store (for the computer) and noticed there was a config manager cert. It had my sql server service acct listed under All Tasks/Manage Private keys. Deleting and removing the cert didn't fix the issue.

5. Next, I ran procmon on the sql server. Filtered on srvboot.exe and noticed that I got access denieds on a certain file in the c:\programdata\microsoft\crypto\rsa\machinekeys folder. Looking at the permissions, my sqlserver service account had Full control rights.

6. Hmm...so what gives.

7. My next step was to remove the particular file in the machinekeys folder AND the certificate that was created in the computer's certificate store and mysteriously the issue resolved itself.

8. Key learnings: Look at the logs (srvboot.log) on the sql server and see what procmon tells you.

Good luck.

Open the path shown in CachePath key in Windows Explorer and do a search for *.xml

Inspect the xml files and you'll see names of people you've resolved or searched for in the people picker

Delete the files as necessary.

Alternatively, if you want to disable the cache, in IE settings, go to the Advanced tab and uncheck the checkbox called "Enable DOM Storage".

Close and restart IE for good measure.

We had some unique requirements and I couldn't really find any good guidance for doing domain migrations while ensuring that SharePoint isn't ensuring that mySites don't get deleted....hence this post.

The SharePoint environment was not a vanilla install. Here were some of the customizations (if you want to call them that):

• It was configured to use ADFS SAML claims for authentication;
• It had a custom claims provider that drove the people picker. The claims provider picked claims from the UPA;
• A BDC connector augmented profiles in the UPA with data from the customer's Peoplesoft repository.

As part of the domain migration, we had some unique requirements to deal with. One example was that the source accounts needed to remain enabled as all the applications had not been updated to work with the new domain.

This presented a unique challenge in that, migrated users could log in as their old IDs (and you know they will) and cause new SharePoint profiles to be created. They would also quickly find out they couldn't access sites using that old ID, which would lead to helpdesk calls etc. Just messy, messy, messy.

So here's how we did it. I'll explain the rationale behind each step where necessary. Feel free to pick and choose to suit your environment.

Steps to perform before the migration starts:

1. If you have your QA or Dev SharePoint farms populated with user profile data similar to Production, disable outbound email flow in those QA or Dev SharePoint farms.

• You typically won't care about any mysites in those environment, disabling email will prevent managers from getting mySite deletion notifications.

2. Before the AD migrations start, create a new sync connection in SharePoint for the new domain. The new domain shouldn't have any users yet. So nothing to worry about yet.

3. Check what time the UPA runs incremental sync every night and also when the MySite deletion timer job runs. Both usually start at 1am.

• This is important because you'll want to make sure these next few steps happen (and finish) before 1am. Alternatively, you may choose to disable these processes.

4. Modify the AD sync connections through FIM to prevent duplicated groups.

• $TODO

5. Work with your domain migration team to ensure that the processes for migrating a user's account happen before 1am.

6. If the migrated accounts will be re-enabled, have them plan on marking some attribute  (we used msExchExtensionAttribute44) on the old account (ie migratedToNewDomain) so you can filter these accounts out later.

7. If step 6 applies to you, modify the AD MA for the old domain and add a new "Connector Filter" on the User object type that reads msExchExtensionAttribute44 Equals MigratedToNewDomain.

• This step requires you to make the edit in the FIM client. Alternatively, you could do it in Central Admin. Just be sure to reverse the operator...central Admin expresses logic backwards.
• At any rate, the reason for making this change is to cause FIM to filter out the account that has just been migrated.

8. If step 6 applies to you and you use ADFS SAML claims, have your AD migration team also add the old user account to a group in the old domain ie UsersThatHaveBeenMigrated.

• By having the old user accounts added to a group as they are migrated, you can tell ADFS to deny any users that are members of that group from logging into SharePoint.
• This will prevent users from creating new non-synchronized profiles in the UPA and creating cleanup headaches for the SharePoint Admins
• In ADFS, go to each relying party you have for SharePoint. Edit the claim rules and on the Issuance Authorization Rules, add a "Permit or Deny Users Based on an incoming claim" rule
• In the rule, choose "group SID", specify the group from the old domain and select Deny.

6. Ensure that user's don't access SharePoint during the migration. This should be obvious, but it's worth mentioning.

Steps to perform when the migration starts:

1. Have the AD migration team run the following for each migrated user. At this stage, ADMT will typically have disabled the old account and created a new user in the new domain. In our case, we were re-enabling the account to allow them to work with unported applications.

• stsadm -o migrateuser -oldlogin "i:0e.t|your custom claims provider|user@olddomain.net" -newlogin "i:0e.t|your custom claims provider|user@newdomain.com" –ignoresidhistory
• Don't worry that the new account has not been imported into the UPA yet. You don't want it in the UPA yet.
• This command works better than move-spuser because move-spuser requires you to bind to each spweb that a user might have permissions to. Not efficient.
• This command will change the account name on the profile (which still belongs to the old user) in the UPA to the new account name.
• Then it will modify the permissions on each site...essentially mapping the old account to the new account. This is what will allow the users to access content they previously had access to.
• The command should be run as the farm account.
• Run this step to before any UPA sync steps have run. Ignore this at your own peril.
• After running the command, the user's permissions has mapped over to the new account. And the profile in the UPA has a new account name mapped to the new domain BUT the profile is still bound to the old user (the SPS-DistinguishedName still points to the old user account). Again don't worry...keep reading.

2. Next, in the FIM client, manually kick off a delta import and delta sync on the old domain's MA.

• This will detect that the old user account has been disabled OR filtered out (if it was re-enabled)
• It will queue up a delete for the old profile. Sounds scary...but don't panic.

3. Next, in the FIM client, manually kick off a delta import and delta sync on the new domain's MA

• This will detect the new user account in the new domain
• This will queue up an Add of a new user in SharePoint.

4. Next run an Export and delta Import on MOSS MA again through the FIM client.

• This will send a delete to SharePoint for the old user profile.
• This delete will mark the profile in the UPA as deleted. Don't panic
• Then the queued up ADD will re-animate that profile. What enables this to happen is the stsadm migrateuser step which changed the account name on the profile to the new user's account name. When FIM tries to add the new user, it finds an existing profile (that's marked for deletion) and re-animates it.

5. Next, run a delta import and delta sync on any BDC MA, followed by a Export and delta Import on MOSS MA.

• This only applies if you have a BDC MA that brings in data from an HR system 

That pretty much sums it up. At this point, users can be allowed to log in and they should find their profile data still intact and access to their existing sites still intact as well.

Issue we ran into:

1. Links to followed documents may not work.

• We changed UPNs as part of the domain migration...ie we went from using a123456@olddomain.net to joe.blow@newdomain.com.
• As you know, MySites are built using the account name...so Joe's mySite prior to the migration was something like: https://my/personal/a123456
• At some point, the UPA will change the mySite path to https://my/personal/joe.blow
• Now imagine that a user was following a document in Joe's mysite prior to Joe being migrated. In other words, that user is following  https://my/personal/a123456/somedocument.docx
• Well, that reference is not updated when Joe's mySite is refreshed to reflect his new account name.

2. Sitefeed and newsfeed references to user accounts break.

• It appears that newsfeed content stored in the Microfeed lists in mySites and TeamSites have static/absolute references to user accounts. So after the migration, you'll notice that feeds no longer show friendly names but instead show the much uglier claims encoding reference ("i:0e.t|your custom claims provider|user@olddomain.net").
• The only way to fix I know of is to programmatically search for and modify each reference. Not fun at all. We made a business decision to deal with it.

Define an Inbound URL Rewrite rule on the IIS site running the portal that looks like the following:

 That's it. Simple as pie.

Looking around the web, I found several resources such as this (Kudos to the author), that provided a way to reorder the profile properties. However, when I looked closer at the default DisplayOrder for existing properties, I noticed several were duplicated.

I have a feeling the duplicate display order values have something with the inability to move properties around through Central admin.

As such, the following solution allows:

- exporting all the properties and sections out to an XML file

- you the Admin, can then clean up the XML, define the order of properties (ie use this mechanism to move properties up and down)

- importing the cleaned up XML

The script is as follows. Just copy and paste into powershell ISE or save as a .ps1 file.

The script will prompt you to select whether you want to Export or Import....pay attention to the prompts. It should be pretty self explanatory.

#This is the xml template into which properties are exported
$template = " 
<Properties>
<Section  Name="""" Order="""" > 
<Property Name="""" Order="""" />  
</Section>
</Properties>"

#xml template is saved out
$template | out-file $home\output.xml
$xml = New-Object XML
$xml.Load("$home\output.xml")

#IMPORTANT...fill this section out before executing script
$siteUrl = https://URLtoSiteCollection

function exportProfileProperties()
{
    #connect to upa
    $site = Get-SPSite $siteUrl
    $context = Get-SPServiceContext $site    
    $psm = [Microsoft.Office.Server.UserProfiles.ProfileSubtypeManager]::Get($context)
    $col = $psm.GetSubtypesForProfileType("User")

    #load xml template
    $sectionTemplate = @($xml.Properties.Section)[0]
    $propertyTemplate = @($xml.Properties.Section.Property)[0]

    $newSection = ""

    #parse sections and properties and generate xml structure
    foreach($propFromUPA in $col.PropertiesWithSection)
    {
        if($propFromUPA.IsSection -eq $true)
        {
            $newSection = $sectionTemplate.Clone()
            $newSection.Name = $propFromUPA.Name
            $newSection.Order = $propFromUPA.DisplayOrder.ToString()
            $xml.Properties.AppendChild($newSection)
        }
        else
        {
            $newProp = $propertyTemplate.Clone()
            $newProp.Name = $propFromUPA.Name
            $newProp.Order = $propFromUPA.DisplayOrder.ToString()
            $newSection.AppendChild($newProp)
        }   
   
        #cleanup xml
        $newSection.Property | where-object{$_.Name -eq ''} | ForEach-Object {$newSection.RemoveChild($_)}
    }

    #cleanup xml
    $xml.Properties.Section | where-object {$_.Name -eq ''} | ForEach-Object {$xml.Properties.RemoveChild($_)}

    #save xml
    $xml.Save("$home\output2.xml")

    write-host "File has been exported to " + "$home\output2.xml"
    write-host "Edit the file by updating the display order and the location where you want to property to be"
    write-host "Then run this script again to in Import mode"

}

function importProfileProperties($fileLocation)
{
    #load xml
    $inputXML = [XML] (Get-Content $fileLocation)

    #connect to upa
    $site = Get-SPSite $siteUrl
    $context = Get-SPServiceContext $site
    $upcManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileConfigManager($context)
    $defaultUserProfileSubTypeName = [Microsoft.Office.Server.UserProfiles.ProfileSubtypeManager]::GetDefaultProfileName("User") 
    $profileSubtypePropManager = $upcManager.ProfilePropertyManager.GetProfileSubtypeProperties($defaultUserProfileSubTypeName)

    #read entries in xml file
    foreach($section in $inputXML.Properties.childnodes)
    {
        #process sections
        Write-Host $section.Name
        $profileSubtypePropManager.SetDisplayOrderBySectionName($section.Name,$section.Order) 
        #process properties within sections
        foreach($property in $section.childnodes)
        {
            Write-Host $property.Name
            $profileSubtypePropManager.SetDisplayOrderByPropertyName($property.Name,$property.Order) 
        }
       
    }

    #verify user wants to commit
    $commit = Read-Host "Press Y to commit changes or CTRL+C to exit "
    if ($commit.ToLower() -eq 'y')
    {
        $profileSubtypePropManager.CommitDisplayOrder() 
    }

}

$userInput  = Read-Host "Type E to export the current properties OR I to import a config file "

if ($userInput.ToLower() -eq "e")
{
    exportProfileProperties
}
elseif($userInput.ToLower() -eq "i")
{
    $fileLocation = Read-Host "Type in the path to the input file "
    importProfileProperties($fileLocation)
}

I'm sure we've all seen ULS log entries that say something like this:

Leaving Monitored Scope (SomeOperationName). Execution Time = 2.344050348

If not, look at your SP2010 or higher ULS logs and you'll definitely see a bunch of them.

On to the point of this post. If you wanted to quickly identify long running operations directly in ULSViewer, you can use RegEx to quickly filter the timing data.

The steps to do this is as follows:

1. Connect ULSViewer to live server data OR to a set of log files (CTRL+U OR CTRL+O)

2. Select Modify Filter from the Edit menu (CTRL+M)

3. In the Field column, select Message

4. In the Operation column, select Regex Match

5. In the Value column, type or paste in the beginning portion of the text you want to match on, eg if you wanted all slow operations, type in Execution Time=

6. Next plug-in the regex you wish to apply right after the = sign. The entire string in the value column would look something like: Execution Time=[1-9]{1}[0-9]{3}

Super duper quick primer on how to apply regex:

1. First, understand that the timing data is in milliseconds and there are 1000 ms in 1 second. (so a 5 second operation will have timing that is >= 5000)

2. Next, understand what you're interested in chasing after. Are you wanting to see all timings that took longer than 5 seconds/30 seconds etc.

3. Next craft your regex. Let's use an example for illustration.

For requests that took longer than a second, the regex would be: [1-9]{1}[0-9]{3}

Explanation:

The first half of the regex [1-9]{1}, looks for the occurence of the numbers 1 through 9 in the first digit following the = sign

The second half of the regex [0-9]{3}, looks for  the occurence of the numbers 0 through 9 in the next 3 digits

So to identify requests that took longer than 10 seconds, your regex would be: [1-9]{1}[0-9]{4}

The regex for requests that took longer than 30 seconds would be [3-9]{1}[0-9]{4}

At any rate, this little trick lets me identify performance issues such as these:

I had a need recently to create many content organizer rules dynamically via Nintex workflow and I couldn't find a pre-canned method for doing so. I eventually figured a way and wanted to share in case someone else needs this. Even though I created the rules using workflow, the rules could also have been created using powershell.

Scenario:
The scenario that led me down this path was that I was designing a SharePoint 2010 records management solution where documents submitted by users had to be routed to a folder created specifically for that user. In other words, the solution had to flow as follows:

1. User submits document to record library

2. Content organizer timer job runs to route document if a Content Organizer rule exists

3. Periodically, a Nintex site workflow would kick off and check to see if documents were still in the drop off library. If documents were still in the drop off library, the workflow would create a folder for the submitting user and a content organizer rule to route documents that that folder.

So now that we understand the scenario, I'll go ahead and outline how to create the content organizer rules dynamically. The steps below assume that a record center site collection has been created. 

1. Make "content organizer rules" list visible by running the following powershell:

$site = get-spsite https://urlToRecordCenter
$list = $site.rootweb.lists[“content organizer rules”]
$list.hidden = $false
$list.update()

2.      Make Condition XML field visible:

$field = $list.Fields.GetFieldByInternalName(“RoutingConditions”)
$field.hidden = $false
$field.update()

3. Now use workflow to create the content organizer rules dynamically. The Nintex Create Item action was configured as follows.

Note: Some of the values below (eg itemCreator) won’t translate directly to other environment because they were variable names I used in other parts of the workflow. The idea I’m mostly trying to convey is that these are the fields that will need to be set at a minimum to have a functioning content organizer rule.

To figure out what applies to you, I recommend creating a rule through the UI first and then copying the values over to your workflow design surface.

• Field: Title => Rule Name
• Content Type: Rule
• Field: Active => Yes
• Field: Priority => 9
• Field: Target Path => webRelativeURL/Records/DestinationFolderName
• Field: Route to External location => No
• Field: Submission Content Type => Document
• Field: Condition XML => <Conditions><Condition Column="ada5b8d0-79d8-48ae-a68e-6181cde84656|UserName1|UserName" Operator="IsEqual" Value="itemCreator" /></Conditions>
• Field: Target Library => Records Library
• Field: Target Folder => itemCreator
• Field: Properties used in conditions => username
• Field: Rule name => Rule for ItemCreator