Sunday, September 28, 2014

Trigger a Full Sync of Passwords for DirSync

Normally the only time you need to do a full synchronization of passwords with DirSync is after you install it. By default, when you complete the configuration wizard it performs a full synchronization of passwords. After that point passwords are synchronized only accounts are created or when the password is changed.

One potential issue that can pop up is changed passwords on the Office 365 side. When passwords are synchronized to Office 365, it is still possible to change them in Office 365 for the user account. This is not recommended from a management perspective, but administrators make bad choices once in a while. When this happens the account is out of sync between on-premises and Office 365.

To ensure that all passwords in Office 365 match their on-premises account, you can trigger the same type of full password synchronization that occurs after DirSync is installed. Perform the following steps:
  1. Open a Windows PowerShell prompt.
  2. Type Import-Module DirSync and press Enter.
  3. Type Set-FullPasswordSync and press Enter.
  4. Use the Services console to restart the Federation Identity Manager Synchronization Service.

Note: If you try to use the Restart-Service cmdlet to restart the Federation Identify Manager Synchronization Services, you will need to use the -Force parameter and it will not restart the Windows Azure Active Directory Sync Service properly.

You can verify the synchronization was successful by looking for Event ID 657 in the Application event log that shows the passwords being synchronized.

Wednesday, September 24, 2014

Firewalls and Proxy for Exchange 2010 Hybrid Mode

Most of the time when we configure hybrid mode, the CAS servers have unrestricted access to the Internet. However, not all organizations allow this. I recently ran into a couple of proxy configuration issues when setting up hybrid mode for a client.

The first errors we got were during the setup of hybrid mode creating the federation trust. However, we would have had ongoing issues because the CAS servers in the on-premises Exchange installation need to communicate with O365 servers to perform tasks such as free busy lookups. I had been assuming the CAS servers had direct Internet access but forgot to confirm with the client.

When creating the federation trust initially we ran into the following:
Unable to access the Federation Metadata document from the federation partner. Detailed information: "Unable to connect to the remote server."
The good news is that error instantly makes you think network connectivity. This error is generated when the the CAS server cannot communicate with the following URL:
  • https://nexus.microsoftonline-p.com/FederationMetadata/2006-12/FederationMetadata.xml
In this case the client uses a proxy server for all outbound http/https traffic. Exchange server will not use the proxy configured in Internet Explorer/Windows. Instead you need to manually configure the proxy server used by Exchange server with the following cmdlet:
Set-ExchangeServer -Identity CASServer -InternetWebProxy:http://proxy:port
After setting the proxy for Exchange Server, we got an error:
(407) Proxy Authentication Required
At this point, there really is nothing we can do because there is no way for Exchange Server to provide authentication to the proxy server. So, we worked with the network team to modify the proxy configuration to not require authentication for the CAS servers. They configured those exceptions based on the IP address of the CAS servers.

For this particular organization, the other alternative would be allowing the CAS servers to communicate directly out, but only to the specific servers required. Microsoft provides a list of Exchange Online and Federation Proxy server IP Addresses to restrict outbound communication if required, but this is a large list and there is the possibility of change over time. This blog post has the links to the IP addresses:
Based on my research, another issue that can occur related to proxy settings is the use of WPAD (Web Proxy Autodiscovery Protocol). Apparently Exchange Server will use this if it's available, even if you have manually set the the proxy with Set-ExchangeServer. So, you may need to disable that if it's in use. Fortunately, this is an easy one, just stop and disable the WinHTTP Web Proxy Auto-Discovery Service.

Our second issue with the proxy server occured when we were adding Exchange Online as a forest in the Exchange Management console.I neglected to get the exact error message, but it was similar to this:
The attempt to connect to https://ps.outlook.com/PowerShell/PowerShell.htm using "Basic" authentication failed. Connecting to the remote server failed with the following error message: The WinRM client is unable to connect.
The good part about this error message is that it tells us what software in unable to connect. Seeing that it's the WinRM client gave us an indication that this is likely the same type of proxy issue that we had with the Federation Trust. However, since the WinRM client is not part of Exchange Server the Set-ExchangeServer cmdlet we used earlier had no effect. Instead we used netsh to import the proxy settings from IE for use by all windows services.
netsh winhttp> import proxy source = ie
I'm not sure whether the WinRM client runs with the security credentials of the user or not. We ran this command on the CAS servers so there were no issues with authentication to the proxy because the proxy already allowed the CAS servers directly out without authentication.

Monday, September 22, 2014

Dirsync Filtering: missing-partition-for-run-step

Normally when you install Dirsync (Windows Azure Active Directory Synchronization Service), you synchronize your entire AD forest. This is the default configuration that Dirsync uses. However, sometimes it's useful (or at least comforting) to synchronize only part of your organziation at a time.

When you filter by organizational unit, there are no issues. You can select the specific OUs that you want synchronized an it will work.

When you attempt to filter by domain, you will get the following error that is visible in Synchronization Service Manager:
Step Type: Full Import (Stage Only)

Partition: DC=deselectedSubdomain,DC=domain,DC=com

Status: missing-partition-for-run-setup
Despite the fact the Dirsync graphical interface is perfectly fine with deselecting a domain, the scripts created during the installation for performing synchronization are not. You can view the code for the steps and probably could edit that code, but that's a little risky for my tastes. Instead the suggested work around is:
  1. In each domain you want to filter, create an empty OU.
  2. Configure OU filtering for each domain you want to filter to include only that empty OU.
It feels like cheating, and not very graceful, but it gets the job done.

Thursday, September 18, 2014

Chrome Invalidates Certificates using SHA-1 in November 2014

Certificates are used to secure digital communication. The most common security measure is SSL/TLS which is used to protect communication with web sites and other services. The certificates used to secure communication have an algorithm that is used to create has values. SHA-1 was a commonly used hash algorithm.

In November of 2013, Microsoft indicated that Windows would not accept certificates using SHA-1 as valid starting in 2017. Most certificates expire after 1-3 years providing ample time to update existing certificates during normal renewal processes.

I just received a notification that Google Chrome will start marking web sites using certificates with SHA-1 as invalid starting in November 2014 if the expiry date of that certificate is after 2015. That is a much faster time frame.

A review of our clients has revealed that only one certificate is using SHA-1 at this time. All of the others are using SHA-256 (one of the larger set of SHA-2 algorithms). For this one client, we need to rekey the certificate to use the new algorithm.

Specific instructions for rekeying vary depending on your SSL provider.

Some potential issues with SHA-2:
  • If you have legacy servers such as Windows Server 2003, you need to update them to support SHA-2 by installing a hotfix (http://support.microsoft.com/kb/968730). This is required for Exchange 2003 servers if you have them or older web servers.
  • If you are using GoDaddy digital signing certificates, the Java security store does not automatically trust the SHA-2 based certificates yet. Apparently, this is in the works and will be complete within the next few months. So, in the short term you may want to keep SHA-1 for that purpose. The Chrome change in November 2014 won't affect Java signing.

References:

Monday, September 15, 2014

Windows 9 Has a Start Menu

Some screenshots and videos are showing up for Windows 9 Technical Preview. I'm not sure what else is in there, but the one I care about is the Start menu. It's back!

Right from the time Windows 8 came out, it bothered me that they tried to use a tablet interface on desktop computers. According to articles, Windows 9 will change the interface depending on the type of device. So, tablets can retain the Start screen (which makes sense) and PCs can have the start menu.

If this all turns out to be true for the release product I think I can finally get customers moving on the new OS instead of sticking with Windows 7.

A YouTube video of the Windows 9 Start menu is below:


Please note that the product name of Windows 9 is not yet confirmed.

Wednesday, September 3, 2014

Saturday, August 16, 2014

Network Error When Adding DAG Member in DR Site

I was adding a new DAG member in a disaster recovery (DR) site and got an error about networking. The error was as follows:
A server-side administrative operation has failed. 'GetDagNetworkConfig' failed on the server. Error: The NetworkManager has not yet been initialized. Check the event logs to determine the cause. [Server: NewMember.domain.com] It was running the command 'Get-DatabaseAvailabilityGroupNetwork | Sort-Objects -Property Name'.
This error is due to Active Directory replication latency to the DR site. The server in the DR site does not have the Active Directory changes in the configuration partition yet. However, if you look at Failover Cluster Manager, the new server is up in the DAG cluster.

You have two options:
  1. Wait for replication to complete. This typically takes 15 minutes between sites.
  2. Trigger replication to speed it up. After I triggered replication to the remote site and then triggered replication back the error was gone right away and I could move on with adding my database copies for the DR site.