The Fix is In! For the Exchange 2007 provisioning issue with ILM 2007 anyway…

Microsoft released the fix for the Exchange 2007 provisioning issue I blogged about earlier.  Essentially, Exchange didn’t properly use the domain controller parameter that was to the Update-recipient cmdlet, which in environments with multiple DCs would result in the mailbox not being properly provisioned because the DC in use by Update-Recipient didn’t know anything about the mailbox, as it was created on another DC.

Anyway, after a long wait (and a teaser release/un-release), Update Rollup 4 for Exchange Server 2007 SP1 has been re-released and contains the fix.  The KB article (949858) behind the specific issue is also public now.  Here are the details on the issue from the KB:

When ILM 2007 calls the Update-Recipient cmdlet to provision user objects, ILM 2007 passes a domain controller parameter to the Update-Recipient cmdlet to make sure that the task uses the same domain controller as the domain controller that was used where the object was created.

However, the Update-Recipient cmdlet creates two domain controller sessions. One session is for a domain controller, and the other session is for a global catalog server. The Update-Recipient cmdlet uses only the parameter that was passed for the global catalog server session, and it enables the Active Directory directory service driver to obtain a domain controller for the domain controller session. Then, the domain controller session is used for various operations, such as retrieving the properties of the object to pass to the Recipient Update Service.

If the domain controller that is selected for the domain controller session differs from the domain controller that is passed by ILM 2007, the Recipient Update Service object may not find the recipient. This issue occurs because of replication latency.

When this issue occurs, user objects may not be updated correctly by the Update-Recipient cmdlet. These objects are displayed as "mail users" instead of as "user mailboxes" in Exchange Management Console.

You can download Update Rollup 4 for Exchange Server 2007 SP1 here.

ISA 2006 and Slow LDAPS Authentication

I recently ran into an issue with LDAPS Authentication from ISA 2006 to an internal domain controller.  I am working with a client to deploy two ISA 2006 Enterprise Edition servers in their DMZ.  They have single NICs (NLB is enabled) and are not members of the internal domain, and are in their own workgroup (I know, I know, not an ideal use of ISA, but that’s a story for another time).  Because they are not in the domain, we decided to use LDAPS authentication (they already had an internal CA and certificates on all of their domain controllers).

Rules were added on the internal firewall rule to allow the ISA servers to do CRL checking to the internal CA and LDAPS traffic (port 636) to the domain controllers.  On the outside firewall, a rule was created to allow the ISA servers internet access for external CRL checking (this was needed to validate the third-party CA certificates in use on the published web servers when making the SSL connection from ISA to the web servers).

Once the rules were in place, the setup of LDAPS on the web listener was straightforward and it worked – sort of.  The initial login took about 15-20 seconds.  Subsequent logins were immediate, until LDAPS session were idle for too long, then the next login took 15-20 seconds again.

It was discovered that the internally issued certificates had both an Active Directory and HTTP CRL Distribution Point, and that AD was listed first.  The theory was the ISA was attempting to pull the CRL from AD first and failing, before succeeding in pulling the HTTP published version.

A coworker helped me find a series of registry keys that control CRL checking at the computer level.  Most of the CRL checking settings found out there though a good old Google search are for a specific user or IIS related, neither of which is applicable in the ISA LDAPS scenario, as the connection is not established under any specific user context and IIS is not involved at all for the LDAPS session.

According to the information, the default timeout value when processing a CRL is 15 seconds, which would explain the 15-20 seconds logons from ISA perfectly.  I added the following registry key to both ISA servers, rebooted them, and now the initial logins take 2-3 seconds.  Note that the value specified is in milliseconds and that the HEX value 000003e8 is equivalent to 1000 in decimal (1 second).

Location	HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
Type	REG_DWORD
Name	ChainUrlRetrievalTimeoutMilliseconds
Value	000003e8

 

Also note that if this value is set to 0 or if this value is undefined, the default value that is used is 15000 milliseconds.  It also doesn’t work if you spell retrieval wrong the first time like I did…