I thought that was a clever title, but it seems more confusing the longer I look at it… anyway, this is the follow up post to take BGinfo from MDT, and add it’s capabilities to the ConfigMgr In-Place Upgrade Task Sequence Process. If you’ve been working with in-place upgrade task sequences, you’ll know they are a different beast than regular OSD. You can’t just call an application and expect it to show up on the screen.. like in OSD, you can say Command Line Step: notepad.exe… and guess what, a notepad.exe window opens during the TS.. freaking amazing!
In Place Upgrades also have new challenges we didn’t really have before with OSD. OSD (bare metal) typically meant it was a clean image, we didn’t have end users sitting in front of it while installing the OS, didn’t have user profiles already full of “super precious data”, we really didn’t need to worry about the end user experience. Now here comes Windows 10, Love it or love it, it’s here to stay, Windows as a Service, it means once OSD is done, that was the easy part, now we have to “touch” that computer every 6 months with a large upgrade. Now we do have users to worry about, we have their precious little datas, and we have to deal with users who don’t read emails, and don’t read popups, and don’t read “ARE YOU SURE” dialog boxes, who just click “Sure” when something pops up, then freak out when it reboots 15 minutes later after they “consented” to an update. And because they were working on large sales strategy document they only save on their desktop (Where else would you save business critical documents), and because the moon was full and the person sneezed in the cube adjacent, their document is now gone, or corrupted, or missing 4 days of edits! Anyway, my point, we have the privilege of attempting to provide a decent user experience and making the process the most user friendly while still applying a huge upgrade that is ripping out the guts of the OS and dropping in the newer OS, with features they didn’t really request, and unknown stability with their current business apps. But I digress…
Where was I going with that… oh yeah, ways to let the user know that hey “A BIG UPGRADE IS HAPPENING… SAVE YOUR STUFF”. I’ve done this in the past with changing the Lock Screen, creating a method to prevent a user from logging on, but what if the user is logged in, they started the TS, but still just don’t get it… how about we temporarily change the background and put up a message that displays for that logged on user until the moment that beautiful first reboot happens? I say, why not… lets do it. My idea, steal MDT’s Bginfo “Set Status” Step, and add it to the In Place upgrade TS. I copied over the “Use MDT Tool Kit” Step, and “Set Status 2” Step, but when it ran that step in the TS… ERROR city. Figured it was too easy. So this is what I had to do.
Assuming you followed the last blog, you’re most of the way there. (I’ve provided all of the files in the zip download, so you can steal those or create your own)
Your folder structure will look like this basically:
BGI file(s) – Create new, or steal from MDT – Included in my download
Image file (.bmp) – Create new, or steal from MDT – Included in my download
Open your BGI File with BGInfo64 and add your fields and text (or modify the one I’ve provided) Note, this will be different than the one we used for OSD, as this time, it is running in the OS, and not WinPE.
Set your Background, note, do not use the full path, just the name of the file, as all of the required files are located in the same directory.
Ok, the BGInfo part is done, feel free to press Preview and confirm it looks how you want, when you’re satisfied, save everything, and create your ConfigMgr package and distribute
Now that you have your package ready, its time to add it to the TS
Run Command Line Step
Basically, we’re stealing the logic from the ztiSetBackground.wsf file in MDT Scripts, and manually creating the command line:
"bginfo64.exe WinUpgradeGaryTown.BGI /nolicprompt /silent /timer:0"
But you’d quick learn, that doesn’t work… you need to use ServiceUI.exe to make it visible, which once you figure out that syntax, you get this:
Now add a condition that it only runs if it was user imitated. no point in changing the background is no one is there to see it. 🙂
Also have seen this step failed if a user is NOT logged on. So recommend you set to "Continue on Error" if you plan to have it run without checking to see if a user is logged on, and run it without a user logged on.
TS Variable = _SMSTSUserStarted = True
Now, sit back and watch your TS give the user something they can’t avoid… unless their desktop is completely covered with files / icons…
Short post to go over something I found while researching Bitlocker Full Disk Encryption on Hyper-V virtual machines.
I was testing Enabling Bitlocker during our Task Sequence, and I didn’t have any physical machines to test on, no problem right? With Hyper-V, you can now enable virtual TPM on Gen2 VMs, and have all the yummy goodness of UEFI, Secureboot, Bitlocker, Credential Guard all on your VM! So I started testing, everything worked! But when I checked the Bitlocker Status (manage-bde –status), it showed I was only encrypting Used Space. While this would be fine for a Virtual Machine, I was confused because I told it to use Full Disk, NOT used space. I ran many tests, trying several different things, but in the end, it never came out as I expected, with Full Disk. Even post OSD, if I decrypted, ensured policy was set for Full Disk, it would only encrypt Used Space. Finally, I gained access to a physical test machine, ran the exact same Task Sequence, and there it was, Full Disk Encryption. – Testing done on Hosts: Win 10 1607, 1709 & Server 2016. VM’s running 1703 and 1709. Security settings were set to Enable Secure Boot & Enable TPM, tested Dynamic expanding & fixed disks. (Not Pass-through)
Hyper-V Virtual Machine = Used Space Encryption only with Bitlocker *Unless you can use a pass-though disk.
This is by Microsoft Design, Bitlocker is “Hyper-V Aware” and will only run in Used Space only mode, even if your policy is set for Full Disk
Remember to eject your ISO you booted from before the Bitlocker steps, or it will error
If you need to test your Full Disk Encryption OSD settings, do it on a physical machine. - Below I have two screen captures side by side. Left side = Physical Machine & right side = VM on that Physical Machine. Both machines ran same TS telling it to use FDE, but only the Physical machine actually used FDE.
How do you change your TS from doing Used Space to Doing Full Disk?
Disable the Pre-Provision Bitlocker Steps
Add Registry key to set Full Disk Encryption before “Enable Bitlocker” Step.
Set “Enable-Bitlocker” step to Continue on Error
This will set several policies settings, like save the key to AD, and which way you want to deploy bitlocker (TPM only, etc)
Here are the details for the steps in my TS, as you can see, I also set it to use XTS AES 256 (except for flash media, which I use older type so it's more backwards compatible with other Windows computers)
Just another group of tasks to add to your arsenal. We run a Check Readiness step before our upgrades, with a minimum of 20GB Free. We have many clients that do not meet this minimum requirement and fail, and then have to remediate. While we have long term plans to automate much of this, and prevent the Task sequence from ever running on machines that don’t reach these pre-reqs, for now, a Band-Aid.
Step Breakdown “Storage Cleanup” Group
Run only if FreeSpace < 20GB
select *from win32_logicaldisk where freespace<20000000000anddeviceid="c:"
This same query is placed on several steps. If the step that is cleaning up is successful at getting FreeSpace above 20GB, then lets continue on. Otherwise, the last step that will run if still under 20GB is the restart, to help flush things from the previous steps.
This requires that the delprof2.exe file from Helge Klein's site. (It is in the download, as I have permission to redistribute it)
You can change the day to any number you want and run this steps as many times as you want. My idea was that I would start at a high number, then slowly lower it, 360, 180, 90, 60, 45, 30, 20,15,10,5, and have the wmi query on it, so as soon as it dumped enough old profiles, to get 20GB Free, it could continue on leaving newer profiles. The script also looks up the top console user, and excludes that from the deletions, so even if the primary user hasn't logged in for awhile (on leave), it won't delete that profile (as long as it's still the top console user, and not some tech's account). This is a powerful step, be careful with it, as you could accidentally remove a profile you didn't want to. If you have some profiles you don't ever want to delete, you can exclude them by adding an /ed:user in the script (look to Helge's documentation for more info).
This is my "Clip Show" blog post, but hopefully you still find it useful.
I've been building out a Task Sequence that is just a collection of Task Sequence sections, or handy steps. I'll use this TS to pull sections from when I create new Task Sequences, and add / modify as I test in "Real" deployment Task Sequences. DOWNLOAD HERE*Note, this is not an actual Deployment TS, it's meant to be imported and then have parts copied into your own TS. All content, including some not used directly in this TS is included.
Power Settings, CCMEXEC Change & Revert - This section will grab your current power settings, place in variable, set system to high performance, then restore them at the end of your TS. It also has steps for changing the CCMEXEC service to auto start, instead of delayed, and back.
Upgrade Lockscreen - This section will change your lockscreen, designed for the Win10 In place upgrades.
User Lockouts - This section will use local group policy to block any users, either via AD Group, or users from local machine
AutoLogon - This adds account and keys for auto logon (for testing in lab)
Enable Mouse Support - This will enable the mouse cursor in the Windows 10 TS after WinPE steps are complete.
Windows 10 Tweaks - Several sub-sections of Customization gathered over the past years, many demo'd @ MMS2017
Upgrade LockScreen & User Lockout : https://garytown.com/change-lock-screen-image-during-upgrade-ts
I’ve made a few modifications since the post about this, moving the cleanup to a scheduled tasks, that will run during the upgrade deleting the Lock Screen images / Keys & cleaning up the Locked Out users, so users can log back in after. It will also clean up the scheduled tasks. I’ve left in the steps for you to add after the upgrade to do clean up as well, leaving you many options on how to implement this idea. Each step has detailed notes in the descriptions.
Most of this section is straight from MMS: https://garytown.com/windows-10-customizations-mms2017-demos
Windows 10 Features, enable or disable some “features” in win10
OEM Info, allows you to set the information that is displayed in “System”
Explorer Tweaks – Covers things that modify things displayed on Desktop or Explorer
Group Branding includes changing the Lock Screen, Wall Papers, User Icons, Start Menu
Default Profile are tweaks that apply only at the user level, so these are added to the default profile.
Remove Default Apps, either a script to remove everything (That is specified in the script, not actually everything) at once, or a line by line option to be granular.
Update 2017.10.26 - After a twitter convo with @brookspeppin, I added two additional steps for the legal notice. I had ones to delete them, but Brooks said he had used them as the upgrade message, skipping everything else. This was something I had considered, but after talking it over with the team, decided against it "No one reads that", but after seeing Brooks' screen capture, I tend to agree that it's worth having in your pocket, so I've added it to the Task Sequence Export that's available to download. Here is a screen capture and keys needed.
REG ADD"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System"/vlegalnoticecaption/TREG_SZ/D"Upgrade in Progress"/F
REG ADD"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System"/vlegalnoticetext/TREG_SZ/D"Do NOT log on, computer is currently running Windows in place upgrade."/F
Update: 2017.09.26 - Was able to take advantage of local group policy bypassing the need to talk with your Group Policy Team. You can do it all in the TS.. Go to bottom to see how..
- Updated info again on 2017.10.13 here (includes updated download): https://garytown.com/configmgr-task-sequence-collection
Original Post: 2017.09.15:
What: Changing the Lock Screen Image to warn end user that the system is performing upgrade, also preventing users from logging on during TS.
Why: So users don’t call upset when they logon to a computer then get rebooted when the TS reaches that point. (For those groups whose users don’t read all of the communications about their machines updating)
How: Downloading Pre-created Images, setting registry keys, and to lock out users, that requires a little help from group policy (1 time setup)
Back story: ProgressUI does not display on computers unless a user is logged on. If the process starts at it’s deadline, and no one is logged on, it will start running the task sequence with no visible signs until it reboots into setup, and the user sees the Windows 10 Setup screen. Lets say the TS has started, and it’s in the middle of downloading the content, which can take awhile on a slow link. User starts to do work (watch cat videos), and then they see a message pop up finally saying "computer will reboot in 60 seconds, you’re welcome", they won’t be so happy, worse yet, they look away for a couple minutes, or are grabbing their coffee to come back and find their computer rebooting to setup. How can we draw more attention to the fact the computer is doing something.. how about make a bold lock screen image warning the user of the upgrade, or even prevent them from logging on.
Here is a picture, the PC was logged into during the TS, the User has no idea it’s in the setup.exe phase of the TS, going to reboot them in a few minutes. This is what we’re trying to avoid.
Lock Screen is pretty easy, I have a couple steps in the beginning of the TS that downloads the files I need to a local folder, then deletes them at the end.
I have this same process repeated several times, before different large steps. In my Example, I update the Security Software, which takes 20 minutes, so I have a custom lock screen image saying it’s updating Security Software.
I then repeat the process after the Security software is installed, and change the Image to say “Upgrading Windows OS”, which will be there until it reboots into setup. At the end, I delete the registry keys allowing the original settings to take over and original lock screen image to return. (If you’re using the registry keys to apply a custom image, just set it back to what it was before, you could easily capture that key into a variable, then set it back at the end, or manually add it if everyone is the same, or have group policy fix it later)
Please modify steps to fit your environment, file names / location are only for example.
Make Temp Folder for OSD Stuff
cmd.exe /c if Not Exist "%programdata%\OSDReqs\" (md %programdata%\OSDReqs)
Copy Background Images (From your package with custom backgrounds)
Wait 5 seconds – Allows time for the Lockscreen to refresh before continuing. – Optional
powershell.exe "Start-Sleep -seconds 5"
As for the locking out of users so they can’t log on, here is how I did that in my lab.
I created a group policy called “Deny Logon Locally” - TechNet
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Set Deny logon Locally to "DenyLogonLocally" (Which is the group we’re going to create in the TS)
During the TS, I create a local group called "DenyLogonLocally" and populate it with all of the users who have logged onto the local computer (Thanks @keithga1) for the powershell code.
Create Local Group DenyLogonLocally
net localgroup DenyLogonLocally /add
Set continue on error (it will error if you already have the group on your machine) – Recommend NOT deleting when done, but leaving for all future upgrades. I had issues when I deleted it and recreated it, the policy didn’t take on the recreated group even with the same name.
I had considered having an AD Group of all Domain Users (that were not admin accounts), but then you have one more group to keep manage in AD, so I decided against that. – that’s my greyed out step. - Note, added section at the end to show I had did set this up.
Add Accounts to DenyLogonLocally – This will grab all of the accounts that have logged onto the machine, and populate them into the local group (You can specify accounts you don’t want included)
Code: (Copy and paste it all, it is just one long line of code, thanks Keith) - Change the -notmatch area with your tech accounts
Here shows the group after the script has run, both accounts garytown & cmadmin have logged on to this machine, but only garytown has been added.
Remove Deny Logon Locally Group Membership – placed near the end in your clean up section, and in the roll back section, so if the upgrade fails, it will remove the users from that group, allowing them to log on again
Note, do NOT kill the winlogon.exe after the setup.exe phase, bad things happen.. like it stops your TS (No errors thrown).
In the image above, you can see the "Stop Process -Name Winlogon" Step, disable / delete that.
You honestly don't need it after the setup.exe anyway, rest of the TS will be visible to your users. After you delete the keys and clean up the images, everything will go back to how it was before once the system reboots at the end of the TS.
Hopefully this is helpful for you, not saying it’s the best or only, I’ve seen a lot of people blogging about similar things during an OSD TS, but I haven’t found much for in-place upgrade TS, so I’ve posted this.
NOTE: Sometimes the Lock Screen is buggy not showing the Lock Screen image, I’ve seen this on countless tests, I believe it is a known bug, so hopefully this gets resolved in the future. In my last test, I changed the Background after the setup stage, but it just stayed a solid color blue, didn’t actually load the background. This is why it’s great if you can prevent logon until the TS is complete.
I’ve also been considering removing the default “Upgrade Operating System” step with a run command line step and remove the /quiet switch. If we don’t want users logged on, then having the UI display will assist with getting them to no be logged on, right? Well, I still have to test this idea, if it pans out, I’ll share.
Updated 9/18 to show adding a domain group to control lock out.
In Active Directory, I created a group "DenyLogonLocallyTemp" and added all of the user accounts that I want to deny access. This is where nested groups would be best. Just make sure you don't have any of the tech / admin accounts in any of those groups.
Above shows the Machine after the steps "Add Domain Deny Group to Local" & "Add Accounts to DenyLogonLocally" have both run. The Domain group was added by the first step, and the individual user by the second. This is for demo purposes, you can pick one or the other, or both, depending on your scenarios.
Step: net localgroup DenyLogonLocally / add DOMAIN\DenyLogonLocallyTemp
Update 2017.09.26 - Update to use Local Group Policy:
using secedit.exe, we can import an inf file for this policy. The issue I had run into, secedit uses the SID of the user group, not the display name, and if you make a local account, the SID will be different on each machine, so I need a way to dynamically update the inf file with the correct SID. So I came up with the idea of having a script that would create the local group, grab the SID, build the inf file from scratch, and use the SID of the newly created group. Then the script runs secedit with the contents of the inf file. (Thanks to Keith again for the assist on creating the Code).
Replace Create Local Group DenyLogonLocally with a new PowerShell Script Step: