While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s something rewarding about quickly finding a solution. In the process, I often end up with an idea for a blog post I can share with thousands five regular readers. A couple of weeks ago I helped a customer solve a particularly weird case: the "legacy" printer management (meaning that Windows will not manage the default printer) was enabled and yet - for some reason - the default printer kept changing for end-users to "Microsoft Print to PDF". Obviously something was broken so I had to investigate.
This case is my favorite kind of case, one where I use PowerShell to solve an issue affecting a customer. The problem at the root of it is also one you might run into if you are using Microsoft Deployment Toolkit (MDT) to apply language packs and features on demand during OSD, making it an ideal troubleshooting example to document and share.
A key part of any complete end-to-end deployment project is analysis of the resulting logs to identify root causes for hiccups you may run into during your deployment process. This is part of the new "data driven" mentality because operating system deployment (OSD) is highly complex and contains many moving parts. You can save yourself a lot of time and energy if you know where to look for answers. I can’t stress enough how invaluable log files can be in tracking down deployment issues!
I bet many of you, like me, performed system maintenance duties for your family. Last week my mom complained that her Windows 10 PC was extremely sluggish. For example, when she opened Microsoft Edge - which I consider to be the best and the most secure web browser on the market for nontech savvy folks - it took round about 10-20 seconds for the browser to become responsive. I had no choice but to investigate. After a couple of minutes with SysInternals tools, I was able to determine the cause and to come up with a workaround.
I haven't blogged the last couple of days because I was busy answering questions on TechNet. A couple of posts ago I talked about the importance of spending some quality time on TechNet as it may bring interesting cases to your attention. Today, I would like to highlight one of these cases in hopes that someone from the Microsoft Deployment Toolkit Team team is out there listening.
A few months ago a customer complained that on a Dell Optiplex 7040 MiniTower the boot menu contained multiple entries for the "Windows Boot Manager". Given that we were in the process of deploying Windows 10 client and the importance of the customer, I immediately started troubleshooting. This particular case is especially interesting because it might affect a large number of users and the vendor was not aware of the issue.
As a reader of this blog I suspect that you, like me, are a frequent visitor to TechNet forums. And I bet many of you have already posted a question there or even spent a few hours helping other people out. A couple of days ago, a user posted a question on the MDT forum asking for guidance on how to upgrade Windows 10 VMs to the latest iteration of Windows 10 "Creator's update" using what I consider – not surprisingly given my history - the best free deployment solution, Microsoft Deployment Toolkit (MDT), partially because a Microsoft Deployment Toolkit task sequence allows you to completely automate the feature update process.
As you’ve probably surmised by my blog posts and my Twitter ramblings, I like to push OSD to its limits. Besides keeping my deployments running smoothly, my vigilance sometimes helps me spot potential problems before they actually become an issue for my customers. The case opened wide when I started testing a pre-release Windows 10 1703 Insider Build based MDT task sequence. During the specialize phase, my VMs would run into a blue-ish screen stating that "Something went wrong".