Speeding up OSD

Setup

For the measurements in this post I’m on SCCM 1702 and using a ThinkPad T470s as the client. In order to measure the individual steps in the task sequence I’m using a report made by Thomas Larsen.

The task sequence I’m using does a bare metal install with a Windows 10 1607 Reference Image totaling 9,8 GB.

Power scheme

The first thing to speed up is changing the powers scheme, by default both the Windows PE and Full OS portion are run in balanced power scheme, so I wanna change it to High Performance.

Built in power schemes in Windows

Listing the built in power schemes in Windows

It can be done with the following command “X:\Windows\System32\PowerCfg.exe /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

 

After the task sequence has reboot and started the full operating system, the command needs to be run again. This time using the tool stored in the loaded OS “PowerCfg.exe /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”

At the end of the task sequence add another “run command line” resetting the power scheme to the balanced scheme using this command “PowerCfg.exe /s 381b4222-f694-41f0-9685-ff5bb260df2e”

In my sample task sequence, running with the balanced power scheme the average execution time was 30:44. When changed the power scheme to high performance it dropped to an average of 22:58 minutes, an improvement just short of 8 minutes.

 

Apply wim from DP

By default the “Apply Operating System” step has two phases. first it downloads the wim-file to disk and then afterwards start unpacking it. On my test system this process takes around 9 minutes. This can be changed unpack the wim-file directly from the distribution point. In order to do this first a share has to be made for the wim-file and then the task sequence should be told to apply the wim-file directly from this share.

The share is created in the properties for each Windows Image as seen:

Next up, in the “Apply Operating System” step:

In my testing this cut the time spent in half from 9 minutes down to 4 minutes and 40 seconds.

Ccmexec startup

The final optimization is a bit of a cheat, the sccm client (ccmexec) gets installed as a Windows service with the startup type Automatic (Delayed). This adds a delayed of two minutes each time there is a reboot in the task sequence while it’s running in the full operating system. This can be changed in the first step after “Setup Windows and Configuration Manager” with a “run command line” running this command “cmd /c sc config CcmExec start= auto

The reason the service is set to delayed startup, is to prevent it from starting a hardware/software inventory during boot/user logon in daily operations after the installation process has finished so as before a final “run command line” step is added resetting the startup with this command “cmd /c sc config “CcmExec” start= delayed-auto

Advertisements

15 comments

  1. Thanks! Need to test this. Have you tested how much power scheme adjust speeds up OSD?

    1. Yes, I’ve update the power scheme section with my timing result. I got a improvement of almost 8 minutes.

  2. Thanks Henrik. I will test this out and get my stopwatch out :).

    1. Take a look at the report I linked to at the top of the post, you can import it to your report server. It will show you the total time taken by a task sequence as well as time spent on the individual steps.

      1. Thanks – that will make it a lot easier.

  3. Steve · · Reply

    When I put the ccmexec service modification step in, I got an error 0x00000424 – service does not exist. I had to drop the quotes around the service name.

    1. richmawdsley31 · · Reply

      Yep I had exactly the same.

    2. Thank, I’ve removed the quotes it seemed the typography mangled them in copy/paste. They are not needed is long a there is no space in the service name

  4. Thanks, regarding the ccmexec startup mode, it seems the task sequence reboots immediately after the “Setup Windows and Configuration Manager” step (and before the service =auto command), therefore at least one reboot still occurs with a delayed start. Is there a way to prevent that step from rebooting so we can change the start mode and then reboot?

  5. You are giving two pieces of bad advise:
    1) Selecting to apply from DP is not as secure. When applying from DP, no hash checking is done. If the content is corrupted or compromised, you would never know. This option is designed for specific scenarios with devices with very small drives that cannot both download the image locally and then apply it
    2) Setting the ConfigMgr client service from Delayed to Auto can cause tons of problems during the Task Sequence. Basically on faster PCs the client will start so fast that sometimes network connectivity is not fully available. End result is that the ConfigMgr client will evaluate to Internet instead of Intranet. This will result in the client looking for Internet based MPs and DPs. When none are available or cannot be reached because the client is actually Intranet, task sequence steps will start failing, especially the Install Application and Install Software Updates tasks.

    1. Thanks for the feedback, does any technet sites listed the recommended scenarios for #1 and the behavior in #2?

      1. For #1, this is a bit older documentation from ConfigMgr 2007, but it still applies to ConfigMgr 2012/Current Branch as the underlying technology has not changed:

        https://technet.microsoft.com/en-us/library/bb680566.aspx

        See the “Important” section.

        For #2, there is nothing external and it was mainly internal bugs. However you can confirm by inspecting the behavior in ConfigMgr 2007 – ConfigMgr 2012 RTM (Delayed), then seeing how the behavior changed in ConfigMgr 2012 SP1 – ConfigMgr 2012 R2 (Auto), and then seeing how it was reverted back in ConfigMgr 2012 SP2/R2 SP1 and newer including ConfigMgr Current Branch (back to Delayed). Reverting the behavior was due directly to the numerous cases that were opened due to the problems caused by setting the ConfigMgr client service to Auto instead of Delayed. It was reverted back to Delayed to prevent these problems

        I am actually probably going to write a blog article regarding this issue due to the problems it caused and due to numerous blogs all of sudden suggesting to change this setting. It may save some time for some customers, but for other customers it is going to result in a huge time and money waster when their deployments start failing. End result is they will have to remediate those PCs and spend precious time trying to figure out why they are failing.

      2. Also see the following article the specifically calls out what the option is truly intended for

        https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-steps#BKMK_ApplyOperatingSystemImage

        Access content directly from the distribution point
        Configure the task sequence to access the operating system image directly from the distribution point. For example, use this option when you deploy operating systems to embedded devices that have limited storage capacity. When selecting this option, also configure the package share settings on the Data Access tab of the package properties.

  6. For #1, this is a bit older documentation from ConfigMgr 2007, but it still applies to ConfigMgr 2012/Current Branch as the underlying technology has not changed:

    https://technet.microsoft.com/en-us/library/bb680566.aspx

    See the “Important” section.

    For #2, there is nothing external and it was mainly internal bugs. However you can confirm by inspecting the behavior in ConfigMgr 2007 – ConfigMgr 2012 RTM (Delayed), then seeing how the behavior changed in ConfigMgr 2012 SP1 – ConfigMgr 2012 R2 (Auto), and then seeing how it was reverted back in ConfigMgr 2012 SP2/R2 SP1 and newer including ConfigMgr Current Branch (back to Delayed). Reverting the behavior was due directly to the numerous cases that were opened due to the problems caused by setting the ConfigMgr client service to Auto instead of Delayed. It was reverted back to Delayed to prevent these problems

    I am actually probably going to write a blog article regarding this issue due to the problems it caused and due to numerous blogs all of sudden suggesting to change this setting. It may save some time for some customers, but for other customers it is going to result in a huge time and money waster when their deployments start failing. End result is they will have to remediate those PCs and spend precious time trying to figure out why they are failing.

    1. Sorry for the double reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: