Reduce OSD TIMES
1. Set High Performance Power Plan
- This has been proven in multiple environments to save 20% – 50% on certain steps. You will see noticeable savings on the download & apply OS. By default while the system in in WinPE, configmgr will a balanced power setting. so making sure we use all resources we can see a major win from this piece. I also set this to prevent systems from going to sleep during the TS.
2. Set SMSHostAgent Startup Options
- The SMS Host Agent (CcmExec) service is set to a delayed start by default. Every time you restart the system during the OSD Process and you see the “initializing System Center Configuration client” you are just costing time. In my environment this message would usually last 2 – 5 minutes each restart. Once I implemented this we noticed the configmgr client would only take < 15 seconds to initialize, that is a savings of 800% - 2000% for this specific task sequence action.
- Frank Rojas whom is one Microsoft CSS Lead OSD Engineer has let me know that this has POTENTIAL for failures in a TS. So please know that if you use this step please understand THIS IS NOT SUPPORTED! I have seen this work successfully in environments for a few months at a time, and then it just stops working. One scenario for this is the ConfigMgr client starts up automatically before network connections are available. This means the ConfigMgr client evaluates to assume it is now on an internet instead of intranet. The Configmr client next look for the CMG for MP and DP purposes, and then steps start to fail in the TS. So if you run into a problem like this go ahead and disable the associated steps and start the TS again.
3. Set SMSTSRebootDelay
- This will change the default behavior from 30 seconds to 0 seconds and occur immediately
4. Set manual Restart times (for displayed messages)
- When you add a restart computer step into the TS by default the time is set to 60 seconds. Simply by un-checking the “Notify the User before restarting” box you now force the restart immediately. Should you need to actually display a message you can just reduce the amount of time this box is displayed.
- I have seen several customer environments that had 8 or more restart steps in their TS. Whenever you have a restart in a TS you can assume usually 2 – 5 minutes are added to the total TS time. I would recommend investigating the status messages for exit codes indicating a restart is necessary before you start modifying a customers task sequence. Many of my peers usually have only 2 or 3 restarts in their TS as they have streamlined their deployments.
- MVP Mick Pletcher has a great post on how to handle restarts in your TS. Basically add a condition statement to check if the system needs a restart you can read about it and implement it here
- This will of course help you out on the install software update steps in your TS. The more patches that are in your WIM, the less to process later. I tend to bake office and patches into the WIM. I’m not a fan of having really thick images loaded with several 3rd party apps that can be installed during ts.
- This should be another no-brainier idea, but you will be surprised. I’ve seen customer environments where a machine from the east cost USA would pull down images from the middle east….like there is literally an entire ocean btwn the DP and the workstation..
- I’ve seen in the SMSTS.LOG before that a system I was imaging was trying to reach out to windows update. Some places you are confined to image from certain vlans only and you can block this communication at the firewall. In my TS I modify the Registry to prevent this action from occurring. Unfortunately this was something changed in my TS a long time ago so I did not grab a screenshot. I can edit this post when I get around to making the next revision of changes in the updated WIM. (Thanks Todd)
On my test experiment the OSD process would take around 100 – 110 minutes…that’s nearly two hours, and wayyyy too long.
Screenshot after changes OSD Time. We see below that this has been reduced to 36 minutes. I am positive I can actually get this to 32 minutes or less, but for now I will leave good enough alone. This test shows that we have cut the OSD time to less than 1/3 of the time. I’ve been in other environments where they had the image process take 24+ hours, but that is mainly boundary related issues.
Power settings: I kind of have this littered everywhere in my TS before major time consuming steps like apply OS, install patches, install apps, etc.
: cmd /c sc config “CcmExec” start= auto
Prevent OOBE from Downloading Drivers:
: Mount the Offline HKLM File
: reg load HKLMOffline C:WindowsSystem32ConfigSoftware
: Set DODownloadMode
: REG ADD HKLMOfflineSOFTWAREPoliciesMicrosoftWindowsDeliveryOptimization /v DODownloadMode /t REG_DWORD /d 100
: Set DoNotConnectToWindowsUpdate
: REG ADD HKLMOfflineSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate /v DoNotConnectToWindowsUpdateInternetLocations /t REG_DWORD /d 1
: Unmount the Offline HKLM File
: reg unload HKLMOffline
: cmd /c sc config “CcmExec” start= delayed-auto
: Set Balanced Power Scheme
: PowerCfg.exe /s 381b4222-f694-41f0-9685-ff5bb260df2e
This customer has unnecessary restarts in their OSD design, and were not very streamlined. Things in this version of the TS can be easily baked into the WIM on the next image refresh with the build/capture TS i provided for the customer. There are things that are slow during this TS like install Visual J+, or .Net Framework 3.5 that would reduce the OSD time if baked into image.
Other things to reduce OSD Time:
I still have unnecessary install software update/restart steps in the TS as a sort of catch all. These systems come out fully patched, but are left enable in case I do not get time to capture and test a new wim one month.
I have seen in the SMSTS.LOG where systems would try to reach out to windows updates for patches instead of staying within my environment. This can be changed via registry modification…I have this in place in my environment but did not capture screenshots when I saw it in the log files.