Some of you might remember my (French) Blog post about FireFox deployment using MDT. From times to times, in the real world, my customers are not using Microsoft products only and they ask me to deal with it.
Of course, even if I don’t like some of those products, my first goal is to help my customers building a world class enterprise solution that covers them.
So here we are, my current customer wants to migrate to Windows 7 and they currently use Lotus Notes 8 as an email/groupware solution. Not a big challenge at first look, USMT 4 migrates Lotus Notes 6, 7 and 8, therefore I’m feeling confident. I set up an MDT Deployment Share, created my Task Sequences and did a first test run and … Notes files and settings were not migrated
I dove into MigApp.xml to understand how USMT manages Notes files and settings and … I realized that the detection of the installation and data paths was not working because the registry key used by MigApp.xml was not even existing in my customer’s context
I modified that and I added extra logic to be able to detect correctly the install and data paths in a 32 bit environment (Windows XP) as well as a 64 bit environment (Windows 7). But still nothing was migrated
I put my swim suit on and dove again in MigApp.xml and I also realized that my customer has packaged Lotus Notes 8 to behave like previous version (e.g. not using %localappdata% to store the data folder). And guess what, USMT looks for data in %CSIDL_LOCAL_APPDATA%. Well well, I changed the objectset to use %NotesInstPath% and %NotesDataPath% instead,
At this point, I was really confident, and I ran (what I thought was) my last test and … USMT failed
It was even worse than before where USMT was running correctly but just not migrating Notes. The failure was caused by an entry in the Notes.ini file. In fact, this entry started by COM1, which is kind of a keyword for Windows and USMT failed trying to process it because I used the /nocompress switch and then USMT tried to create a file named COM1 (try this at home for fun)
The solution was simple (even though I tried something way more complicated before finding it), removing the /nocompress switch was enough🙂
Here are the lessons learned from this experience
- If you deploy Lotus Notes 8, try not to change the default data path, or at least, put it in the user profile to maintain Lotus Notes 8 multi users capability
- If you need to migrate Lotus Notes Settings using USMT, make sure that the install and data path are correctly detected in MigApp.xml (in both 32 and 64 bits environments)
- use the <pattern type=”ini”> syntax to bring notes.ini settings and not only the notes.ini file, this won’t work if (like my customer) you switch from 32 bits to 64 bits but be carefull not to use /nocompress