In my last blog post, I discussed clearing Trusted Platform Module (TPM) using PowerShell and MDT. This time I’m turning my attention to another issue: field upgrading TPM from 1.2 to 2.0 specification on HP and Dell systems which support discreet TPM switching.

Systems that shipped with Windows 7 from the factory will have TPM 1.2, however, most modern systems feature a firmware based component running in a trusted execution environment on a general purpose SoC, which allows discrete TPM mode switching in real time. Customers I worked with in the past couple of months and which roll out Windows 10 intend to make use of important security advantages of TPM 2.0 specification including greater crypto agility by being more flexible with respect to cryptographic algorithms, newer algorithms, which can improve drive signing and key generation performance, a more consistent experience across different implementations and a consistent dictionary attack protection guarantee.

Before a Trusted Platform Module (TPM) can be used for advanced scenarios it must be provisioned. Windows 10 automatically provisions a TPM, but if you are planning to reinstall the operating system, you may have to clear the TPM before reinstalling so that Windows 10 can take full advantage of the TPM. In today's blog post, I will take a closer look how to clear the TPM ownership using WMI in Microsoft Deployment Toolkit (MDT), allowing Windows 10 to automatically take ownership of the TPM on the next boot (TPM AutoProvisioning). Clearing the Trusted Platform Module (TPM) cancels TPM ownership and invalidates cryptographic materials created by the previous owner.

This case is my favorite kind of case, one where I get to learn something new to solve a problem. The other day I was creating a couple of users in my Office 365 environment and assigning Exchange Online licenses when I was interrupted with a message that informed me that "The email address "This email address is being protected from spambots. You need JavaScript enabled to view it." is already being used by contact (Christopher Blair) This email address is being protected from spambots. You need JavaScript enabled to view it.. Use a different email address.".

As Windows 10 Fall Creators Update development winds down, it’s the grandiose time to examine updated and new Group Policy settings. There is no official documentation from the Group Policy team at this point, frankly there still might (or will) be a few changes to Group Policy settings. 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 lines of text. Right?

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 small PowerShell script can quickly lead to a solution.

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.

A couple of days ago, I posted a blog post detailing how to add language packs to MDT using PowerShell. In today's blog post I am going to build up on that and showcase how I use PowerShell to automatically generate a tasksequence specific CustomSettings_%TaskSequenceID%.ini containing the rules required to create a simple and dynamic deployment process. This includes configuring commonly used rules and also injecting language pack GUIDs.

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".

In order to deploy Windows 10 with Microsoft Deployment Toolkit in a multi language environment successfully, you probably have to work with language packs. In today’s blog I will discuss the approach that I use to import language packs and features on demand packages in Microsoft Deployment Toolkit using PowerShell.

I would never usually be as presumptuous as to suppose that I knew exactly what my thousands tens of readers wanted to hear me talk about this week, but this is clearly a special occasion. Only one thing has been on everyone's mind since Microsoft quietly updated the list of features that are being removed and/or deprecated in the Windows 10 1709 update, and only that thing would be expected to be the subject of an almost-weekly almost-amusing blog post.