powershell script works locally but not when deployed ...

[Legacy User]

Hi experts!

 

I want to deploy a powershell script using DSM. The script works fine when running locally with an admin account. But when deployed through software delivery the script never worked. The script removes some Win10 apps and modifies the default user profile.

 

Any idea(s) why the script won't work with DSM?

 

Greetings

[lecri01]

Remember the script is running as local system not as a user.  You need to specify a literal path since it has no profile associated with windows\system.

 

Richard Lechner

Principal Engineering Services Architect

 

CA Technologies

Mobile: [phone] | [e-mail]

 

<mailto:[e-mail]>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google]<https://plus.google.com/CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

[Legacy User]

Hi Richard!

 

Thanks for your response. Could you please give me more advice on this?

The script is loading "NTUSER.DAT" from ..\Users\Default directory and set some registry values.

Am i missing here something?

 

Regards,

Andreas

[lecri01]

Have the script write the value to a log file.  Then compare the value returned when run locally and by the at any

 

To test the script locally assign it to the windows scheduler. For testing using the at command. The windows scheduler also runs as local system.

 

Get Outlook for Android<https://aka.ms/ghei36>

[Steve Parker]

Perhaps if you showed us the script we would have a better idea?

[Legacy User]

The script itself works. It also works as system account (tested with psexec). The problem occurs when the script gets deployed via DSM. I get an error message that "Import-StartLayout" is not recognized as a Cmdlet ...

 

I called Import-Startlayout within a script (.ps1) --> I get the above error ...

I called it this way: powershell -Command "Import-StartLayout -LayoutPath ... " --> I get the above error ...

[lecri01]

Try this. import-startlayout -mountpath $env:SystemDrive

 

 

Based on this link

https://social.technet.microsoft.com/Forums/lync/en-US/c7a75c34-767a-404a-a0a1-daa4a978f5a1/using-importstartlayout-to-a-local-system?forum=winserverpowershell

 

Richard Lechner

Principal Engineering Services Architect

 

CA Technologies

Mobile: [phone] | [e-mail]

 

<mailto:[e-mail]>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google]<https://plus.google.com/CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

[Steve Parker]

By default, if you have specified your .PS1 script in the Item procedure it will run a 32bit powershel.exe.  Change this to use the 64bit as default and try again.

 

 

[Legacy User]

I already know this thread ... I googled around not finding a solution. But it must have something to do with DSM. Maybe someone can test importing an layout within a software job ...

[lecri01]

https://comm.support.ca.com/kb/software-delivery-job-start-a-command-in-64-bit-mode/kb000031305

 

Richard Lechner

Principal Engineering Services Architect

 

CA Technologies

Mobile: [phone] | [e-mail]

 

<mailto:[e-mail]>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google]<https://plus.google.com/CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

[Legacy User]

I call *.ps1 within *.cmd ... When the procedure calls the *.ps1 directly then I get a security warning which means user interaction. So I have to copy the *.ps1 to local disk ... call unblock file on the script and call the script ...

 

Is there a better way?

[Steve Parker]

In the default configuration for the Agent change the powershell interpreter setting to “powershell.exe -ExecutionPolicy ByPass -NoLogo -NonInteractive -File”

 

 

 

Then specify the PS1 file directly in the item procedure.

[lecri01]

 

Richard Lechner

Principal Engineering Services Architect

 

CA Technologies

Mobile: [phone] | [e-mail]

 

<mailto:[e-mail]>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google]<https://plus.google.com/CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

[Legacy User]

No Change ... I got the security message again. How long does it take for the policy to be active after sealing?

[Legacy User]

Now no security warning ... Instead the job fails immediately ... <no output available ...>

[Steve Parker]

The alternate approach is to modify your command file to make sure it launches the 64bit powershell.exe.

 

Else, let’s take this off line and I can work with your tomorrow to work out what’s going wrong.

[Shocko]

is this possible? I though the AM/SD agents were 32-bit. 

[Legacy User]

That was my first Approach ... Procecure --> *.cmd --> C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe ...

 

I'll try everything possible with the help of google before posting into such communites.

 

This is frustrating ...

[Steve Parker]

I will reach out in the morning.