Any migration can be daunting when you first look at it, especially one as core to IT processes as a client management product. Previously I shared some basic information on the steps that were taken when we migrated from Novell to Altiris. This time I'm going to share with you the documented steps we took to convert our NAL objects to MSI files and some other items we used to fill in the gaps.
Starting Point
I'll start with this reminder your experience may vary in your organization. We were in an environment that was heavy into NAL software installs that were snapshot captures. If you're at a business that used MSI based installs or other included scripts like those for Install Shield, then you're in a much better position than we were.
Also, when looking into converting items you'll want to watch your project deadlines. We had the advantage of an extended project timeline as the servers were going to be converted as well and NAL would be around until all of the Novell servers were completely migrated to Microsoft 2003 servers.
My first tip to those of you in heavy snapshot environments is to look seriously at the methodology that the snapshots were taken. Ours, unfortunately, didn't follow best practices, many of the snapshots were taken on the same computer and it wasn't a clean environment at all. When we looked deep into the objects we found registry keys that were not applicable to the application that was going to be delivered at the time.
After an initial attempt at converting those objects proved to be disastrous. When delivered as MSI objects the software installs would often time attempt a self repair any time the computer was started. I worked within Wise Package Studio to attempt to clean the registry keys, but was soon overwhelmed. It soon became policy; whenever possible we would need to completely re-create the packages using best practices.
However as many of you know that's not going to work for everything. So we still need to convert those really, really old applications that have been long forgotten. For this we used Wise Package Studio Professional.
Converting AXT installs
The Legacy Setup Conversion tool within Wise Package Studio Professional is really rather simple. The prompts will take you through each step and even help identify the Merge Modules that can/should be included into your installation.
In this example we are of course converting a Novell AXT file. This is the information on the install and in my experience it didn't contain source files. You'll want to make sure that those are accessible in their current location. This of course meant in our situation that the Novell Client needed to be installed on the workstation.
While the source files did reside on a Novell server I was able to export the AXT and copy it locally to the workstation. You'll see in our example that both the source and destination files are local, however the snapshot files for the NAL itself was still on that Novell server volume.
Not every install will show this item, but I found that generally when it prompts you to include files it's a good idea. If you do include these merge modules then you'll be prompted for a location to download them from. If you don't know of a particular reason to choose another option I always downloaded using the Wise Website option.
Depending on the size of your installation and the data involved it may take awhile to convert it completely. Patience is definitely a requirement here, especially for larger applications.
Step 5 - Compile and Test
At this point the installation will have been converted into a Wise MSI Project File (.wsi). As with any other Wise Studio Project you'll want to modify the install before you compile it to include any important information that your organization has set as an internal standard.
Fill in the blanks
Converting NAL objects to MSI is only part of the battle. There were a couple of items our setup of Netware Application Launcher that weren't readily available in Altiris. One of the items that some people had grown accustomed to was the ability to place icons on a desktop for pull installations. In some instances it did make things easier. It was great to say "Hey just log out and back in and you'll see this little icon on your desktop when you're ready for the software just click on it".
Functionality like this can of course be setup. If you get creative an Altiris admin can setup software delivery tasks that send icons to desktop and that refresh that icon until a user runs the install which would then get picked up by inventory and moved in their respective collections, but part of this migration was also a shift to better customer service.
Each corporate culture will have differing views of what customer service means to them. We realized, once we stopped and thought about it, there was no reason why we had to make someone log out of their computer and back in to get this install they had to do themselves. We could be more proactive and take care of the customer while they were on the phone with our IT Service Desk. Altiris' Deployment Server gave us a level of service people hadn't known before. Other organizations might treat each individual workstation update as a small change request and require items to be done after hours.
There were still some items that had to remain the same. What I recommend is thinking outside the box. If you need those icons to be replicated to desktops even after the migration there are ways to accomplish this. In our environment we had a particularly useful document drop-off location that many users used daily. It was literally just a shortcut to a network folder. To keep this icon on desktops there are a couple of options. One would be a scheduled Software Delivery task to create the icon on either login or some other specified length of time.
Take time to familiarize yourself with the tools at your disposal. If you can you should certainly employ the help of Altiris services, but does not need to be required for you to accomplish your goal of migration.
Our Novell to Altiris Migration - Step 1: Prepare