none
Script Detection Method RRS feed

  • Question

  • I'm having some difficulty using custom scripts as the detection method for an application deployment type. I'm hoping someone can confirm what I'm running into.

    Signed powershell scripts do not execute and powershell claims they are signed. After digging into this, I've discovered that any scripts uploaded in the detection method Script Editor window are converted so the newline character is no longer CRLF, but just LF. Powershell doesn't realize there is a signature block when the file is saved with just LF as the newline character.

    The scripts don't live on the client for longer than it takes to execute them. To get around that, I've denied SYSTEM's ability to delete files from c:\windows\ccm\systemtemp. This way I can actually see the file that is being downloaded. It doesn't matter how I upload the file or paste the values into the Script Editor window, CRLF is converted to just LF when the file is downloaded.

    I can always do VBScript or change powershell's execution policy, but is there a solution so I can use signed powershell code? My site is running on Server 2012, SQL 2012 SP1 and ConfigMgr 2012 SP1.

    Wednesday, May 8, 2013 7:42 PM

All replies

  • There is a setting in the "client settings" in sccm 2012 which allows you to run unsigned powershell scripts regardless of what the client has configured as powershell execution mode... maybe that can help you out.

    it is under computer agent.

    I'm running an unsigned script and the policy on m pc's is that it should be signed thanks to that...

    http://technet.microsoft.com/en-us/library/gg682067.aspx

    Tuesday, May 14, 2013 5:24 PM
  • I recall an issue with pasting the script directly into the script window if you created it with powershell ISE. The workaround I believe was to save the script as a file with something like notepad and then browse to it from detection method script screen as opposed to pasting it in the window. May have had something to do with the character set when the script was in ISE editor.  But thanks, I like your idea of temporarily removing delete for system account in ccm\systemtemp because I have other issues with powershell detection method scripts I am trying to troubleshoot and had no clue where to look.
    Saturday, May 18, 2013 2:05 PM
  • Ah I see, you also commented on my blog. I just wanted to link it.

    AS Mitch mentioned and I also Point out in my Blog:
    Try to open your script in  Notepad, copy it to another new Notepad, and save the newly created script.

    Tuesday, May 28, 2013 6:53 AM
  • There is a client setting of the powershell from the site server.

    Open Admin Console -> Administration->Client Settings -> Default client settings -> Properties -> Computer Agent

    Setting name: Power shell execution policy

    Default value : All signed scripts

    You can change it to "ByPass" and clients consumes it whenever it gets the policy.

    Then detection script will get succeed.

    Thanks

    Sreekar Mankala

    Tuesday, May 28, 2013 11:30 PM
  • The workaround works but it would be nice if I could use the powershell script with the AllSigned policy.  I think the security concern is moderate because it is only changing the Execution Policy for ConfigMgr related powershell scripts.  We have our ConfigMgr infrastructure pretty well locked down.

    The script works fine when I run it outside of ConfigMgr.

    I used your idea of denying delete to the SYSTEM account and was able to look at the script.  Below is how the script gets formatted by ConfigMgr when I open it in Notepad.  The first is with Word Wrap off and the second is with Word Wrap on.  Interesting.  I tried a bunch of different ways to format it so that line breaks remained but nothing worked.  I'm going to tray one more idea

    Wednesday, November 6, 2013 4:21 PM
  • I know it is a little older, but have you tried opening it with Notepad++ it really helps with formatting like this

    Friday, December 5, 2014 4:53 PM
  • looks like this is an old post. Im running into the same problem. Has their been a resolution to this issue other than setting the power shell execution policy to bypass in client settings. Seems silly to have a feature like this that is bugged and have an answer to turn off security as the answer.
    Wednesday, May 6, 2015 8:18 PM
  • I think the solution is to sign the script and for ConfigMgr to process that correctly.  I could never get it to recognize the signed script and never came back to it.
    Wednesday, May 6, 2015 8:23 PM
  • When changing the execution policy within the client settings this is only for ConfigMgr related tasks. I don't think it changes the execution policy on the device. (I am sure I read it somewhere)

    Just check it on a client though, it doesn't take long.

    edit:referenced here:

    http://blog.coretech.dk/heh/configuration-items-and-baselines-using-scripts-powershell-example/

    Wednesday, May 6, 2015 8:36 PM
  • That is correct Richard
    Wednesday, May 6, 2015 8:37 PM
  • Did anyone ever resolve this???     The bypass setting does not appear to work in my environment.

    I've tried the multiple methods of signing the scripts and it seems that no matter what I do,  the number of characters changes and the script isn't signed correctly.

    Wednesday, June 3, 2015 7:10 PM
  • I can verify that this is still an issue with SCCM version 1511. Bypassing security policies is a poor solution for a problem that is really very simple. SCCM should not modify the contents of the Powershell script when copying it to the client. Problem solved. However, I don't think this is very high up on the priority list because SCCM has been mangling Powershell detection scripts for the last three years at least.
    Wednesday, February 17, 2016 5:42 PM
  • There's a workaround that you can use for this scenario. See: https://blogs.msdn.microsoft.com/ameltzer/2014/09/24/using-signed-powershell-scripts-with-configuration-items-and-applications/


    Check out my Configuration Manager blog at http://aka.ms/ameltzer

    Wednesday, August 31, 2016 6:27 PM