Force Sync to Office 365 with New DirSync

On June 3, the Directory Synchronization tool was updated.  It is now known as the Windows Azure Active Directory Sync tool and is available to Office 365 customers within their portal.

The following is an update to an earlier post, “Force DirSync for Office 365“.

There might be occasion where a change in your on-premise Active Directory will need to be forcibly replicated to your Office 365 account.  Maybe it is for a new user or a change in a user attribute.  In any case, the standard scheduled sync occurs every 3 hours.  However, we have been given the tools to synchronize those changes on our terms.

From your DirSync server, open PowerShell and navigate to C:\Program Files\Windows Azure Active Directory Sync.  Then enter, .\DirSyncConfigShell.psc1.  A new PowerShell console will open.

From this console, type Start-OnlineCoexistenceSync and press enter.  This command will begin a synchronization of the changes made in the on-premise AD to Office 365.  It is the same command that is automatically scheduled to run every 3 hours.

Once the synchronization is complete, the Office 365 Users management portal will show “Last synced less than an hour ago“.  The Application log in the Event Viewer on the DirSync server will show several events.  The primary one to watch for is Directory Synchronization Event ID 114–this shows us the “Export cycle completed. Tracking id: …

Microsoft Forefront Identity Manager (FIM) 2010 R2…

FIM is another way to check if the sync has completed successfully and, maybe even more importantly, check what users and attributes have been synced.  FIM is installed with DirSync.  FIM has a application know as the MIIS client that can be located in C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell.  In this folder, double-click miisclient.exe to open Forefront Synchronization Service Manager (FSSM).

From the Operations section of FSSM, we can monitor the sync process and granular changes.  In the Export Statistics section (bottom left of window) within Operations, we can see (and even double-click) the adds, updates, renames and deletes.  In the Object Details, granular information can be viewed by selecting the properties of a Distinguished Name.

by Todd Nelson (@oddytee)

Advertisements

On-premise Mail Flow Issue After AD FS Decommission

In my lab last week, I decommissioned AD FS and DirSync to bring Exchange back on-premise after a brief period of co-existence.  The only federated user I had for this environment was no longer able to receive mail in to the on-premise mailbox–however I could send as that user.  The inbound SMTP logs all showed the communication but no successful completion of the connection.

I confirmed the TargetAddress attribute was no longer pointing to the onmicrosoft.com address.

The NDR message received looked like this…

     Delivery has failed to these recipients or distribution lists:

     User

     A problem occurred during the delivery of this message. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message later, or provide the following diagnostic text to your system administrator.

     Diagnostic information for administrators:

     Generating server: exchangeserver.domainname.local

     user@domainname.com

     #< #5.4.6> #SMTP#

The local administrator account also has a mailbox and is able to receive external messages without an issue.  And when I checked this mailbox found NDR messages similar to those just below.  Luckily, I set up the administrator mailbox as the postmaster to be able to see this information…

     The following recipient(s) cannot be reached:

           User on 5/13/2013 11:09 AM

                 A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients.  Contact your administrator.

                 <exchangeserver.domainname.local #5.4.6>

I was able to use the information above to trigger a thought, “Eventhough I removed the reference to onmicrosoft.com, maybe the TargetAddress attribute is still not correct”.

That is when I noticed my mistake, I changed to user@domainname.onmicrosoft.com to user@domainname.com and this is the reason the mailbox would not receive emails–from external and internal senders.  The TargetAddress attribute must be cleared if you want mail to flow properly into an on-premise mailbox.  Any value that is set in this field will attempt to send the message out of the environment even when that email address is local to the environment.  Once the TargetAddress attribute was cleared to <Not Set>, mail flow resumed.

by Todd Nelson

Check Current Active Directory or Exchange Server Schema Version

Need to determine what AD and Exchange Server schema versions are installed?  Run the following three commands from an elevated Command Prompt…

For Exchange Server schema version…

dsquery * “cn=ms-exch-schema-version-pt,cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr rangeUpper

For AD forest version…

dsquery * “cn=first organization,cn=microsoft exchange,cn=services,cn=configuration,dc=domainname,dc=local” -scope base -attr objectVersion

For AD domain version…

dsquery * “cn=microsoft exchange system objects,dc=domainname,dc=local” -scope base -attr objectVersion

Reference(s): http://support.microsoft.com/kb/556086

by Todd Nelson