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.
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.
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.
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.
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.
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.
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.