Trouble running powershell as advertisement

[Chris Zeigler]

Hey folks, I've created a simple package that has a program that simply runs "powershell.exe" No batch file or anything, I've reduced it down to the most simple thing since I've been having issues trying to call anything else. I've advertised it to two Windows 7 machines, one 32 bit and one 64 bit. Powershell.exe starts just fine on the 64-bit machine, but on the 32-bit machine it fails with a -65536 error. Obviously there's no code trying to be run so it can't be an error there. This seems to happen on all of our 32-bit machines. I even changed the program to go directly to the path of powershell on a 32-bit machine, but the same error occurs. Any ideas?

[Trevor Sullivan]

Hello Chris,

 

If you run powershell.exe with no parameters, it should start an interactive session which will never exit. This is probably not what you want ultimately.

 

For testing purposes, open a cmd prompt and test your command in that before deploying through SCCM. For example, on a problematic 32-bit machine, open cmd, run powershell, and if it exits immediately, run "echo %ERRORLEVEL%" in the cmd prompt, and see what you get in return. It's possible that this will spit out the same error code you're seeing.

 

Either way though, as I said above, it *should* start an interactive session, so I'd avoid deploying a straight "powershell.exe" command via SCCM.

 

Hope this helps.

 

Cheers,

Trevor Sullivan

http://trevorsullivan.net

http://twitter.com/pcgeek86

[Chris Zeigler]

Hello Chris,

 

If you run powershell.exe with no parameters, it should start an interactive session which will never exit. This is probably not what you want ultimately.

 

For testing purposes, open a cmd prompt and test your command in that before deploying through SCCM. For example, on a problematic 32-bit machine, open cmd, run powershell, and if it exits immediately, run "echo %ERRORLEVEL%" in the cmd prompt, and see what you get in return. It's possible that this will spit out the same error code you're seeing.

 

Either way though, as I said above, it *should* start an interactive session, so I'd avoid deploying a straight "powershell.exe" command via SCCM.

 

Hope this helps.

 

Cheers,

Trevor Sullivan

http://trevorsullivan.net

http://twitter.com/pcgeek86

 

My original program was more than just powershell.exe without parameters, but it would do the exact same thing, work fine on the 64-bit machine but fail on the 32-bit one. Running powershell.exe from a command prompt on the 32-bit machine opens up the interactive powershell just fine, it only seems to be when it's called from SCCM that it fails.

[Trevor Sullivan]

My original program was more than just powershell.exe without parameters, but it would do the exact same thing, work fine on the 64-bit machine but fail on the 32-bit one. Running powershell.exe from a command prompt on the 32-bit machine opens up the interactive powershell just fine, it only seems to be when it's called from SCCM that it fails.

Try enabling the "Allow users to interact with this program" checkbox and see what happens.

 

For the sake of making testing easier, you could publish this as an optional advertisement and execute it on-demand from Run Advertised Programs.

 

Hope this helps.

 

Cheers,

Trevor Sullivan

http://trevorsullivan.net

http://twitter.com/pcgeek86

[Peter33]

Check the Execution Policy on your Workstations with "powershell.exe get-executionpolicy". It should bes set to RemoteSigned.

[Chris Zeigler]

Try enabling the "Allow users to interact with this program" checkbox and see what happens.

 

For the sake of making testing easier, you could publish this as an optional advertisement and execute it on-demand from Run Advertised Programs.

 

Hope this helps.

 

Cheers,

Trevor Sullivan

http://trevorsullivan.net

http://twitter.com/pcgeek86

 

Sadly, checking the "Allow users to interact with this program" did not change anything.

[Chris Zeigler]

Check the Execution Policy on your Workstations with "powershell.exe get-executionpolicy". It should bes set to RemoteSigned.

 

Even with the execution policy set to "Unrestricted", nothing changes

[Peter33]

OK, create a task sequence and a add a command prompt with just calling powershell.exe . In this step choose "run this step as following account" and fill in the credentials from the local admin.