My customers often send me exciting cases. This particular one is especially interesting because it is common in infrastructures that use "Local Administrator Password Solution" (LAPS) for password management. LAPS, which I can't recommend highly enough, provides management of common local administrator account by setting a different, random password on every managed domain-joined computer. The case opened when a customer contacted me a few weeks ago reporting that they experienced issues when re-installing computers using Microsoft Deployment Toolkit: after OS deployment, LAPS didn't update the local administrator password which in turn significantly increased the risk of lateral escalation (Pass-the-Hash (PtH)) that results when the same administrative local account and password combination is used. Given the importance of the customer, I immediately sat down to investigate.

As a reader of this blog, I suspect that most of you, like me, are frequenting Twitter. And I bet many of you picked up useful information shared by other IT Pros. Every day when I wake up, I typically spend a few minutes going through my feed, to stay current by consuming small bits of information on a daily basis.

Continuing the theme of focusing on disk-related cases (yesterday I posted an article detailing how to fix the "Verify BCDBootEx" step failing on HP ProDesk 600 MT G3 systems), this post showcases yet another reason why you should stop deploying systems in Legacy mode. It also shows how a little time spent on reviewing log files to get a couple of clues can quickly lead to a solution.

If you’ve read any of my tweets, you know that I emphasize how Microsoft Deployment Toolkit and ConfigMgr are powerful OS deployment tools which allow a high grade of customization. This blog post is another demonstration of MDT flexibility. It also shows how a PowerShell script can quickly lead to a solution.

In several of my previous articles, I've discussed how to remove built-in applications and capabilities during operating system deployment. Over the past few years, I delivered quite a few customer-focused Windows 10 workshops in which I placed emphasis on covering Windows as a Service in great depth. After all, one of my primary goals is to enable IT departments to keep pace with more frequent Windows updates and to allow them to continuously deliver new functionality to end-users. I realize that there are still some misconceptions out there as well as a need for more user guidance. In today's blog post I'd like to focus on removing built-in applications and capabilities straight from install.wim, and why you might want to do this in the first place.

Windows 10 "April 2018 Update", also known as version 1803, "Redstone 4", or RS4 will be available via Windows Update for Business, Windows Server Update Services (WSUS) and the Volume Licensing Servicing Center (VLSC) starting on the 8th May with the download via Media Creation Tool and Visual Studio Subscriptions (MSDN Subscriptions) already being available. Windows 10, version 1803 is the fifth feature update released for Windows 10. As with the previous updates, Microsoft continues the trend of moving to more agile development and delivery models as part of the ongoing "Windows as a Service" efforts with Windows 10 1803 update making the base operating system better with new features to help IT pros more easily manage and better protect data and devices in their organizations.

The development of the Spring Creators Update (codenamed "Redstone 4") is now heading towards the finishing line. We can assume that Windows 10 1803 is now feature-complete and as such, I can't stress it highly enough that you should start testing the newest features and functionality in this Semi-Annual Channel release as soon as possible in preparation for broad deployment to the devices in your organization. As part of this process, you should take a look at provisioned apps - most likely you want to ensure that only a choice selection of apps is being installed, whenever a user logs on either for the first time or after installing a feature update on a Windows 10 computer, because app installation directly impacts login times.

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 three regular readers. Yesterday I successfully solved an interesting case that opened when a customer contacted me a month ago and reported that the Photo app was no longer working on their 1709 reference image.

As Windows 10 Redstone 4 Update (1803) development winds down, it’s the grandiose time to examine updated and new Group Policy settings. There is (obviously) no official documentation from the Group Policy team at this point and there might be quite a few changes to Group Policy settings before Windows 10 Spring Update hits RTM. Still, it can't hurt to poke around current ADMX files because there are truly several things duller in our line of work than comparing thousands of lines of text. Right?

There are many reasons why an organization would spend a lot of time on image creation and maintenance. Often, it’s due to the lack of a standardized image engineering methodology. Whatever the cause, the experience of manually creating Windows images quickly deteriorates and becomes a time-consuming and difficult to manage organizational nightmare. However, using free Microsoft deployment tools and PowerShell you can greatly simplify the task of building and maintaining Windows images.