Based on design requirements, determine applications for inclusion in the ThinApp repository
I’ve said it a number of times already and will no doubt do so again, but you will need to refer back to back to original requirements and results of analysis tools. Some applications will be more suited to being installed in the master image if they are utilised by user that will be given a virtual desktop. Applications like Microsoft Office sometime are better suited to being installed directly into the image. Smaller applications such as Adobe reader also make good candidates to be installed directly.
Similarly, some applications simply can’t be virtualised. Granted, most applications these days make suitable candidates, however, a large number of business still run legacy software that hasn’t been updated since the year dot, however their business can’t function without them. I can’t remember where I heard someone say this, and it may be slightly misquoted, however next time you are in an airport taking a flight with American Airlines, peek over the check-in counter and you’ll see a Windows 7 desktop (likely to be virtual) with a terminal emulator running on the screen connecting back to the booking system.
Other niche legacy applications may not like to be virtualised, some providers with smaller development/support teams may simply refuse to support their applications when virtualised.
Determine storage and networking requirements for the ThinApp repository
Here comes the tricky part. As we already (should) know, The ThinApp repository is simple to deploy, it only requires a Windows file share(s), and it’s also fairly easy to maintain. However with all applications being different and working in different ways how are you expected to realised how much storage or network bandwidth is required. The best way to determine the requirements would be to package your applications and start testing.
The load on a ThinApp repository ‘should’ behave similarly to the load a file server generates. At the end of the day, they are simply both sharing files (hopefully not acting as a file server and Thinapp repository). With today’s technology, file servers can be quite cleaver with the placement of files, for example, if a certain file, or in this case ThinApp package is accessed a large number of times it will likely be opened from cache making it quicker.
Tools are available to simulate load for testing purposes that can mimic different types of use case. VMware has its own tool for this purpose called VMware View Planner, LoginVSI also have a comprehensive solution available to generate load.
The share needs to reside on a ‘bare’ minimum 100 Mbps network however 1GB is should really be your aim. Connections and storage with low latency should also look tone utilised otherwise you will find applications are extremely unresponsive and most will actually crash. This can make ThinApp look like the culprit when intact its the infrastructure thats the underlying issue. Always ensure you have plenty of storage available for your repository and fast responsive disk. Flash may not be an option, however FC/SAS should be considered. Older storage classed as lower tier will likely not suffice.
Determine placement of application repository
We have already discussed that the repository needs to reside on a Windows file share so that’s our first constraint we need to adhere to. This being said CIFS shares direct from a storage array are a good option and depending on the disk it’s being hosted on should give good performance also. DFS is another option and will allow replication between multiple shares for BC/DR.
Try and ensure the ThinApp repository and the Horizon View desktops reside in the same virtual infrastructure. With the hosts and the repository being close by to each other in the data centre will provide shorter distance to travel across the network and faster response times.