Tuning Windows 10 Part 4: Deploying the golden image


There has been a popular request for this article, in the series I was writing number four was missing. I thought, and boy was I wrong, that no one would be interested in reading about a deployment of a Windows 10 image in a virtual environment.

Deployment

The series

This series consists of a couple of articles, this article, although it is part four, is the last part.

  • Microsoft Windows builds, versions – Click here.
  • Creating the virtual machine – Click here,
  • Installing Windows 10 – Click here.
  • Tuning Windows services and scheduled tasks – Click here.
  • Deploying the golden image, you are reading it.
  • Resource usage of Windows 10 in a VDI environment – Click here

Back to the future

A little look at what we achieved so far. We’ve decided which Windows build and the version we use in our environment. Of course, while this year progressed Microsoft changed a number of things with Windows 10. Deployment of Windows 10 has changed from CBB / CB to SAC / SACT. initially, it looked like they would only deploy SAC version but someone woke up in the office and technically we are back to where we started. Every six month they release a Windows 10 build, this build will be the SACT version. With this version, you can pilot your applications.  After a few months, this build is promoted to SAC. At that stage, it is production ready and you, as you tested your applications, can deploy it broadly.

We created a virtual machine, tuned it so that all the crap is gone. Tuning is something that will take most of your time in the future as well. Microsoft, we noticed, is adding features to Windows 10 without hanging the posters in the hallways. Services might be added or scheduled tasks are added. You need to be very keen on this as we’ve seen performance issue there missing new services.

We tuned the services and the scheduled tasks we found in the build we tested. With all this done we are ready to deploy a desktop for the users.

Deployment

As this blog is not about VMware or Citrix or any vendor as it comes to delivering a desktop I initially decided against writing this blog. I will talk you through the different scenarios of deploying a Windows 10 desktop for the various vendors. Don’t want a sticker on my head being a fanboy of either one, as I’m not.

Citrix and VMware are the vendors used mostly for provisioning desktops. So if we look at Citrix we see they offer two ways of deploying desktops.

  1. Citrix Provisioning Services (PVS) – streaming of desktops
  2. Citrix Machine Creation Services (MCS) – Linked clone type of deployment

If we look at VMware we see that they offer also two way to provision desktops.

  1. VMware Linked clones
  2. VMware Instant clones

Of course, both vendors also support persistent desktop or existing desktops to be used but a persistent desktop can also be deployed by either solution.

Citrix

Let’s start with Citrix, as mentioned before they work either with PVS or MCS. The way these offerings work is very different from each other. When you want to use PVS you need to install the Target device software in the golden image before you continue.

For more information, I would recommend the Citrix eDocs which are found here – Citrix Docs

PVS

Citrix PVS works with a vDisk, this vDisk is a copy of the golden image and is streamed to a target device when this devices MAC address is found in the database. So when you want to deploy our image to Citrix PVS, install the target device software in the image. when the software is installed you are asked what you want to do.

Do you want to work with a vDisk that is already waiting on the PVS server or do you want to create a new vDisk? Another question you will get is whether you want to use dynamic or static disks. I think the general recommendation is to use dynamic disks, there was a lot of debate about this but I think dynamic won.

Once you worked through this you select the disk you want to copy to a vDisk and the software goes to work. In the end, the vDisk is created and you need to reboot the target machine which now will boot (PXE) to get the disk streamed.

MCS

With Citrix MCS the process is a bit different, far more simple to be honest. I’ve always been a fan of PVS but more of what it can do that of the complexity for admins. With MCS this complexity is completely gone. Our image that we created is ready as it is, it only needs a Citrix VDA installed. The VDA is the agent that will communicate with the Studio server or broker and offer the channels to the user.

Once the VDA agent is installed you shut down the image and create a snapshot. With that, you are 90% done already. Within Studio you create the desktop pool, select the golden image and the snapshot. The desktop pool is created with the options you selected.

Of course, Citrix MCS also has its pitfalls. With PVS you can select a certain vDisk and connect it with one or more desktops. Once these are restarted the new vDisk is streamed instantly. With MCS changing an image is not as instantly, it will need to copy information first to each datastore or host before it can replace the delta disk of the virtual machine. The identity disk is kept. It happens that replacing the version requires a couple of reboots. From an IT admin point of view managing an MCS environment is easier to understand.

I think with this you should be able to deploy a desktop pool if you want screenshots of this please look at my fellow bloggers there are many who screenshot every step. I don’t have a blank Citrix environment on hand right now.

Creating a pool in either offering is done the same way, in the desktop pool selection screen you will see the option to select either offering and anything else.

Deployment
Copyright Carl Stalhood

VMware

VMware as well as Citrix has two option to deploy your desktops. Linked clones were their first and primary option but Instant clones were introduced a while ago. For instant clones, however, you need the Enterprise license while the linked clones are available in all licenses. So when we look at the deployment of Windows 10 in a VMware environment we get the following.

For more information, I would recommend VMware knowledge base which is found here – VMware Docs

Linked clones

With linked clones, you are in the same scenario as we saw with Citrix MCS. Citrix initially didn’t have a linked clone offering but created a similar offering as VMware is offering. If you take our golden image, all tuned, and install the VMware Horizon agent in it you have prepared the image for deployment.

After you installed the agent you shut down the golden image and take a snapshot. don’t overdo with the snapshots are they also will take a hit at your performance. Once you created the snapshot you can open the admin console and create a desktop pool.

Select the type of pool persistent or non-persistent and after you selected the option you select the golden image. Once that is selected you see all the snapshots and you select the last one. More options available there but they are no different than with Windows 7.

Instant clones

Not that much different from Linked clones, the biggest change is that you don’t need a Composer server. VMware developed a technique that was already used in other areas called forking. By using forking they can speed up the creation of the desktop and skip some reboots.

What you need to understand is that, besides differences in the configuration of the backend, is that when you install the VMware Horizon agent you select the right option. Default the agent installs to serve linked clones and a Composer server. To use instant clones you need to clear one checkmark and select another one.

Creation of a desktop pool is the same in both offerings, no differences there beside that you select the option while creating the pool.

deployment

There is a difference in how you update a desktop pool, with Linked clones you recompose and that does what it says. It recomposes the desktop pool and will deploy replicas. With Instant clones, you push a new image.

Deployment

Windows 10 experiences from the field

I don’t think that anyone reading this article is really wondering how to deploy Windows 10 in a virtual environment. Deployment is pretty straightforward and Windows 10 is like Windows 7. Where they differ a lot is how they perform in the virtual environment. Windows 7 was nice when it was tuned but Windows 10, even when it is tuned, is still bugging us.

If we look at the design you might start to question if non-persistent is still an option when working with Windows 10. Microsoft did not design Windows 10 to operate in a virtual environment hence the question. Windows 10 was designed to run on powerful devices like laptop and desktops.  In a non-persistent virtual environment, the “power” of Windows 10 is being challenged. Each boot is like a groundhog day and it seems that Windows 10 is not a fan of that movie. It might be that a persistent environment is the best way to handle Windows 10.

That would bring new challenges along with the desktops in the virtual environment as they suddenly need to be managed like FAT clients.

User profiles

One of the challenges that would instantly come along is how to handle user profiles? My way of handling user profiles in any non-persistent environment has been to add a UEM layer on top of the desktop. I didn’t touch the profile Windows was creating. Didn’t create a default user profile and so on as with changes you needed to change that as well. Of course, I did do those things but only to see if the customer would benefit from it. I stopped doing it and just used UEM for this, way more powerful and easier to maintain.

In a persistent environment, this is a challenge as the profile created by Windows is not deleted after logoff. The challenges we used to have 20+ years with roaming profiles are suddenly alive again. This is a serious challenge.

So you might think I favour a non-persistent environment but I don’t as they also have challenges. One of them rears its ugly head when things move to the Cloud. If Exchange is Cloud-based Outlook can’t work with a direct connection anymore and needs an offline cache. In a non-persistent desktop, a cache would be lost after logoff. There are solutions of course from VMware, Citrix, Liquidware and FSLogix. But remember there are challenges with each choice you make, please take a good look at your application landscape and design accordingly.

I hope this last 2017 article gave some insight into deployment. I didn’t encounter many issues outside performance and user profile things. Still very unhappy about Windows 10 usage in a virtual environment but also still working to understand how we can improve it.


0 thoughts on “Tuning Windows 10 Part 4: Deploying the golden image”

Leave a Reply

https://tracking.cirrusinsight.com/869c29e2-3a9b-48c5-9232-0b95e7993ae8/controlup-com-pixel-php