Unhealthy Directory Synchronization Notification - Expired Credentials

As you may be aware, when there are issues with Dirsync connecting to O365, you get an Unhealthy Directory Synchronization Notification email. The email doesn't provide any information other than to check the event logs. I got this notification for my test environment recently.

I happened to have the Synchronization Service Manager (miisclient.exe) open on my Dirsync server and looked in there first. The Active Directory Connector had a status of Success, which is expected. So, all good on the local side. However, the Windows Azure Active Directory Connector had a status of "stopped-extension-dll-exception".

The Application event log gave more information:

• Directory Synchronization, Event ID 115 - Access to Windows Azure Directory has been denied
• Directory Synchronization, Event ID 0 - Update your password and try again
• Directory Synchronization, Event ID 655-  Failed credential provisioning ping

The cause of my error was an expired password on the account I was using for directory synchronization. I was using a dedicated cloud account in Office 365 that I was not monitoring. The password for the account expired and was not allowing authentication for the account.

The fix was to perform the following:

1. Log in to Office 365 as an administrator and reset the password for the directory synchronization account.
2. Update the password in Dirsync.

To update the password in Dirsync, you can run Directory Sync Configuration again. However, instead, I updated the credentials in Synchronization Service Manager. To do this in Synchronization Service Manager, use the following steps:

1. Open Synchronization Service Manager (miisclient.exe).
2. In Synchronization Service Manager, click Management Agents and double-click Windows Azure Active Directory Connector.
3. In the Properties window, click Connectivity.
4. On the Connectivity page, update the Password and click OK.
5. Run Start-OnlineCoexistenceSync (or wait for Dirsync to do it automatically)

Update Dirsync Credentials

The long term fix for this issue to prevent the Dirsync credentials from expiring on the account. In the graphical interface of O365 management, you can configure a password expiration policy for all cloud accounts but not individual cloud accounts. To set the password expiration policy for a single account, you need to use Windows PowerShell and the command Set-MsolUser -UserPrincipalName -PasswordNeverExpires $true.

A complete set of instructions is here:

• https://support.office.com/en-us/article/Set-up-user-passwords-to-never-expire-f493e3af-e1d8-4668-9211-230c245a0466?ui=en-US&rs=en-001&ad=US

Updated Exchange Online Protection Addresses - Jan 2015

Microsoft has indicated that they are going to be updating the Exchange Online Protection addresses in January 2015. Here is a link with the new IP addresses:

• http://technet.microsoft.com/en-us/library/dn163583%28v=exchg.150%29.aspx

What does this mean to you? Well, these are the outbound addresses from EOP to your on premises email system. So, if you are using EOP for your on-premises email system, you need to ensure that your firewall is updated to allow traffic from these IP addresses to your on-premises email system.

Also, it is not explicitly stated, but I would be concerned that mailflow for hybrid environments will be affected. So, it may be necessary to go into the receive connector used for hybrid mailflow and allow these IP addresses there also. I'll try to check on my hybrid system when the changes go into effect in January and update this post.

Terminal Services Device Redirector Missing

We have a client using SBS 2008 that is unable to use printer redirection to print locally when connected to the server via RDP. Printer redirection is basic functionality in RDP and normally works without any setup at all. We took over maintenance on this server from another organization about 4 years ago, but never had any need to test or use printer redirection until recently.

After taking a look at the event logs, we saw EventID 1103 for Microsoft-Windows-TerminalServices-Printers with the following message:

An internal communication error occurred.  Redirected printing will no longer function for a single user session.  Check the status of the Terminal Services Device Redirector in the System folder of Device Manager.

The Terminal Services Device Redirector is a device driver that is responsible for printer redirection. On this server, the Terminal Services Device Redirector did not exist in Device Manager. So, we need to install it.

Conveniently, several web sites provide instructions on how to use the devcon utility to install the RDPDR driver and get this going again. However, many of these are for Windows Server 2003. On Windows Server 2008, which is 64-bit, the included devcon utility doesn't work properly because it is 32-bit. The 32-bit version of devcon can query drivers, but not change or add them. It will give a delightfully generic error message of "Devcon Failed".

So, step 1 is to download the 64-bit version of devcon. It is included as part of the Windows Driver Kit. This article describes how to download the 600 MB Windows Driver Kit and extract only the 64-bit version devcon from it:

• http://social.technet.microsoft.com/wiki/contents/articles/182.how-to-obtain-the-current-version-of-device-console-utility-devcon-exe.aspx

After you have the correct version of devcon, installation of the Terminal Services Device Redirector is easy. Run the following command and then restart the server (note the space between inf and root):

• devcon -r install %windir%\inf\machine\inf root\rdpdr

After a reboot I was able to redirect printers properly. I have no idea how this went missing in the first place.

Microsoft has a TechNet article about this event (http://technet.microsoft.com/en-us/library/cc727392%28v=ws.10%29.aspx) but I found at least one item in it may be inaccurate. The article states that there should be a registry key for the RDPDR at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\RDPDR. The system I was working on did not have this registry key before or after I fixed it by installing the Terminal Services Device Redirector. Instead, there was some information added to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\System\0003. This may be because I added it manually.

The article also mentions the idea of reinstalling Terminal Services as a fix. Given that this server did not have Terminal Services installed, I'm not sure how we would have accomplished that. It had remote access enabled in Admin mode, but not full on Terminal Services.

If what I have written doesn't fix your issue with Terminal Services printing, take a look at this article by ChicagoTech.net. It has a whole bunch of issues to look at:

• http://www.chicagotech.net/RemoteAccess/printredirection1.htm