Virtually Jason

When configuring Windows for use in VDI, we disable Windows Update.  Why push updates to 1,000 end points when you can instead update the master (be it a Linked Clone parent or an Operating System layer) and just switch everyone else over to the updated version?  Of course, your admins will still need to be able to update their master image, which isn't allowed if the Windows Update service is disabled. I know that it's easy enough to go in, enable and start the service, apply updates and then disable the service once again... but if something's that easy to do and must be done over and over, it's probably worth scripting.  In fact, referencing the XKCD "Is It Worth The Time" chart  (I'm so happy that I have an excuse to link to XKCD on here), since this is a monthly task and I'm probably shaving about 30 seconds off of the process, I can see that my 10 minutes spent looking up the commands to do this was time well spent! Anyway, the script is supe...

There are two very useful documents around making Windows 7 work in a VDI environment; I find myself searching for these with some frequency, in order to provide links for customers.  Given that frequency, I guess that it’s only appropriate that I make a quick post here about them. The first one is the Windows 7 Optimization Guide .  This guide contains a lot of useful (really, vital) steps that make Windows 7 work well in a VDI environment.  It’s an excellent guide, with information as complex as how to make a customized Windows install or as simple as just running a batch file that makes the changes.  It also explains the changes in great detail, listing requirements vs. recommendations, so it is definitely worth a read. The second one is a KB article.  When using multiple monitors, there will be “hitches” when a user drags a window from one monitor to the other.  To prevent this, you must change some VM advanced settings  on that VM. ...

Getting control over your Default Printer in a Windows 7 VDI environment is a little more difficult than I would have expected.  There are a lot of different factors that can come into play and, depending on the type of client connection, you can get some unexpected results.  Here are the factors that I know of that can set a desktop’s default printer: 1) The user’s Profile 2) A logon script/GPO 3) Windows’s spooler behavior when the default printer that it expects is missing 4) The TPAutoConnect.exe program (which executes automagically at PCoIP session connection) My current customer is intending to use a combination of #2 and #4.  The logon script is setting their network printer based on who they are and is responsible for 90% of the printer assignment.  TPAutoConnect.exe is used to install direct-attached client printers and map them into the VDI desktop.  The simple fact that the plan doesn’t involve #1 and #3 doesn’t remove them from the equati...