PowerShell, FIM, and overcoming surprises when migrating from Exchange 2007 to 2010

So, there I was, just minding my own business, developing a FIM solution in my lab after reconfiguring Exchange provisioning from 2007 to 2010 and all was well in the world when, all of a sudden, I noticed that users were no longer maintaining the same standard mailbox configurations for my organization!

After some research, I discovered that requests from the portal to take a workflow action against newly provisioned user mailboxes were receiving PowerShell errors.

In the previous design, when provisioning Exchange 2007 mailboxes, the Exchange management tools were installed on the server hosting the FIM service.  This was so our PowerShell scripts, which update our mailboxes via FIM portal workflow/MPR, could utilize the locally installed Exchange module required.  However, the old commands could no longer be run against 2007 tools and a 2010 CAS.  What to do????

Establishing a remote connection was the answer.  Much like the AD MA Exchange 2010 configuration, which essentially provisions using the PowerShell URI defined against the Exchange CAS server, I decided to change our scripts to follow the same approach.  The result is the following:

So now, I am actually updating our mailboxes by executing our commands remotely on our CAS!  That fixed our issue, only after giving me a slight scare.  :)

-jose the admin