Reducing Windows Deployment time using Power Management

The following post was contributed by Benjamin Rampe a Senior PFE working for Microsoft.

While studying up on Windows 10, I came across a technique that has been shown to reduce the time it takes to apply an OS WIM to disk by 20 – 50%*.  That’s a fairly significant savings in time and the implementation of this technique is relatively easy and does not require you to change how you deploy Windows.  Believe it or not, the savings come from adjusting the OS power management settings during a deployment.  While there are multiple ways to implement these power management settings, below I’ve outlined what I consider the most non-intrusive to existing deployment methods. 


1. Copy PowerCfg.exe binaries to MDT Files package’s Scripts subfolder

  • By default, WinPE runs with the power management scheme set to “Balanced”
  • ConfigMgr 2012 R2’s boot images use WinPE v5.0 which is based on the Windows 8.1 OS
  • PowerCfg.exe is necessary for changing the power management scheme
  • PowerCfg.exe is not included in WinPE
  • Create subfolders in the MDT Files package’s Scripts subfolder for each architecture, as shown below:


  • From a system running Windows 8.1 (or Server 2012 R2) copy %WINDIR%\System32\PowerCfg.exe to the AMD64 folder in the MDT Files package Scripts folder
  • From a system running Windows 8.1 (or Server 2012 R2) copy %WINDIR%\SysWOW64\PowerCfg.exe to the x86 folder in the MDT Files package Scripts folder
  • Update distribution points for the MDT Files package (Note: SysWOW64 contains 32 bit files hence we use this folder.)

2. Insert a step early in the task sequence to set the power management scheme to “High performance”

  • The GUID for the High performance scheme is “8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”
  • The GUIDs for the default power management schemes in Windows are consistent between Windows versions (Vista and later)
  • The first instance of this action is for setting the power scheme during a REFRESH scenario (which starts in the full/old Windows OS).  In this scenario, we want to execute the PowerCfg.exe native binary included in the OS (not the version in the MDT Files package).  The Command line for this instance should be:  “PowerCfg.exe /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”.  To ensure this action only runs during a REFRESH scenario, the condition on this step should be “_SMSTSInWinPE not equals TRUE”
  • The second instance of this action is for setting the power scheme during a NEW COMPUTER scenario (which starts in WinPE).  In this scenario, we want to execute the PowerCfg.exe binary included in the MDT Files package.  The Command line for this instance should be:  “"%DeployRoot%\Scripts\%PROCESSOR_ARCHITECTURE%\PowerCfg.exe" /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”.  To ensure this action only runs during a NEW COMPUTER scenario, the condition on this step should be “_SMSTSInWinPE equals TRUE”
  • The example below leverages the MDT-specific variable %DeployRoot% which gets instantiated only after a “Use Toolkit Package”, so be sure to insert the step to change the power scheme after the first “Use Toolkit Package” as shown below:


3. After every “Restart Computer” step within the Preinstall, Install, and Post Installphases, insert another action to reset the power management scheme to “High performance” using the PowerCfg.exe from the MDT Files package.  These 3 phases all run under WinPE which does not persist the power scheme between reboots.  For example:


4. After the first “Restart Computer” step within the State Restorephase, insert another action to reset the power management scheme to “High performance” using PowerCfg.exe from the native (full) Windows OS as shown below.  (NOTE:  Perhaps a better alternative to implementing this step would be to set the power scheme to High performance prior to image capture which would provide the added benefit of using the High performance scheme during PnP enumeration, driver installation, etc.):


5. Finally, set the power management scheme to the scheme you wish for the system to use after the deployment.  In the example below, the GUID for the Balanced power scheme is set.  GUIDs for the built-in power schemes in Windows can be found here.  To set the GUID for any custom scheme, use “PowerCfg.exe –L” to obtain the scheme’s GUID and paste into the Command line for the action: 


Early results are very promising using this technique, we would love to hear if this improved the speed of your deployment via the comments.

*From Windows 10 for PCs and 2 in 1s Manufacturing End-to-End Overview –

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Comments (47)
  1. Anonymous says:

    OK. Thanks for the quick response.

  2. Ben Hunter says:

    Hi Preenesh,
    The System32 and SysWOW64 folders are correct. Here is a nice blog showing why –

  3. Jeff Stokes says:

    I'd have to say it depends on the hyper-visor perhaps. I know the 'balanced' power plan for Windows 7 in VMware for instance is a big no-no.

  4. Ty Glander says:

    You could just as easily inject powercfg.exe into the boot Wim using the Extra files setting in the Deployment Console.

  5. Anonymous says:

    Great post. Have you tested whether this has any effect on virtual machines? This approach is useful for the hypervisor host to get more performance out of it, but what about making a difference inside a VM?

  6. Aaron.Parker on a side note a common mistake I see with Hyper-V hosts being used to make images often have their power settings not set for maximum performance.

  7. Benjamin Rampe says:

    Great question. You are not likely to see much savings when deploying to VMs. Many virtualization platforms turn off power management settings altogether.

  8. Lenin Dominic says:

    Great article. Am I right in assuming that this will not work for windows 7 family deployment?

  9. deploymentMonkey says:

    Thx for sharing , nice article.. Now I know what to do this saturday nite 😉

  10. Feroze Khan says:

    Can we use the same for Windows 7 deployment as well running on WinPE 4.0 and SCCM 2007?

  11. Nicke11 says:

    Is this working on Windows 7 deployment aswell?

  12. Mark says:

    Is likely to affect the build time of a Windows 7 machine?

  13. Matthew Uebelacker says:

    Can this same principle be applied to SCCM 2007 with MDT 2010 Update 1? Unfortunately we are still working on getting our 2012 environment stood up.

  14. Pierre Rondeau says:

    Great post. I assume this is limited to Windows 10 and won't improve the performance of deploying Windows 7 and 8.1 images?

  15. Benjamin Rampe says:

    This technique should work with all versions of Windows 7 and newer (including Windows Server versions).

  16. Benjamin Rampe says:

    This should work with versions of WinPE v3.0 and later. Keep in mind that you'll want to use the version of PowerCfg.exe that is specific to the version of Windows that the version of WinPE is based. See here for information about WinPE versions:

  17. Saeid says:

    This is what I use during deployment to put comuter ( laptops in our case ) into balanced and never go to sleep

    @echo off
    powercfg -setactive 381b4222-f694-41f0-9685-ff5bb260df2e
    powercfg -SETACVALUEINDEX 381b4222-f694-41f0-9685-ff5bb260df2e 238c9fa8-0aad-41ed-83f4-97be242c8f20 29f6c1db-86da-48c5-9fdb-f2b67b1f44da 000
    powercfg -SETACVALUEINDEX 381b4222-f694-41f0-9685-ff5bb260df2e 4f971e89-eebd-4455-a8de-9e59040e7347 5ca83367-6e45-459f-a27b-476b1d01c936 000

  18. Dean says:

    Thanks for the article. I have conducted a test where I performed 6 deployments, using SCCM 2012 and powercfg.exe configured and 6 without it configured. There was zero noticeable difference between the deployments. The deployments were Run from DP and
    deployed the standard Windows 8.1 Ent wim. I put it to you that any gains would be so slight that you would need to do several thousand deployments to make back the time you have spend incorporating this and the benefits are almost completely eroded if you
    were to deploy 1 or 2 extra systems at the same time. Your network and DP disk access will always be the bottleneck. There *may* be some merit to using this when incorporated with USB standalone or OEM deployments but who has the time to validate that?

  19. Benjamin Rampe says:

    Ty, you're absolutely correct. However, I also like the idea of keeping the implementation solely within the task sequence so that it can conditionally be disabled (use the default "Balanced" scheme) for situations where High performance might not be ideal.

  20. Preenesh says:

    Have a doubt on the below.. Should it not be the other way round.. System32 to x86 and SysWOW64 to AMD64

    From a system running Windows 8.1 (or Server 2012 R2) copy %WINDIR%System32PowerCfg.exe to the AMD64 folder in the MDT Files package Scripts folder
    From a system running Windows 8.1 (or Server 2012 R2) copy %WINDIR%SysWOW64PowerCfg.exe to the x86 folder in the MDT Files package Scripts folder

  21. Benjamin Rampe says:

    Dean: Thanks for your feedback. Were these tests with done with physical or virtual machines? I don't expect much gain, if any, on virtual systems. Further, the gains will vary depending on various hardware and deployment factors.

  22. Anonymous says:

    (This comment has been deleted per user request)

  23. Michael Cusick says:


    This is great, I look forward to trying this in the very near future.

  24. As another person mentioned, the architecture folder copy should be reversed. As written you will be greeted with a subsystem missing error due to the wrong architecture instructions. 😉 BTW – I tested this in Hyper-V and saw no improvement (was actually
    2 min longer build time) so hoping physical hardware testing will prove better.

  25. Anonymous says:

    (This comment has been deleted per user request)

  26. garrett says:

    Just ran a test for myself as well, and there was little to no improvement in the deployment times. It was a physical machine, Win 7 x86, Dell Optiplex 755 SFF. I'll keep testing, but I was slightly disappointed in the results. If anyone wants to know
    anything more, or has any other ideas, please let me know.

  27. nick says:

    I think it's best to keep in mind that hardware is going to be a very large factor here, as well as network speed. If you're connected via a 10/100 vs a gig switch you'll see a considerable difference in deployment times obviously. Whether it's 5 minutes
    or 50 minutes in the end, any little tweak us engineers can give to our deployment teams in a positive gain is a plus. Well done Ben!

  28. Aaron Powell says:

    I have been giving this a go in my free time this week. We have a set of eight HP workstations on an IP KVM that we use to test our build. We use MDT Lite Touch (MDT 2013/ADK 8.1) to deploy Windows 7 and testing both 32-bit and 64-bit I am consistently
    seeing 10-15% decrease in overall build time.

    I plan to continue testing, of course, but so far so good! Even if we only reduce build time by a five minutes in some cases it's such a simple no risk change.

    Thanks Ben!

  29. Mihkel Soomere says:

    I implemented it and are seeing 10-15 minute reduction in time in our SCCM2012R2 OSD TS. Times have dropped from ~80-85 minutes to ~65-70 minutes (depending on hardware).
    I also tried to use custom unattend.xml to apply power profile as early as possible at first boot but PreferedPlan option just seems to not work (Google seems to agree). If this worked, we could shave off a few additional minutes (first boot, driver configuration,
    SCCM agent installation).

  30. Stephen Owen says:

    Do you have any metrics or before/after listings of performance?

  31. Liverpool Lee says:

    Hello there, I can confirm that the WinPE v5.0 will work with Windows 7 deployment. I have built many Windows 7 of all flavours using WinPE v5.0 🙂

  32. Stuart Watret says:

    Win7 via MDT with this technique – 1st test approx 10 min savings.

  33. Hampus says:

    Great post!

    MDT Build and Capture Went from 9 hour to 6 hours, so its like a 33% faster capture process.
    SCCM deploy went from 55 minutes to 35 minutes so it's like a 35% increase.

    It will be interesting to test when there are more patches and when we deploy machines with the full Adobe suite. They normaly take 2-3 hours to finish so it should give even more.

  34. Jay Connor says:

    Saves us around 10-15mins. I don't think theres any performance increase once in Windows.

  35. Sean Shuler says:

    Tried Implementing this in My SCCM2012R2 with MDT2013 environment and when I run the TaskSequence I receive a Task Sequence Failed Error message (0x80070057). I looked in the SMSTSLog and I do not see any errors when this task is being performed. When
    I run the command manually within WinPE it works with no issues but the Automated running of it through the Task Sequence Fails. Anyone else have this issue?

  36. Steph R. says:

    Implemented with SCCM 2012 R2 for Windows 8.1 tablet PC deployment. Installation goes approximately 20% faster.

  37. Anonymous says:

    Reduce your apply OS task sequence by up to 50%

  38. Benjamin Rampe says:

    Perhaps you copy/pasted directly from the blog post and have extra quotes in the command line. In general, quotes are for the file path only, and not for or after any command parameters (e.g. "%DeployRoot%Scripts%PROCESSOR_ARCHITECTURE%PowerCfg.exe"
    /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c).

  39. Anonymous says:

    Reduce your apply OS task sequence by up to 50%

  40. TowheeR says:

    Good grief. No wonder deploying the "Microsoft Way" is so damn slow.

  41. Chris says:

    Is this possible without SCCM, and just using MDT?

  42. Owen2 says:

    I'll be looking to see if the following VBScript works for Windows 7 / SCCM 2007 tomorrow:
    sPlanName="High Performance"
    set objWMI = GetObject("winmgmts:\.rootcimv2power")

    set colPlans = objWMI.ExecQuery("Select * from win32_PowerPlan where ElementName='" & strPlanName & "'")

    for each objPlan in ColPlans

    set colPlans2 = objWMI.ExecQuery("Select * from win32_PowerPlan")

    for each objPlan2 in colPlans2
    Wscript.Echo objPlan2.ElementName & " power plan status is: " & objPlan2.IsActive

    It seems to have an effect when running it straight in the cmd shell produced by hitting F8 on our dev boot image. Have a few thousand PCs to depoy sortly with a 40GB WIM, so anything that reduces the time is great!

  43. Marcus Holz says:

    Hello @all,

    i changed a bit in lag of also missing "Use Toolkit Package" in my Task Sequence.
    I found several entries "Copy Scripts" i changed path "%DeployRoot%Scripts%PROCESSOR_ARCHITECTURE%PowerCfg.exe" to "%Scriptroot%%PROCESSOR_ARCHITECTURE%PowerCfg.exe" and added power state Change after that entries. That works and CPU running now permanently
    in Turbo mode.
    Cut Installation time from 27 minutes on an i7 CPU, 8GB with SSD to nearlly 20 minutes.

    Used with MDT 2013 Update 1 with MDT for Windows 7 x64 rollout.

    Big "thank you" Ben!

    Best regards Marcus

  44. Mike Hufnagle says:

    I'm on 2013 Update 2 with no local WSUS server and here's my real world take on this:

    I didn't want to use powercfg.exe as there should be a powershell way to do everything. Sure enough, after digging around I found a way. For each deployment share, I added a script called SetHighPower.ps1 in the Scripts folder with the following contents:

    (gwmi -NS rootcimv2power -Class win32_PowerPlan -Filter "ElementName ='High Performance'").Activate()

    I then placed it in every task sequence at the beginning of Preinstall, Install, Post Install, and State Restore. Then I added it under State Restore after each round of Windows Updates (pre and post app installs). Each time it runs, it takes about 10 seconds
    to apply.

    Original time to deploy my captured reference image was 53 minutes with no apps to install and minimal side processes (creating user accounts, copyOEM, etc). Updated deployment time after the power settings I mentioned is cut down to 27 minutes.

  45. carsten says:

    I also implemented the high performance power scheme to our OS-Deployment.
    When it comes to installing Intel network drivers, this part will fail. Switching back to the balanced power scheme before installing the intel NIC drivers has the effect, that it works again.
    So keep an eye on non working driver installations, if you are using the high performance power scheme in WinPE.

  46. Nate says:

    I have something weird happening with a custom WIM I created from a Win 10-1511 VM. I post it here because I only noticed it once I started trying to modify the the power settings mentioned in this article. I saw the boost in deployment speed once I added
    this step to the Preinstall steps of my task sequence in MDT 2013 update 2 but for some reason during the state restore phase of the deployment (which is not affected by the step I modified since that was set during the WinPE stage) the power settings are
    also getting set to high performance. I attempted to make the last step in my deployment a step to manually change the power settings back to balanced but that fails to stick as well and the power scheme always changes back to high performance. This wouldn't
    be an issue except that this will be used for laptops and high performance disables sleep etc. I checked the VM I created the wim from and the powercfg /l command shows it is using balanced so it didn't come from the base image I used. I disabled all the steps
    associated with this post to rule out the WinPE setting wasn't somehow responsible for changing the value post deployment and that had no effect on the High Performance power setting being set by the end of deployment.

    Does anyone know if any of the deployment scripts have a setting to set power schemes? I'm stumped and about ready to recreate the base image again. I've not set any power settings via GPO but I also deployed the machine without joining the domain with the
    same result of high performance being set by the end of deployment.

  47. Power B app for windows 10 mobile.
    Power B windows 10 app for disktops.

Comments are closed.

Skip to main content