0

I have a "Run PowerShell Script" Step in an OSD Task Sequence.

This script copies some files to a location and then runs an executable.

If I use ROBOCOPY to copy the files, i get an exit code 1 (files copied ok) and the executable fired, does what it needs to and quits happily.

If I use XCOPY (external call) or Copy-Item (PS Cmdlet) - the files still copy and land in the correct place, exit with code 0, but the executable doesn't fire up and doesn't do what it is meant to.

Any ideas?

Example code (Not working:)

if (!(Test-Path "C:\Installs\sx1install")){New-Item -ItemType Directory -Path "C:\Installs\sx1install" -Force}
Copy-Item . C:\Installs\sx1install -Recurse -Force
.\setup.exe /s /f1"c:\installs\sx1install\setup.iss"

Working:

robocopy .\ C:\Installs\sx1install /E /R:0 /W:0
.\setup.exe /s /f1"c:\installs\sx1install\setup.iss"

In both cases, C:\Installs\sx1install folder creates, gets fully populated with all required files and folders (including subfolders etc) - but the setup.exe doesn't work on the first example.

What is it about robocopy that makes this work/not work?

The non-working script works perfectly once in windows by doing a set-location to the location of the script package and then executing.

We need to try and find a way to get this to execute and return 0 as a return code 1 bombs out the task sequence. We need to stop the TS if the executable returns 1 as this is a critical part of our builds, so just setting success codes to 1 or continue or error are not a choice.

SCCM 2012 R2 CU3 // MDT 2012 // Deploying 8.1 Pro via MDT OSD TS

  • For running the PowerShell script, what execution policy are you setting? – Joe S Dec 27 '15 at 22:13
  • Hi Joe, In The TS step, execution policy is set to bypass, but we have an earlier step to set all execution policies to unrestricted (they're locked down again later by a GPO) – Fazer87 Dec 28 '15 at 9:22
1

If things are working with Robocopy, why are you worried about Xcopy, why not just use the one that works?

Also, why are you manually copying files over rather than just creating a Package or Application, specifying the original location of those files as the source, and then letting the Task Sequence handle copying the files over to be ready for the install? If you're worried about specifying the full (non-relative) path to your setup.iss installation automation file, then just specifying "-s" on your setup.exe's command line it should tell it to look for a "setup.iss" file in the same folder without needing to specify the path or filename at all (as log as they are both called "setup.[exe|iss]". which would make it:

.\setup.exe -s

Otherwise what do your smsts.log, AppEnforce.log, execmgr.log files say at the time of the failure?

  • Robocopy returns "1" as a success exit code - SCCM reads this as a fail and bombs the task sequence, so I want to find something that won't kill the deployment. The files are part of a package, but after the install completes, there are some custom configs, imagery etc which need overwriting to make things work properly - its a bodge of a third party application I've inherited, and I need this to work in the immediate term until I have the spare time to re-write the whole application from scratch (scheduled for mid next year) – Fazer87 Dec 21 '15 at 14:49
  • @Fazer87 if the issue is with robocopy is just the exit code you can change what exit codes will be treated as a success. – Tim Brigham Dec 21 '15 at 16:20
  • @Fazer87 but as I said, is there a reason that you're doing the copy yourself rather than just letting SCCM deal with moving the files around as part of the Package or Application source? – GAThrawn Dec 21 '15 at 17:46
  • Yeah, using a reference of /f1".\setup.iss" or /f1"setup.iss" doesn't work. It throws up a file not found error. – Fazer87 Dec 22 '15 at 9:58
  • @Fazer87 Try not specifying the file. If your .ISS file has the same filename as the setup file (ignoring the extension) and is saved in the same folder, then you shouldn't need to specify the file or path at all, you just put the "-s" switch on the command line with no file or path (as in my answer above) and it should default to the same folder as the installer. – GAThrawn Dec 22 '15 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.