SharePoint User Profile Service Application: Exception while trying to migrate account. The user does not exist or is not unique.

A while ago I was facing an issue with NetBIOS names when configuring the SharePoint Server User Profile Service Application. In this particular scenario the NetBIOS name was different from the domainname. For instance NetBIOS namespace would be CON\username and the domainname would be CONTOSO\username. The errors which were thrown on the applicationserver:

The extensible extension returned an unsupported error.
The stack trace is:

“System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.AggregateException: One or more errors occurred. —> Microsoft.Office.Server.UserProfiles.UserProfileException: Exception while trying to migrate account ‘CON\Username’ to ‘CONTOSO\Username’. —> Microsoft.SharePoint.SPException: The user does not exist or is not unique. —> System.Runtime.InteropServices.COMException: The user does not exist or is not unique.<nativehr>0x81020054</nativehr><nativestack></nativestack>
at Microsoft.SharePoint.Library.SPRequestInternalClass.SelectSitesAndUserInfoForMigration (Object& pvarContentDsns, Object& pvarContentIds, String bstrOldLogin, String bstrNewLogin, String bstrFullUserKey, Boolean bEnforceSidHistory, Guid guidSubscriptionId, String& pbstrNewLogin, Byte[]& ppsaOldSid, Byte[]& ppsaNewSid, Object& pvarSidHistory, Object& pvarSiteIds)at Microsoft.SharePoint.Library.SPRequest.SelectSitesAndUserInfoForMigration (Object& pvarContentDsns, Object& pvarContentIds, String bstrOldLogin, String bstrNewLogin, String bstrFullUserKey, Boolean bEnforceSidHistory, Guid guidSubscriptionId, String& pbstrNewLogin, Byte[]& ppsaOldSid, Byte[]& ppsaNewSid, Object& pvarSidHistory, Object& pvarSiteIds)
— End of inner exception stack trace —
at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)
at Microsoft.SharePoint.Library.SPRequest.SelectSitesAndUserInfoForMigration(Object& pvarContentDsns, Object& pvarContentIds, String bstrOldLogin, String bstrNewLogin, String bstrFullUserKey, Boolean bEnforceSidHistory, Guid guidSubscriptionId, String& pbstrNewLogin, Byte[]& ppsaOldSid, Byte[]& ppsaNewSid, Object& pvarSidHistory, Object& pvarSiteIds)
at Microsoft.SharePoint.Administration.SPFarm.MigrateUserOrGroup(Guid subscriptionId, String oldLogin, String newLogin, Boolean usersOnly, Boolean enforceSidHistory)
at Microsoft.SharePoint.Administration.SPFarm.MigrateUserAccount(Guid subscriptionId, String oldLogin, String newLogin, Boolean enforceSidHistory)
at Microsoft.Office.Server.UserProfiles.UserProfile.MigrateUser(String newAccountName, Boolean fullMigration)
— End of inner exception stack trace —

The default configuration and behaviour of the User Profile Service Application does not include the NetBIOS namespace. When you would address the Service Application with PowerShell with Get-SPServiceApplication you would see the property NetBIOSDomainNamesEnabled set to 0 which is disabled.

To enable the NetBIOS namespace for SharePoint you have to recreate the Synchronization Connection to ADDS in the User Profile Service Application. This is necessary since in the creation process of this connection the Configuration Naming Context (CNC) is written to the FIM configuration and SQL database behind it.

  1. Delete the existing faulty Synchronization Connection in the User Profile Service Application.
  2. Open the SharePoint 2013 Management Shell with administrative rights.
  3. Run Get-SPServiceApplication and copy the GUID of the User Profile Service Application.
  4. Run this script in with the correct GUID.

    $UserProfile = Get-SPServiceApplication –Id <GUID>

    $UserProfile.NetBIOSDomainNamesEnabled=1

    $UserProfile.Update()

  5. Create a new Synchronization Connection with Active Directory Domain Services.
  6. Run a new and first “Start Profile Synchronization”.

Once the sync has completed eveyones SAMAccountName should be including the correct NetBIOS namespace of CON\username.

Import distribution groups to Office 365: Exchange Online with PowerShell

Today we faced an issue where a client needed to migrate their GroupWise distribution groups to Office 365. Since there is no easy way doing this we developed a PowerShell script to automate this proces. Well, actually it are two scripts.

The scripts are divided in one, creating the distribution groups and part two is adding the members to the newly created groups. First we have to gather the input for creating the distribution groups in Office 365. For this I only used the required attributes for creating a distribution group.

$import = Import-Csv -Path “C:\temp\Create-DG.csv” -Delimiter “;”
foreach ($item in $import) {
New-DistributionGroup -Name $item.Name -DisplayName $item.DisplayName -PrimarySmtpAddress $item.PrimairyEmailAddress -Type $item.Type
Export-Csv -Path “C:\temp\New-DistributionGroup_LogFile_$(get-date -Format ddMMyyyy).csv”
}

Once the distribution groups are created we can head on adding the members to them using the PowerShell script below.

$import = Import-Csv -Path “C:\temp\Add-DGMembers.csv” -Delimiter “;”
foreach ($item in $import) {
Add-DistributionGroupMember -Identity $item.GroupName -Member $item.UPN -Verbose
Out-File -FilePath “C:\temp\Add-DGMembers_LogFile_$(get-date -Format ddMMyyyy).log”
}

As we can see both the scripts import a .csv file containing the content. The .csv files and the PowerShell scripts can be downloaded below.

DOWNLOAD HERE

Please note that the distribution groups can be either created on-premises in Active Directory and then synced to Windows Azure Active Directory (Office 365) or either directly created in Office 365 with the help of remote PowerShell. Based on your infrastructure and migration scenario it can differ which is the best way to go. Functionally there will be no difference for Exchange Online. However in some hybrid scenarios it can be best to create the distribution groups on-premises and sync them to Office 36 with the help of Azure Active Directory Sync (DirSync).

Filter OU’s to be synchronized to Office 365 with Windows Azure Active Directory Sync

When performing Office 365 deployments for most companies DirSync comes in the picture. Or as Microsoft prefers to call it, Windows Azure Active Directory Sync. Since most of the IT environments become polluted when time flies by most of my client’s prefer to perform a limited synchronization with DirSync.

As said earlier, most IT environments become polluted by time. As Active Directory Users & Computers is one of the most heavily administered you can imagine how much dirt sneaks in which makes it very interesting for businesses. Therefore Microsoft has a way to perform a limited DirSync based on OU (Organizational Unit) hierarchy and selection. For this we have to digg our way into ForeFront Identity Manager.

For this we have to open the FIM 2010 console by navigating to the following directory “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell”.

Here you will find a executable called miisclient.exe. Run this application with “Run as administrator” priviliges. Make sure the account which initiates the request is member of the “Domain Admins” and the “Enterpirse Admins” security groups within your ADS forest. It’s also required to be a member of the local security group “FIMSyncAdmins” on the DirSync server.

Please refer to the image illustrated here for the instructions listed below.
FIM_console_instructions1
1. Click on “Management Agents” in the top ribbon.
2. Right click on the “Active Directory Connector” management agent and select “Properties”.
3. Click on “Configure Directory Partitions” on the left hand side of the menu.
4. Click on “Containers” and fill in the credentials of the local ADS service account.
5. After filling in the credentials a windows opens with the AD forest hierarchy. Here you can select the required Organizational Unit’s. Please refer to the image illustrated below.
FIM_console_instructions2

After selecting the prefered OU’s select OK and save the configuration. Next is waiting for DirSync to kick of a fresh Delta Sync. If you can’t wait then fire up PowerShell on the DirSync server and run the following two cmd-lets:

1. Import-Module DirSync
2. Start-OnlineCoexistenceSync -FullSync

Hope this helps fellow IT Professionals deploying succesfull Office 365 product. And obviously it is best to configure this filtering before Windows Azure Directory Sync synchronizes for the first time.