Some comments: * We have DCRs to look at getting this added to both MDT and SCCM, for both WinPE and the full task sequence. No promises, we still need to do testing. * Powercfg is now included by default in WinPE v10. If we add support it will likely be with this version going forward. * Pulling powercfg.exe from the full OS into WinPE may work, but would not be technically supported (if you get wonky behavior, support would ask you to try repro without it). If you do go this route, my one suggestion is to make sure you’re using like versions. * Performance improvements depend on the specific hardware. * Worst case this may cause overheating and spontaneous shut down if it goes thermal. So be cautious of enabling across the board on every system.
Aaron From: [email protected] [mailto:[email protected]] On Behalf Of Steve Whitcher Sent: Tuesday, April 7, 2015 12:20 PM To: [email protected] Subject: Re: [MDT-OSD] Speeding up OSD process Joe - I just booted one up to winpe and ran powercfg from a command prompt. As you said, it didn't output anything. However, when I ran it again with the /q parameter, it output information on the power scheme and all of it's settings, so I think it's working as it should. On Tue, Apr 7, 2015 at 1:51 PM, Joe Sestrich <[email protected]<mailto:[email protected]>> wrote: I added powercfg.exe to winpe and tried to run it from the command prompt, it looked like it ran but there was no screen output. Are there any other dlls needed? Sent from my iPhone On Apr 7, 2015, at 2:28 PM, Steve Whitcher <[email protected]<mailto:[email protected]>> wrote: Also, it may be that we didn't see any benefit because the device collection we use for osd already has the power management settings applied in the collection properties, setting the scheme to high performance. I'm not sure whether that would take effect early enough though to give the same benefit as these task sequence changes. . . On Tue, Apr 7, 2015 at 12:56 PM, Steve Whitcher <[email protected]<mailto:[email protected]>> wrote: Just for the record, my test of this was on a Lenovo all in one computer, model M93z / 10AF0003US, with an i5-4570s cpu. The wim file deployed is 7.68GB. Our Task sequence is (relatively) simple, an MDT integrated sequence which prepares the drive, installs our Win7 Enterprise reference image, Symantec Endpoint Protection, and Java, then applies updates. At the time I ran these tests this morning, there were 35 updates applied during the task sequence. The total time for the task sequence from start to finish was approximately 1 hour and 54 minutes in each test. Just in case there was something I missed, here are the changes that I made to the TS: I added both of the "Set power scheme" steps to the task sequence in the Initialization phase, just after "Use Toolkit Package", and added the "Set Power Scheme in WinPE" step once in the "Refresh Only" phase and once in the "Install" phase, also right after the "Use Toolkit Package" steps. Lastly, I added the "Set Power Scheme - Full OS" step again as the 3rd step in my State restore phase. I wonder if there might be a power management driver needed in winpe for the power scheme change to really make a difference? On Tue, Apr 7, 2015 at 12:03 PM, Michael Niehaus <[email protected]<mailto:[email protected]>> wrote: No change would be the expected result with a VM – power settings don’t matter there. I would expect the changes to be most noticeable with more recent processors that are more aggressive with power management. The improvements would be entirely due to the CPU speed increase from the “high performance” power profile. That benefits any CPU-intensive process, including WIM decompression and a few other operations that happen during first boot of the OS. Thanks, -Michael From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Steve Whitcher Sent: Tuesday, April 7, 2015 9:05 AM To: [email protected]<mailto:[email protected]> Subject: Re: [MDT-OSD] Speeding up OSD process I had added it to a test task sequence last week, just to confirm it didn't blow anything up. Then I added it to my main task sequence, and timed an OSD without the changes, and then with the changes. Unfortunately, there was virtually no difference. On Tue, Apr 7, 2015 at 10:17 AM, Bain.John <[email protected]<mailto:[email protected]>> wrote: 20%-50% seems like quite speed jump … I’d be interested to see some benchmarking. Is it the decompressing of the wim that receives the speed buff ? John From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Keith Garner (Hotmail) Sent: April 3, 2015 5:29 PM To: [email protected]<mailto:[email protected]> Subject: RE: [MDT-OSD] Speeding up OSD process This should bump up the CPU performance for SpeedStep processors, and since WIM decompress/compress uses the CPU, that’s where the performance gain happens. However, it shouldn’t speed up disks, memory, network, or the CPU within virtual machines. -k From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Friday, April 3, 2015 11:07 AM To: [email protected]<mailto:[email protected]> Subject: [MDT-OSD] Speeding up OSD process There is an intriguing post on The Deployment Guys about setting the powercfg to High Performance during OSD that claims to improve writing the WIM to disk performance by 20%-50%. I can’t wait to try it, and I thought others might be interested too. If you implement it, please report back on your time savings and I will do the same. http://blogs.technet.com/b/deploymentguys/archive/2015/03/27/reducing-windows-deployment-time-using-power-management.aspx I got notified of this post on account of following Ben Hunter on the twitter. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________
