The next type of DirSync errors generated by the organization in Part 1 were objects with invalid User Principal Names. Using some of the error messages sent in the Directory Synchronization error report email, I will examine why these errors occurred and how we fixed them.

Blank User Principal Name

Although the error states the UPN was a duplicate, I included it with the Invalid UPNs rather than the duplicate values in Part 2 because of the reason the UPNs were duplicated. The ASPNET accounts had blank UPNs, thus when they were replicated they were each given the default UPN suffix of @contoso.onmicrosoft.com. Blank User Principal Names or missing UPN suffixes can occur when the account was created by a program, through software installations, a script or other user provisioning system outside of Active Directory Users and Computers. ADUC will include the AD domain name as the UPN suffix by default, while other account creation methods may leave the UPN or suffix blank. Changing the UPN to match the Primary SMTP Address will fix these problems unless, like these accounts, they do not have a mailbox. The ASPNET account was present in the parent and all child domains, causing multiple dirsync errors but only one error message in the error report.

Resolution:

1. Update the account UPNs in each domain with a federated domain as the UPN suffix.
2. Dirsync will update the objects at the next synchronization cycle.

Change UPN to Different Federated Domain

Bob moved from an office in Iowa to an office in Ohio. His primary SMTP address was changed from @ContosoMW.com to @ContosoOhio.com to reflect his new location and his UPN was changed to match. It is not possible to change from one federated domain to another just by updating the UPN on the on-premise account. The user object must be updated in the portal when the UPN suffix changes between federated domains.

Resolution:

1. Launch the Azure AD PowerShell Module from an admin workstation.
2. Run the Connect-msolservice cmdlet from the PowerShell window.
3. Log in with an Office 365 account that has rights to manage users.
4. Change the cloud UPN from the old federated domain to the default domain on Office 365.
   • Set-MsolUserPrincipalName -UserPrincipalName [email protected] -NewUserPrincipalName [email protected]
5. This change requires 2 Dirsync cycles to replicate the changes in both directions.
6. The Cloud Account will be updated with the correct on-prem UPN when the dirsync cycles complete.

Invalid Characters in User Principal Name

Both of these accounts have invalid characters in their User Principal Names. These errors are discovered during the initial readiness assessment or roadmap when AD is examined for accounts that will cause directory synchronization errors. However, these accounts were created after the assessments were run at the beginning of the project so they showed up in the dirsync error report. Changing the UPN to match the primary SMTP address would have resolved these errors.

Resolution:

1. Remove the / from UPN, Display Name, alias, and first name in the Vacation Calendar shared mailbox user account.
2. Remove the space from the Tech Use UPN.
3. Dirsync will update the objects at the next synchronization cycle.

The majority of Invalid UPN errors can be resolved by changing the UPN to match the email address. Accounts that lacked email addresses or moved between federated domains required manual intervention, but the resolution is still straightforward. In Part 4 I will examine the strange errors that do not fit in the other two dirsync error categories.

Edit – In an earlier version I used the word internvention instead of intervention. Neither the standard Office dictionary nor my editor consider internvention a real word, however I believe it should be.

In-tern-ven-tion. Noun. The act or fact of assigning the repetitive menial tasks required to solve a problem to an unpaid subordinate.

Manually editing UPNs to fix dirsync errors is a prime example of a task that requires an internvention. English is a living language. If enough people start using it, we can make internvention a real word.

The most common type of DirSync errors generated by the organization in Part 1 were objects with duplicate values. Using some of the error messages sent in the Directory Synchronization error report email, I will examine why these errors occurred and how we fixed them.

Duplicate Proxy Addresses

There was an EHernandez in East.Contoso.com and West.Contoso.com. Each domain has separate email address policies, all based on alias, that were updated with the tenant routing address of %[email protected] during the hybrid configuration. Normally, Exchange and AD will not allow duplicate SMTP addresses. One user will be [email protected] and the other will be [email protected]. However, this organization is geographically distributed and normal AD replication lag allows 2 accounts to be created with the same email address before the updates are replicated across the forest.

Resolution:

1. Remove [email protected] from [email protected]
2. Re-apply email address policy to user
3. A new tenant routing address of [email protected] is applied to the account
4. Dirsync will update the objects at the next synchronization cycle
5. For accounts that are common across all domains, like Helpdesk, you will have to repeat this process for each account. You will have to wait for or force AD replication before updating the next account or it will try to use [email protected] and generate a new error.

Duplicate User Principal Names

User accounts in each domain had their User Principal Name changed to match their Primary SMTP address. This was done just before migration of that domain to Office 365, so there was a transition phase where some domains were changed and others were not. In this case we had MSmith accounts in West.Contoso.com and South.Contoso.com. These UPN suffixes were not defined as accepted domains in Office 365 so both MSmith accounts were assigned the default domain of @contoso.onmicrosoft.com when the accounts were synchronized by Dirsync from the on-premise environment.

Resolution:

1. Change one or both MSmith account UPNs to match their primary SMTP address
2. Dirsync will update the objects at the next synchronization cycle

Duplicate On-Premise and Office 365 Accounts

This issue was a conflict between two synchronized users and a user created in Office 365.

David Banner was created directly in Office 365 even though a David Banner existed on-prem and would be synchronized. David, however, had not had his UPN changed to his email address so Office 365 was trying to assign him the [email protected] UPN during directory synchronization, which conflicted with the primary email address of the cloud account. The Don and David Banner on-premise accounts both had DBanner aliases so both were also given the [email protected] proxy address.

Resolution:

1. Delete DBanner Cloud user. The user was not licensed so it had no mailbox.
2. On-premise DBanner user will sync later and update the cloud Global Address List
3. Change UPN of the on-premise DBanner to match his email address
4. Remove tenant routing address and reapply Email Address Policy to update routing address as [email protected]
5. Dirsync will update the objects at the next synchronization cycle

User Principal Name and Email Address Conflict

Both SMTP Addresses and UPN must be unique. This domain had a policy where a departed employee’s email address would be given to their replacement or supervisor as an extra proxy address. The departed users were already migrated to Office 365 so their UPNs had been changed to match their email address. In this case, the UPN of one account was conflicting with an SMTP address of another account.

Resolution:

1. OldGuy had his primary SMTP address changed to [email protected]
2. Change OldGuy’s UPN to match his new GONE email address
3. Dirsync will update the objects at the next synchronization cycle

In Part 3, I will examine the next class of DirSync errors, Invalid User Principal Names.

There’s always a lot of confusion on exactly how to use CCMSETUP and the various switches and properties for it even though it’s fully documented on TechNet.

The first thing to note about CCMSETUP is that it is used for all client agent installation activity (except client agent installation from WSUS). Yes, even client push uses CCMSETUP. Basically, client push simply delivers CCMSETUP to target systems and starts it. What that ultimately means is that no matter how you install the client, it’s always the same process so there is no technical difference between any of the methods (except using WSUS as mentioned).

Next, it’s important to note that CCMSETUP is simply a bootstrapper that in turn initiates a handful of of other things including the following (this isn’t an exhaustive list, just the main relevant points for this discussion):

Copies itself to C:\Windows\ccmsetup, installs itself as a service, starts that service, and then immediately exits. Why would it do this? Reboot resilience. Thus, if the system reboots for whatever reason without CCMSETUP actually finishing the entire installation process, it will restart after the reboot automatically. The main ramification to keep in mind here is that that service runs as the local System account. That means that if CCMSETUP needs access to anything else on the network, it will use the AD computer account of the system. If the system is not a member of a domain, it has no AD computer account to use (obviously) and thus won’t be able to authenticate as anything other than anonymous.

Downloads prerequisites – like .Net Framework 4.0 client profile and Silverlight — and other files needed to install the client – like client.msi — and installs prerequisites not already installed on the system.

Where does it download these from? By default (in 2012), CCMSETUP locates an MP using normal MP location rules (AD, DNS, WINS) and then asks the MP for the closest DP. Then, using BITS, it downloads the files using BITS from the DP returned by the MP which follows normal content location rules which are purely based on boundaries within content distribution boundary groups. If for whatever reason, no valid DPs exist or are available for the target system based upon the boundaries, the files will be downloaded from the MP itself. Note that this BITS download will work fine for anonymous clients – like those in a workgroup or untrusted domain and does not require any special permissions or access.

Finally, it installs the client agent from the locally downloaded files by initiating the install using client.msi.

That brings us to /mp and SMSMP. Both are valid on the CCMSETUP command-line, but both are completely different in multiple ways.

/mp

“Options” like /mp that are prefixed with a forward-slash are parameters for CCMSETUP itself. Thus, they control or affect the behavior of CCMSETUP and not the client agent. So, even though /mp contains the letters ‘m’ and ‘p’, this does not in any way mean that it sets the MP for the client agent. What /mp actually does is instruct CCMSETUP which MP to use to query for a DP (as mentioned above) thus bypassing the normal MP lookup.

Multiple MPs can be specified using /mp by separating them with a comma (this enables the lookup to try each MP in order if availability of the MPs is a concern):

ccmsetup.exe /mp:mp1.mydomain.local,mp2,mydomain.local

Additionally, if an MP requires HTTPS communication, you should specify the prefix in URL format including the protocol:

ccmsetup.exe /mp:https://securemp.mydomain.local

It is always a good practice to use the full FQDN and ensure that name resolution is working for this name on the target clients. If name resolution is not working, you’ve got bigger problems that CCMSETUP cannot magically solve. Note also that CCMSETUP setup parameters require a colon between the option name and the value specified for that option.

SMSMP

“Options” like SMSMP that are in all capital letters are public properties that are not processed or used in any way by CCMSETUP but are instead passed directly to client.msi when CCMSETUP executes it. Thus, these properties do directly affect the client agent and its configuration. Note that you don’t actually have to specify the properties in all capital letters on the command-line, but it is best to do this so that they clearly stand-out.

SMSMP specifies the initial MP that the client agent uses (“initial” because with 2012, we can have multiple MPs within a single primary site and this will rotate periodically on clients). Without SMSMP, the client agent relies on normal MP location processes (AD, DNS, WINS) just like CCMSETUP does to initially set the MP that the client agent will use.

As with /mp, you should use the full FQDN of the MP and if an MP uses HTTPS, you should also specify the name of the MP in URL format including the prefixed protocol:

ccmsetup.exe SMSMP=https://mp.mydomain.local

ccmsetup.exe SMSMP=https://securemp.mydomain.local

Unlike /mp, you can only specify a single MP with SMSMP. Also, public properties are not prefixed with a forward-slash and use an equals sign to set the value of the property.

One thing to make sure of is that you specify all CCMSETUP parameters on the command-line before you specify any public properties. This simply has to do with how CCMSETUP parses the command-line: it assumes that all parameters come first so as soon as it encounters a property, it stops looking for anymore parameters.

You can of course use both these options together which is common because the reason for using them is the same: you don’t want to (or can’t) rely on normal MP lookup. If MP lookup is working, then there’s no reason to use either. The only time to really expect any issues with MP lookup is when the target client is untrusted like when it’s in a workgroup. Remember that during a Build and Capture task sequence, the target/reference system should not be joined to a domain so specifying SMSMP in the Setup Windows and ConfigMgr task should be done – no need to specify /mp though because the source files needed by CCMSETUP are part of the client agent install package and thus already resident locally.

Although I haven’t tested explicitly and so I’m not sure of the exact ramifications, if a client is destined to be within a secondary site’s scope, you should still specify the MP for the primary site for both of these options instead of the MP at the secondary site. Remember, that clients always need to be able to communicate the MP in their primary site even if they are within the scope of a secondary.

Finally (yes finally), some of the behavior above can be overridden using the available parameters; e.g., use /noservice to prevent CCMSETUP from installing itself as a service (this changes the authentication discussion above because CCMSETUP is no longer running as the local System but is instead running as the user that initiated it so beware) and /source to explicitly specify a network UNC to download the necessary files from using SMB instead of a DP using BITS (this also changes the authentication discussion above because gaining access to an SMB share is not allowed by default to anonymous requestors). These additional parameters (and much more) is all detailed in the TechNet article I linked at the top. If you already have too many bookmarks, simply remember to search for “Configuration Manager 2012 ccmsetup”: it is always the first hit in real search engines (like Bing) and evil search search engines also.

I change the User Principal Name on the accounts I migrate to Office 365 to match the primary SMTP address for two main reasons:

1. Office 365 requires that users have a valid, internet routable User Principal Name suffix, such as BlueSun.com instead of BlueSun.local.
   1. Email addresses are, by their very nature, internet routable.
   2. Changing the UPN solves many of the UPN validation problems like invalid characters, spaces, or even duplicate UPNs.
2. Many times Office 365 services will ask for email address and password when it really wants a UPN.
   1. ActiveSync account setup on mobile devices asks for Email and password. ActiveSync then uses those credentials to retrieve Autodiscover information. If ActiveSync cannot authenticate and get an Autodiscover response, the user will have to go through a manual account setup
   2. Lync sign-in is easier when the UPN and email match
   3. If the email address and UPN match, it is one less thing users have to remember

The first step is to gather all of the user data. I use PowerShell and the Quest ActiveRoles AD cmdlets. I cannot always count on having a 2008 R2 or higher domain controller running the web AD role to handle the AD cmdlets now included in PowerShell, but I can always control what is installed on my admin workstation. Plus, I have many scripts written using the Quest AD cmdlets and I am not going to rewrite all of them. The output from this script includes more data than we need to change the UPNs. I collect all this data now so that I can use it later in the project to see which accounts are not managed using email address policies – usually because the user prefers a nickname over their full first name. These scripts were modified for a client that had multiple child domains. You can use the single domain scripts if you are in a single domain environment, but I am including the child domain scripts for those who are not so lucky. The domain controller input file was created from information in the ADTD.csv file generated by the Active Directory Topology Diagrammer.

Get Domain Users (Single Domain)

get-qaduser -sizelimit 0 -includeallproperties | where {$_.PrimarySMTPAddress -ne $null} | Select-Object samaccountname,givenname,sn,displayname,mailNickname,primarySMTPAddress,userprincipalname,EmailAddressPolicyEnabled | export-csv c:downloadscriptsoutputGISX-Users.csv –NoTypeInfo

Get Child Domain Users (Multiple Domains)

#Define Input File

#Required Fields in CSV (in any order): Domain, ServerDNSName

$DOMFile = “C:DownloadScriptsInputChildDomains-EditedInputFile.csv”

$DOMList = Import-Csv $DOMFile

Foreach ($NEXTDOM in $DOMList)

{

get-qaduser -service $($NEXTDOM.Domain+”.BlueSun.com”) -sizelimit 0 -includeallproperties | where {$_.PrimarySMTPAddress -ne $null} | Select-Object samaccountname,givenname,sn,displayname,mailNickname,primarySMTPAddress,userprincipalname,EmailAddressPolicyEnabled | export-csv $(“c:downloadscriptsoutput”+$NEXTDOM.Domain+”-Users.csv”)

}

Next, analyze the exported CSV to find the accounts whose UPN and email address do not match. Convert the CSV to an Excel file, add a column called UPNMatch and use this formula in the UPNMatch column to compare the PrimarySMTP and UserPrincipalName cell values. Adjust the formula so that it covers your full range of rows and copy the formula to the UPNMatch cells.

=IF(ISERROR(MATCH(F2,$G$2:$G$135,0)),””,F2)

If a user’s UPN and email match, that value will be written in the UPNMatch column. Otherwise the column will be blank. Here is an excerpt with a matched and mismatched account:

Sort by UPNMatch and delete the rows that have values in the UPNMatch column. The remaining users are the only ones that need to be changed. Now I have a list that contains only the accounts that need to be changed, as well as the account values prior to the change. Your change control board may require this information before the change control request is approved. Save the file as UPNMismatch.csv and use it as the input file in the Set UPN script.

Set UPN

#Must have Quest AD cmdlets

#Define Input File

#Required Fields in CSV (in any order): SAMAccountName, PrimarySMTPAddress

$UserFile = “C:DownloadScriptsInputUPNMismatch-.csv”

$UserList = Import-Csv $UserFile

Foreach ($NEXTUser in $UserList)

{

set-qaduser -Identity $NEXTUser.SamAccountName -UserPrincipalName $NEXTUser.PrimarySMTPAddress

}

Set UPN Child Domain

#Must have Quest AD cmdlets

#Define Input File

#Required Fields in CSV (in any order): SAMAccountName, PrimarySMTPAddress

$UserFile = “C:DownloadScriptsInputUPNMismatch.csv”

$UserList = Import-Csv $UserFile

#Set domain controller for user scope

$DC = ‘DC.Child.BlueSun.com’

Connect-QADService -Service $DC

Foreach ($NEXTUser in $UserList)

{

set-qaduser -Identity $NEXTUser.SamAccountName -UserPrincipalName $NEXTUser.PrimarySMTPAddress

}

Allow Dirsync to update the user accounts in Office 365 if single sign-on has already been configured and the users can now log in to Office 365 using their email address (UPN) and password.

Changing the UPN is not without risks. A User Principal Name is a valid login method in Active Directory, so changing it can affect how your users log in. In my experience, users logging into Windows domains with their UPN is rare but there instances where it is more common. Service accounts can be configured though code or on the service itself to log in with a UPN. My method ignores accounts that do not have email addresses, so as long as the service account does not have a mailbox no changes will be made to the service account. Linux users running Thunderbird also use UPNs for mailbox authentication. Changing the UPN will require them to reconfigure their account in Thunderbird, but they were going to have to reconfigure Thunderbird as soon as they were migrated to Office 365 anyway. Changing the UPN can cause Directory Synchronization errors if email addresses are reassigned following an employee’s departure. An email address on one account will conflict with the UPN of another, requiring you to change the UPN of the departed employee. These few issues are worth the trouble to resolve in order to simplify the login experience for your users.