Hi Guys,I understand that the Enable Exchange 2007 provisioning checkbox facilitates the creation of mailboxes, but what about contacts?For "big bang" migrations, only being able to provision mailboxes is fine, but for environments where protracted (or possibly indefinite)periods of cooexistence is required, having ILM provision a raw AD contact - which then requires admin intervention on a per-contact basis (or possibly script an alternative, which is now what I have to look at), makes the option itself seem a little incomplete.Cheers,Lain

If you need to do any sort of advanced provisioning for Exchange 2007 where there is some sort of after the fact operation needed such as adding a mailbox to an existing account, creating a linked mailbox, and (possibly) working with contacts incrementally, you will probably have to drop down to PowerShell to issue the proper Exchange management commands. In theory, you could figure out the exact attribute flow you need (since after all, Exchange configuration is really just data in AD), but the exact attribute population requirements and values for many Exchange operations are not well documented and may not be fully supported. Issuance of the base Exchange PowerShell commands will always be supported. You can call PowerShell commands directly from ILM if you write a custom management agent. This procedure is described in a blog posting at http://www.wapshere.com/missmiis/adding-exchange-2007-mailboxes-to-existing-user-accounts. Basically you create a Management Agent for mailboxes that uses PowerShell commands to create, delete, and set any special options you need. I had a client that needed to create linked mailboxes to a trusted forest and used this technique quite successfully. Their migration had a long co-existence period and the mailboxes needed to be created one by one long after the accounts had been created. I don't see why the same sort of technique could not be used to manage contact objects during a migration period.

Thanks for the URL, Rex. At least it's an avenue I can pursue. I had considered Powershell as a solution, but as an entirely stand-alone task which wouldn't have been as neat as what you've indicated above. It would have been nice if ILM2 could handle this natively, but in the absence of full Exchange support, I'll definitely check that out.Cheers,Lain

Rex, could you elaborate more on your linked mailbox implementation with custom MA? Thanks! Henry

Our client had several subsidiaries each of which had and managed their own AD forest. The project was to provide a common and centrally managed email system (Exchange 2007) that served the client and all of its subsidiaries. The requirements were for each subsidiary to manage their own users and logins and leverage the central email solution but… the catch was that the client didn’t want to grant any administrative rights within Exchange to the subsidiaries (and still wanted the subsidiaries to manage their own users.) The solution was to have each subsidiary maintain “special” attributes within their own AD environment. These attributes were used to indicate to the provisioning system (FIM) which users should have mailboxes, what the published SMTP addresses should be for each user, if the user was allowed to have Internet mail (or just corporate mail), and whether or not the user should show up in the global address book. The provisioning code looked at these attributes and for the users that were supposed to have mailboxes, the code would create a dummy mailbox enabled, login disabled stub account in the client’s active directory (which would “own” the mailbox) and linked the mailbox to the account in the subsidiaries AD. We had to drop down to PowerShell to deal with the linked mailboxes and handle SMTP collisions. (You can set proxy addresses via attribute flow, but if you put the same SMTP address on two different users, email delivery will fail silently. If you set addresses with PowerShell, you will get an error that you can handle if a SMTP address is already in use.) We also had the need to be able to remove a mailbox from a user without deleting the AD account, another thing you need PowerShell for. As to the MA itself, it presents a list of users and a virtual attribute containing the type of mailbox they have. Provisioning code and attribute flow adds to this list or changes the mailbox type. The export code translates changes in mailbox type to the appropriate PowerShell commands.