A recent engagement set out a scenario which I will uses as the basis for this blog. The scenario sounded very familiar and had many attributes that I have seen a number of times and it made me think. Is there a boxed “Solution” that could be used that would address all of these issues?
A customer has made the decision to run Non-persistent VDi before understanding the Application estate. Their initial deployment was for a single business unit with a very simple application set (Web apps and office). This has been deemed and presented as a success (and rightly so for the described use case) and has therefore validated the VDI Non-persistent design. The design was ratified and has now been added as the “Architectural Design Pattern” for on-going VDi requirements with a need to get exceptions through the Design process for deviating from the single Image approach.
The next business area/project requirement needing to deploy on to the VDi infrastructure happens to have the added complexity of multiple business departments all requiring a different matrix of applications. App-V is used in the estate, but as a fall-back position for application conflicts (e.g. delivery of MS project 2007 where the native office installation was 2010) and deployed through SCCM to their Physical Desktop Estate (i.e. no App-V infrastructure). The majority of applications in the estate are still deployed as MSI applications. There is also an expectation that their applications will virtualise on to the VDi platform 100% and that they will achieve the perfect single image solution. (The truth is that there is generally an understanding that not all applications will virtualise, but there is no design considerations in the infrastructure to account for the affect this will have on the number of “Single Images” required (and therefore the on-going Operational overhead of many single images), or what the effect many “Single Images” might be on the VDI infrastructure design (Consider how needing 5 different base images might affect the capacity of the infrastructure).
The New Business unit needs to be moved onto VDi as part of a larger business driven project. There are a number of departments within the business unit (10-15) all with their particular matrices of business applications. Some individual users also have individual application requirements for a good reason, they perform a particular capability within the department. There is a firm line drawn in the “sands of time” and that date is unmovable (think end of building contract and other such things). There is very little appetite to introduce a lot of new infrastructure as this would need to go through the standard design processes (Which are not aligned with the Projects Timelines) and these would also add DR requirements.
Any technology that might be introduced into the VDI infrastructure will be more easily fast tracked if it could be shown that there was potentially a larger organisational benefit (In this case – If the technology could also span the physical desktops and add value there, it would be more likely to pass the Architecture Processes).
- Introduce no new Infrastructure
- Deliver as many applications virtualised as possible to minimise re-provisioning the Image for application updates
- Manage the application availability on a per user basis
- Enable DR capabilities for the application and the users
- Keep to the principle of a "Single Master Image" for users and business areas
- Any technology that does get introduced should be usable across the whole desktop estate if proved to be of value.
- Oh - and the evergreen requirement - As Cheap and Quick as possible.
So in essence – VDI with a single image that delivers a full “user focused” application delivery model for virtual and locally installed applications without introducing any infrastructure components and can be easily DR’d.
One Possible Answer:
(Edit: It is always nice to see others having a similar mind set and just as I am finalising these articles to publish, MVP Rorymon has published the following article that I think is also a relevant read. App-V 5.0 Scalability)
Using AR.c we are able to rapidly convert the applications into App-V packages, test them and build a remediation plan. (For a view of the methodologies and processes that AR.c has been designed around take a look at the following pages on this site: AR.c LiT Overview, Package Throughput and Methodology. Whilst these are described as Services they are in essence capabilities that are enabled with AR.c, that if you followed the principle of effort based release will stand you in good stead for projects as well as BAU activities.)
This gives us the applications that we are able to virtualise (Apps that Just Work), the applications that will not virtualise and the apps that needed remediation and will worked through as the rest of the elements are being pulled together. We are also able to feed into the project a more realistic delivery timescale for the applications in the packaging process, as well as guide any migration planning based on effort.
2. App-V Deployment
To deploy the App-V applications to the non-persistent VDi infrastructure (or any other platform) we need tooling to replace the App-V server infrastructure or the SCCM agent etc. One suggestion is to use App-V Scheduler, as it brings App-V client management and other advanced deployment capabilities. Where it is not possible to use App-V Scheduler the alternative is to use a PowerShell script to add the App-V packages globally to each client. (See part 2). This script will walk the content directory and globally publish any applications and connection group files found. The PowerShell Script that came out of the example client engagement will be covered in part 2.
(N.B. Also worth a note. App-V Scheduler has also just released version 2.3 with new feature. See HERE for more information)
FsLogix is used to manage the availability of applications on a per user basis. It will managed both the installed and App-V Globally published applications utilising image masking. To achieve this the FsLogix Rules Editor will output Rules file (.fxr) and Access Rules file (.fxa). These files will be centrally stored and managed by a deployment script, the details of which are described in AD&M parts 3 and 4.
These Rules files will be created during the packaging process for both App-V packaged applications and also applications that are going to be installed into the OS. It is this technology that allows us to replicate the functionality of the Full App-V infrastructure by managing the availability of Globally Published applications based on Active Directory User Groups. If an application is to be made available across the enterprise then no rules need to be applied. It also enables the ability to deliver a single image across multiple user types when applications cannot be delivered virtual. All “Non-virtual” applications can be installed into the same base image and controlled with access rules. Users will only see the Applications, Plugins, middleware components that they are entitled to.
4. Service Account
A service account will need to be created that has Local Administrator access and also access to the appropriate file shares. This account will run the ScheduleTasks associated with the App-V Deployment & Management script, or App-v Scheduler Service, and the FsLogix Deployment and Management scripts. The same account may also be used for the UE-V Agent to enable access to the Application Template store.
UE-V is Microsoft’s User Environment Management software and is available in the MDOP suite. As this article is focusing on App-V as the virtualisation engine it is assumed that MDOP is available and therefore access to UE-V is also available. UE-V will enable the Application Persona mobility so that settings changes, made within an application by the user, can follow between devices.
6. Installed Applications
Finally we can create a Run Book to add the locally installed applications into the image. This allows the OS to be patched independent of the applications that need to be installed into the image. When there is a need to re-deploy the image to the VDi environment the most recent and current run book will add the locally installed applications, their patches/updates and the configurations into the image prior to deployment. If the timescales of the project do not allow for re-engineering all of these apps into MSI it might be possible to utilise the knowledge gained when using AR.c, to extract the silent installation capabilities of the applications and the key configuration information learnt whilst attempting to virtualise the apps (In a single image VDi deployment the benefits of Run Book install of the applications each time removes the need to uninstall applications from the image before adding a new version). This information could be re-used for the application installation run book. Not all of the applications will silently install but it might be acceptable that the effort to “click” some buttons for some of the applications is not an operational overhead too far (Re-packaging the applications might be an operational requirement or performed as part of an application maintenance task). The beauty of this approach is that these applications can be re-engineered at a later date out with project timescales. These can then be injected into the run book approach to automate the build better. But in this case the foundations are there.
It is possible using the above technologies and processes to make the best decision about the applications delivery format, based on effort and the time constraints/delivery requirements of the project, without either of the options having to affect the infrastructure design. The requirement of an application needing to be installed locally does not have to be considered a compromise in this instance. By virtualising as many applications as possible you do gain the operational benefits of not needing to edit the base image for application updates. To update a deployed application you need only add the new version to the Content Store (along with Connection Groups, FsLogix rules and UE-V Template is appropriate and “Archive” the old version. The next time that the Deployment mechanism runs it will add the new and remove the old. You also have an effective role back mechanism built in by switching the archived status of the original and recently deployed.
||Introduce No New Infrastructure
The only infrastructure required is the File Share(s) to store the App-V Content / the local application installation media / the FSLogix Rules, the UE-V data and the AR.c Database.
||Deliver as many application as App-V as Possible
AR.c will allow you to convert and test your applications as virtual applications quicker and ensure that effort is focused on the right applications.
||Manage the applications on a per user basis
FsLogix managing availability of both locally installed and App-V apps based on active directory group association.
||Enable DR Capabilities for Applications and Users
The FsLogix Rules, App-V packages, locally installed run book and UE-V file shares are all replicated and each technology is Platform agnostic. So in essence the DR might be onto Physical desktops / Laptops or RDS servers. In fact – Defining the DR requirements might mean that there is no need to DR the VDI infrastructure and for DR purposes you just have direct connected 1-2-1 sessions for the key personnel (this would be determined by an appropriate look at RPO/RTO etc.). The key point is that by making the delivery of applications, configuration and “user access” device centric rather than infrastructure tied, and the technologies platform independent, there are no dependencies for the DR mechanism or target. (Other than the replicated file shares).
It would also be possible to replicate the key elements to distributed sites if there was a requirement.
||Keep to the principle of a Single Master Image for users and business areas
We would able to reutilise the original Image that was deployed to the “Simple” business users and layer the above technology stack on top. We can then deploy the new image to both the new user base and the old user base without any of the original users noticing that there was any difference.
To round out Part 1, hopefully there have been some useful insights into the possibilities available when you are looking at deploying applications into any platform and that considering alternative solutions in your management stack might reduce the complexity of what is already a pretty complicated arena for EUC application and platform delivery. In the following AD&M Parts to this series I will cover in more detail the following: