I need to know if I need to prep my SCCM 2012 R2 server to execute powershell scripts from either the Task Sequence or a Package.  Should SCCM work out-of-the-box in pushing powershell scripts?

I have a simple ps1 file that works fine if I run it from the computer as myself but does work from SCCM.

Bat files works fine when I create a program.  I don't have to add anything in the command line.  The command line field only has the name of the bat file.  When I create a program to deploy the ps1 file, I have used different command line settings.  Nothing seems to work.  Whether running the deployment locally or from the Distribution Point, Administrator or User Rights, it always fails.  What am I doing wrong? 

This is what I need in order to troubleshoot this:

I need step by step instructions (detailed) when creating a simple package/program to running a powershell script.

Any help will be appreciated, thanks

Ultimately, this has nothing to do with ConfigMgr. All ConfigMgr can do (and does) is run the command-line that you give it. This is actually preformed by the client agent on the target and so has nothing to do with the server infrastructure whatsoever or the ConfigMgr client agent. There are nuances to be sure though, specifically, the agent will run the command-line using the local System account; however, it's up to the command-line to properly execute and this is totally outside the scope of control of ConfigMgr. Thus, there is nothing magic or special needed within ConfigMgr. PowerShell has it's own nuances as well like the execution policy as pointed out. Combined with the agent running as local System, you need to ensure that the execution policy is set for the local System account on the target systems. This may or may not be your issue though.

Have you reviewed execmgr.log on a target client system? This log details the execution and return-code of the command-line in the program.

Have you added your own logging to the script to see where in the script it is failing?

I'd also like to point out that if you want to test things with SYSTEM -account (before implementing stuff to ConfigMgr), you could use psexec (http://technet.microsoft.com/fi-fi/sysinternals/bb897553.aspx). Just run psexec -s cmd and you'll get a command prompt opened with SYSTEM -account. Now you can test your command lines / scripts etc. there.

• Proposed as answer by Juke ChouMicrosoft contingent staff, Moderator Monday, March 24, 2014 8:20 AM

I'd also like to point out that if you want to test things with SYSTEM -account (before implementing stuff to ConfigMgr), you could use psexec (http://technet.microsoft.com/fi-fi/sysinternals/bb897553.aspx). Just run psexec -s cmd and you'll get a command prompt opened with SYSTEM -account. Now you can test your command lines / scripts etc. there.

• Proposed as answer by Juke ChouMicrosoft contingent staff, Moderator Monday, March 24, 2014 8:20 AM

Hello,

i guess it is the execution policy. You can configure the setting for the clients. SCCM console -> Administration -> Client Settings -> <your client settings> -> properties -> Computer Agent -> Powershell execution Policy -> Switch to Bypass.

This only modifies the policy for powershell during runtime throug sccm client.

Please note, that this policy will only work for scripts which are executed locally. If you want to execute ps1 scripts from a network drive it might be neccessary to add the dp server name into the trusted sites of the IE!

The commandline for executing a ps1 within a SCCM application is:

32bit:
%systemdrive%\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -command .\install.ps1

64bit:
%systemdrive%\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command .\install.ps1

-> where .\ is the source dir of your application

Best Regards

• Edited by dev1337 Monday, March 24, 2014 9:33 AM

Hello,

i guess it is the execution policy. You can configure the setting for the clients. SCCM console -> Administration -> Client Settings -> <your client settings> -> properties -> Computer Agent -> Powershell execution Policy -> Switch to Bypass.

This only modifies the policy for powershell during runtime throug sccm client.

Please note, that this policy will only work for scripts which are executed locally. If you want to execute ps1 scripts from a network drive it might be neccessary to add the dp server name into the trusted sites of the IE!

The commandline for executing a ps1 within a SCCM application is:

32bit:
%systemdrive%\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -command .\install.ps1

64bit:
%systemdrive%\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command .\install.ps1

-> where .\ is the source dir of your application

Best Regards

• Edited by dev1337 Monday, March 24, 2014 9:33 AM

For sake of simplicity I just use the -ExecutionPolicy switch with any Run Command Line steps I use.

powershell.exe -ExecutionPolicy Bypass -File install.ps1

OK, this is what I did:

created my program using only this entry in the Command Line field:  powershell.exe -excutionpolicy bypass -file .\test.ps1

This worked if running as the User Rights (local admin).

If I run this same program  but with Administrative Rights instead of User Rights, it does not work.  The Status in Software Center says that it is installing but sits there forever.

I also checked the execmgr.log and the results look very similar to the one with "User Rights.

I used the "Trace Log Tool" to open the log and the only yellow marking was this entry:

"Program PowerShell Test 2 change to state STATE_ADVANCED_DOWNLOAD content available"

There are no RED highlights.

Just because there are no red highlights in CMTrace doesn't mean your command-line ran successfully and did what it was supposed to do. As mentioned, what that command-line does is outside the scope of what ConfigMgr controls explicitly.

Can you please post the relevant snippet from the execmgr.log showing the execution including the command-line and return code?

Test your command with SYSTEM account using psexec -s cmd like I explained above. After your command WORKS with system account, you can implement the ConfigMgr part. If you're using a package for deployment, make sure that you've added test.ps1 as your content and that content is distributed to the distribution point.

Sorry, I was out yesterday.

Below are the results of the execmgr.log for the package (runs as administrator). 

I have not tested my script as "narcoticoo" mentioned.  I will do that next.

Policy arrived for parent package CB100084 program PowerShell Test 2 execmgr 3/25/2014 11:56:19 AM 4796 (0x12BC)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 6l, value NULL, user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 11:56:19 AM 4796 (0x12BC)
Requesting content from CAS for package CB100084 version 2 execmgr 3/25/2014 11:56:19 AM 4692 (0x1254)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of SoftDistProgramOfferReceivedEvent
{
 AdvertisementId = "CB1200F3";
 ClientID = "GUID:3CA194A1-349B-40FF-B155-94D919C14E86";
 DateTime = "20140325185619.366000+000";
 MachineName = "ComputerName";
 ProcessID = 3812;
 SiteCode = "CB1";
 ThreadID = 4796;
};
 execmgr 3/25/2014 11:56:19 AM 4796 (0x12BC)
Successfully created a content request handle {DAE42B8F-06A0-4FD3-A338-FC8BC09756C7} for the package CB100084 version 2 execmgr 3/25/2014 11:56:19 AM 4692 (0x1254)
Program PowerShell Test 2 change to state STATE_ADVANCED_DOWNLOAD content available execmgr 3/25/2014 11:56:19 AM 4692 (0x1254)
Execution Request for advert CB1200F3 package CB100084 program PowerShell Test 2 state change from NotExist to AdvancedDownload execmgr 3/25/2014 11:56:19 AM 4692 (0x1254)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 1l, value , user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 11:56:19 AM 4692 (0x1254)
Mandatory execution requested for program PowerShell Test 2 and advertisement CB1200F3 execmgr 3/25/2014 11:56:19 AM 1180 (0x049C)
Creating mandatory request for advert CB1200F3, program PowerShell Test 2, package CB100084 execmgr 3/25/2014 11:56:19 AM 1180 (0x049C)
An existing MTC token was not supplied, using ExecutionRequest's Id as MTC token and this execution request is the owner of resultant MTC task. execmgr 3/25/2014 11:56:19 AM 1180 (0x049C)
Request a MTC task for execution request of package CB100084, program PowerShell Test 2 with request id: {9D6705B3-875B-4926-8957-5C22FF80BA31} execmgr 3/25/2014 11:56:19 AM 1180 (0x049C)
Execution Request for advert CB1200F3 package CB100084 program PowerShell Test 2 state change from WaitingDependency to Ready execmgr 3/25/2014 11:56:20 AM 1180 (0x049C)
MTC task with id {9D6705B3-875B-4926-8957-5C22FF80BA31}, changed state from 0 to 4 execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 1l, value , user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 11:56:20 AM 1180 (0x049C)
MTC signaled SWD execution request with program id: PowerShell Test 2, package id: CB100084 for execution. execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Sending ack to MTC for task with id: {9D6705B3-875B-4926-8957-5C22FF80BA31} execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Executing program powershell.exe -executionpolicy bypass -file .\ietaskkill.ps1 in Admin context execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Execution Request for advert CB1200F3 package CB100084 program PowerShell Test 2 state change from Ready to NotifyExecution execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 1l, value , user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Checking content location C:\windows\ccmcache\a for use execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Successfully selected content location C:\windows\ccmcache\a execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Executing program as a script execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Found executable file powershell.exe with complete path C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Successfully prepared command line "C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -executionpolicy bypass -file .\ietaskkill.ps1 execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Command line = "C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -executionpolicy bypass -file .\ietaskkill.ps1, Working Directory = C:\windows\ccmcache\a\ execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Running "C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -executionpolicy bypass -file .\ietaskkill.ps1 with 32bitLauncher execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Created Process for the passed command line execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of SoftDistProgramStartedEvent
{
 AdvertisementId = "CB1200F3";
 ClientID = "GUID:3CA194A1-349B-40FF-B155-94D919C14E86";
 CommandLine = "\"C:\\windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -executionpolicy bypass -file .\\ietaskkill.ps1";
 DateTime = "20140325185620.269000+000";
 MachineName = "ComputerName";
 PackageName = "CB100084";
 ProcessID = 3812;
 ProgramName = "PowerShell Test 2";
 SiteCode = "CB1";
 ThreadID = 4796;
 UserContext = "NT AUTHORITY\\SYSTEM";
 WorkingDirectory = "C:\\windows\\ccmcache\\a\\";
};
 execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Raised Program Started Event for Ad:CB1200F3, Package:CB100084, Program: PowerShell Test 2 execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 1l, value NULL, user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 1l, value , user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)
MTC task with id {9D6705B3-875B-4926-8957-5C22FF80BA31}, changed state from 4 to 5 execmgr 3/25/2014 11:56:20 AM 4796 (0x12BC)

I checked the log file again and that was it.  The below entries is after I deleted the advertisement:

Policy deleted for advertisement CB1200F3 package CB100084 program PowerShell Test 2 execmgr 3/25/2014 12:08:28 PM 4604 (0x11FC)
Policy was deleted or expired for running program PowerShell Test 2. Leave the program in STATE_RUNNING execmgr 3/25/2014 12:08:28 PM 4604 (0x11FC)
Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="CB100084",ProgramID="PowerShell Test 2", actionType 45l, value NULL, user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 3/25/2014 12:08:28 PM 4604 (0x11FC)
ContentAvailable ignoring update with no DPs for content request ID {03A793EE-CF78-4439-9CD0-D58E02998346} execmgr 3/25/2014 12:18:28 PM 6080 (0x17C0)

Like I said before, under System Center, the status says "Installing", but it just sits there spinning.  I can run another one with User Rights to compare notes (logs) if you like.

Is this your issue? I see that all the time, the package is not actually installing. If you deploy it again via the console it will install just fine. As far as I can tell this is a WMI issue where the evaluation_state gets hung.

http://www.potentengineer.com/task-sequence-stuck-installing-in-software-cente

Are you doing from a TS or a stand-alone package?

I was going to say something to what Daniel said as it appears that the script itself not actually finishing based upon the above log file.

If you are doing this from a TS, what does smsts.log say?

this is a stand-alone package.  Like I said before, it works if program is deployed with User Rights (me - local admin rights).  If I deploy this program with Administrator Rights, it sits in the "installing" state and just keeps spinning as mentioned in your link.

All it does is close IE if it is open

Used another test computer and got same results.  Script does not execute if Run Mode is set to "administrative rights".

From the Stop-Process docs at http://technet.microsoft.com/en-us/library/hh849781.aspx:

"By default, Stop-Process prompts for confirmation before stopping any process that is not owned by the current user."

That's why your script is not finishing. Thus, you need to add the force parameter to the cmdlet.

Just tested this with psexec, force parameter is indeed needed. If the -force isn't added, the script just hangs with system account. Change your script (processkill.ps1) to:

stop-process -processname iexplore* -force

And for running the actual script (package program): powershell.exe -executionpolicy bypass -file processkill.ps1

You have got to be kidding me, it worked!!

I spent days trying to figure this out thinking it was SCCM's permission issues with running PS on local computer.

Ok, so there are two pieces to this puzzle - one is the command line string, and the other is the PS itself.

I ran the deployment from both the Distribution Point and Run Locally - worked great.

Since my powershell scripts are going to get bigger, now I know what to look for.

Thank you both Jason and narcoticoo for all of your help.

• Marked as answer by Noe.O Wednesday, March 26, 2014 5:36 PM

You have got to be kidding me, it worked!!

I spent days trying to figure this out thinking it was SCCM's permission issues with running PS on local computer.

Ok, so there are two pieces to this puzzle - one is the command line string, and the other is the PS itself.

I ran the deployment from both the Distribution Point and Run Locally - worked great.

Since my powershell scripts are going to get bigger, now I know what to look for.

Thank you both Jason and narcoticoo for all of your help.

• Marked as answer by Noe.O Wednesday, March 26, 2014 5:36 PM

Ok, so there are two pieces to this puzzle - one is the command line string, and the other is the PS itself.

Hi,

could you please share the details of which command line string you used, which helped the ps script to execute sucessfully

i have put two seperate scripts in a Task sequence and trying to execute one after other

Regards

Tanoj

See Narcoticoo's reply above.

stop-process -processname iexplore* -force

powershell.exe -executionpolicy bypass -file processkill.ps1

i am using below script ( powershell ) to write out logged in user

whoami | out-file C:\username.txt
Start-Sleep -s 10

command line is : Powershell.exe -executionpolicy Bypass -file .\Username.ps1

if this is executed as individual package it gives error : that access to the Path C:\username.txt is denied

if i change the Run Mode to "Run with administrative rights" it does the same

if i add the same package in Task sequence it does write out, however writes "nt authority\system" in the txt file insted of logged in user name

if i run the package as a command line in Task sequence giving admin account details, it writes out my admin details in the txt file

Tried using VB script too, does same

My requirement is the script should run locally, and write out current logged in user to the txt file

Regards

Tanoj

whoami will give you the account running the script, which is correct for all scenarios listed above.

You need to query WMI or some other means to determine the actual logged in user. whoami will not do that when deployed from SCCM.

You need to query WMI 

I tried querying wmi, however it comes out null, i checked inside the class and beside username there is blank

Also whenever a powershell script is executed on client machine it opens the blue window ( powershell ) even though i tried deploying as hidden, cant we avod this blue window poping up ?

Regards,

Here are a few examples of querying the current logged in users. There are many different methods.

http://learn-powershell.net/2010/11/01/quick-hit-find-currently-logged-on-users/

http://ss64.com/nt/query-user.html

http://blogs.msdn.com/b/alejacma/archive/2008/03/04/how-to-get-the-logged-on-user-with-wmi-vbscript.aspx

To run a PowerShell script with the window hidden, use the following command.

powershell.exe -executionpolicy bypass -windowstyle hidden -file processkill.ps1

Hi,

so far i have achived to add the logged on user to the "Administrators" group, when he runs "Elevateme" package (powershell script ) from software center

Next challange is how to revoke the Admin rights after 24 Hours ?,

1. can we use time stamp ? , is it reliable method

2.other way which came to my mind is, whenever the script ( Elevateme) runs on the client computer, it will simultaniously write a txt file on the server(sharefolder) which will have get date, get hostname, get username

then make other script which will read this txt file every 6 hours and revoke admin rights if their timelimit completes ?

3. create a Configuration iteam to check if admin rights is there, run auto remediation rule to remove admin rights ?, but what if the ci runs on the same day after some time, is there a way to achive it to do only once in the morning etc ?

Please pour in your ideas

Thank you

Regards

I always use a batch/cmd file.

Lets say you have install.cmd and install.ps1 in the same source folder..

I always start the batch/cmd script with the following...

if %PROCESSOR_ARCHITECTURE%==x86 if defined ProgramFiles(x86) start /wait "" "%windir%\sysnative\cmd.exe" /c "%~f0" & exit %errorlevel%
This will start the batch/cmd file itself again with the system native CMD and still exit the script with the correct exitcode. Otherwise I will get a lot of problem with Windows folder paths and cmd utilities when SCCM always execute 32bit cmd.exe on a 64bit Windows OS.

And then when a want to execute the Powershell script I use...

"%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy ByPass -File "%~dp0install.ps1"

Everything work perfect running from UNC-path...

Daniel

With this approach do you have to watch out for issues with double quotes ("") in your PowerShell code or is that only when you use the -Command syntax?

-Tony

• Edited by Tony Chirillo 14 hours 11 minutes ago

When using the [Run Command Line] task sequence option with the syntax of  [powershell.exe -ExecutionPolicy Bypass -File MyFile.ps1], does the Powershell script launch in the same manor as it would when using the [Run Powershell Script] task sequence option or does it do\handle things differently?

-Tony

• Edited by Tony Chirillo Saturday, June 13, 2015 2:29 AM

When using the [Run Command Line] task sequence option with the syntax of  [powershell.exe -ExecutionPolicy Bypass -File MyFile.ps1], does the Powershell script launch in the same manor as it would when using the [Run Powershell Script] task sequence option or does it do\handle things differently?

-Tony

• Edited by Tony Chirillo Saturday, June 13, 2015 2:29 AM

Hi Daniel!

Great explanation! I did not realize the client policy had a tie in here. In theory, if I have a PowerShell script that runs in a Run PowerShell Script  task it should run just the same if I trigger it using the Run Command Line task?

Like this for example: powershell.exe -ExecutionPolicy Bypass -File .\approve.ps1

I ask because part of a script is not working as a Run PowerShell Script  task because it is being ran as LocalSystem. I am hoping to get around this issue with the Run Command Line task because I can specify a specific account to use instead of LocalSystem. Do you foresee any gotchyas with this approach?

• Edited by Tony Chirillo Monday, June 15, 2015 3:51 PM

I attempted to run the exact same PowerShell script using the 'Run Command Line' task instead in my task sequence and received different set of errors. Would you have any idea why essentailly a working script using one method completely bombs using another?

Here is my syntax:  powershell.exe -ExecutionPolicy Bypass -File .\approve.ps1.

Here are the errors in the SMSTS Log:

Here is the script:

Note: ('Run PowerShell Script' task get to line 7 below and then fails on permissions. Looks like the first line is now failing by switching to a different task sequence task.)

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$OSDComputerName = $tsenv.Value("OSDComputerName") 

$OSDcomputerName = $OSDcomputerName + ".my.domain.com"

md "C:\Program Files\OpsManModule"
xcopy $PSScriptRoot\*.* /s /e "C:\Program Files\OpsManModule"

Import-Module "C:\Program Files\OpsManModule\OperationsManager\OperationsManager.psd1"
New-SCOMManagementGroupConnection ComputerName "my.server.my.domain.com"

get-SCOMPendingManagement | where {$_.AgentPendingActionType -eq "ManualApproval" -and $_.AgentName -eq "$OSDcomputerName"} | Approve-SCOMPendingManagement

• Edited by Tony Chirillo Tuesday, June 16, 2015 1:23 PM

When using the [Run Command Line] task sequence option with the syntax of  [powershell.exe -ExecutionPolicy Bypass -File MyFile.ps1], does the Powershell script launch in the same manor as it would when using the [Run Powershell Script] task sequence option or does it do\handle things differently?

-Tony

I attempted to run the exact same PowerShell script using the 'Run Command Line' task instead in my task sequence and received different set of errors. Would you have any idea why essentailly a working script using one method completely bombs using another?

Here is my syntax:  powershell.exe -ExecutionPolicy Bypass -File .\approve.ps1.

Here are the errors in the SMSTS Log:

Here is the script:

Note: ('Run PowerShell Script' task get to line 7 below and then fails on permissions. Looks like the first line is now failing by switching to a different task sequence task.)

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$OSDComputerName = $tsenv.Value("OSDComputerName") 

$OSDcomputerName = $OSDcomputerName + ".my.domain.com"

md "C:\Program Files\OpsManModule"
xcopy $PSScriptRoot\*.* /s /e "C:\Program Files\OpsManModule"

Import-Module "C:\Program Files\OpsManModule\OperationsManager\OperationsManager.psd1"
New-SCOMManagementGroupConnection ComputerName "my.server.my.domain.com"

get-SCOMPendingManagement | where {$_.AgentPendingActionType -eq "ManualApproval" -and $_.AgentName -eq "$OSDcomputerName"} | Approve-SCOMPendingManagement

• Edited by Tony Chirillo 18 hours 7 minutes ago

Does anyone know if there is an issue with trying to call this line:

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

Using the 'Run Command Line' task? I am using this syntax:

powershell.exe -ExecutionPolicy Bypass -File .\approve.ps1

The code is in the approve.ps1 script.

There error goes away when using the 'Run Powershell Script' task.

Thoughts? Opinions? Theories?

-Tony

• Edited by Tony Chirillo 17 hours 44 minutes ago

Hi Daniel!

Great explanation! I did not realize the client policy had a tie in here. In theory, if I have a PowerShell script that runs in a Run PowerShell Script  task it should run just the same if I trigger it using the Run Command Line task?

Like this for example: powershell.exe -ExecutionPolicy Bypass -File .\approve.ps1

I ask because part of a script is not working as a Run PowerShell Script  task because it is being ran as LocalSystem. I am hoping to get around this issue with the Run Command Line task because I can specify a specific account to use instead of LocalSystem. Do you foresee any gotchyas with this approach?

• Edited by Tony Chirillo 15 hours 40 minutes ago

Does anyone know if there is an issue with trying to call this line:

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

Using the 'Run Command Line' task? I am using this syntax:

powershell.exe -ExecutionPolicy Bypass -File .\approve.ps1

The code is in the approve.ps1 script.

There error goes away when using the 'Run Powershell Script' task.

Thoughts? Opinions? Theories?

-Tony

• Edited by Tony Chirillo Wednesday, June 17, 2015 2:11 PM

Daniel

When you used it with the Run Command Line step, were you also supply alternate credentials? My experience of failures in the above screen shot were from using alternated credentials.  -Tony