Exchange 2007 Provisioning Issue with ILM 2007 FP1

I've been meaning to post on this for a while, but have been pretty busy.

A few months ago I did a project which included Exchange 2007 provisioning with ILM. When running a small development environment (single DC, very important), everything ran fine. But when it got to production I noticed that when the new connector space object is exported to AD, the mailbox is a "Legacy Mailbox" in Exchange because it does not have all of the required Exchange 2007 attributes. I also noticed that when any type of update for that user is exported to the AD MA, the mailbox is then updated to be a standard Exchange 2007 mailbox. From Shawn's blog post, I learned the ILM code is simply using the Update-Recipient cmdlet under the covers to do the update. In Exchange 2003, the Recipient Update Service handled the stamping of the remaining Exchange specific object on the user object and completing the set up of the mailbox. In Exchange 2007, the RUS has been removed, so the Update-Recipient cmdlet was specifically added to address this type of situation. Update-Recipient is called by ILM every time there is an export for that object, and is supposed to use the same DC that the AD MA is using. Key word: supposed.

Turns out there is a bug in the Update-Recipient cmdlet. It does NOT consistently use the same DC as the MA, so while you are exporting your object to one DC, Update-Recipient goes off to another DC where the object does not exist yet. Best of all, when it does, it silently errors out.

After much poking around, I developed a suitable, fairly simple workaround - trigger a second export for any provision action to AD. The workaround goes like this:

1. Extend the Metaverse schema to include an attribute for the AD SID (we'll call it ad_sid for this).
2. Create an inbound flow rule to place the user SID from your AD MA to the Metaverse ad_sid attribute.
3. Find a relatively insignificant attribute that flows from the Metaverse to all users in your AD MA (we'll use title for this).
4. Create an export flow rule using a Rules Extension to only flow the title attribute from the Metaverse to the AD MA if ad_sid is present in the Metaverse (you'll need to send both the title and ad_sid attributes to the AD MA title attribute).

Now, when a new user is provisioned into AD, a confirming import will bring the user's SID into the Metaverse. The user won't have a title, but the import of the SID will trigger the new export flow rule and generate a pending export of the title. Ensure a suitable amount of time passes to allow AD replication to occur so that the new user is present on all DCs, and then when this second change is exported, Update-Recipient will be called again. Regardless of what DC it uses, it will then be successful and the user will go from "Legacy Mailbox" to "Exchange Mailbox".

Here is a sample bit of code for the Export Flow Rule:

Select Case FlowRuleName
Case "set_cs.title"
If mventry("ad_sid").IsPresent Then
csentry("title").Value = mventry("title").Value
End If
Case else
Throw New EntryPointNotImplementedException()
End Select

In terms of a fix, it is important to remember this is actually an Exchange issue, not an ILM issue. For someone within MS I was able learn that supposedly the KB article behind this is KB949858, but it is not publicly released. The fix was initially slated for Exchange 2007 SP1 Rollup 3, but it didn't make it in and should in Rollup 4 - the release of which, I learned from Aaron's post today, is imminent. Looks there are some issues with the links to the download though; I imagine they will be straightened out shortly.

KB250455: How to change display names of Active Directory users

Nothing earth shattering here, just something I can never seem to find quickly when I need it.

When a new user is created in Active Directory, the Full name field is always generated in FirstName LastName format. In turn, this field sets the Display Name field on creation, therefore, you end up with a FirstName LastName formatted global address list.

You can make this change by using the Adsiedit utility. Adsiedit not only changes the default way the Display Name field is built, but also the Full Name (that is, the "cn") field, therefore, users appear in the chosen format when you look in the Users and Computers snap-in.

http://support.microsoft.com/kb/250455

Two PowerShell Event Logs on Exchange 2007 Servers

When PowerShell 1.0 is installed an Event Log called "Windows PowerShell" is created.  When Exchange 2007 is then installed, a second Event Log called "PowerShell" is created.  When this log is created, multiple entries are added each time the Exchange Management Shell is opened, so this log rapidly fills up and you will get errors unless you go and change the configuration of the Event Log.  More interestingly, the entries in the "PowerShell" Event Log are unable to be resolved so that the description can be presented.  A typical entry in this log looks like this:

Event Type:      Information
Event Source:      PowerShell
Event Category:      (4)
Event ID:      403
Date:            5/12/2007
Time:            2:45:55 AM
User:            N/A
Computer:      MYCOMPUTER
Description:
The description for Event ID ( 403 ) in Source ( PowerShell ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Stopped, Available,       NewEngineState=Stopped
      PreviousEngineState=Available
      SequenceNumber=20
      HostName=Default MSH Host
      HostVersion=1.0.0.0
      HostId=2afe9b64-5601-4df3-8478-6efc5cf2c471
      EngineVersion=1.0.0.0
      RunspaceId=433e6992-c711-47a8-b732-728a45104767
      PipelineId=
      CommandName=
      CommandType=
      ScriptName=
      CommandPath=
      CommandLine=.

To resolve this issue, simply delete the following registry key, which will delete the "PowerShell" Event Log:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\PowerShell

A reboot is required for the change to take effect.  Once the "PowerShell" log is deleted and the server is rebooted, the PowerShell events will flow into the "Windows PowerShell" Event Log without issue, and you will be able to properly view the description of the events.

Note though, that updates or service packs for Exchange may put this Event Log back in, so check for it after any update and simply delete the registry key again if it appears.

Using Messenger accounts with non-Microsoft SMTP Domains in LCS/OCS With PIC

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:

• hotmail.co.jp
• hotmail.co.th
• hotmail.co.uk
• hotmail.com
• hotmail.com.ar
• hotmail.com.tr
• hotmail.de
• hotmail.it
• hotmail.fr
• messengeruser.com
• msn.com
• simpatico.ca
• passport.com
• passporthotmail.com
• webtv.com

I think it's safe to assume the live.com domain 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.

Comparing Exchange 2007 UM and Cisco Unity UM

I've had many clients ask for a feature comparison between Exchange 2007 UM and Cisco Unity CM.  Until I stumbled across this blog posting from Matt McGillen, I had nothing tangible to offer.  Kudos to Matt for assembling this.