Sowith that said, back to the topic: PreCaching is a still must in my opinion, to smooth out the experience, making everything run faster and taking the opportunity to run Compatibility Scan as well to increase the chances of success.
This step records the date and time of when the PreCaching Task Sequence was started. The date and time is later picked up by a PowerShell script and written into registry to be inventoried.
NOTE: This should make it fairly easy to modify the entire task sequence to use with your process. Changing the value here, will change the value everywhere throughout the task sequence.
NOTE: This should make it fairly easy to modify the entire task sequence to use with your own process. Changing the value here, will change the value everywhere throughout the task sequence.
This is also the first step, where you will notice the use of the variables SMSTSCompanyName and SMSTSTargetOSBuild, and how they dynamically creates the registry structure.
This group will only run, if the current Management Point is your local Management Point. This translates into, if the device is being within the local area network, which is required in order to complete the subsequent steps.
The steps will also create a sub folder with the name of the computer failing the Readiness Check and another sub folder indicating which step that failed. In this case ReadinessFailed.
This group runs if the previous action also ran, which translates to every single step in the previous group, making sure that everything is precached. If the packageID already exists in the CM cache, the content is kept in the cache and not re-downloaded.
Setting the SMSTSPreCached variable to True. Again, this is because the actual precaching was done successfully and thus we change the value from False to True for later use.
This group will run if the actual compatibility scan is coming out OK. That translates into a hex-value, which again translates into a decimal value of
3247440400. More on upgrade error codes here: -us/windows/deployment/upgrade/upgrade-error-codes
Setting the SMSTSCompatScan variable to True. This is because the actual compatibility scan was done successfully and thus we change the value from False to True for later use.
This script also uses the variables SMSTSCompanyName and SMSTSTargetOSBuild that we configured in the beginning, so everything is done dynamically. The script needs no modifications.
This step records the date and time of when the PreCaching Task Sequence is done running. The date and time is later picked up by a PowerShell script and written into registry to be inventoried.
Awesome work! Question regarding the first PreCache Packages step above the Lenovo Drivers and BIOS Group. Is that a placeholder? After importing the TS and making modifications, ,when I go to save it wants me to enter a package into that step but not sure if anything should be put there.
Did anyone came across this issue, where CompatScan SafeGuard blocks the installation because local Administrator or Guest account is renamed?
-us/windows/release-information/status-windows-10-20h2#1514msgdesc
It is, but the issue you mention has been fixed since the release of 20H2, so you should redownload the iso from VLSC or Visual studio or service your media yourself with the latest patches. Find more details here: -us/windows/release-information/status-windows-10-20h2#1513msgdesc
A Very Well Documented and nicely written Article! I had one question though, how do you deal with language packs? Do you change the language to english prior to the upgrade and restore the language pack after the upgrade?
I found the following two entries under event viewer, I will shorten the .NET Error which indicates it cannot find a file, but I am not sure what file it wants. I am using a package that contains only the SendSchedule.exe & Microsoft.Diagnostics.Tracing.EventSource.dll
Please remove my previous submission regarding the Send Schedule error. I figured out the issue and it was caused by not having the SendScheduleMessages.xml file in my package. Thanks again for providing your pre-cache and upgrade TS.
Thanks for this guide it is great.
One question, how did you configure the criteria for the collections to reference the registry items?
Happy for you to show me for just one collection and I will figure the rest out from there.
Hey Alan, you will need to extend hardware inventory to pick up those registry entries to use with the collections. Google search for Extend hardware inventory configmgr will give you a lot of useful results ?
I believe this is contrary to what you recommend. If I set the precache task sequences to download all content locally before running the task sequence will it download / cache ALL driver packages for ALL hardware models specified in the task sequence before running . I cater for 25 different models of HP, Dell and Lenovo machines and only want to locally cache the required WIM files for each specific model.
Would these kind of upgrade operations ever be rerun on a schedule in production? These ts provide very good logging and registry entries, but seeing as an OS upgrade, do they not still need manual monitoring and redeployment?
3a8082e126