How to Check Exchange Prepare AD Values

Before installing a new Exchange environment, and sometimes when updating to a newer Cumulative Update, we need to prepare our Active Directory (AD) forest and its domains. Exchange needs to prepare AD so that it can store information about users' mailboxes and the configuration of Exchange servers in the organization.

Once we have extended the AD Schema, prepared AD, and prepared all its domains, several properties are updated to show that preparation is complete. At this stage, it is strongly recommended to make sure everything has gone smoothly. To do so, typically a tool called Active Directory Service Interfaces Editor (ADSI Edit) is used to check these properties have been updated to the value they should have. Each property needs to match the value for the release of Exchange that we are installing:

• “In the Schema naming context, verify that the rangeUpper property on ms-Exch-Schema-Verision-Pt is set to the value shown for your version of Exchange 2016 in the Exchange 2016 Active Directory versions table;
• In the Default naming context, verify that the objectVersion property in the Microsoft Exchange System Objects container under DC=root domain is set to the value shown for your version of Exchange 2016 in the Exchange 2016 Active Directory versions table;
• In the Configuration naming context, verify that the objectVersion property in the CN=your organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain container is set to the value shown for your version of Exchange 2016 in the Exchange 2016 Active Directory versions table.”

 

 

But there are other methods. For example, Michel de Rooij has blogged about checking these properties using LDAP and PowerShell in his Exchange Schema Versions blog post. Additionally, we can use the LDP.exe tool (an LDAP client GUI), or we can use DSQuery.

 

Dsquery is a command-line tool that is built into Windows Server when the Active Directory Domain Services (AD DS) server role or the AD DS admin tools are installed. Using dsquery we can query AD (shocker!) by using search criteria that we specify.

 

So, let’s say we want to check the value of the rangeUpper property using dsquery. We can easily do this by running the following command:

DSQUERY.exe * “CN=ms-Exch-Schema-Version-Pt,CN=schema,CN=configuration,DC=domain,DC=com” -Scope base -Attr rangeUpper

In my lab, where I have a nunomota.pt domain, I would run:

DSQUERY.exe * “CN=ms-Exch-Schema-Version-Pt,CN=schema,CN=configuration,DC=nunomota,DC=pt” -Scope base -Attr rangeUpper

To check for the other two properties, we would use the following two queries:

DSQUERY.exe * “CN=Exchange_Org_Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com” -Scope base -Attr objectVersion

DSQUERY.exe * “CN=Exchange_Org_Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com” -Scope base -Attr msExchProductId

Now that we know how to easily check these properties, we can make it even easier by automating the check with the script below. In order to automate this, I use the Get-OrganizationConfig Exchange cmdlet to determine the Exchange Organization Name (when it is not specified), so the Exchange Management Shell (EMS) should be used. This means that if we run the script from a normal PowerShell console and do not specify the Exchange Org Name, the script throws an error:

 

 

Obviously, if this is a brand-new Exchange environment, the EMS will not yet be available at this stage. In these cases, we must specify the Exchange Org Name and the script will not use the Get-OrganizationConfig cmdlet:

 

 

From the values presented by the script, and by looking at the Exchange 2016 Active Directory versions table, we can see that this Exchange Environment is running Exchange 2016 CU3.

 

The following is the script that produced the output above:

[CmdletBinding()]
Param (
 [Parameter(Position = 0, Mandatory = $True)]
 [ValidateNotNullOrEmpty()]
 [String] $Domain,

 [Parameter(Position = 1, Mandatory = $False)]
 [String] $ExOrgName = (Get-OrganizationConfig).ID
)


If ($Domain -notmatch "\.") {Write-Host "Please enter a correct Domain name." -ForegroundColor Red; Exit}
ForEach ($name in $Domain.Split(".")) {$tempDomain += ",DC=$($name)"}

$rangeUpper = (DSQUERY.exe * “CN=ms-Exch-Schema-Version-Pt,CN=schema,CN=configuration$($tempDomain)” -Scope base -Attr rangeUpper)[1].Trim()
$objectVersionDNC = (DSQUERY.exe * “CN=Microsoft Exchange System Objects$($tempDomain)” -Scope base -Attr objectVersion)[1].Trim()
$objectVersionCNC = (DSQUERY.exe * “CN=$ExOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration$($tempDomain)” -Scope base -Attr objectVersion)[1].Trim()
$msExchProductId = (DSQUERY.exe * “CN=$ExOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration$($tempDomain)” -Scope base -Attr msExchProductId)[1].Trim()

Write-Host "rangeUpper (Schema)           :", $rangeUpper
Write-Host "objectVersion (Default)       :", $objectVersionDNC
Write-Host "objectVersion (Configuration) :", $objectVersionCNC
Write-Host "msExchProductId               :", $msExchProductId

We could take this script one step further and build a list of all these properties and their values for each Exchange CU, and then print which ones match. Because some CUs do not update all these properties, sometimes they will match more than one Exchange version:

 

[CmdletBinding()]
Param (
 [Parameter(Position = 0, Mandatory = $True)]
 [ValidateNotNullOrEmpty()]
 [String] $Domain,

 [Parameter(Position = 1, Mandatory = $False)]
 [String] $ExOrgName = (Get-OrganizationConfig).ID
)


If ($Domain -notmatch "\.") {Write-Host "Please enter a correct Domain name." -ForegroundColor Red; Exit}
ForEach ($name in $Domain.Split(".")) {$tempDomain += ",DC=$($name)"}


$rangeUpperHash = @{}
$rangeUpperHash.Add("Exchange 2016 CU3 and CU4", "15326")
$rangeUpperHash.Add("Exchange 2016 CU2", "15325")
$rangeUpperHash.Add("Exchange 2016 CU1", "15323")
$rangeUpperHash.Add("Exchange 2016 Beta and RTM", "15317")
$rangeUpperHash.Add("Exchange 2013 CU7 and later", "15312")
$rangeUpperHash.Add("Exchange 2013 CU6", "15303")
$rangeUpperHash.Add("Exchange 2013 CU5", "15300")
$rangeUpperHash.Add("Exchange 2013 SP1", "15292")
$rangeUpperHash.Add("Exchange 2013 CU3", "15283")
$rangeUpperHash.Add("Exchange 2013 CU2", "15254")
$rangeUpperHash.Add("Exchange 2013 CU1", "15254")
$rangeUpperHash.Add("Exchange 2013 RTM", "15137")

$objVerDNCHash = @{}
$objVerDNCHash.Add("Exchange 2016 Beta to CU4", "13236")
$objVerDNCHash.Add("Exchange 2013 RTM to CU10", "13236")

$objVerCNCHash = @{}
$objVerCNCHash.Add("Exchange 2016 CU4", "16213")
$objVerCNCHash.Add("Exchange 2016 CU2 and CU3", "16212")
$objVerCNCHash.Add("Exchange 2016 CU1", "16211")
$objVerCNCHash.Add("Exchange 2016 RTM", "16210")
$objVerCNCHash.Add("Exchange 2016 Beta", "16041")
$objVerCNCHash.Add("Exchange 2013 CU10 and later", "16130")
$objVerCNCHash.Add("Exchange 2013 CU6 to CU9", "15965")
$objVerCNCHash.Add("Exchange 2013 CU5", "15870")
$objVerCNCHash.Add("Exchange 2013 SP1", "15844")
$objVerCNCHash.Add("Exchange 2013 CU3", "15763")
$objVerCNCHash.Add("Exchange 2013 CU2", "15688")
$objVerCNCHash.Add("Exchange 2013 CU1", "15614")
$objVerCNCHash.Add("Exchange 2013 RTM", "15449")

$msExchProductIdHash = @{}
$msExchProductIdHash.Add("Exchange 2016 CU5", "15.01.0845.032")
$msExchProductIdHash.Add("Exchange 2016 CU4", "15.01.0669.032")
$msExchProductIdHash.Add("Exchange 2016 CU3", "15.01.0544.027")
$msExchProductIdHash.Add("Exchange 2016 CU2", "15.01.0466.034")
$msExchProductIdHash.Add("Exchange 2016 CU1", "15.01.0396.030")
$msExchProductIdHash.Add("Exchange 2016 RTM", "15.01.0225.042")
$msExchProductIdHash.Add("Exchange 2016 Beta", "15.01.0225.017")
$msExchProductIdHash.Add("Exchange 2013 CU15", "15.00.1263.005")
$msExchProductIdHash.Add("Exchange 2013 CU14", "15.00.1236.003")
$msExchProductIdHash.Add("Exchange 2013 CU13", "15.00.1210.003")
$msExchProductIdHash.Add("Exchange 2013 CU12", "15.00.1178.004")
$msExchProductIdHash.Add("Exchange 2013 CU11", "15.00.1156.006")
$msExchProductIdHash.Add("Exchange 2013 CU10", "15.00.1130.007")
$msExchProductIdHash.Add("Exchange 2013 CU9", "15.00.1104.005")
$msExchProductIdHash.Add("Exchange 2013 CU8", "15.00.1076.009")
$msExchProductIdHash.Add("Exchange 2013 CU7", "15.00.1044.025")
$msExchProductIdHash.Add("Exchange 2013 CU6", "15.00.0995.029")
$msExchProductIdHash.Add("Exchange 2013 CU5", "15.00.0913.022")
$msExchProductIdHash.Add("Exchange 2013 SP1", "15.00.0847.032")
$msExchProductIdHash.Add("Exchange 2013 CU3", "15.00.0775.038")
$msExchProductIdHash.Add("Exchange 2013 CU2", "15.00.0712.024")
$msExchProductIdHash.Add("Exchange 2013 CU1", "15.00.0620.029")
$msExchProductIdHash.Add("Exchange 2013 RTM", "15.00.0516.032")


$rangeUpper = (DSQUERY.exe * "CN=ms-Exch-Schema-Version-Pt,CN=schema,CN=configuration$($tempDomain)" -Scope base -Attr rangeUpper)[1].Trim()
$objVerDNC = (DSQUERY.exe * "CN=Microsoft Exchange System Objects$($tempDomain)" -Scope base -Attr objectVersion)[1].Trim()
$objVerCNC = (DSQUERY.exe * "CN=$ExOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration$($tempDomain)" -Scope base -Attr objectVersion)[1].Trim()
$msExchProductId = (DSQUERY.exe * "CN=$ExOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration$($tempDomain)" -Scope base -Attr msExchProductId)[1].Trim()

Write-Host "rangeUpper (Schema)           : $rangeUpper ($(($rangeUpperHash.GetEnumerator() | ? {$_.Value -eq $rangeUpper}).Name -join ' | '))"
Write-Host "objectVersion (Default)       : $objVerDNC ($(($objVerDNCHash.GetEnumerator() | ? {$_.Value -eq $objVerDNC}).Name -join ' | '))"
Write-Host "objectVersion (Configuration) : $objVerCNC ($(($objVerCNCHash.GetEnumerator() | ? {$_.Value -eq $objVerCNC}).Name -join ' | '))"
Write-Host "msExchProductId               : $msExchProductId ($(($msExchProductIdHash.GetEnumerator() | ? {$_.Value -eq $msExchProductId}).Name -join ' | '))"

 

User Photo in Exchange, Lync and Active Directory

There are several posts out there about how to upload users’ photos into Active Directory (AD) so they can be used by Exchange or Lync, but very few on how this works or how to export them if we need to.

In AD we can use images no greater than 96×96 pixels in resolution and 100KB or smaller in size. This looks ok in the Lync and Outlook client, but results in a blurred photo when Lync, for example, attempts to upscale the image for use in a conference.

In Lync 2013 (and Skype for Business Server 2015) photos can be stored in the user's mailbox (when using Exchange 2013), allowing for photo sizes up to 648x648 pixels. In addition to that, Exchange automatically resizes these photos for use in different products as needed:

• 64x64 pixels (96 dpi, 24 bit depth, approx. 2KB), the size used for the AD thumbnailPhoto attribute. If we upload a photo to Exchange, Exchange will automatically create a 64x64 pixel version of that photo and update the user's thumbnailPhoto attribute. However, if we manually update the thumbnailPhoto attribute in AD the photo in the user's mailbox will not automatically be updated. This photo is only used by Lync 2010 or legacy clients, so we are ok;
• 240x240 pixels if the original picture is larger than 240, otherwise 96 (96dpi, 24 bit depth, approx. 8KB), for use in Outlook, OWA, Skype for Business Web App, and Skype for Business;
• 648x648 pixels for use in Skype for Business and Skype for Business Web App.

Importing Photos

To use high resolution photos, we have to use the Set-UserPhoto Exchange cmdlet:

Set-UserPhoto “Nuno Mota” -PictureData ([System.IO.File]::ReadAllBytes(“D:\Photos\nuno.jpg”)) –Confirm:$False

As already mentioned, the Set-UserPhoto cmdlet does two things: it stores a copy of a high resolution image in the user’s Exchange mailbox, and stores a copy of the photo as a 64×64 image in the thumbnailPhoto AD attribute.

Exporting Photos

To check someone’s photo, we can use Exchange Web Services and the following URL (updating the user’s email and maybe image size):

https://mail.domain.com/ews/Exchange.asmx/s/GetUserPhoto?email=nuno@domain.com&size=HR648x648

 

If we want to export a user’s photo from AD, we can PowerShell and the following commands:

$photo = (Get-ADUser nuno -Properties thumbnailphoto).thumbnailphoto

We can now save this photo into a JPEG file and or import it directly to a different user for example (useful if the user gets a new account):

Set-Content “D:\Photos\nuno.jpg” -Encoding byte
Set-ADUser mota -Replace @{thumbnailphoto = $photo}

However, if we are using Exchange 2013, we should use Exchange cmdlets to manage users’ photos. This way we can export the 648x648 pixels photo from the user’s mailbox instead of the small one from AD:

(Get-UserPhoto nuno).PictureData | Set-Content “D:\Photos\nuno.jpg” -Encoding byte

If you want to use high resolution photos in Lync as well, you might want to ensure you update your Lync Client policy with a MaxPhotoSizeKB of at least 100 instead of just 30.

Exchange Management Shell and Active Directory

Working in multi-domain / multi-site environments can sometime be tricky if we don’t know how the Exchange Management Shell (EMS) queries Active Directory (AD) in these scenarios.

In Exchange 2013 and 2010, we can use the Set-AdServerSettings cmdlet to manage the Active Directory Domain Services (ADDS) environment in the current EMS session. This cmdlet cmdlet replaces the AdminSessionADSettings session variable that was used in Exchange 2007 (which we will look at in a minute).

The following example specifies that all recipients in the entire forest can be viewed and managed (by default, only those in the local domain are used):

Set-AdServerSettings -ViewEntireForest $True

The following example sets the recipient scope to the IT Users OU in the nunomota.pt domain for the current session:

Set-AdServerSettings -RecipientViewRoot “nunomota.pt/IT Users”

The following example sets the scope of the current session to the entire forest and designates dc1.nunomota.pt as the preferred global catalog server.

Set-AdServerSettings -ViewEntireForest $True -PreferredGlobalCatalog dc1.nunomota.pt

The following are the most common parameters that administrators change:

• PreferredGlobalCatalog: specifies the FQDN of the global catalog server to be used for reading recipient information in this session;

• PreferredServer: specifies the FQDN of the domain controller to be used for this session;

• RecipientViewRoot: specifies the OU to include in the recipient scope for this session. When we specify a recipient scope with this parameter, only the recipients included in the scope are returned;

• ViewEntireForest: when we specify a value of $true, the value stored in the RecipientViewRoot parameter is removed and all of the recipients in the forest can be viewed and managed.

As already mentioned, in Exchange 2007 we had a variable named $AdminSessionADSettings for this purpose. To achieve the same as the examples above, all we have to do is update this variable as follows.

The following example specifies that all recipients in the entire forest can be viewed and managed (by default, only those in the local domain are used):

$AdminSessionADSettings.ViewEntireForest = $True

The following example sets the recipient scope to the IT Users OU in the nunomota.pt domain for the current session:

$AdminSessionADSettings.DefaultScope = “nunomota.pt/IT Users”

To set the recipient scope to the nunomota.pt domain and use dc1.nunomota.pt as the recipient domain controller, run the following commands:

$AdminSessionADSettings.DefaultScope = “nunomota.pt”

$AdminSessionADSettings.PreferredDomainControllers = “dc1.nunomota.pt”

Changing the recipient scope in the EMS changes the set of recipients that are returned for the Get- cmdlets of the recipient. The fields that are stored in the $AdminSessionADSettings variable are retained until the EMS is closed and is reset to its default settings the next time that the EMS is opened.

To make the changes permanent, we have to manually edit the Bin\Exchange.ps1 file in the Exchange Server installation folder and update lines such as:

$global:AdminSessionADSettings.ViewEntireForest = $false

DirSync Attributes Synced

Have you ever wondered exactly which Active Directory (AD) attributes are synced from the on-premises AD to Windows Azure AD and/or which AD attributes are written back to the on-premises AD from Azure AD in an Exchange hybrid deployment scenario?

 

If yes, then the following Wiki has the answer: DirSync: List of Attributes that are Synced by the Windows Azure Active Directory Sync Tool.

 

It also details how DirSync determines what is not synced (excluded) from the on-premises environment to Windows Azure AD.

How to manually force a Directory Synchronization with the new DirSync tool

In the latest release of the Windows Azure Directory Synchronization tool (aka DirSync), the way we manually force a directory synchronization has changed.

In previous versions, we had to navigate to the location where DirSync was installed, launch DirSyncConfigShell.psc1 (PowerShell Console) and then run the Start-OnlineCoexistenceSync cmdlet:

 

 

However, in this latest version this console file does not exist anymore:

 

 

So how do we manually force a directory synchronization now?! Well, DirSync cmdlets are now part of a PowerShell module named DirSync. As such, simply lunch a PowerShell console with administrative rights, import this module and run the usual Start-OnlineCoexistenceSync cmdlet. Simple as that!

 

This change, however, will obviously break any scripts you might have developed, but it shouldn’t be hard to update them.

As expected, if you try to import this module in an older version of DirSync, you will get the following error as the module does not exist:

 

 

If we try to list all the cmdlets available in this module, we actually don’t receive anything back:

 

 

So where are all the DirSync PowerShell cmdlets we had in previous versions?! Not to worry. The DirSync module is actually just a wrapper which calls “%programfiles% \Windows Azure Active Directory Sync\DirSync\DirSync.psd1”. As such, if we want to list all the cmdlets, we have to check the Microsoft.Online.Coexistence.PS.Config module instead:

 

 

Unfortunately not all of these cmdlets are fully documented yet, but we can guess what most of them do based on their name anyway.

 

 

In my opinion, this change is more than welcomed as it makes life a lot easier!

Azure Active Directory Sync Services goes Beta

Microsoft Azure Active Directory Sync Services (AADSync) has been announced as Customer Technology Preview (CTP) and is available through the Connect site.

AADSync, which is the next iteration of FIM2010 and DirSync, is used to onboard an on-premises environment to Windows Azure Active Directory and Office 365 and continue to synchronize changes. This new version allows for more advanced scenarios where DirSync, targeted at organizations with a single-forest, does not provide support for. Although FIM addresses scenarios that DirSync does not, it is often too complex for most IT admins to configure. With AADSync Microsoft is making this configuration a lot easier and more predictive.

One example of such scenario is the “Fully mesh with optional GALSync”, which allows users and resources to be located in any forest (commonly there would be two-way trusts between the forests). If Exchange is present in more than one forest, there could optionally be a GALSync solution representing a user in one forest as a contact in each other forest.

 

In this picture, AADSync would join on the mail attribute so a user with a mailbox in one forest is joined with the contacts in the other forests. Distribution and security groups can be found in each forest and can contain a mix of users, contacts, and FSPs (Foreign Security Principals).

For more information, please visit www.aadsync.com. Note that the content on this site will be moved to TechNet once AADSync has been released.

Stay tuned for further details on AADSync!

DirSync Password Synchronization

The latest version of the Windows Azure Active Directory (WAAD) Sync Tool, also known as DirSync, has just been released.

Besides supporting Windows Server 2012, this new version provides the much anticipated Password Sync feature, which enables users to log into their Azure Active Directory services (such as Office 365, InTune, CRM Online, etc.) using the same password as they use to log into their on-premises network.

However, this should not be seen as a replacement for ADFS. Rather, it is an alternative for organizations that find it sufficient to have users using the same password in Office 365 as in the on-premises Active Directory. ADFS provides many other features that this tool does not, one of them being Single-Sign On (SSO) where users only need to authenticate once when they are logged on to a domain-joined client machine. With this new tool, and without ADFS, users will get prompted for credentials when accessing Office 365 resources even if they are on a domain-joined machine. The advantage is that the username and passwords are the same, and when users update their credentials on Active Directory, the password will get synchronized to WAAD. This tool does not provide SSO because there is no token sharing/exchange in the Password Sync based process.

How Password Sync Works
The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to an on-premises network and it is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service. The actual data flow of the password synchronization process is similar to the synchronization of user data such as DisplayName or Email Addresses.

Passwords are synchronized more frequently than the standard Directory Sync window for other attributes. Passwords are synchronized on a per-user basis and are generally synchronized in chronological order. When a user’s password is synchronized from the on-premises AD to the cloud, the existing cloud password will be overwritten.

When the Password Sync feature is first enables in DirSync, it will perform an initial synchronization of the passwords of all in-scope users from the on-premises Active Directory to Azure Active Directory. You cannot explicitly define the set of users that will have their passwords synchronized to the cloud. Subsequently, when an on-premises user changes their password, the Password Sync feature will detect and synchronize the changed password, most often in a matter of minutes. The Password Sync feature will automatically retry failed user password syncs. If an error occurs during an attempt to synchronize a password the error is logged in event viewer.

The synchronization of a password has no impact on currently logged on users. If a user that is logged into a cloud service also changes their on-premise password, the cloud service session will continue uninterrupted. As soon as the cloud service session expires, the user has to re-authenticate using the new password.

Security Considerations
When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment.

Password Policy Considerations
There are 2 types of password policies that are affected by enabling password sync:

• Password Complexity Policy: when you enable password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users;
• Password Expiration Policy: if a user is in the scope of the password sync feature, the cloud account password is set to "Never Expire". This means that it is possible for a user's password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password. The cloud password will be updated the next time the user changes the password in the on-premises environment.

Enabling Password Sync
Password Sync is enabled when running the Directory Sync tool Configuration Wizard. When prompted by the Wizard, select the “Enable Password Sync” checkbox. This process will trigger a full synchronization which generally takes longer than other sync cycles to complete.

NOTE: DirSync is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature will not function correctly if DirSync is installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

 

The new version of DirSync (v1.0.6385.0012) can be downloaded from your respective Office 365 Admin portal or from here.

DirSync Filtering

Introduction

If you subscribe to Microsoft Office 365 (with the exception of the Small Business Plan) and your company already has users in a local Active Directory [AD] environment, you can use the Microsoft Online Services Directory Synchronization [DirSync] tool to synchronize those users to your Office 365 directory.

By using DirSync, you can keep your local AD in constant synchronization with Office 365 so that any changes made to users such as contact updates for example, are propagated to Office 365.

This allows you not only to create synchronized versions of each user account and group, but also allows Global Address List [GAL] synchronization from your local Exchange environment to Exchange Online.

Synchronization

Until now, one of the problems of DirSync was that it would sync your entire AD to Office 365. This means that if you had 10,000 AD users and only wanted 500 in Office 365, you would have all 10,000 users listed in Office 365... There were a couple of methods of excluding certain objects, but none supported by Microsoft.

DirSync Filtering has been possible for early Office 365 for Education customers but now it is available to all customers, allowing you to easily exclude Organizational Units [OUs], for example, from being synchronized. Let’s have a look.

DirSync is simply a pre-configured Microsoft Identity Integration Server [MIIS] installation specific for Office 365 integration. What some administrators don’t know is that MIIS can be customized by using the MIIS Client located at:

• 32-bit: %SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell

• 64-bit: %SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell

WARNING: Before we proceed, please be very careful when using MIIS Client as it can cause harm to your office 365 environment if not used properly!

Filtering

At the time of writing of this post, there are 3 filtering options that can be applied to DirSync:

1. Organizational Units based, which allows you to select which OUs are to be synced to the cloud;

2. Domain based, allowing you to select which domains are synchronized to the cloud;

3. User attribute based, enabling you to control which objects shouldn’t be synchronized to the cloud based on their AD attributes.

NOTE: If you have already run DirSync and synced all your AD into Office 365, the objects that you now filter will no longer be synchronized and will be deleted from the cloud! If you excluded, and subsequently deleted objects because of a filtering error, you can easily re-create them in the cloud by removing the filter and then syncing the directories again.

Organizational Units Based Filtering

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Directory Partitions and then click Containers;

5. When prompted, enter domain credentials for your on-premises domain and then click OK;

6. In the Select Containers dialog box, clear the OUs that you don’t want to sync;

7. If you click in Advanced... you will be able to further control which OUs to include and exclude;

8. Click OK three times;

9. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

10. Once finished, you can check the results at the bottom left corner of the window.

Domain Based Filtering

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Directory Partitions and then select the domains that you want to synchronize. Because in my environment there is only one domain, I only get one domain listed. To exclude a domain simply clear its check box;

5. Click OK;

6. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

7. Once finished, you can check the results at the bottom left corner of the window.

User Attribute Based Filtering

As the name suggests, this third option can only be applied to user objects. It is possible to filter contacts and groups, but these use other and more complex filtering rules.

To exclude users from filtering, we can utilize around 114 AD attributes. For example, you can set extensionAttribute10 to “noOffice365” for all the users you don’t want to sync and then create a filter rule to exclude these from synchronization. After you configure in AD the attribute you want to look, here’s how you configure MIIS:

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Connector Filter;

5. Select user in the Data Source Object Type column. In here you can see some examples of accounts being excluded already such as Exchange System mailboxes or the MSOL_AD_Sync account used by DirSync;

6. Click New;

7. In Filter for user, on the Data Source attribute, select extensionAttribute10. For Operator select Equals and then type noOffice365 in the Value field. Click Add Condition and then click OK;

8. Click OK again;

9. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

10. Once finished, you can check the results at the bottom left corner of the window.

Hope this helps!

Exchange AD Schema Changes

We all know that with every Exchange Service Pack [SP] we have to run the usual setup /PrepareSchema (or setup /ps) in order to prepare the Active Directory Domain Services Schema for the newer version of Exchange. This is because every new SP introduces new attributes and modifies some existing classes and attributes in the Schema. But what exactly is added and/or changed?! To help answering this question, Microsoft made available the Exchange Server Active Directory Schema Changes Reference document.

The latest version of the document, from November 2011, includes changes made by:

• Exchange Server 2010 SP2, SP1 and RTM
• Exchange Server 2007 SP3, SP2, SP1 and RTM
• Exchange Server 2003

Not sure why the file is not available a “simple” download, but you have to download a nADSchemaRef.msi file, install it and then get the document from (by default) C:\Program Files\Microsoft\ExDevCenterDownloads\Exchange Server Active Directory Schema Changes Reference. Very strange...

DOWNLOAD: Exchange Server Active Directory Schema Changes Reference,November 2011

Other alternative you have, is by looking at all the .ldf files that are used in the process, which are located in the \amd64\Setup\Data\ directory on the setup DVD.

I recon you will prefer the first method   :)