7 Replies Latest reply on Feb 22, 2016 10:17 AM by bwallace

    calling WinSAT.exe w/provisioning fails


      So I am currently installing some device drivers outside of HII because LDMS 9SP2 still can't handle .exe driver installs...I've pulled the WinSAT.exe out of unattend.xml and I am choosing to run it after my drivers are installed.  I want to run it in the SYSTEM CONFIG phase of provisioning because that is where the last of my drivers are added.


      I need to run the following:


      "c:\windows\system32\winsat.exe" formal


      when I try this with provisioning I get:


      "error:[80001000H]file "c:windows\ssytem32\winsat.exe" not found."


      so I created a batch file that calls this and my provisioning template copies the batch file to the client and then runs it.  I get " 'winsat.exe' is not recognized as an interna or external command, operable program or batch file."


      If I manually launch the batch file then WinSAT.EXE runs fine.



      I'm told that provisioning uses the system account which has full local admin rights.  If this is true then why can't it run WinSAT.exe?

        • 1. Re: calling WinSAT.exe w/provisioning fails

          Are you attempting to run on a Win 7 x64 machine?


          I'm trying to do the same, and came across this article (regarding AutoIT) which I "Think" explains the issue I'm, and possibly you (if using x64), are having.




          Explanation is only part of it mind, now to find a way of "fixing" it....


          let me know how you get on.

          • 2. Re: calling WinSAT.exe w/provisioning fails

            Tested and working!!!


            If you use:


            c:\windows\Sysnative\winsat.exe as your target path and pass Formal as a parameter.


            Not yet tested, but next logical step would be %%windir%%\sysnative\winsat.exe.


            As per the AutoIT link that reason is that if a 32-bit application is run on an 64-bit version of windows then system32 is re-directed to WoW64, winsat.exe is not in %windir%\system32\ so the task fails.


            Solution - use the path alias of %windir%\sysnative forces the path to %windir%\system32 where winsat.exe actually is.

            • 3. Re: calling WinSAT.exe w/provisioning fails

              thanks for the reply...I gave up waiting for one and moved winsat.exe back into unattend.xml.  If what you say actually works I'll pull it back out.



              So yes to x64 here; maybe that is the problem...


              ..but you have lost me with the "\windows\sysnative" piece.  Is this some kind of environment variable like %windir%?  I don't have a \sysnative folder but I do have C:\Windows\System32\ where Winsat.exe can be found.  As you can see in the OP the command line that I am using in provisioning points exactly to this place.

              • 4. Re: calling WinSAT.exe w/provisioning fails

                If I understand it rightly, if a 32-bit application attempts to access %windir%\system32 it is instead redirected to %windir%\SysWoW64, so when were are specifying %windir%\system32\winsat.exe in LANDesk we are re-directed to %windir%\SysWoW64, due to it being a 32-bit app and file not found is returned.


                If instead of system32 we use sysnative the redirect behaviour is overidden, and we can browse system32 from a 32-bit app.


                I too could not find a sysnative folder while attempting to browse for it, whether this is because explorer.exe and anything else I could think of to access it  is running as a 64-bit application I'm unsure.


                All seems to work in my head, but I may have missed some important part of how it actually works.


                Here's one resource from Microsoft...




                And there's loads of other posts on the Internet around File System redirection, a number coming from people wondering why they can't use a 32 system to remotely execute system files on 64-bit systems.



                Hope that helps clear things up, I got all excited that I'd got it working and fingers were probably moving faster than my brain.

                • 5. Re: calling WinSAT.exe w/provisioning fails

                  Slightly diverting from the original question.


                  So why are you running winsat.exe?  Is it so the users dont have too?  I thought it only updated your windows experience score. 


                  Does it do something for the install process after a sysprep that I am not aware of?


                  I don't want to be skipping a step I should be running.

                  • 6. Re: calling WinSAT.exe w/provisioning fails



                    I'm electing to run WINSAT.EXE for two reasons


                    1) For lack of any other benchmark tester, this one provides a relative score that I would like to use to compare the different types of hardware in our deployment.  My hope is that this number turns out to be meaningful and that we are able to observe how the various components of that score correlate to performance differences between our machines...


                    2) I've read that windows uses this score to tweak certain performance aspects of the OS in a behind-the-scenes way; I've thought that it would be a good idea to get the score established early in the process and let windows do its thing....



                    I can't say that either of these reasons DEMAND use of WinSAT...but it was something I wanted to try and I wanted to see if I could get it to work, if for no other reason, than to be an exercise in learning more about Win7 and LDMS.  When I was working on this I was waiting for landesk to cure some provisioning problems that were leaving me stuck without an end-to-end capability.  I was able to mess around with this one piece while being stuck in the middle of the process....



                    ...as I said before, I've moved on from trying to get LDMS to execute WINSAT; it currently is called from my unattend.xml file and runs after all of the drivers are installed.

                    • 7. Re: calling WinSAT.exe w/provisioning fails

                      Thanks, I ran into this exact problem, but with pnputil rather than wsat. using the sysnative path fixed it. I appreciated your explanation as well.