Deploying Applications to VDI

Today’s post comes from a question submitted via the mailbag. In this post we will look at ways of deploying applications in ConfigMgr reliably and quickly to personal or pooled desktops in a VDI environment.

The mailbag question comes in from JPUK who writes:

We are looking at using SCCM 2012 SP1 to deliver App-V 5.0 apps to desktops, both physical and pooled VDI. The pooled VDI desktops experience a severe delay in receiving their allocated applications.

What would be the best practice to follow in implementing such a scenario? Do we need to consider pre-caching large/more frequent used applications?

Before We Begin

Before I go into any detail in this post, we touch a few questions here. The first is, can we speed up the deployment of applications? (Remember App-V sequences are just a different deployment type) The second, can we effectively manage our pooled VDI clients just like a desktop? Finally the third is, should we look at caching content before deployment?

Managing VDI Clients

The first topic I want to touch on is, can we manage our VDI clients in an effective way just like a desktop, laptop or server for example. The answer to this is yes. However due to the nature of the pooled VDI world it requires some specific setup of ConfigMgr before we can do this.

You may remember some time ago a post about managing XenDesktop clients using ConfigMgr. The process I am about to go through is very similar if not the same actually. First steps are to prepare the master image that your pool will be based on. To do this three steps are required, they are.

  1. Stop the CCMExec Service
  2. Delete the file C:\Windows\SMSCFG.INI
  3. Run CCMDelCert.exe (can be found in the SMS 2003 Toolkit)

From here we need to sysprep our image so it is ready for VDI. What this process means is that when new clients are spun up in the pool, each client will have a unique GUID, this is very important as we cannot manage clients with duplicate GUIDs. You can verify this information by looking in ClientIDManagerStartup.log which will inform you the client has been granted a certificate, followed by the hardware ID of the client and then the GUID. This information is stored in SMSCFG.INI. We still need to persist the SMSCFG.INI file for each client which can be done with a startup and shutdown script in Group Policy. More information on this GPO configuration can be found on this article.

The next step is to create a collection, something like “All Pooled VDI Clients”. We can populate this with a number of methods depending on your configuration. For example, Active Directory group membership, NetBIOS name, domain OU and more.

The next step here is to reduce the client policy interval in a custom device settings policy as shown in the screenshot.

033012_1244_TheFinalMan2.png

So here we have set the polling interval to 15 minutes (you could set this lower), these clients are on a well-connected network in our data centre so that means we can afford a lower setting for these clients. We can also in this custom policy set the hardware and software inventory to be much more frequent if we want inventory.

Once this is setup, deploy this policy to the collection you created above.

Speeding up Deployments

The next question to answer is can we speed up deployment on our pooled VDI clients. Again the answer is yes. The first method as above is just to make the policy refresh more frequent. However you can do this another way if you wish, it does require a logon script. Something you can add as a logon script or maybe just something in the image under the Run key in the registry.

The PowerShell script will basically execute a client action trigger such as “Machine Policy Retrieval Evaluation”. This can be set to execute as logon so by the time the user is logged on and has Outlook open for example, you have a good change the client policy has been updated, two lines of code is all we need.

$Client = [wmiclass] ("\\.\ROOT\ccm:SMS_Client")
 $Client.TriggerSchedule("{00000000-0000-0000-0000-000000000021}")

Caching Deployments

The final question to answer here is should we cache any deployments or frequently used applications.

In this scenario I would generally make use of the feature block technology within App-V, especially for those well-connected VDI clients. Using this method, actual launching of the application can be quicker when feature block zero or FB0 is configured properly for a sequenced application. I would recommend checking out the fantastic blog of Aaron Parker on this subject.

Another suggestion on this question would be to make applications available for users to launch through the Application Catalog rather than forcing the deployment. In this instance the user picks what they want and the applications are installed in real-time rather than waiting for policy to download to the client. This is one of the benefits user-centric targeting brings us.

Summary

Bit of a long one (sorry about that). I hope it answers the question or at least provides you with some guidance JPUK. Stay tuned for the next mailbag submission.

Advertisements

Tags: , , , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: