The long awaited RC1 for FIM 2010 was released yesterday. Microsoft has promised an upgrade path from RC1 to RTM. No upgrade path exists for any of the betas or RC0.
Get the bits at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4bb3f16b-27f8-4c1d-922f-2c7b522d9ad6.
UPDATED 03.18.09: This does not work correct with Office Communicator 2007 R2 RTM. The workaround for this can be found here. Also, the list of MS domains has expanded to include live.com and its variants. See the KB article referenced below for the full list.
I'm not sure if the subject on this post even makes sense, but it's the best I could come up with. Essentially the issue is that even though you have LCS or OCS set up with Public IM Connectivity (PIC) you can't add contacts that use MSN/Live Messenger unless they have a Microsoft SMTP domain for their account. The valid MS domains (as of the latest update on the KB article) are:
I think it's safe to assume the live.com and all the country specific variations of it are on that list as well, but I haven't tested those.
But, you can set up a Messenger account with any SMTP domain you want. If you add them in to the LCS/OCS client, they simply don't work. I may be an idiot, but for the longest time I thought that's just the way it was. Then today I stumbled across a KB article that describes how to do it. It's a matter of manipulating the IM address of the contact you want to add. It's not very obvious, and it would be nice to see the OCS client/server catch these and fix them for you, or at least tell you the proper format.
So I know user@gmail.com is a Messenger user, and I want to add them to my OCS client, the address should be entered in the following format:
user(gmail.com)@msn.com
Odd, but hey it works. Check out the full KB article here.
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.
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…
Here's an interesting item (to me anyway). If you are running Virtual Server 2005 on a computer with a wireless connection, Virtual Server won't let you share that connection with VMs. You can only share wired connections with VMs. To get around this, you can install the Microsoft Loopback Adapter, and enable Internet Connection Sharing on your wireless connection. Then you can create a Virtual Network using the Loopback Adapter, and assign your VMs to that. One thing to remember though, and it may or may not matter depending on what your are doing with your VMs, is that ICS enables NAT and hands out IP addresses in 192.168.0.0/24 subnet, so your VMs will not be on the same subnet as your physical machine.
The instructions for setting all of this up are on Wade Wagner's blog. Here is the direct link:
