Systrack will play even a bigger role when using distribution systems that are not so tightly tied to Active Directory. In some cases there is no relation to users at all, maybe even the workstations are not following the same user ie. if they are picked up from a pool in the morning and returned back in afternoon. This is somehow the “physical version” of pooled virtual desktop, but there is one important difference from project scoping perspective.
Pooled virtual desktops are published to users or user groups, at least on some level. Because user must access and authenticate to the system, so we know who is using what, where and when. Even though physical machines generally has an owner, it may be very difficult to track down the user related to specific machine as the information is usually maintained in different ways, in different systems. In worst case, there is no relation between the user account, machine account and the application.
This kind of legacy systems may be very painful from project point of view. Reasons being that organizations have been postponing their migrations as long as possible, because they have experienced how painful it is to complete large scale migrations. Also one common goal for every migration is to take control on the application management as it has generally been fairly simple in the past, but also slipping change management process over the years has been eating the integrity of the overall application management. Now, when user scenarios and requirements evolve faster than implementation capability, there is no possibility to manage the process without control.
One example of “distribution systems from hell” is <ADD NAME HERE>. It sounds like a very simple and straight forward system. Actually it is not so bad from AppDNA perspective, but reality is different when considering the whole project and the usual success criteria.
It is fairly simple system to integrate with, similar to SCCM, but applications are installed using script files, which are essentially .vbs scripts, but using custom libraries. Actually, it is amazing system because it guarantees very high quality installations by allowing high level of configuration thru the scripts. Technically it is possible to capture the applications as they are installed by executing the script file using install agent or cscript -utility – meaning that we should only need a suitable execution profile.
However, there is two things why it is not so good. High level of customization thru install scripts means that the process is difficult to automate from end to end. For example, it is common to configure user dialogs to expect reaction from user, application requiring logoff before installation or restart during installation. These all are huge challenges for AppDNA administrator and unfortunately, most would give up. Well, even restart can be faked by intercepting the shutdown request, suppress it and return zero as a response (indicates success) to the installation process. I propose you try it out before saying it is easy 😉
Most frustration with such systems comes from the fact that they are usually installing standard MSI packages, meaning that in theory you could just import the MSI´s directly. Taking the blind shot for importing the MSI´s directly is the worst mistake you can do. It is fine if you think and make a conclusion for doing that. As a default procedure it is failure because, like I said, those systems often include customizations outside the MSI installation action. Also it is fairly common to see nested installations where MSI´s are installed on top of MSI´s. If you are lucky, you may experience some real engineering with these legacy systems.
Another reason why this kind of systems may be bad for migration, is that they may live their own life without any relation to Active Directory objects.
Following points are just few example considerations with legacy distribution systems:
- How would you manage your applications in relation to your users?
- What would be your decision criteria for migrating or retiring applications?
- How could you define importance of applications?
- How could you define how much effort and cost is associated with remediation?
- Where is the limit for reasonable cost?
Even though these points are huge challenges, it should be discussed with the customer as they must understand where they are standing, your knowledge is needed to pinpoint the caveats and shave off all unrealistic expectations. Remember these are also sales arguments, not only for AppDNA product, but also for upselling consulting services and TRM services. Actually, most common reason for evaluating migration project as “failed” is not the complexity, it is the false expectations!
“Mr. Valued Customer, It is difficult but our consultants will make sure it goes well”…
It becomes even more important when you realize why you are in a meeting room with the customer anyways. You are there because someone has sold a solution! That solution is probably XenDesktop, which means you are on driver seat for much larger case than yours alone.