Guest Post: Azure AD Connect: Dollar sign character in device’s display name in Azure AD after renaming

Guest Post: Azure AD Connect: Dollar sign character in device’s display name in Azure AD after renaming

  •  
  •  
  •  
  •  
  •  
  •  

As you may have figured out from the title, I’ve got a guest post today.  Jorge Lopez is a Premier Field Engineer, and has spent a lot of time in the trenches with Windows, AD, and Azure AD, and currently works helping customers resolve hybrid identity issues.  This is his story.

[ Law and Order bum-bum ]

Background

Hi everyone, Jorge Lopez here. I’m a Hybrid Identity Premier Field Engineer at Microsoft.

I’ll like to share to you an interesting scenario I was dealing once with a customer. One day I got an email from a customer saying: “Hey where did the “$” come from and how do I make it go away?

My first thought was: “I could use some extra bucks so I’ll be happy to help you getting rid of some money!” Sadly, this was not about money.  This was literally a trailing dollar sign character “magically” being appended at the end of some display names on their Azure AD devices list, and after a couple of hours (Sometimes days) the “$” was disappearing by itself (perhaps this AAD Connect instance has kids).

At the beginning it didn’t feel like a big deal, since as you may know all objects in Azure AD Connect uses a common Source Anchor (usually ObjectGUID->ImmutableID), so no matter how many changes you make to the name of the objects (users or computers), the underyling object being referenced is still the same.

The problem this customer experienced was that they were doing some custom scripting to report Bitlocker encryption status from the Win 10 devices in Azure, so the Azure device name needed to match the on-premises device name.  The mismatched computer names caused the script to report a lot of discrepancies.

Here is where the investigation started. There was one important thing to consider, was only happening to computers that had been previously renamed in Active Directory (On-prem)

The first step was to try to replicate the issue, so we took an existing machine named PFEWIN10

Computer Name in OS Settings:

Display Name in Azure AD Devices list:

So far, so good – names match. We renamed it through the computer’s System Properties applet (Start | Run | control.exe /name Microsoft.System) from PFEWIN10 to NEW-PFEWIN10, waited for the next sync cycle and there it was–Azure AD displayed the computer’s name was : NEW-PFEWIN10$

Computer Name in OS Settings:

Display Name in Azure AD Devices list:

Azure AD Connect was telling us about the update in its log as well as the audit log in for the device in the azure portal :

We did re-name the computer but what is up with that $ character in the end of it?

After a couple of hours or sometimes more, this was actually being ‘fixed’ by itself:

We noticed the following logs in Azure AD once the display name was showing the correct value without the $ character and the Device Audit logs was showing us the change, notice the “Initiated by” Column

 

AHA! – So the Device registration service is now renaming this back to the actual name in AD, but why AAD connect was adding the $ to begin with?

Time to go to the Azure AD Connect Rules for Device Synchronization and look at the Devices Rule.

We found that there is an Inbound Rule (In from AD) that is calculating the value of the displayname Target attribute to Azure AD . This rule is called: In from AD – Computer Join

It has the following function for the displayname rule

IIF(IsNullOrEmpty([displayName]),[cn],[displayName])

In English , the above rules provisions the device displayname attribute in Azure to match the displayname attribute on-prem, BUT if displayname is empty then use the CN attribute from the computer object On-prem

This explains it now – So when a computer is first joined to the domain , the displaymame attribute in AD is usually <Not Set> , hence in Azure AD , the device’s displayname is populated with the value of the CN attribute (as the rules mandates), this will not change until the actual displayname on-premises is populated on certain events.. like renaming a computer.

In Active Directory Domain Services when a computer is renamed, the displayname attribute is then populated with the name of the computer and appending a $ to the end (this is on-prem AD by design) , and since now this attribute is not NULL , AAD connect uses displayname on-prem instead of CN to populate the displayname value in the AAD object

This rule logic is basically the culprit of having $ in the end of all devices that have been renamed

Reference : https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-functions-reference

This is great but now: how are these getting renamed back by Device Registration Service (DRS)? The answer is simple: DRS does NOT use displaymame or CN to populate the Display Name in Azure AD.  DRS bases its calculation on another attribute: dnshostname (a.k.a the FQDN of the computer). DRS uses a function to only take a portion of this attribute, from the first dot to the left (basically the NETBIOS name only)

i.e. : abc123.contoso.com will be populated as abc123

Solution

Cool, cool.  So how do we fix it using AAD Connect?

Fortunately, Azure AD Connect Sync Rules Editor support some text manipulation functions too! So, we need to create another Sync Rule in Azure AD Connect to use the same logic as DRS

Here’s the function that would do the trick:

UCase(Left([dNSHostName],InStr([dNSHostName],".") - 1))

Function Explanation: “Find the position of the first dot on dNSHostName attribute , then take the left portion of this same attribute starting on that position minus 1 and change it to upper case.

*The UCase function (to uppercase) is for consistency only, not required.

Here are the steps to recreate it on your own.

Ensure the dnsHostName attribute is being synced to Azure AD

NOTE: This attribute is not in the list of the “Directory Extensions” configuration through the AAD Connect console, so this has to be added directly on the connector in the Synchronization Service Manager console application.

  1. On your Azure AD Connect Server, launch the Synchronization Service and select the Connectors tab.
  2. Select the connector for your on-premises directory (it should be the Active Directory Domain Services connector type) and click Properties.
  3. On the properties Screen, in the connector Designer section, click Select Attributes and make sure the dNSHostName attribute is checked.  If it’s not, then click on Show All checkbox at the top right – find the attribute and select it. Click OK.

Create a New Rule with Higher precedence (Lower Number)

Now that we’ve got the attribute available, we need to create a rule using our sample sync rule above.

  1. On your Azure AD Connect Server – Open AAD Connect Synchronization Rules Editor Click on “Add new Rule” , make sure the Direction is set to “Inbound”

  2. On the Description page, enter the following: 
    • Name: Give the rule a descriptive name, try to keep the default naming convention if possible.
    • Description: Give some clarification so someone else can understand what the rule is for.
    • Connected System should be your on-prem AD domain name
    • Connected System Object Type should be set to Computer
    • Set Metaverse Object Type to device
    • Link type: Make sure you choose Join (In that way, this rule only overrides the attribute once the objects are already provisioned by the default rule)
    • Precedence: Provide a value that is unique in the system. A lower numeric value indicates higher precedence.
    • Leave Tag empty and make sure the Enable Password Sync and Disabled options are unchecked
    • Click Next
  3. On the Scoping Filter, leave this empty and click Next
  4. On the Join Rules page, leave the field empty and click Next
  5. On the Transformations page, Click Add Transformation,  then choose the following options:

    • Choose Expression as the Flow Type
    • Select displayName as the Target Attribute
    • in the Source field Type the Expression:
UCase(Left([dNSHostName],InStr([dNSHostName],".") - 1))
    • Apply Once should be unchecked
    • Merge Type should set as Update
    • Click Add

NOTE: Synchronization rules are cAsE-sEnSiTiVe.  If incorrect capitalization of a function or attribute name will result in either an error saving or processing the rule.For more information, see our documentation.  

 

Run a full synchronization

  1. On the Azure AD Connect Server, launch an elevated PowerShell Window.
  2. Type the following Command to run a full sync:
    Start-ADSyncSyncCycle -PolicyType Initial 

NOTE: This could take from a few minutes to several hours depending on the size of your organization.

Closing

That’s it from Jorge.  Be sure to go look him up on LinkedIn or TechCommunity!

Published by Jorge Lopez

Senior Systems Engineer several years of experience providing top level customer service coupled with strong technical knowledge. SME in Hybrid Indentity with Azure AD and Active Directory .High expertise in the support of systems to drive company growth and technical innovation. Proven ability to direct large-scale development and support initiatives. Proficient in determining system requirements and resolving technical issues quickly. Skilled in providing effective leadership in fast-paced, deadline driven environments. Able to lead and motivate teams. Highly educated including my Bachelor of Science in Computer Science as well as my MSCA and MCP.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.