H is for Heterogeneity

As consultants, we have the opportunity to interact with different customers’ environments on a regular basis. Though seemingly overwhelming at first, the advantage is that we are exposed to a large amount of variability with respect to how IT systems are conceptualized, deployed, and maintained. Through these types of experiences, we often run into scenarios we’ve not witnessed before and have a burning desire to bring to resolution. In today’s post, we will cover three of these scenarios from a recently completed engagement involving a major gift retailer and distribution company.

Orphaned Objects

As part of our scope, New Signature was responsible for performing an identity cutover from one Azure AD Connect server to another involving 15k+ users synchronized from Active Directory on-premises to Office 365. To ensure a successful result, we needed a solid method of maintaining an association between an on-object on-premises, in Azure Active Directory (AAD), and in Exchange Online (EXO).

As we’ve covered previously, the association (“hard-match”) between a synchronized on-premises AD and Azure AD object is via the objectGuid (on-premises) and ImmutableId (in AAD). In short, the ImmutableId is the Base64 string representation of the objectGuid.

When it comes to Exchange Online, however, it is not immediately clear how a mail-enabled object is hard-matched to its AAD counterpart. One might suspect it’s by way of the UserPrincipalName attribute, which must be unique across all objects in an Office 365 tenant, and this is a legitimate presumption. However, when working in a relatively large environment where UPNs may become modified and where hundreds of directory synchronization errors exist, it’s necessary to find a hard link between cloud objects in disparate directories.

Having compared different attribute values and reviewed our findings with Microsoft’s partner technical architect team, we have determined that the ExternalDirectoryObjectId attribute in Exchange Online directly maps to the ObjectId attribute in AAD. With this knowledge, we exported AAD and EXO objects to separate CSV files and performed a ‘join’ using this attribute association, giving us a clear picture of all synchronized objects and their respective attribute values in the cloud. Having this data in hand gave us the confidence to move from one AAD Connect server to another without fear of object orphaning. We ultimately completed the cutover activities with a <0.1% error margin, largely considered a monumental success.

Sync Error Reporting

For various reasons, not all existing directory synchronization errors could be resolved prior to cutover activities. Therefore, we needed a method of exporting errors before and after the cutover so that the two reports could be compared afterwards, if necessary.

While error details are visible in both the Office 365 Admin center and Synchronization Service Manager (miisclient.exe), neither provides an easy technique by which to export the data. As a result, we created the following basic script which connects to Azure AD via PowerShell, iterates through all sync errors, and records various properties of each error to a CSV file. The script can be modified to add or remove error properties as necessary.

Identity Crisis

During the setup of the new AAD Connect instance, we repeatedly ran into an issue where we could not get past the “Connect to Azure AD” step of the AAD wizard. We tried using credentials for multiple Office 365 Global Admin accounts and researched the error message to no avail:

Error: An error occurred while executing the An error occurred while executing the ‘Get-MsolUser’ command. The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input. command.

After conferring with the customer, we became privy to a specific security setting that had been deployed across all servers in their environment. In essence, enhanced PowerShell logging had been enabled to capture all PowerShell commands executed on a server. Should a server ever become compromised, the logs would display a transcript of all actions taken on that server.

The setting is enabled by creating a DWORD (32-bit)/REG_DWORD registry value under the Software\Policies\Microsoft\Windows\PowerShell\Transcription path with a name of EnableTranscripting and a value of 1. Transcripting can subsequently be disabled by setting the value to 0.

Need expert assistance with a complex scenario? Reach out to New Signature today to see how we can be of assistance.