Everything you wanted to know about virtualizing, optimizing and managing Windows 10, but were afraid to ask – part #8: OPTIMIZATION
By James Rankin | 12th October 2016
With Windows 10 now into its latest edition, the 1607 “Anniversary” update, it now appears, for better or worse, to be here to stay. It has generated a lot of interest; supposedly the “last version of Windows”, many expected it to be akin to Windows 7 – an improvement following a much-maligned previous Windows version. However, the reality has turned out to be somewhat different from what many were expecting.
Microsoft are now “cloud first, mobile first”, and a lot of this new strategy shows through – sometimes somewhat cynically – in Windows 10. For my sins, I’ve been involved in a Windows 10 deployment since August of 2015, so now, just over a year in, it is maybe time to share the things I’ve learned in the hope that it may give some of you a bit of help when it comes to deploying (or not deploying!) this new version of Microsoft’s flagship operating system.
This set of articles is going to expand at the rate of one a day over the next week or so, and cover a wide range of issues for those of you deploying Windows 10 – whether it be fully virtualized via Citrix XenDesktop or the like, or simply a general physical deployment. Hopefully, it will be everything you need to know!
Getting the best possible performance out of Windows 10 is paramount, because users (especially those on Windows 7) will have a certain level of expectation. In fact, what you are facing these days is not simply an expectation borne out of previous experience – it is much more of a generational thing.Fifteen years or so ago, users didn’t really have devices in their houses (maybe games consoles, the odd PC, but generally not much). In the enterprise, users were given PCs using a monolithic image with natively-installed applications, usually delivered by something like SMS (the product that was later to become SCCM, for younger readers). Users had no choice, no preferences, no input – they just got what they were given, the tools to do their job as prescribed by enterprise IT.Of course, now we have a generation of new users with tablets, smartphones, online services and subscriptions, all of whom expect a certain level of performance and intuitiveness, because that’s what they’ve become used to. If the interface they’re presented with doesn’t measure up to their expectations, then they will reject it. So we’ve got to extract the maximum possible performance from a Windows 10 instance for our new breed of users – and that can be challenging, because Windows 10, performance-wise, is a bit different compared to its predecessors.
When we deployed Windows 10, we noticed a few bottlenecks from a performance perspective:-
Very long first logons – these are a major bugbear, especially in open-access areas where many users share the same machines. In our observations, standard Windows 10 can take four to five minutes for the first logon to be processed. This issue also manifests itself, unsurprisingly, in non-persistent VDI environments
Lots of disk activity – Windows 10 shows a large uptick in disk I/O compared to Windows 7 and Windows 8.1. According to campfire rumours, Microsoft based a lot of their design and testing for Windows 10 on three large customers from the US who have all adopted solid-state drives right across their environments. Whatever the accuracy of this, Windows 10 appears to be particularly optimized for SSD environments. It performs much more acceptably when used with a solid state drive for the boot disk
Large system footprint – Windows 10, in its default configuration, has a very large footprint of services and scheduled tasks. Some of these are not necessary for enterprise environments and can be disabled
Update processes – Microsoft had the whole “Patch Tuesday” practice nailed down, with a predictable and process-friendly method of deploying updates, but Windows 10 appears to throw caution firmly to the wind in this department. Universal Windows Apps appear to update simply whenever they feel like it, and even the standard operating system updates come down in a far more haphazard fashion than has ever been seen before
Boot behaviour – we also have noticed a real discrepancy between logon times and initial system performance when a “cold” boot is compared to a “warm” one. When Windows 10 starts up, the logon screen is presented to the user while a lot of boot processes are still running in the background, and this background activity consumes a lot of resource, resulting in sub-optimal performance if a user logs straight on after a boot-up. This is a smoke-and-mirrors tactic introduced by Microsoft in Windows 8 to give the impression of faster startup times, but it can detract from the overall perception of the system’s performance
Firstly, if at all possible, I’d recommend using Windows 10 systems with SSD or some form of flash-based storage, whether the systems are physical or virtual. If you can, this offsets some of the “drag” that you will see, particularly if moving from Windows 7 to Windows 10.
Remediating that long first logon is something that we’ve discussed previously. Using a custom default user profile, removing Modern Apps, creating customized Start Layout files – all of these help towards getting this down. In an ideal world, your first logon should be reduced by these methods down to 40 seconds or under, which I would class as acceptable.
Dealing with update processes is a tricky one. Firstly, I would remove as many Modern Apps as possible and disable the Store and Store updates to cut down on a lot of this. Then you need to make a decision about how you want to deploy updates to your endpoints. Obviously you want to turn off the Windows Update peering features (this can be done via GPO), and make sure you use a technology like WSUS or SCCM to maintain control of when updates are deployed.
The “cold boot” issue can be overcome also, if you find this is affecting you. If you have high-turnover environments where users need to get working quickly, waking the machines prior to peak times and “pre-booting” them may be a useful approach. If you’re a VDI environment, you could automatically spin machines up using a variety of management technologies – if you’re not, using Wake On LAN or the like may allow you to achieve this.
With regard to reducing the system footprint and putting in some settings that will improve the performance of the system (particularly for VDI), then we are fortunate to have some automated help at hand, in the shape of the VMware Operating System Optimization Tool (OSOT).
This tool was originally developed to optimize systems for Horizon View deployments, but it’s so effective I would recommend that it is used – carefully! – in any Windows 10 deployment. Obviously you need to test it on non-production systems first and validate the performance of your applications – if you want me to fix anything you break in this way, I will be charging my full day rate 🙂
You can find the tool at this URL – https://labs.vmware.com/flings/vmware-os-optimization-tool. What I generally do is wait until my Windows 10 machines are building, then drop into Audit Mode (see the PROFILES article for how to do this) and then run the OSOT whilst in Audit Mode. This performs all of the customizations on the user that will then be used to create the default profile, which kills two birds with one stone, as all of the user-level customizations are then baked into the image along with the machine-level ones.
You can also use the OSOT to create your own templates for optimizations if you want to get advanced. I can’t stress enough, this is an invaluable tool for operating system optimizations, and the fact that it is provided free just makes it even better. You can also use it on all earlier Windows operating systems, including servers.
If you want to just do this in a very simple straightforward way, you just unpack the OSOT and run it directly on your client image, from a network share or wherever you may have stored it. In this example, we’ve run it on a completely vanilla Windows 10 Enterprise 1607 build with a standard domain-joined configuration. You will notice that it produces a list of options and recommendations, along with possible advice as to under what circumstances you may want to enable each setting.
Once you’re happy with your selections (or if you’re just testing and want to see what impact the changes have), simply click the Optimize button and let it do its stuff!
This will apply all of the selected optimizations. As I said earlier, this is particularly effective when done in Audit Mode so that all of the user-level customizations then get captured into the default user profile (as long as you clean it up afterwards as specified in the PROFILES article), and would then be applied to all users that log on to the endpoint. It also does a certain amount of garbage removal around Modern Apps (although some will be leftover and need you to remove them), and it also takes a hammer to some of Windows 10’s more, shall we say, less useful features, so it’s pretty much an all-round Windows 10 cleanup tool.
You can also download “public templates” which have been submitted by the community, or even submit your own, so that when newer Windows 10 versions arrive you will still be able to deal with them. It’s an excellent tool, and I must mention Jeroen van der Kamp of LoginVSI for first alerting me to it when he did a Citrix User Group presentation on Windows 10. Quite simply, this is an invaluable tool to any Windows 10 administrator. One of the issues with Windows 10 is that because of the fast update cadence, there is considerably more application testing and remediation required – so automation of any type is very welcome and takes pressure off IT departments which may already be completely overloaded. You simply can’t ignore the OSOT – if you’re deploying Windows 10, get it in your arsenal.
So what are the takeaways for optimizing Windows 10?
- Get SSDs if possible in your machines (if they’re physical) or use fast storage (if they’re virtual)
- Remove Modern Apps you don’t need, and disable the Store updates
- Use WSUS or SCCM or the like for updating, and make sure you have a tightly controlled update process
- Investigate “pre-booting” techniques if you want machines to be in a fully optimized state when users come in and start logging on
- Use the VMware OSOT in Audit Mode to apply a tested optimization template (don’t forget to clean up the default profile afterwards!)
With these optimizations in place, you should be able to see performance from your Windows 10 estate that approximates that which you had before. For the most part, in-session performance from Windows 10 isn’t markedly different, but if you apply these optimizations, you should be able to make sure it is as lean and mean as possible for those demanding new generations of end-users.
My last day-to-day project came to a sudden end, so if anyone wants my help on anything, I’m currently available. I’d be only too happy to help, advise or even come and present to companies about Windows 10 migration and deployment (not surprisingly, I have a huge amount of material about it – these articles only scratch the surface!) Of course, I’m also all about the EUC arena, user and app virtualization, Citrix, AD and many other technologies – anyone who has a project they need help with, then just get in touch with me by emailing james [at] htguk [dot] com.
The next instalment of this series is going to be about MANAGEMENT – stay tuned!
Bonus item for the RES User Group attendees I spoke in front of on the 29 November – here’s a link to the slides I used, should you want to get them.