Firstly let me stress a point I have already made. This migration can also be an opportunity. It could be a great time to change how you package and deploy your applications. For example, you could look at virtualizing your applications. You are probably telling yourself, I don’t have the time to do that. I just want to quickly package the apps the way I know we can and get a move on. But did you know, virtualizing an application is actually much quicker and simpler than packaging an MSI and offers greater benefits. Applications are completely isolated which eliminates application conflicts, it also does not require an install or uninstall of applications when using streaming, because the apps are isolated and possibly streamed it means less regression virtusion testing required during packaging as there’s no threat of system files of files belonging to another application being removed during your uninstalls. Also, if it’s quicker than packaging for a large percentage of your estate and quicker to package upgrades too (which it is) than you have long term cost savings. For more information on application virtualization you can get more information HERE , HERE , HERE and HERE I won’t hark on about it but there’s some links to useful info if you are willing to entertain this idea.
I just suggested you might choose virtualizing over MSI packaging, well maybe you don’t even MSI package. Maybe you choose scripting installations in your environment. If you do this then you will already be aware of the problems that comes with this when you look at your service desk stats for issue resolutions. I’m not saying you have to MSI package everything, especially if you are working in a smaller, more manageable environment. There’s certain applications such as Office 2010 and SQL Server 2008 which are very large and would require a lot of effort to MSI package with very little return on the effort as Microsoft have built in Utilities for creating answer files to silently deploy these applications to your users. In my opinion though, MSI packaging is the way to go for any apps that are not being deployed as virtual applications. This is because MSI leverages Windows Installer which is part of the operating system. Windows Installer offers great benefits such as silent installation and uninstallation. Silent Rollbacks if an installation fails, which is awesome. If you scripted an installation and it failed half way through, could it remove what it already put down before the installation? MSI will cleanly roll back and remove if the install errors out, leaving the machine unaffected. Applications also have automatic repair functionality. If for some reason a file or folder for the application has been deleted, the application can repair automatically to ensure the it continues to function. It also offers a great platform for standardization and consistency in your environment. Let’s move to remediation for Windows 7 and Windows 8 etc.
The tools mentioned in the previous part of this series. AppDNA, ChangeBase and Flexeras Application Compatibility tool can offer automatic compatibility fixes. However, if you do not have the benefit of these tools or you would prefer to use a more open solution you could use Microsoft ACT. There is an Application Compatibility Manager tool that is part of the the toolset which can be used to create something called a Shim. A shim is an .sdb file which you install along your applications. These can also be used with virtual applications but needs to be installed and live on the local machine and not within the virtual application itself. A Shim in my own realm of thought, is like a system lie. When you have detected a compatibility issue say that your application is throwing a prompt for users for UAC, there’s a shim to suppress the prompt called RunAsInvoker (this is one of the most commonly used Shims), you install this shim with your application and it will act like a listener. When the process for the application your applied the shim to is launched the shim will trick the OS into believing that this application does not require a UAC prompt. Perhaps a more logical example is that of when an application has been hardcoded to only run on an Older OS you can applied a SystemVersionLie shim which will ensure the application see’s that it is on a machine tagged with the correct version OS for the app to function, even though it is not. RunAsAdmin is another useful Shim to use, this is for those rare applications that require a user to actually be in the Administrators group to function, the shim will simply dummy that the user is in the group. There is much more granular shim options such as for specific XP compatibility for redirecting registry and files to certain locations.
ACT also has canned shims for previously identified applications, though this list is pretty outdated now. ACT has hundreds of options for Shim, it would be impossible to go through all of these. Plus, I have only ever used maybe 10 of the available shims before as I never had a requirement for others! Other than maybe the odd SystemVersonLie or RunAsInvoker shim you likely won’t use shims too much. Windows 7 Virtualization and the fact vendors have caught up with their apps makes this a bit redundant. Which is good! And I think Microsoft would agree with that as this was always a band-aid to help get moved and was never seen as a permanent fix. Internally developed applications will again, likely be the biggest culprits. There is an alternative to using a shim and requiring that component to live with the application and act as a listener requiring some overhead. Your developers can quickly create a Manifest file to live with the applications files to perform the same effort as a shim. Really, they should just fix the damn issue when possible though but if time is a factor it may be a quicker option…..or more likely you will create a shim because they will not have time for revisiting their applications themselves. That’s the cost of waiting too late to migrate. Application Virtualizations technologies such as App-V and ThinApp do not get around compatibility issues per se, but they do both have the ability to assign flags natively through the application for some but not all compatibility issues which also means less effort and resource than spinning up the ACT to create your shims and then deploy the shim via a custom action within your MSI or through a script. Shims by default appear in Add\Remove Programs and can clutter it up.
Some biggies which will require remediation and change in process for application packaging for Windows Vista and later is the fact that Windows Firewall has changed. It is now Advanced Windows Firewall, if your process was to set the firewall exceptions by using the registry this will no longer work. You will need to look at using a custom action for doing this or even better use GPO. If you currently use CACLS.exe or ICACLS.exe these are now deprecated. You will need to use a new method for setting NTFS Permissions for your applications. Take a Look: On multiple projects I have worked on the company set branding within the registry to each application. If you are going to a 64-bit architecture these will now go to HKLM\Software\WOW6432Node which may not be desirable if you have an auditing tool looking at HKLM\Software. Also 64-bit compiled MSI’s with 64-bit components will put them in HKLM\Software so you may have the stamps for some applications in one hive and others in another. You will need have conditioned components for 64-bit and 32-bit OS if you support both a 32-bit and 64-bit OS going forward. You can mark one as a 64-bit component and the other as 32-bit via the Component Table or through the UI of your favorite MSI editor if you are so lucky. ISELFREG entries in MSI’s may cause issues as these run in the user context and your users will not be elevated to run this registration, SELFREG should continue to work. In a lot of cases neither is a requirement and in fact other means of registration are the best practice. When reviewing your application packages for Windows 7 it is important to query the Launch Condition table and also conditions set on Components and the body of your Custom Actions code for any hardcoded paths or variables which may no longer exist in your environment. Again, you could use this migration as an opporunity to revise your packaging standards. Maybe you could set some environment variables on your machines which could be useful and leveraged for conditioning in MSI installs or scripts? Maybe you have redundant actions in your MSI’s. Maybe you use a wrapper and have found these wrappers have also been used to execute pre or post install steps and you want to consolidate these into your MSI Custom Actions. Perhaps you could set some custom Properties in the Property table to track Application Owners and The Packager who worked on the app.
For more information and an a more graphical example of creating shims you can read more HERE
Many people believe that solutions like App-V can help with application compatibility and they can to an extent. App-V and ThinApp do offer the possibility of setting tags for applications which act like shims to allow other incompatible applications to work. You can see this with the use of the RunAsInvoker tag. However, Application Virtualization itself is not an out of the box app compat solution. It cannot resolve all issues. What it is great good for resolving is issues with deprecated components. If you figure out what the application requires that was on XP but is not on your new OS, you can sequence the app and copy the files into the virtual file system during the sequence. Beware, this will not fix all issues related with deprecated components but can fix a few.
If you have no way to remediate an application you will either need a replacement or you will need to use an alternative such as Citrix or MED-V, which you can read more about HERE Beware these alternatives will also have a short shelf life! Server 2003 will be end of life soon too. I hope I have illustrasted considerations for packaging and remediation and alleviate some fears!
For more read on to Part 5
