Upgrading the BIOS Part 2

In Upgrading the BIOS Part 1, I gave some very important reasons why you should be proactive about upgrading the BIOS on supported systems in your environment. In this blog, I want to discuss the approach to flashing the BIOS along with some lessor understood caveats as it relates to BitLocker, BIOS passwords and UEFI 64-bit systems.

Any solution that I create and implement, I like it to be as modular as possible so that I can get maximum use out of it (it is the engineer in me and probably the reason that I still enjoy playing with Legos at my age). When flashing the BIOS, we need to be able to do it under two different operating systems – a full operating system like Windows 7/8.1/10 and a lightweight operating system called WinPE. This will allow us to handle existing clients that are already deployed and also bare metal/break fix scenarios. After all, it would not make much sense to have to boot into a full operating system just to flash the BIOS. Other solutions that I found relied on Configuration Manager Applications and Package/Programs. While these may work for specific scenarios, they cannot cover all scenarios. The Install Application and Install Package task sequence steps only run under a full operating system and not WinPE, so those methods eliminate the bare metal scenarios. Sure, we could create another task sequence or a duplicate package that just does bare metal, but now we have twice as much to manage, update and maintain – no thanks!

Now, there is a slight disclaimer that I need to put out there for the time being. Because of certain limitations with some vendor systems, plus the fact that Configuration Manager can only have one boot image assigned to a task sequence and that you need to use the correct boot image architecture to boot a UEFI system, then you will need to have a separate task sequence to handle the bare metal/break fix scenarios (or better yet, pressure the vendor into supporting 64-bit WinPE). The problem is some vendor models currently only support a 32-bit flash utility. If a system is configured for UEFI (or we are doing BIOS to UEFI in a single task – yes, this is possible now), then you need to use the corresponding boot image architecture. This is going to be 64-bit for modern PC systems (within the last four years or so). Long story short, be sure to check with the vendor of the models that you currently support in order to handle those exceptions (or get rid of them and buy something you can support).

Another important point, both the HP and Lenovo flash BIOS utilities require the WinPE-HTA component to be included in the WinPE boot image. Do not ask me why, I just know that it does not work without it. Just make sure that component is included and things should work just fine. Now Dell, HP and Lenovo do supply 32-bit and 64-bit flash BIOS utilities (with certain models being the exception), so you only need one task sequence if you have these vendors (and supported models). These are the only three vendors that I will be covering, but I will gladly take donated test systems of other vendors you would like me to test.

BIOS Passwords can be tricky. Usually you password protect something in the first place in order to make it secure. However, the flash BIOS utilities will take the password as a command line parameter or in some cases (HP) a bin file. Neither one of these methods are ideal for automation with Configuration Manager. A bin file is downloaded to the cache (or TS working directory) at some point in the process and you do not need the password in order to make changes (including clearing the password) as long as you have the bin file. Command lines get logged and there is nothing like having a password in clear text sitting in a log file. If you would like to see better handling/log file suppression, then head on over to UserVoice and vote up Secret task sequence variable value Exposed. I am not advocating to not use BIOS passwords, you should absolutely be using them in order to lock down settings that should not be changed (like Boot Order). You may have to get clever and write a compiled exe that masks the password(s) in your environment (yes – I know that even this can be cracked depending on how it is done, but at least it is more secure than clear text log files or bin files). Lastly, if dealing with multiple passwords, most of the vendors allow three tries before requiring a reboot and attempting again. If you have multiple passwords in the environment, have a group in the Task Sequence that removes the password before flashing the BIOS. You typically only get one shot specifying a password when flashing the BIOS, so this is a way to overcome this limitation.

When it comes to BitLocker, it will need to be suspended before flashing the BIOS (which is one of the reasons I like using a Task Sequence). If it is not suspended prior, BitLocker will detect a change to the system, and then be prepared to enter the BitLocker recovery key upon restart. It is easy to suspend BitLocker but keep in mind the native Configuration Manager step only suspends BitLocker for one restart. Newer Windows operating systems will allow BitLocker to be suspended for x number of reboots or indefinitely. See my previous blog, called How to detect, suspend, and re-enable BitLocker during a Task Sequence, for more information and examples. For 3rd party disk encryption you are on your own. Your best bet is to contact the vendor on how they support flashing the BIOS. If they do not understand what you are asking, then start seeking alternative disk encryption products (like BitLocker).

So, here are my tips and tricks in a nutshell when flashing the BIOS:

  • Use a task sequence for total control.
  • Incorporate flashing the BIOS into your OSD process for Refresh/In-place Upgrade/New Computer/Break-Fix.
  • Suspend BitLocker!!! (or be prepared to enter the BitLocker recovery key)
  • Disable/re-enable BIOS passwords or use it in the command line of the flash utility (just be careful not to have passwords in clear text in log files or command lines).
  • Dell requires a utility called Flash64w in order to flash in WinPE x64 (see First look – Dell 64-bit Flash BIOS Utility).
  • HP and Lenovo system work on WinPE x64, but requires WinPE-HTA to work.
  • Test, test, test!
  • Baseline and document supported configurations (including how each setting is configured), current BIOS version and release date (this part is key).

In an upcoming blog series, I will be covering off some of my tips and tricks on how to deploy BIOS updates in a modular, dynamic fashion during a Task Sequence (bonus – the same method can be used for drivers as well).

Originally posted on https://miketerrill.net/

Upgrading the BIOS Part 1

Operating systems and software are not the only thing that needs to be upgraded these days. It is really important that the BIOS firmware gets updated as well. Lately, I have been talking to a lot of IT Pros at conferences and user group meetings and I have discovered that not too many people upgrade or ‘flash’ the BIOS on systems after they have already been deployed (or even ever – sometimes they are sent out with the version they came with from the vendor). It is really important to change this going forward. I recommend developing standard versions that you support so that all systems are running your minimum standard version or newer. Periodically, a review of BIOS releases should be done to see if a later version should become the new minimum standard.

So why even upgrade the BIOS in the first place? There are a few reasons that I can think of that answer this question. The first reason is Windows 10 support. Believe it or not, the hardware vendors test the latest operating systems on the models that they currently support. Take the Lenovo ThinkPad T450, looking in the BIOS release history, you can see that Windows 10 support was added for version 1.17:

<1.17> 2015/09/07
– (New) Added win10 support.
– (New) Enabled N25Q128 SPI ROM support.
– (New) Added security fix addresses LEN-2015-002 SMM “Incursion” Attack.
– (New) Included security fixies.
– (New) Added new incompatibility bit for Back Flash Prevention.

Now this does not mean that Windows 10 will not work on versions lower than version 1.17. It means that this is probably the version that they validated and tested Windows 10 against. If you happen to run into an issue running Windows 10 on a version lower than 1.17 and you call in for support, chances are they will have you upgrade the BIOS to the latest version to see if that addresses your issue.

The second reason to upgrade the BIOS is to get fixes. It makes sense to start off on one of the latest releases than it does to start off with a version that is a year or more behind in fixes. By not upgrading to a recent version as part of the deployment process, you are potentially wasting everyone’s time – the end user, help desk, desk side (and your time if the problem comes back to you). Save the hassle and be proactive. Looking at a newer BIOS release version for the same Lenovo ThinkPad T450, we see that there is even a ‘SCCM’ fix listed in version 1.19:

<1.19>
– (New) Updated verbtable for noise.
– (New) Changed Haswell + N16s Tolud.
– (New) Updated Winuptp & Winuptp64.
– (Fix) Fixed an issue that srsetupwin fails to install pop/hdp with clearing SVP.
– (Fix) Fixed an issue related to SCCM 80070490 error when HDP is set.
– (Fix) Fixed an issue related to silent install auto restart issue.

The third reason to upgrade the BIOS is to get security related fixes. Yes, they find and fix security fixes in the BIOS firmware just like they do in operating systems and software. Do your security team (and yourself) a favor and deploy versions that contain these security fixes. Looking at the BIOS release history for the HP EliteBook Folio 9470m, we can see some of these security fixes listed in this version:

Version:F.60 A (20 Jan 2015)
Fixes
– Fixes an intermittent issue where enabling the LAN/WLAN switching feature in the F10 BIOS settings causes the system to stop functioning properly (hang) at POST after a warm boot.

Enhancements
– Provides improved security of UEFI code and variables. HP strongly recommends transitioning promptly to this updated BIOS version which supersedes all previous releases.

NOTE: Due to security changes, after this BIOS update is installed, previous versions cannot be reinstalled.

Pay close attention to the note at the end of the release text – it states that previous versions cannot be reinstalled. What this means is that you can no longer ‘flash’ back to an earlier BIOS version. This is important when it comes to deploying BIOS and how we detect what systems need to be updated, but more on that later.

The fourth reason that comes to mind is has to do with manipulating the BIOS settings programmatically. I have written blogs and talked on the topic of using the vendor utilities to programmatically change the BIOS settings (like BIOS to UEFI) using a Configuration Manager task sequence. Just as it is important to standardize on the BIOS versions, you should also develop standards on how each BIOS setting should be configured in order to maintain consistency and ensure devices are configured accordingly. By running on the latest BIOS version, you will ensure that these utilities will work correctly and configure the settings correctly.

I am sure I can think of many more reasons why you should start baselining and upgrading the BIOS versions for the supported systems in your environment, but hopefully I have identified the top four reasons and have convinced you that this needs to be done on a regular basis. In the next blog, Upgrading the BIOS Part 2, I will discuss the approach to flashing the BIOS along with some lessor understood caveats as it relates to BitLocker, BIOS passwords and UEFI 64-bit systems.

Originally posted on https://miketerrill.net/

BIOS and Secure Boot State Detection during a Task Sequence Part 2

In BIOS and Secure Boot State Detection Part 1, I talked about the various states a system can be in for the BIOS Mode and Secure Boot state. Having these states defined as OSD variables can be useful in determining what actions need to be performed in order to switch a system to UEFI Native with Secure Boot enabled. Depending on how you perform the vendor firmware changes, you may or may not need to define the difference between UEFI Hybrid and UEFI Native. UEFI Hybrid is when the system is running UEFI and the Compatibility Support Module (CSM) is enabled (this is how you can run Windows 7 in UEFI mode – yes, really). In order to enable Secure Boot, the CSM needs to be disabled first. Also, for Secure Boot state, you may or may not need to define all of the possible options. If the goal is to get to Secure Boot enabled, that may be good enough to just test for that. However, Secure Boot disabled may be a nice to have in the case you have systems that do not play well with Secure Boot being enabled.

I start off by creating a group called Set BIOS and Secure Boot Variables. For a Windows 10 In-place Upgrade Task Sequence, I place this group after the Install Updates step in the Post-Processing group (but more on that in another post). This way, the system is already running Windows 10, which is a Secure Boot capable operating system (unlike Windows 7, which is not capable of running Secure Boot). The first Task Sequence variable I like to define is called BIOSMode, I set this to LegacyBIOS on the condition that _SMSTSBootUEFI equals FALSE.

imageimage

We could just use the _SMSTSBootUEFI variable, however it is not as intuitive to other administrators if they need to read or edit the Task Sequence or read Status Messages and/or log files.

Next, add another Task Sequence variable called SecureBootState with the value Enabled. The condition on this is going to be based on the registry value:  HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State\UEFISecureBootEnabled = 1.

image

image

Now add another Set Task Sequence variable step with the same name, SecureBootState, but this time set the value to Disabled. The condition on this is going to be based on the registry value:  HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State\UEFISecureBootEnabled = 0.

image

image

There is also the Secure Boot state of unknown or NA, but for the time being I do not use this one in any of my Task Sequences. I also do not use the condition where SecureBootState = Disabled currently, but I figured it would be handy to have it in the future if needed. I have also created an item on uservoice so that maybe one day we will see a variable like this as part of the product: Create an OSD variable for Secure Boot – _SMSTSSecureBootState.

Feel free to download my exported Set BIOS and Secure Boot Variables Task Sequence here (created on Configuration Manager Current Branch 1702). Stay tuned on how to use these variables in a BIOS to UEFI Task Sequence…

Originally posted on https://miketerrill.net/

User Group Getting Started Guide

I just got back from the best systems management conference called the Midwest Management Summit. The reason this conference is so great (besides all of the awesome technical sessions and information) is because it is built for the community, by the community. In fact, the Microsoft Management Summit actually started out as a User Conference – I still remember the very first one I attended – The SMS & Windows 2000 User Conference.

Every year at the Midwest Management Summit, there is a session on user groups – how to find them, start them, or make one better. The first place to start is by searching for a user group in your area. The Minnesota System Center User group maintains a pretty comprehensive list of systems management/System Center user groups here. And if you know of any that should be added, just reach out to them and they will gladly add it.

Since I have been running the Arizona Systems Management User Group (AZSMUG for short) for over a decade, I often get questions from individuals on how to start a user group. I recently decided to put this in my OneNote for future use but thought that it would be great to share with everyone that is looking to start a user group. There isn’t an exact formula for what works and many of the user groups all run a little different. But the most important thing is to stay the course and keep the group going.

Fellow User Group Leader Daniel Ratliff also has a blog on his tips here.

Now for my tips and information on how to get a user group up and running:

Domain Name
Purchase and register a domain name. For AZSMUG, I use GoDaddy because it works well with Office 365 (the DNS settings for Skype for Business are important). I also use it to redirect www.azsmug.org to our Office 365 SharePoint page so that others can find the user group.

Technical Community
Register you user group with Technical Community. This will get you access to a free Office 365 E3 subscription that you can use to setup a few email accounts. It also gets you access to SharePoint in which you can use as a public website for your user group so that others can find it. You may need to let them know that you are a new user group just getting started and use one of the other user groups or user group leaders as verification. Note that the Office 365 subscription needs to be renewed/verified every year by proving that you are still an active user group. The following is what currently you get with the E3 subscription:

In addition, you can get funding (if you are lucky) from Technical Community for user group meetings. Although, I have given up on requesting funding after being denied several times.

Email Addresses
As soon as you get your domain name and Office 365 account setup and configured, create a few email accounts that you will use for official user group communication. I suggest setting up a shared mailbox for your user group – like usergroup@usergroup.org (where usergroup is the name of your user group). Also setup account for any members that will be helping to run the user group. Give those accounts access to the shared mailbox.

Chair Members or Board
If you are just getting started, you may just have a yourself or another person or two that helps run the user group. In this case, it is probably fine to not have anything official in terms of who runs the group and how the group is run. If after you start the user group you find that you have lots of interest from members wanting to help run the user group, you may want to adopt some formal bylaws in which elections are held yearly for various positions (like President, Vice President, Secretary, Treasurer). I know groups that use both models and each works well depending on the group.

Email lists
Email can be a primary method of communication to your user group members. There are several email distribution lists available today, plus you can create your own distribution list with your Office 365 Account. Otherwise, myITforum still maintains some distribution lists. Mail Chimp is another one that some user groups use (this has some integration into Eventbrite).

Sponsors & Sponsorship
Depending on how your group is set up will depend on how you get sponsorship. Some user groups get non-profit status so that they can have an operating budget and checking account. Other user groups get sponsors to come in and pay for food & beverage (and maybe guest speaker travel). Sponsors are given the option to present on their products at your user group. Just make sure that they keep it technically focused and do not turn it into a time share sales pitch (your user group members will thank you). Also, some vendors will want your user group member list of names/companies/email addresses. Depending on your sponsorship agreements, you may turn this over – just make sure your members know in advance and they are okay with this. Otherwise, have them raffle off an item at the meeting they present at. That way, user group members can opt-in to the raffle by providing their information. This keeps you and the user group out of any privacy issues.

Speakers
Try to speak at your own user group at least once a year. This will help you in your current position at work and be beneficial for your career to get some public speaking experience. Also try to encourage other user group members to present at your meetings. This will help them out as well. Plus, chances are that someone else is facing the same problem and needs to come up with a solution. Or use it to demonstrate your knowledge about a specific feature and how that helps in your day to day job.

Getting guest speakers can generate interest and get more people to attend the meetings. Many of the Microsoft MVPs will gladly present at your user group if they happen to be in town and are available. Otherwise, use sponsors or sponsorship money to pay for their travel to come to your meeting.

User Group Focus
Some user groups run a general focus (like all things Microsoft), whereas other user groups are more specific (like System Center or just even one product focus). Find out what fits for your audience. The last thing you want to do is put a bunch of time and effort into a meeting only to get a few people to show up because the topic is not of interest to the other user group members.

Meeting Invites
There are two good services that do not cost anything for the basic level of service for sending out invites and tracking registrations. Eventbrite and Meetup both work well and have professional looking invitations. The also provide other things as well (like promotion and the ability to email notifications and reminders – either natively or using external service like MailChimp).

Social Media
In addition to the meeting invitation service you provide (which can be used to promote events), use social media to promote your user group. Twitter, LinkedIn and Facebook are all great ways to spread the word about your user group and upcoming meetings.

Meeting frequency
This can be a tricky one. If you are just starting off, don’t bite off more than you can chew. In other words, start by planning for one meeting per quarter or four times per year (summers can be slow). Getting everything lined up for a user group meeting is a lot of work. I have run meetings every other month for several years and changed to a quarterly schedule a couple of years ago. This seems to draw more interest and attendance from user group members. If it is too frequent, members are more likely to have conflicts or decide to skip a meeting and catch the next one. But I do know groups that run every other month or even every month. Just keep in mind that it can be a lot of work keeping up with that cadence unless you have others helping out. If you can set a fixed date, say the third Thursday of the third month in the quarter, great – this will help people plan and know when the next meeting is going to be. If you cannot have a fixed date, then be sure to let your user group members know enough time in advance when you are in the pre-planning phases of the next meeting so that they can ‘pencil’ it into their calendar.

Meeting duration and times
This is another one that can be tricky and you will not be able to please everyone. The time might also depend on when you guest speakers can present. If they are busy working/consulting/teaching during the day, then you might have to run evening meetings (like from 5 – 7).

Meeting locations
If there is a local Microsoft office, then chances are you will be able to have your meetings there. Reach out to your local Microsoft contacts as you will need a Blue badge sponsor if you plan on having meetings outside of working hours (like after 5 PM). Also, they will be able to check the meeting room schedule and book the room for you. They can also help promote and generate interest in the user group with their customers in the area. Otherwise, a local library, training center or a member’s work location are all other alternatives. Pick a location with free parking or one that will validate parking.

Online Meetings/Recording Meetings
If you get to a point where you want to open up meetings online for others to attend or if you just want to record them, you can use Skype for Business that is part of the Office 365 E3 subscription.

If you have any other suggestions, please let me know in the comments below or send me a message on Twitter.

Originally posted on https://miketerrill.net/

BIOS and Secure Boot State Detection during a Task Sequence Part 1

With all of the security issues and malware lately, BIOS to UEFI for Windows 10 deployments is becoming a pretty hot topic (unless you have been living under a rock, UEFI is required for a lot of the advanced security functions in Windows 10). In addition, with the Windows 10 Creators Update, Microsoft has introduced a new utility called MBR2GPT that makes the move to UEFI a non-destructive process. If you have already started deploying Windows 10 UEFI devices, it can be tricky to determine what state these devices are in during a running Task Sequence. The Configuration Manager Team introduced a new class called SMS_Firmware and inventory property called UEFI that helps determine which computers are running in UEFI in Current Branch 1702. This can be used to build queries for targeting and reports, but it would be nice to handle this plus Secure Boot state (and CSM) during a running Task Sequence. We do have the Task Sequence variable called _SMSTSBootUEFI that we will use, but we need to determine the exact configuration in order to execute the correct steps.

There are three different BIOS modes that a system can be running:
Legacy BIOS – also known as BIOS emulation, this requires a MBR partitioned disk in order to boot. Most Windows 7 systems are running this configuration.
UEFI Hybrid – this mode is when a system is running in UEFI, but with the Compatibility Support Module (CSM) (also known as Legacy ROMs) enabled. Unlike Legacy BIOS, this mode requires a GPT partitioned disk in order to boot. Windows 7 can run in this configuration and before there was MBR2GPT, this was the recommended mode to deploy Windows 7 in so that it could be easily upgraded to Windows 10 at a later date without repartitioning the disk.
UEFI Native – this mode is when a system is running in UEFI without the CSM. It also requires a GPT partitioned disk in order to boot. Windows 7 cannot run on a system that is configured for UEFI Native.

Now let’s talk about Secure Boot. Secure Boot and CSM are incompatible – if the CSM is enabled, then you cannot enable Secure Boot. When Secure Boot is enabled, you cannot enable the CSM. Based on this information, we know that Secure Boot will be unsupported in Legacy BIOS and UEFI Hybrid modes (Note: When I say unsupported, I am not talking about if the device is capable of running Secure Boot. Secure Boot requires a device running UEFI 2.3.1 Errata C or later and an operating system capable of running Secure Boot). Configuration Manager currently does not have out of the box functionality for reporting on Secure Boot, but the feature has showed up in the Technical Preview 1703 release. In the meantime, see my blog called Inventory Secure Boot State and UEFI with ConfigMgr on how to extend hardware inventory in Current Branch 1702 or older in order to collect this information.

From this information, we can create a handy chart to help visualize the configuration options:

NOTE: For UEFI Hybrid, Secure Boot State is unsupported if the CSM is enabled, however, an operating system that supports Secure Boot will show that status as Off (Disabled) in System Information.

Now, with this information and MBR2GPT, we should be able to create a single Windows 10 Feature Update Task Sequence for clients Windows 7/8/8.1/10 and it should not matter if they are already running UEFI or Legacy BIOS. The actions that we need to perform do matter and this is where we can set some Task Sequence variables to help with the logic on the various steps. But first, let’s see what needs to be done based on the four configurations above. We already said that Legacy BIOS is the only configuration that uses a MBR partitioned disk. Therefore, this will be the only configuration that we need to run MBR2GPT. When we run MBR2GPT, we also need to configure the device’s firmware settings for UEFI and enable Secure Boot (the Microsoft solution does not do this for you, you are on your own to use the vendor methods to do this piece).

If you are one of the few that took last year’s recommendation and started deploying Windows 7 in UEFI mode, then those systems will be running UEFI Hybrid. We do not need to run MBR2GPT on these systems since they are already running a GPT partitioned disk. We simply need to turn off the CSM (or Legacy ROMs) and enable Secure Boot (once again, the Microsoft solution does not do this for you).

For systems that are running UEFI Native but Secure Boot is not enabled, we simply need to enable Secure Boot. Lastly, for systems that are already running UEFI Native with Secure Boot enabled, we do not need to do anything additional for these systems. Adding these actions to our chart, it makes it very clear what actions need to be done under each scenario:

In a follow blog post, I will go into more detail on how we can use this logic in a single Windows 10 In-Place Upgrade Task Sequence, what the steps look like and where each of them go.

Originally posted on https://miketerrill.net/

How to open CMTrace in WinPE like a boss

If you have ever done OSD, then chances are you have had to open up CMTrace a time or two to look at the smsts.log file. CMTrace displays one of the most annoying pop up boxes of all times and it is usually hiding behind the running task sequence dialog window: “Do you want to make this program the default viewer for log files?”

01 Do you want to

The answer is yes for the millionth time! Wouldn’t it be nice if it just did this automatically and never asked you again? If I had to guess, I bet you are shaking your head yes. For this post, I am going to show you how to modify your boot images so that it never asks you this annoying question again while running in WinPE.

Several years ago (back in 2009) I developed a solution on how to automatically open CMTrace (called Trace32 back in those days) for a debug task sequence. I finally got around to blogging the solution a few years ago and it is called ConfigMgr 2012 OSD: Automatically Open SMSTS log. This contains the important registry keys that we need to set in order to bake this into our boot images (and thus eliminating these three steps for the WinPE phases).

  1. The first thing we need to do is create a directory that we can use to mount our boot images (for example, MD d:\mount).
  2. Next we need to mount the boot image. This can be done using dism (be sure to run it from an elevated command prompt that has dism in the path – like the Deployment and Imaging Tools Environment short cut under Windows Kits). Select the boot image you would like to modify, I am using the default x86 boot image (in this example Configuration Manager is installed in D:\Program Files\):
    Dism /mount-wim /wimfile:”D:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\boot.wim” /index:1 /mountdir:D:\mount
  3. Now we need to load the DEFAULT registry hive from the WinPE image. In my other blog post, we are creating the key in the HKEY Current User, however, since this is an offline registry, we are going to set it in the HKEY User hive which is what HKCU loads defaults from:
    Reg load HKU\winpe d:\mount\Windows\System32\config\default
  4. Now that we have the offline registry loaded, we can create the entries that we need. We will create the following registry keys that causes CMTrace to launch that annoying pop up box if they don’t already exist:
    Reg add HKU\winpe\Software\Classes\.lo_ /ve /d Log.File /f
    Reg add HKU\winpe\Software\Classes\.log /ve /d Log.File /f
    Reg add HKU\winpe\Software\Classes\Log.File\shell\open\command /ve /d “\”x:\sms\bin\x64\CMTrace.exe\” \”%1\”” /f
    NOTE: I used to put CMTrace in the Windows\System32 directory, but this is no longer needed since x:\sms\bin\i386 (use this path above for 32-bit boot images) and x:\sms\bin\x64 are now in the path now and ConfigMgr places the proper architecture of CMTrace in these locations by default. Also, be careful of smart quotes if copying and pasting.
  5. Next, unload the WinPE registry:
    Reg unload HKU\winpe
  6. Now we need to unmount the WIM file and commit the changes:
    Dism /unmount-wim /mountdir:d:\mount /commit
  7. In the Configuration Manager Console, select the boot image and update the distribution points. Generate new boot media based on the modified boot image, boot up a system (or PXE boot) and test by opening up a command prompt and typing CMTrace.

If everything worked right, CMTrace will open up without asking you “Do you want to make this program the default viewer for log files?”, as it already knows the answer. Repeat for other boot images you would like to modify. Here is a link to a text file that can be downloaded and renamed to .bat.

If you think this should automatically be in Configuration Manager, head on over to User Voice and vote for Stop CMTrace from asking us if we want to use it as the default viewer for log files in WinPE.

Originally posted on https://miketerrill.net/

How to detect, suspend, and re-enable BitLocker during a Task Sequence

In this blog post, I am going to show some simple steps that you can add to your Task Sequences to be able to detect, disable, and enable BitLocker status. This can be useful (and necessary) when performing activities like flashing the BIOS, running the new MBR2GPT utility, or upgrading to a newer version of Windows. In Configuration Manager, there are a few Task Sequence steps that are for BitLocker configuration and management:

Disable BitLocker – this step will disable BitLocker encryption on the current operating system drive or one that you specify and runs in a full operating system (does not run in WinPE). It does not decrypt the drive, but it does leave the key protectors visible in clear text on the hard drive. This step only disables BitLocker for one reboot (if you would like to see this step updated, vote for my Configuration Manager Uservoice item Add Reboot Count functionality to the Disable BitLocker TS Step). This means that BitLocker will be enabled again after the restart. If you need BitLocker to be disabled for more than one restart, then you can use manage-bde with a Run Command Line step (see below). Also, if there are data drives encrypted, then they need to be disabled before disabling the operating system drive.

Note: before running MBR2GPT, BitLocker should be disabled. Also, for just a Windows 10 In-place Upgrade with BitLocker (not doing MBR2GPT), it is not required to disable BitLocker, however, there have been reports of BitLocker not being suspended long enough during the upgrade (see the link to Jonathan Conway’s blog below) .

Enable BitLocker – this step will enable BitLocker encryption on a drive. It only runs in a full operating system (in other words, it does not run in WinPE). If selected for use, the TPM must already be enabled, activated, and allow ownership prior to running this step. This step can be used to re-enable BitLocker if the drive is already encrypted with BitLocker but in a disabled state.

Pre-provision BitLocker – this step runs under WinPE (only) and is used to enable BitLocker during the WinPE phase of the Task Sequence. It also encrypts the used drive space, which makes encryption times faster. Once in the full operating system, use the Enable BitLocker step to apply the key management options. This step is generally be used in New Computer or Wipe-and-Load Task Sequences.

Manage-bde – this is a built in command line tool that allows for the enabling, disabling, updating and reporting on BitLocker. The Microsoft TechNet documentation on Manage-bde is a bit stale and has not been updated to reflect some of the new capabilities that have been added in the newer releases. The most important one is the ability to control the reboot count when the protectors have been suspended. There is a new parameter called -RebootCount or -rc that takes a value between 0 and 15, where 0 suspends the protection indefinitely. This can be useful if you have several reboots during a Task Sequence and you need to make sure that BitLocker stays suspended (optional method listed below).

Note: Jonathan Conway has a great blog on how to use Manage-bde with the Task Sequence called SCCM Windows 10 Upgrade Task Sequence: BitLocker PIN Protector Issues on Laptops.

Now, to disable BitLocker, you could place that step in the Task Sequence and allow it to ‘Continue on error’. If you like to only use ‘Continue on error’ in certain cases and definitely want to know if BitLocker was enabled (so that you can conditionally re-enable it later on in the Task Sequence), then this can easily be done with a Set Task Sequence Variable step. Create a new Group called Disable BitLocker and on the Options tab add the following:
Task Sequence Variable _SMSTSinWinPE equals “False”

Place a Set Task Sequence Variable step in the Disable BitLocker Group and call it Set OSDBitLockerStatus for the name. Enter OSDBitLockerStatus for the Task Sequence Variable and enter Protected for the Value.
On the Options tab, add the following:
WMI Namespace: root\cimv2\Security\MicrosoftVolumeEncryption
WMI Query: select * from win32_encryptablevolume where driveletter = ‘c:’ and protectionstatus = ‘1’

This will check the BitLocker status on the C: drive (which is hopefully the OS drive). Keep in mind that if there are other data volumes that are BitLocker encrypted, these will need to be detected and decrypted first. Those systems can be filtered out in the collection targeting or it can be built into the Task Sequence using the same logic as above.

Next, add a Disable BitLocker step (with the option set Current operating system drive).
On the Options tab, add the following:
Task Sequence Variable OSDBitLockerStatus equals “Protected”

Optionally (recommended if needing multiple reboots), instead of using the built in Disable BitLocker step, add a Run Command Line step:
Name: Disable BitLocker
Command line: manage-bde -protectors -disable C: -RC 0
On the Options tab, add the following:
Task Sequence Variable OSDBitLockerStatus equals “Protected”

 

To re-enable BitLocker later on in the Task Sequence, create another group called Re-enable BitLocker.
On the Options tab, add the following:
Task Sequence Variable _SMSTSinWinPE equals “False”
Task Sequence Variable OSDBitLockerStatus equals “Protected”

Next, add an Enable BitLocker step under the Re-enable BitLocker Group (with the option set Current operating system drive). Since the drive is already encrypted, this step will just re-enable the key protectors if they are currently disabled (like if you used managed-bde and specified a reboot count).

Remember that the built in Disable BitLocker step will only disable BitLocker for one reboot (similar to what happens when you suspend BitLocker from the Control Panel applet), but if you used manage-bde with -RC 0, you will need to re-enable BitLocker.

Keep this Task Sequence template handy so that you can easily copy and paste into other Task Sequences in the future. I will be referring to this template in upcoming blog posts.

Originally posted on https://miketerrill.net/