Master Images – hidden CPU time bombs
Wrapping up master images has become something virtualization engineers of all product disciplines have to become familiar with. A bad master image can be deployed dozens or hundreds of times – only to find out a simple tweak could have saved you thousands in necessary hardware costs.
Here’s a new hidden gem I found and I hope to add to this list as more arrive.
Installing or updating Dot Net
Almost all Microsoft patching includes some form of a dot net update. When this product is updated, it likes to recompile a lot of code to help speed up launching dot net applications – pre-compiling actually does help user perception of application launch speeds.
Typically you run windows update on a server or workstation and dot net installs its updates and queues items in a work list that dot net executes later. This typically happens later in the day or evening and almost always pegs your CPU for a minute to 1/4 of an hour while is pre-compiles code.
Microsoft is pretty clear about this process in this MSDN Blog post.
The problem is, when you’re patching master images – you don’t want to leave the queued items for each deployed VM to have to execute. Deploy a dozen servers, and now you have a dozen servers with queued dot net jobs waiting to flog your CPUs.
For Windows 2008 R2 and Windows 2012 servers, you can easily kick off these queued items before you wrap up your images for templates by following these simple steps:
- Run a comand prompt or powershell prompt with administrative privlegdges.
- Run this command:
- Wait for the compiling to finish
The blog post above contains other paths for other versions of Windows, but hopefully that helps others.