Reconnecting Cloud Users with Old/Previous/Moved AD User Objects

Posted on Updated on

dirsync_thumb For those admins who have been around the Microsoft Cloud Services, such as BPOS and Office 365 2010, you may remember the issue where DirSync takes a user object, takes it’s objectGUID, double-base-64 encodes it and sends to the cloud as a sourceAnchor. This sourceAnchor is used to flag the user as being synchronized by DirSync and managed by an on-premises Active Directory.

For those admins who are or have moved from one Active Directory Forest to another, the objectGUID changes while the online user maintains this old objectGUID/sourceAnchor. SO, what do you do to reconnect the cloud user with the new AD user?  You leverage set-msolUser and set their -ImmutableID, which allows DirSync to hard-match (AD objectGUID == sourceAnchor) and take over management of this cloud object.  If the sourceAnchor does not exist in the cloud, then DirSync does a soft-match, based on SMTP address(es) and if there is a match, DirSync takes over management. BUT in this particular scenario the sourceAnchor overrides a soft-match approach, which is why the –ImmutableID option must be used.

Steps to Set -ImmutableID

Allowing DirSync, AAD Sync, AAD Connect to Take Over Management

  1. Move user to new forest
  2. Take their ObjectGUID, found in Active Directory Users and Computers –> Advanced View –> Attribute Editor tab in user object Properties location OR use ADSIEdit and use this site to convert the “objectGUID” to a “sourceAnchor”, which will then be set to -ImmutableID.
    1. http://guid-convert.appspot.com/
  3. Use the Get/Set-MSOLUser –ImmutableID command to the converted GUID, done in the step above. Reference to command variables: https://msdn.microsoft.com/en-us/library/azure/dn194136.aspx
    1. Set-msoluser –Userprincipalname upn@company.com–ImmutableID “xxxxxxxxx”
  4. Launch DirSync/Sync/Connect and allow it hard match on the user in the cloud and now this Office 365 user is under DirSync/Sync/Connect control.

Managing EXO Online & AD User MBX Settings When Using DirSync and Rich Coexistence

Posted on Updated on


As some Office 365 administrators have noticed, licensing is a big part of their jobs, assigning and removing licenses for new hires and removing licenses from people who have been let go.  There is a corner case scenario where an Online Admin removes the online user’s Exchange Online License and any others that might be assigned and disables the online user.

When using this scenario while using Directory Synchronization AND Exchange Rich Coexistence (Sharing the same SMTP Namespace, Free/Busy Lookups, etc), you should use the following process when wanting to either disable or delete Online Users:

On-Premises Active Directory

  1. When using Active Directory and Directory Synchronization, you should understand that the source of authority for all online objects (Users, Contacts, Groups, etc) must be managed within Active Directory itself.
    1. Disabling
      1. Disable the on-premises Active Directory user and leverage DirSync to push this disablement into the cloud
        1. This will NOT remove the user’s license or mailbox at this time and the MBX can be used via Exchange Online Mailbox Search/eDiscovery
    2. Deleting
      1. When you would rather remove the user from your Online Environment and want to make this update permenant (removal of account from all environments), then you would want to remove the on-premises Active Directory user account and leverage DirSync to push this removal into the cloud
        1. This WILL remove the online user and any mailbox attached/associated with the account.  The Online Admin, if they want to save mail data, should login to the EXO MBX via Outlook and save all content to .pst before continuing.

There is a specific corner case scenario where an online Admin has removed an Exchange Online (EXO) license from a user located in on-premises Active Directory and synchronized and enablement with license within Office 365.  Removing the license in this way will cause the following effects:

    1. IF you remove an Exchange Online license from someone in Office 365 without using either of the Delete or Disable options listed above, your online user will have their EXO MBX disconnected, which is available for restore for up to ~30 days after this operation of removing the EXO MBX license.  Since the user’s MBX originally came from an on-premises AD and Exchange environment, the removal of the EXO license will not flow back via Directory Synchronization (DirSync Write-Back), thus leaving the on-premises mail-enabled user (with a targetAddress of user@contoso.onmicrosoft.com) which will continue to route mail to this online user who no longer has an EXO license and/or Mailbox.
      1. The best approach to this is to manage the user account, either using Delete or Disable which will allow the following effects to take place
        1. Delete in AD – Remove the user from AD (no more targetAddress for on-premsies Exchange to use in forwarding mail to the online user’s MBX
        2. Disable in AD – Disabling allows the AD mail-enabled user object (and targetAddress) to be maintained, allowing on-premises Exchange to forward mail to this online users MBX, even though the account is disabled (cannot login) and the user cannot login to the MBX themselves.

Note – It is best to manage the user instead of the license itself.  Removing an EXO license from an online user will do nothing more than disconnect the MBX, while leaving your on-premises Active Directory with the mail-enabled user, which is used by on-premises Exchange to route mail.  So if you no longer want/need the user and MBX == Delete. If you would rather maintain the user and MBX (requires the EXO license to remain applied) then Disable is the route to go.  Removing a license from online will leave your on-premises Active Directory with the mail-enabled user and targetAddress while leaving your online user still able to login and use other services within Office 365.

BPOS Transitioned Customers with DGs Instead of SGs in Office 365

Posted on Updated on

As you may know, in BPOS using DirSync that Security Groups (SGs) are converted into Distribution Groups(DGs) as BPOS did not have Security Groups as a type.  Many administrators who needed SGs for use in Outlook Delegation and/or SharePoint groups (assign permissions to groups and manage users in the group for effective management) had to request BPOS Operations to make this conversion back to SGs on behalf of the customer/administrator.


Customers who Transitioned from BPOS into Office 365 may fall into the following scenario:

  1. Transitioned into Office 365 from BPOS
  2. Ran DirSync V2 against Office 365 and found that their on-premises Active Directory Security Groups (SGs) are STILL listed as Distribution Groups in the new Exchange Online 365 environment, effectively not able to be used for security purposes.


When BPOS DirSync converts SGs to DGs for use, when the BPOS to Office 365 Transition completed, the DGs are brought over as DGs because that is the groupType set.  Once you run Directory Synchronization V2 against Office 365, Directory Synchronization does not check the groupType setting and finds the group already in the cloud and as such will NOT convert the group back to a Security Group (SG).

Proposed Solution

To fix this issue without needing to delete the on-premises Active Directory groups (delete, recreate and start over), you can use Directory Synchronization Filtering to have these groups removed in the cloud, so they can be created as SGs instead of being stuck as a DG.  For more information on Directory Synchronization Filter, please refer to:

Configure Filtering for Directory Synchronization

Use the above approach to put the DGs into a separate OU and configure DirSync Filtering to NOT synchronize that OU.  This will instruct DirSync to tell O365 MSODS that the groups have been removed and to remove them from the cloud.  Once done and verified that the groups are no longer available, DirSync Filtering can be removed by putting the groups back into the normal OU container and run DirSync.  It will pick up these groups, find they are SGs and synchronize them into the cloud.

Once the above has been done you will have effectively replaced the old DGs (converted during the BPOS DirSync operation) with the proper groupType as Security Group(s).

Office 365 Directory Synchronization Resources

Posted on Updated on

For those Office 365 Directory Synchronization administrators, here is a listing of Administration, Configuration and usage articles, links, lists and locations to help you in this endeavor:


Office 365 Management – Account Renames or Getting Married

Posted on

For those administrators who are using Active Directory Synchronization to bring all your users, contacts and groups into Office 365, you may have found that when someone gets married and for example has their last name changed, managing this in Office 365 may be tricky.  Here are the steps needed to properly manage this scenario:

Name Change/Getting Married

When someone’s last name changes, from Smith to Clark, either a request is sent requesting a last name change or the user is given a tool where they can change this themselves.  Once changed in Active Directory, DirSync will pick this change up and attempt to update the online company user’s last name information.

However in addition to simply a last name change, users typically change their login information (i.e. old: firstLastOld@contoso.com | new: firstLastNew@contoso.com) along with their email address.  Hopefully the users User Principal Name (UPN) and Email address are the same, if not that is another story, but lets continue.

So the user has her last name, UPN and Email Address changed within Active Directory and expects these updates to flow into the Online company, so the user will be seen with the new information within SharePoint, Outlook/OWA, etc.

Directory Synchronization Operations

Directory Synchronization WILL synchronize the lastName attribute and value along with email address changes HOWEVER the login UPN update will not be synchronized.  This means the user’s email and friendly “last name” display will be updated however the user’s old login UPN (firstLastOLD@contoso.com) will not be changed.


Use Microsoft Online for Windows PowerShell to change the activated online user’s UPN to match the users email address.  Once complete, the users UPN, Email and potentially SIP (Instant Messaging – If enabled for IM) will now be the same and allow the user one address they have to manage!

Windows Online PowerShellhttp://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125002.aspx#BKMK_ManageUsers

Set-MsolUserPrincipalName The Set-MsolUserPrincipalName cmdlet is used to change the User Principal Name (user ID) of a user. This cmdlet can be used to move a user between a federated and standard domain, which will result in their authentication type changing to that of the target domain.

Office 365 Directory Synchronization – Filtering Now Available

Posted on

For all the Office 365 administrators out there who have wanted to control which users, contacts and/or groups are synchronized into Office 365, that day has arrived:  http://community.office365.com/en-us/wikis/sso/configure-filtering-for-directory-synchronization.aspx

Until now, Directory Synchronization would synchronization ALL users, contacts and groups for your ENTIRE Active Directory Forest, allowing you as an administrator to then Activate which users need Online services and having Contacts and Groups  become available within your Online tenant/company.  With this new functionality, you can now control which objects are synchronized into the cloud, potentially reducing the time updates take, for example dramatically reducing the time it takes to perform a “Full Sync”.

Please review the above link which describes all of the different ways in which you can control this Filtering capability:

  1. Set up organizational-unit–based filtering
  2. Set up domain-based filtering
  3. Set up user-attribute–based filtering

Office 365 DirSync Database Running Out of Space? Automate Cleanup of Run History

Posted on Updated on

As you start using the Office 365 Directory Synchronization application, providing administrators the ability to manage users, contacts, groups and Active Directory attributes and values, all from your local Active Directory.  These updates/changes will be synchronized into your Office 365 tenant, keeping the two Active Directories synchronized.

Directory Synchronization runs, by default, every 3 hours, synchronizing all changes found within the local Active Directory.  Each run saves a history of the runs and over time your DirSync database will run out of space, due to saving these run histories.

Manage your Directory Synchronization


You are running the Office 365 / Directory Synchronization tool with a SQL Server Express backend.  You have less than 50,000 users.  Now, you are seeing information in the Application Event Log indicating that the database is full.


The reason this happens, is because each run is logged on the Operations tab of the MIISCLIENT.EXE console.  This is commonly referred to as the Run History.  If there is no process to clean up the run history, then it will continue to grow, and the MDF file of the SQL Server Express database will grow as well until you reach the 10GB limit.


To resolve the issue, you will need to clear the run history.  To prevent the issue from happening, you may need to build a script that can be called from Task Scheduler to clear the run history.

Clear Run History

Use the following steps outlined in this TechNet article to clear your Directory Synchronization Run History and keep your DB at a manageable size:  http://social.technet.microsoft.com/wiki/contents/articles/7034.how-to-clear-the-run-history.aspx


The goal of this article is to provide information on a good and common question, “How do I clear the run history?” to be able to reduce the size of my MDF / LDF files.

As many of us already know, if we do not clear the run history, then we run into issues such as

  • Performance of Synchronizations
  • Performance of moving between Management Agents and Operations tabs in the Synchronization Server Console.
  • Size of the MDF file has grown to extreme

This article has been compiled to help provide information on how to clear the run history.  We do provide several ways to clear the run history.  Let’s talk about them now.


In the MIISClient.exe GUI, found in c:\Program Files\Microsoft Online Directory Sync\SyncBus\Synchronization Service\UIShell\MIISClilent.exe, while viewing the run history on the Operations Tab, you can select from the Actions menu, “Clear Runs”.

In doing so, you will receive a dialog with a few choices.

  1. Clear All Runs: This will clear everything you see on the operations tab, essentially the run history.
  2. Clear Runs Before: This allows you to pick a date and time to remove that date and time and previous to that date and time.  It allows you to be able to keep some of the run history.
  3. Save runs before clearing them:  This box is checked by default.  It allows you to dump the run history to an XML file.

Once you configured how you want to clear the run history, you simply click Ok and then wait for it to finish clearing the run history.


The Synchronization Service engine has a WMI Provider that allows you to interface with the Synchronization Service Engine via WMI.

MSDN provides a great resource using the WMI Provider to build a script using VBSCRIPT and/or PowerShell.

MIIS_SERVER is the WMI Class that you will start with when building your script.

ClearRuns Method is the method that you will utilize to clear the runs.

Example Script to Clear Runs
Clear Run History Script
Dim Service

Dim ManagementAgent

Dim DeleteDate

Set Service = GetObject(“winmgmts:\root\MicrosoftIdentityIntegrationServer”)

Set Server = Service.Get(“MIIS_Server.Name=’MIIS_Server1′”)

‘// DeleteDate the date to use for the deletion of runs

DeleteDate = GETDELETEDATE( Date() – 1 )

WScript.Echo “Deleting Run Histories from ” & DeleteDate

WScript.Echo “Result: ” & Server.ClearRuns(DeleteDate)

‘// ======================================================================


‘// PURPOSE: To be able to execute an If…Then…Else statement on a single line

‘// — conditionalString: is the conditional statement to check via the IF

‘// — TrueString: if the condition is true, the statement to execute

‘// — FalseString: if the condition is false, the statement to execute

‘// ======================================================================

FUNCTION IIF(conditionalString, TrueString, FalseString)

IF conditionalString THEN

IIF = TrueString


IIF = FalseString



‘// ====================================================================


‘// PURPOSE: The date has to be formatted in a special way to work with the sync engine.

‘//     using this function to help format the date.

‘// ====================================================================


GETDELETEDATE = YEAR(TheDeleteDate) & “-” & IIF(LEN(MONTH(TheDeleteDate))=1,”0″ & MONTH(TheDeleteDate), MONTH(TheDeleteDate)) & “-” & IIF(LEN(DAY(TheDeleteDate))=1,”0″ & DAY(TheDeleteDate), DAY(TheDeleteDate))



If you have a version of the Synchronization Service Engine prior to Microsoft Forefront Identity Manager 2010, then you can utilize the Resource Kit for Microsoft Identity Integration Server 2003 and the MIISCLEARRUNS.EXE utility.

Download the Resource Kit 2.0 for the Microsoft Identity Integration Server 2003


How can I automate the clearing of the run history?

This is actually a great question.  You will need to write a script that does the clearing of the run history.  Once you have the script compiled utilize Task Scheduler to have the script run at a specified time.

How often should I clear the run history?

The answer to this question is based on your business rules for your current identity solution.  Keep in mind, that every time a run profile is executed, a record is added to the run history.

An example, if you have 2 management agents.  You run Full Import (Stage Only) on both, Full Synchronization on both, Export on both, and Confirming Delta Import on both Management Agents.  You execute this cycle every 30 minutes.

2 Management Agents x 4 Run Profiles = 1 cycle = 8 Records in the Run History every 30 minutes