Archive for June, 2010

Automating installation of custom FIM workflow assemblies during development cycle

Last night I was chatting with my ex-co-worker, who just dived-in the world of FIM development. He have had several questions about workflow development for FIM. I have pointed him to my FTE Owner Requirement workflow mentioned before in this blog, and published on CodePlex to serve as an example of FIM workflow for people who are starting out FIM coding.

One of the things that I found annoying, and therefore worth automating is the "deployment" of your activity on the system. When you are working on workflow, and especially when your workflow has a visualization (Admin UX) class, you need to do many routine "moves" before you can successfully attach to the process for debugging. So after your DLL is compiled you need to

  1. Remove previously GACed library form Global Assembly List
  2. GAC your new assembly
  3. Copy assembly to "Portal" folder (along with your symbol’s file)
  4. Restart FIM Service
  5. Restart IIS (if you are writing Admin UX, and not using XOML)

In my book, this counts as tedious routine, especially when you need to do this time and time again over the development cycle.

So, I’ve wrote rather basic CMD file to automate this routine. It is parameterize to allow multiple DLLs to be deployed with the same script. Script uses GACUtils.exe to work with Global Assembly Cache. Utility comes with .NET SDK, I think, and uses dependency library – msvcr71.dll. To simplify everybody’s life I’ll include both in this ZIP file.

As an alternative you might want to consider "converting" this script logic to be a post-compilation job in Visual Studio. Personally, I have found that adding this script as post-build operation is a little bit time-prohibitive, since restarting FIM and IIS services takes some time, however you might want to think about it.

 

It is worth mentioning that if you are intending to leave your activity behind you might want to make your administrator’s life easier by writing an MSI package that would deploy your custom activity on the production FIM portal. Even though this post provides simple command-line script to deploy your activity during development cycle, mentioned above FTE Owner Requirement activity on CodePlex contains WIX installer project that will reliably deploy your activity on any FIM 2010 portal without you explaning where to place your DLL, how to GAC it and else you need to do with it.

Happy coding!

Converting Mailboxes to Mail-Users with ILM for Exchange 2003 AD

After couple of weeks of working with a client of mine in Boston area, I’ve learn more about Exchange 2003 than I care to learn, and wanted to share some snippets of information with my fellow-Outlookers.

Using ILM as a migration tool

First of all, I have to say that, for better or for worse, proverb "if all you have is a hammer, everything looks like a nail" applies very nicely to the method I am about to describe. In short, I have managed to set-up ILM server for the tasks that are traditionally done with other tools (mostly scripts). I cannot advocate this usage of the product, nevertheless if you are "fluent" with ILM you will find that this method have its advantages over any kind of script.
Firstly, ILM will provide you with staged environment. Any bulk operation that script would perform directly on your AD, ILM would stage and allow you to have a chance to analyze pending exports before actually committing changes to the directory. Secondary you will get to use managed code vs. script language, which is a better choice, in my honest opinion.
On the flip side, setting-up ILM just to perform migration process is an overkill. Not only you’ll need to install Windows Server, SQL Server, ILM Server, OL Sync with all dependencies and apply all Service Packs, you also need to install Visual Studio. All that takes time; if you don’t have that time (or desire to install all this stuff) you might want to consider using scripts which are not require any "infrastructure".

So what do we need to do?

In the scenario when school converting their student mailboxes from on-premise AD with on-premise Exchange 2003 to hosted Outlook Live solution, and intending to use OL Sync (GAL Sync) you will need to figure out how to convert existing student user accounts with mailboxes to mail-enabled users… in bulk. Reason being for this requirement is an OL Sync "rule". Outlook Live Sync will automatically create mailboxes in the cloud, based on your Active Directory information. Every mail-enabled user (an Active Directory user object with mailAlias and targetAddress populated) will receive corresponding mailbox in the cloud. However user with mailbox on-premise will NOT have a mailbox created in the cloud (which is understandable; there is no reason to have two mailboxes)
It is all sounding simple enough, until you are looking into details of such operation. How do we exactly going to convert thousands of users with mailboxes to mail-enabled-users?
Let’s flashback to year 2003… Exchange 2003 fully relied on AD to provide "key" attributes that will identify a user object as a mailbox-deserving or mail-enabled-user object. UI of Active Directory Users and Computers was taking care of all of those operations by simply pre-setting some attribute values in AD; in turn, Exchange 2003 would "sense" those values and act accordingly to create a mailbox or append mail-enabled user to its GAL. There were NO direct calls to Exchange server form the snap-in itself (to my knowledge). As it turns, all we need to do, it to figure out which attributes are responsible for identification of mailbox vs. mail-user and "voila" — we have got ourselves a conversion machine.
 

Outlook Cash

There is another thing to remember. Prior to migration, teaching staff could have emailed to a student from their Outlook. That operation was performed as from on-premise to on-premise email operation. After migration is done, should a teacher use Outlook to email to the same student again, he/she would likely to use "auto-complete" feature that will pick previously resolved address for a student, which would be incorrect, since on-premise mailbox for that particular user is no longer present in on-premise Exchange. It was replaced with mail-enabled user object; As a result, message will bounce back and teacher will likely to make a phone call to tech support.
Boston colleagues of mine, did not fancy the idea of talking with their teaches all that much, so we had to figure out how to solve this dilemma during migration.
 

So what did we actually do?

Outside of running IMAP mail-content migration process and providing password synchronization between on-premise and the cloud (Outlook Live) environment for all new and existing users and figuring-out email flow during split-namespace scenario, we had to figure out how to convert existing users with mailboxes (MBX) to mail-enabled-users (MEU).

Deleting attributes:

As I have mentioned before several attributes in AD are responsible to "linking" mailbox in Exchange 2003 mail-store with an actual user account. Delete or modify those attributes and Exchange mailbox will lose its "connection" to the user in AD. Augment some user attributes and Exchange 2003 will identify that user account as a mail-enabled user object, which will be displayed in local GAL (visible to all teaching staff, which will keep mailboxes on-premise)
So what are those magic attributes?
Before somebody in Exchange team or Microsoft legal team gives me a call and kills me, I want to say that if you are about to perform this operation – you are doing it at your own risk. I (or anybody else to my knowledge) cannot guarantee that this will work for you. So please test and do plenty of backups before editing your production directory.

To "sever" user form his/her on-premise mailbox I’ve deleted values in following attributes form every student account:
homeMTA; homeMDB; mDBUseDefaults; mail; msExchHomeServerName; msExchMailboxSecurityDescriptor; msExchMailboxGuid; msExchALObjectVersion
To mark user as a "mail-enabled-user":
I’ve set value of Windows Live ID for each particular user to "targetAddress" attribute and to "mail" attribute
I’ve set "mailNickname" attribute value to be user’s ‘left’ side of the Windows Live ID value (to the left form @ sign)
I’ve set value of "false" to "iMAPIRecepient" attribute (this was optional)
To address "Outlook Cash" issue (see above):
I’ve stored value of "legacyExchangeDN" and added that value with a prefix of "X500:" as one of the entries in "proxyAddresses" attribute.

Conclusion

All that was performed with ILM 2007 with a single Active directory Management Agent configured to import and export mentioned-above attributes, and rather simplistic extension code that ensured formatting attributes.
It took several days to go through procedures and meetings, however in the end we have had clean conversion and good tractability – thanks to ILM logs with every operation on every object being captured.
ILM provided nice platform for reviewing upcoming changes on user objects as well as a way of communicating with AD