Batch file doesnt run after deploying from SCCM

Question

I have a batch file which uses gpresult /v and saves the output in a text file and copy that text file to a shared folder. This batch when i run on my local machine works perfectly fine but once i deploy it through SCCM it says can not open file with error code 4. I dont know what is wrong in the file.

the code is Like this:

@echo off

gpresult /v >%computername%.txt

xcopy %computername%.txt \some path

Answer 1

Error 4 is "The system cannot open the file.", as if the path is invalid or the open() fails for some other reason.

• Do you know what directory the program is running in (CWD)?
  That's where the results of gpresult are going (if the output redirection succeeds).
• gpresult is not going to produce meaningful user-level data for the SYSTEM user.
  Perhaps you should use gpresult /v scope computer.
• Why are you using xcopy when you're only copying one file? xcopy really only has added value (over copy) if you are copying directories.
  xcopy's behavior changes depending on how you specify the target. If the target ends with the directory separator (backslash), xcopy treats it like it's a directory. If it doesn't and the target doesn't exist, xcopy asks you what to do, which causes automated processes to pause indefinitely waiting for user input.

SCCM Programs Run as 'NT Authority\SYSTEM'

When SCCM (2007) runs a program, the program doesn't run as a regular user. It runs as the highest privilege user (sort of), SYSTEM.

This account is not a regular account, and many settings and environment variables that exist and are predictable for a regular user are different or do not exist for SYSTEM. One particularly frustrating "feature" of the SYSTEM account's profile is that it is nestled away under %WINDIR%\System32, and so it is subject to filesystem redirection whenever you refer to anything relative to the profile.

Try this: use psexec -s (sysinternals) to get shell access as the SYSTEM account and run the command in that environment to see how it behaves. This is as close as we can get to an environment like the one SCCM programs run under.

When SCCM runs the command, the CWD will probably be somewhere under %WINDIR%\SysWOW64\CCM\ and may be invoked with the 32-bit version of CMD.EXE.

Answer 2

I have a question in regards to something similar to this. So I have an uninstall bat that runs. Due to the vendors uninstall it causes a force close of the windows explorer UI. So in haste to solve that issue I added a call to open explorer.exe. There is a problem with this as someone pointed out to me. Actually as soon as he said I knew exactly what he was saying and where he was going with his statement. Calling explorer.exe would be fine except that the bat is running under the system context not the user so when explorer is restarted it will start under the guise of the system desktop profile not the user's. I know there is way to still run under the guise of system but to restart explorer under the currently logged in user's profile.