Following up on my own question from earlier, I did add powercfg.exe.mui in to the system32 en-US directory, and I started to get text output from the command line.
Sent from my iPhone > On Apr 7, 2015, at 11:41 PM, Aaron Czechowski > <[email protected]> wrote: > > 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]> 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]> 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]> 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]> 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]] > On Behalf Of Steve Whitcher > Sent: Tuesday, April 7, 2015 9:05 AM > To: [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]> 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]] > On Behalf Of Keith Garner (Hotmail) > Sent: April 3, 2015 5:29 PM > To: [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]] > On Behalf Of Miller, Todd > Sent: Friday, April 3, 2015 11:07 AM > To: [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. > > > >
