As a reminder, Microsoft will be ending support for Windows 7 SP1 on January 14, 2020. I've had multiple enterprise customer engagements over the past several months and with less than two years left, I wanted to take a look at how you can potentially optimize your OS image and successfully transition to a Windows 10 environment. The clock is ticking!

The topic of Windows 10 optimizations comes up often enough, so I figured I should address it in a separate blog post. There are a lot of customers I've worked with who have heard "somewhere" (not sure where) that they should be optimizing their operating system by minimizing connections from Windows to Microsoft services and by disabling unnecessary services and features to improve performance. Now, I've seen a few optimization scripts on the net that will reduce the functionality and security configuration of your devices and may also put you into an untested and unsupported configuration. Consequently, I thought I would share the Windows 10 optimization script that I put together based on my conversations with enterprise customers. Several organizations used this script as part of their deployment to rapidly drive successful Windows 10 adoption and to thrive within a Windows as a Service environment.

It’s been a busy couple of weeks for me, so I’m slowly going through a backlog of things to cover. The push to get modern continues with the third part of my series on automating the process of transitioning from BIOS to UEFI using MDT. Today's blog post discusses the process of configuring BIOS settings on supported Dell Inc. enterprise systems.

This is the second post in my series that explores one of the most common questions I’ve been asked from folks who are migrating to Windows 10: "How do I go about transitioning from BIOS to UEFI?". So naturally, I’m addressing this question. This time, I am going to discuss automating firmware configuration on supported HP (Hewlett-Packard) notebook, desktop, and workstation models. Now, it's not as if it's been no-man's-land before. I am fully aware that there are blogs out there that talk about doing this kind of thing and I’ve tried a few of the solutions with various rates of success. Still, the feedback I've been getting over the past few weeks has been that I should share my approach when working with the Microsoft Deployment Toolkit (MDT), so, here's my attempt to do precisely that.

This article is the first blog post in a series I'll write over the coming days that will provide a comprehensive overview that explains how you can automate the process of transitioning from BIOS to UEFI during "wipe-and-load" OS deployment scenario. To be able to migrate from BIOS to UEFI effectively you need to understand how to configure firmware settings, such as secure boot, legacy support, and TPM device configuration, as well as how to use the MBR2GPT tool. Unfortunately, though it seems like a relatively straightforward process when using Microsoft Deployment Toolkit, based on questions I received as well as threads posted on TechNet over the past few weeks, there is still some confusion around this in the Windows technical community. Converting a device to UEFI comes with quite a few benefits including the ability to make full use of Windows 10 modern security features, so I thought it would be worth taking a few minutes to share my approach to dealing with BIOS to UEFI conversions.

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.