WARNING... WORK IN PROGRESS... This has been in my drafts for a couple months, I'm pretty busy so I don't know when I'll get to polish it, so for now, just publishing it with intent to go back and update it. Since I wrote this, there has been several changes already, due to advances in CM, finding bugs, etc. Anyway, because this is really never going to be 100% done, just going to click publish now, so you can start playing with it...
PS.. Mike Terrill is working on a very detailed blog post that will hopefully answer many of your questions as well, but he is waiting for making his more polished, he takes more pride in his blog posts than I do. 🙂
Download the Task Sequences and Content ---> HERE <--- I will try to keep that updated as I update my Lab's TS
Ok, so about a couple weeks ago, I posted the Pre-Cache Compat Scan Task Sequence, in Part 1, now it’s time to go over the IPU. It’s taken a couple weeks as I keep updating, refining, and finally came to the realization, I could keep tweaking this forever and never get around to posting. So, I figured, I should just post this, even if it’s not 100% complete. Just this should be pretty helpful to many.
Recommendations. Use Reg2Mof - While I write much of the data to WMI, throughout the TS, I update registry keys with useful information (WaaS_Stage as example), which I’m not writing to WMI until the end of the TS. At work, we do not use any of the WMI options like I do in my lab, we only write this information to the Registry, then use Reg2Mof to pull these keys in. After we make changes to the Registry during the TS, we trigger a Hardware Inventory, that way reports are updated fairly quickly. Also several useful values are written using the PreFlight Script (by @Keithga1) which are not written to WMI, so you’d miss all that great data… long story short, if you want to add all this useful data into your CM’s Database for Metrics / Reporting, use Reg2Mof. (Example of Registry keys being updated then hardware inventory being triggered)
So here is the TS (work in progress). I’ve flattened most of it into 1 TS, instead of having several Sub-TS’s mostly for simplicity of blogging and exporting.
There is just so many steps to go into, so I’m not going to go into all of them. I’ll give brief overviews of sections, and more detail on what I’d consider important. If you download and Import the TS into your lab, I’ve tried to document most of the steps themselves in the comments sections.
TS Prep: Sets variables used later on, then a folder for Running the majority of the TS, but only if it’s not already on SMSTS_Build (1803 in this example) – we did create a way to bypass this if we wanted the upgrade to run again on a machine already on the current build using a collection variable (SMSTS_Build_Bypass).
If the OS is already on the upgraded version, it skips to the end and sets the Registry to Success for the reports, then updates inventory.
Next we run the PreFlight, ideally we wanted to run this outside of the Task Sequence, as these are not true task sequences failures. These are things that we want to check to prevent the TS from running, as we have a good idea it will prevent the TS from running successfully. Hopefully Keith blogs the PreFlight Script, as I can’t do it justice. It is in the export that I’ve uploaded and you can take or leave what you want. We run the PreFlight in two different modes, if someone is logged on, it created self-closing popup dialog boxes for the user to interact with, so they can plug in their device, or connect to vpn. If no one is logged on, it just records the information to the registry and continues without creating a popup box
If PreFlight Fails, it drops out of it’s Group, skips the Main TS Group, and sets the Return Code to be used in the “PHail if not 1803” step.
If the PreFlight Steps fails in a “good” way, where it writes information to the registry, it will grab that and use for the return code. If PreFlight fails in a bad way, and doesn’t write any useful info to the registry, it will set ReturnErrorCode to "143".
After PreFlight, we move into the Main TS, where we set some additional variables, change power settings, update the lockscreen image and legal text and download the drivers again, but not really download, they should already be there from the CompatScan / PreCache TS. However, we need to run the steps again so that it creates the DRIVER01 variable used for the TS to know where the drivers are in the Cache, and which OS Upgrade Step to use (Drivers or no drivers). It should run these steps very quickly, as it will see that the content is already there.
In my lab example, I also set the user’s desktop background to something custom during the upgrade using BGInfo, it’s probably a bit much, but I added it in to this because, well, just because. I’ve also added the Deny Logon Section, but disabled it.
I also have a few “failsafe” steps to help remove the machine from Provisioning mode if a rollback should occur. I have a step that creates a Scheduled task, that runs when someone logs in, that will create a run-once key to remove a computer from provisioning mode. This way, if a machine rolls back, and is in provisioning mode, when a user logs in, it will trigger the scheduled task to create the one once key, so the next time they log on, it will actually remove it from provisioning mode. Why not just remove it on the next user logon? Well, what if someone ignores the warning and logs on during the upgrade? I really don’t want it to get pulled out of provisioning mode then, but at that point, it would create the run once key for when someone logs in after the upgrade.
Alright, so all of that is leading up to the actual upgrade OS steps.
First adding Variables, one to grab the time before we start the upgrade, and one to add additional parameters for the upgrade.
We then finish off with grabbing the time again and setting a variable to the finished time. Then setting a return code to use at the end of the TS, based on the Setup Engine.
After the Setup is done, we move on to the Post-Processing section, Here we call another TS to apply all of the customizations again.
Then onto some cleanup, make sure all of the lock screens, and other scheduled tasks we used are gone, since at this point, if the ts made it this far, we wouldn’t need those safe guards.
Then we grab more info, and and write it to the registry and WMI (SetOSDInfo PS Step).
It will then go through, check if the current OS is the desired OS, if not, Copy Logs to Server, and fail the Task Sequence using the ReturnErrorCode that we’ve set along the way.
Otherwise it continues to the end running the 4 last steps that are redundant at this point, but were there as explained earlier if the machine was already upgraded.
So, I didn’t go into a ton of Detail, and hope the TS itself will provide that detail. If you’ve imported the TS, and some things still don’t make sense, let me know and I’ll go into more detail here. But for the sake of time, and to get this posted… this is what you get.
You then inventory that, and make pretty reports.
Originally Posted on GARYTOWN.COM