MSEndpointMgr

Skip syncing specific Windows versions with Azure AD Connect synchronization rules

When enabling Hybrid Azure AD join in Azure AD Connect wizard it gives you the option to choose to enable the configuration for Windows 10 and down-level devices (Windows 7 and 8.1). A requirement for devices to be enabled for Hybrid Azure AD join is that they’re synced to Azure AD, which is configurable in the Azure AD Connect wizard now as well. However, there’s no configuration option in that wizard to skip specific Windows versions to be synced, obviously because you’re selecting the organizational unit structure that will be synchronized. In this blog post I’ll go over the required steps to configure a custom rule in Synchronization Rules Editor included in Azure AD Connect to filter out devices that does not meet a specific requirement in terms of operating system version.

Filter and synchronize devices

Whatever the reason is for turning on Hybrid Azure AD join in your environment, if you’re not planning on enabling the feature on down-level Windows versions, would you really want to sync those objects to Azure AD and have them show up along with the Windows 10 devices? Hybrid Azure AD join for Windows down-level versions require additional configuration and distribution of the workplace join agent. Synchronization rules rely on various attributes available on the object being synchronized. One in particular is interesting for this scenario, when the goal is to only synchronize Windows 10 devices from a given organization unit, the operatingSystem attribute. This attribute contains the display name of the operating system installed on the device, for instance Windows 10 Enterprise or Windows 7 Enterprise. With this information, we can create a custom synchronization rule with a specific filter for this attribute to match a given string, for instance Windows 7.

Custom and built-in synchronization rules

Before we continue with this blog post, I want to make sure that you understand that we’re going to create a custom synchronization rule and not edit an built-in rule. The reason for this is that the built-in synchronization rules will be overwritten whenever you upgrade Azure AD Connect. I’ve seen plenty of blog posts out there suggesting to edit a built-in synchronization rule to enable the synchronization of the for example the Usage Location attribute from Active Directory objects, which will work initially, but eventually be overwritten.

Read more about creating custom synchronization rules and changing the current configuration on the link below:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-change-the-configuration

Create a filtering synchronization rule

When adding or editing synchronization rules there’s a requirement to disable the Azure AD Connect synchronization scheduler to prevent any scheduled synchronization to occur during this configuration change. This task can easily be accomplished by opening up an elevated PowerShell console and execute the following command:

Set-ADSyncScheduler -SyncCycleEnabled $false

With the synchronization scheduler temporarily disabled, we can now continue with configuring the rules to accomplish the filtering of a specific Windows version, in this instance Windows 7. For this scenario we’re working with, the way we have to go about filtering out the objects with a specific attribute and a given value, we need to create a new inbound rule. This means that when the synchronization engine processes this rule, it’s happening while processing objects and data from the on-premise Active Directory connector. In addition to this, since we’re creating an inbound filtering rule we need to tag the object with a specific metaverse attribute named cloudFiltered with a value of True. Setting this attribute tells the synchronization engine to simply filter out the object while synchronizing to Azure AD.

  • On the server where Azure AD Connect is installed, open the Synchronization Rules Editor application.
  • Make sure that Inbound is selected under Direction and then click Add new rule.

  • Give the new rule a name that follows the existing naming standard and configure the following configuration:
    • Connected System: <on-premise connector>
    • Connected System Object Type: computer
    • Metaverse Object Type: device
    • Link Type: Join
    • Precedence: <any number lower than the any of the existing inbound rules>

  • Click Next.
  • On the Scoping filter page, click Add group and then Add clause.
  • Select operatingSystem as the Attribute and STARTSWITH as the Operator.
  • Enter Windows 7 in the value field. At this point we could add more clauses if we want to filter out Windows 8.1 as well.

  • Click Next.
  • Skip past the Join rules page and click Next.
  • On the Transformation page, click Add transformation. Select Constant as the FlowType, cloudFiltered as the Target Attribute and enter True in the source value.

  • Click Add.

At this point we’ve now created the new rule to filter out any down-level versions of Windows. There’s a couple of small tasks that we need to do now in order for it to take effect. First off we need to enable the synchronization scheduler again by running the following PowerShell command:

Set-ADSyncScheduler -SyncCycleEnabled $true

The second task is to run the following PowerShell command, that will enforce a complete synchronization which is required after editing or adding new rules:

Start-ADSyncSyncCycle -PolicyType Initial

Nickolaj Andersen

Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences such as Microsoft Ignite, NIC Conference and IT/Dev Connections including nordic user groups.

Add comment

Sponsors

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.