none
PowerShell script-based Application Detection Method during OSD RRS feed

  • Question

  • Hi all,

    I'm deploying the Windows Management Framework during an OSD task sequence. I'm using a 1-line PowerShell script as my detection method for the Windows Management Framework application:

    if (Get-WmiObject -Query "Select * from WIN32_QuickFixEngineering where HotFixID = 'KB2506143'"){write-host "Installed"}

    When the task sequence reaches this step, it fails to run. The AppDiscovery.log file contains the following lines:

        Performing detection of app deployment type WMF 3.0 Win7SP1 x64 and 2008 R2 SP1(ScopeId_C2C3E2A6-CD6C-4041-815A-40099562602C/DeploymentType_5c5f1be5-647e-4203-9e93-e10f76a4ffe0, revision 18) for system.	AppDiscovery	3/11/2013 5:41:33 PM	2168 (0x0878)
    Failed to read script execution time-out from policy. Use default 60 seconds.	AppDiscovery	3/11/2013 5:41:33 PM	2168 (0x0878)
        In-line script returned error output: & : File C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1 
    cannot be loaded. The file 
    C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1 is not 
    digitally signed. The script will not execute on the system. For more 
    information, see about_Execution_Policies at 
    http://go.microsoft.com/fwlink/?LinkID=135170.
    At line:1 char:3
    + & 'C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1'
    +   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : SecurityError: (:) [], PSSecurityException
        + FullyQualifiedErrorId : UnauthorizedAccess
    	AppDiscovery	3/11/2013 5:41:36 PM	2168 (0x0878)
    Script Execution returned error message: & : File C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1 
    cannot be loaded. The file 
    C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1 is not 
    digitally signed. The script will not execute on the system. For more 
    information, see about_Execution_Policies at 
    http://go.microsoft.com/fwlink/?LinkID=135170.
    At line:1 char:3
    + & 'C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1'
    +   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : SecurityError: (:) [], PSSecurityException
        + FullyQualifiedErrorId : UnauthorizedAccess
    , ExitCode: 1	AppDiscovery	3/11/2013 5:41:36 PM	2168 (0x0878)
      Script Execution Returned :1, Error Message: & : File C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1 
    cannot be loaded. The file 
    C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1 is not 
    digitally signed. The script will not execute on the system. For more 
    information, see about_Execution_Policies at 
    http://go.microsoft.com/fwlink/?LinkID=135170.
    At line:1 char:3
    + & 'C:\Windows\CCM\SystemTemp\67d54b0a-d6ee-4fed-809a-6ce225bf9b48.ps1'
    +   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : SecurityError: (:) [], PSSecurityException
        + FullyQualifiedErrorId : UnauthorizedAccess
    . [AppDT Id: ScopeId_C2C3E2A6-CD6C-4041-815A-40099562602C/DeploymentType_5c5f1be5-647e-4203-9e93-e10f76a4ffe0, Revision: 18]	AppDiscovery	3/11/2013 5:41:36 PM	2168 (0x0878)
    CScriptHandler::DiscoverApp failed (0x87d00327).	AppDiscovery	3/11/2013 5:41:36 PM	2168 (0x0878)
    Deployment type detection failed with error 0x87d00327.	AppDiscovery	3/11/2013 5:41:36 PM	2168 (0x0878)
    Failed to perform detection of app deployment type WMF 3.0 Win7SP1 x64 and 2008 R2 SP1(WMF 3.0 Win7SP1 x64 and 2008 R2 SP1, revision 18) for system. Error 0x87d00327	AppDiscovery	3/11/2013 5:41:36 PM	2168 (0x0878)
    

    As you can see, the PowerShell script that performs the application detection can't be run because it is unsigned. I've tried the following to fix it, but nothing is helping:

    1. I signed the script using a code signing certificate issued by my enterprise CA

    2. I added a "run command line" step before the application that sets the PowerShell execution policy to Bypass. I also tried Unrestricted which didn't help either. After the OSD task sequence failed, I verifid that the PowerShell execution policy had been changed.

    I should also note that the above detection method works just fine if I run it using regular application deployment from within the full Windows OS. It only fails if run during an OSD task sequence.

    Any suggestions?

    Thanks,

    --Russel

    Tuesday, March 12, 2013 3:45 PM

Answers

  • We’re having a similar problem with powershell detection methods not working under the Install Application step during OS Deployment. Our powershell is more than a few lines long thus wrapping them in VBScript is less than ideal.

    I tried some debugging yesterday with this VBScript detection method:

    Set objShell = CreateObject("WScript.Shell")
    strCmd = "powershell -ExecutionPolicy ByPass -Command "
    strCmd = strCmd & """$s=(Join-Path $env:windir ""TEMP\dm.txt"");Get-ExecutionPolicy >> $s;Get-ExecutionPolicy -List >> $s"""
    intResult = objShell.Run(strCmd, 0, true)
    WScript.Echo "It Ran"

    I discovered the difference in powershell execution policy between an OS Deployment Task Sequence and a fully installed OS is an Undefined MachinePolicy scope. This makes sense because the machine hasn’t yet applied Group Policy from the domain while still running OS Deployment.

    So to mimic Group Policy you can set these two registry settings prior to your Install Application step and voila, powershell detection methods start working during OS Deployment.
    reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v EnableScripts /t REG_DWORD /d 1 /f
    reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v ExecutionPolicy /d RemoteSigned /f

    I hope this helps someone as much as it did me.


    • Marked as answer by Russel Riley Thursday, July 18, 2013 4:48 PM
    Thursday, July 18, 2013 1:48 PM

All replies

  • I have the same problen with Application Deployment, it seems that powershell script behind detection method causing this or something.
    Monday, March 18, 2013 4:10 PM
  • If none of this is working then last resort is to install Windows Management Framework as a package in OSD TS if it is feasible in your setup.


    Cheers | Navdeep Sidhu

    • Marked as answer by Russel Riley Thursday, March 21, 2013 11:14 PM
    • Unmarked as answer by Russel Riley Thursday, July 18, 2013 4:49 PM
    Monday, March 18, 2013 4:26 PM
  • I got the powershell error done, by setting the agent policy to bypass the powershell execution. Maybe the same solution will work for OSD?

    Configure how Configuration Manager clients can run Windows PowerShell scripts. These scripts are often used for detection in configuration items for compliance settings, but can also be sent in a deployment as a standard script.

    • Bypass: The Configuration Manager client bypasses the Windows PowerShell configuration on the client computer so that unsigned scripts can run.
    • Restricted: the Configuration Manager client uses the current Windows PowerShell configuration on the client computer, which determines whether unsigned scripts can run.
    • All Signed (Configuration Manager SP1 only): The Configuration Manager client runs scripts only if they are signed by a trusted publisher. This restriction applies independently from the current Windows PowerShell configuration on the client computer.

    This option requires at least Windows PowerShell version 2.0 and the default is Restricted in Configuration Manager with no service pack, and All Signed in Configuration Manager SP1.

    TipTip
    If unsigned scripts fail to run because of this client setting, Configuration Manager reports this error in the following ways: 

    • Error ID 0X87D00327 and the description of Script is not signed as a deployment status error in the Monitoring workspace of the Configuration Manager console.
    • Error codes and descriptions of 0X87D00327 and Script is not signed or 0X87D00320 and The script host has not been installed yet with the error type of Discovery Error in reports, such as Details of errors of configuration items in a configuration baseline for an asset.
    • The message Script is not signed (Error: 87D00327; Source: CCM) in the DcmWmiProvider.log file.
    • Proposed as answer by yannara Monday, March 18, 2013 4:37 PM
    • Unproposed as answer by Russel Riley Tuesday, March 19, 2013 3:13 AM
    Monday, March 18, 2013 4:37 PM
  • I got the powershell error done, by setting the agent policy to bypass the powershell execution. Maybe the same solution will work for OSD?

    Thanks for the reply. I've already configured my client settings to set the PowerShell execution policy to bypass, but those settings do not appear to be relevant during OSD.

    NavdeepSidhu

    As a work-around, I did just what you are suggesting, and created a separate package for WMI as well as for the App-V 5.0 client and am using those during OSD instead of using the Application model. I don't like this solution, so I'm thinking of changing my detection method in the WMI framework from Powershell to VBScript, and just using VBScript to launch my 1-line PowerShell script with execution policy disabled. I'll try that tomorrow and report back what I find.

    --Russel

    Tuesday, March 19, 2013 3:18 AM
  • This is serious, if the same applications does not work in OSD, but are deployed fine as deployment. There must be reliable solution to debloy also KB fixes as applications, because packages does not support depencies as a functionality. And there is lot of applications, which requires some KB to work.

    Making double import of software as package and as application would be very annoying. Maybe lot of folks would suggest you to import these KBs directly to .wim.

    Another thing - can you post pone or delay the installation of WMF during OSD as application? This is due, that let the client policy to be applied during TS. So if the WMF is one of the first installable apps, postpone it to be the one of the latest, will that help?

    Tuesday, March 19, 2013 6:38 AM
  • Hi Russel

    You only have to create package for Windows Management Framework & then add a step to restart because it is needed after installing WMF 3.0.

    As far as App-V 5.0 client is concerned, it can be installed under "Install Application" step along with other applications during OSD TS. You do not need to create package for App-V 5.0 client.

    The above mentioned step/solution is just working great for me!

    However as you said, you didn't like this solution then you may use other detection method like VBScript.


    Cheers | Navdeep Sidhu

    Tuesday, March 19, 2013 12:26 PM
  • Hi Russel

    You only have to create package for Windows Management Framework & then add a step to restart because it is needed after installing WMF 3.0.

    As far as App-V 5.0 client is concerned, it can be installed under "Install Application" step along with other applications during OSD TS. You do not need to create package for App-V 5.0 client.

    The above mentioned step/solution is just working great for me!

    However as you said, you didn't like this solution then you may use other detection method like VBScript.


    Cheers | Navdeep Sidhu


    The situation is that I have computers on field is use, and we have new computers to be deployed via OSD. Both needs App-V client which requires WMF3.0. Because powershell script detection method does not work during OSD as Russel noticed, I´m forced to creade WMF package and WMF application, because package does not support deppencies.
    Wednesday, March 20, 2013 8:32 AM
  • yeah, I understand that package does not support dependencies & hence WMF 3.0 can't be installed as an application under App-V application dependencies tab. That's why I'm asking to create a seperate package for WMF 3.0, then add restart step in OSD TS & then install App-V 5.0 client.

    Cheers | Navdeep Sidhu

    Wednesday, March 20, 2013 10:28 AM
  • yeah, I understand that package does not support dependencies & hence WMF 3.0 can't be installed as an application under App-V application dependencies tab. That's why I'm asking to create a seperate package for WMF 3.0, then add restart step in OSD TS & then install App-V 5.0 client.

    Cheers | Navdeep Sidhu

    My point is that this powershell script problem during OSD should be treated as a potential bug. Because there will be always some KBs required for some application and detection method should implemented for them.

    Creating application and package of the same KB is silly. Also, just an example, what if I don´t want to deploy WMF to every machine, just for the App-V needs. Sure in this case the best way would be to (al least what I would do), is to inject this WMF directly to WIM with dism, but I´m sure there are similar cases with other KBs.

    Wednesday, March 20, 2013 3:48 PM
  • I wound up finding 2 workarounds. First off I created both WMF 3.0 and App-V 5.0 as packages and deployed them as packages instead of applications. This was a short-term fix that I didn't much like. Note that I have my App-V 5.0 Application configured so that it depends on WMF 3.0, so even after WMF 3.0 was installed as a package, App-V wouldn't install because the detection method for WMF wouldn't work during the OSD TS.

    The 'better' workaround was to change the detection method for my WMF package to use VBScript instead of PowerShell. The VBScript just runs a single PowerShell command, but it also sets the execution policy to bypass while running it. Here is what I came up with:

    Set objShell = CreateObject("Wscript.shell")
    installed = objShell.run("powershell -executionpolicy bypass -command if (Get-WmiObject -Query \""Select * from WIN32_QuickFixEngineering where HotFixID = 'KB2506143'\""){exit 1}", 0, true)
    If installed = 1 Then 
    	WScript.Echo "Installed"
    End If

    I do consider this a bug because there appears to be no way to run a PowerShell script detection method during OSD, but this workaround is fine for the time being.

    Thanks to all who chimed in.

    --Russel

    • Marked as answer by Russel Riley Thursday, March 21, 2013 11:21 PM
    • Unmarked as answer by Russel Riley Thursday, July 18, 2013 4:49 PM
    Thursday, March 21, 2013 11:21 PM
  • I tried your VBS script as is, enabled as 32 process in 64bit OS or not, it doesn´t work. Evaluation of WMF fails during OSD. Are you sure it´s working? Could you publish a screenshot of the detection setting?
    Tuesday, March 26, 2013 10:53 AM
  • I'm sure it is working, but I did make one mistake when I first tested. I changed the content of the script without changing the type to VBScript, so even though it was a VBScript, the OSD TS engine was trying to still run it as a PowerShell script. Here is a screenshot of my detection method. It is the same for both x86 and x64.

    • Proposed as answer by yannara Monday, April 1, 2013 3:19 PM
    Tuesday, March 26, 2013 3:39 PM
  • Thanks Russel for posting the screenshot, I had misstiped something. I can now confirm that this solution works during OSD as well. I have now a valid App-V implementation in OSD.
    • Edited by yannara Monday, April 1, 2013 3:20 PM
    Monday, April 1, 2013 3:20 PM
  • My WMF 3.0 application simply uses registry based detection and it works great in Windows 7 OSD and regular distributions.

    Key: SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine

    Value: PowerShellVersion

    DataType: String

    Operator: Equals

    Value: 3.0

    Andy


    My Personal Blog: http://madluka.wordpress.com

    Monday, April 1, 2013 4:02 PM
  • Yep MadLuka, that could do the trick as well, but I was trying to find common solution for implementing the same script for any KB package, like RSAT for example.
    • Proposed as answer by Emil_78 Thursday, September 26, 2013 12:21 PM
    Tuesday, April 2, 2013 6:29 AM
  • In 50% cases, installation of WMF fails 0x8004005 as application, I had enough of this, so I just mounted it to wim with DISM :)

    Wednesday, April 10, 2013 6:59 AM
  • In fact, I'm also facing this issue that WMF gets fail with same error code & I'm glad I'm not the only one who is facing this issue. BTW I also injected this into Windows image to get rid of this annoying error.


    Cheers | Navdeep Sidhu

    Wednesday, April 10, 2013 8:55 AM
  • We’re having a similar problem with powershell detection methods not working under the Install Application step during OS Deployment. Our powershell is more than a few lines long thus wrapping them in VBScript is less than ideal.

    I tried some debugging yesterday with this VBScript detection method:

    Set objShell = CreateObject("WScript.Shell")
    strCmd = "powershell -ExecutionPolicy ByPass -Command "
    strCmd = strCmd & """$s=(Join-Path $env:windir ""TEMP\dm.txt"");Get-ExecutionPolicy >> $s;Get-ExecutionPolicy -List >> $s"""
    intResult = objShell.Run(strCmd, 0, true)
    WScript.Echo "It Ran"

    I discovered the difference in powershell execution policy between an OS Deployment Task Sequence and a fully installed OS is an Undefined MachinePolicy scope. This makes sense because the machine hasn’t yet applied Group Policy from the domain while still running OS Deployment.

    So to mimic Group Policy you can set these two registry settings prior to your Install Application step and voila, powershell detection methods start working during OS Deployment.
    reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v EnableScripts /t REG_DWORD /d 1 /f
    reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v ExecutionPolicy /d RemoteSigned /f

    I hope this helps someone as much as it did me.


    • Marked as answer by Russel Riley Thursday, July 18, 2013 4:48 PM
    Thursday, July 18, 2013 1:48 PM
  • Hi Zandarian

    I just modified my task sequence and packages to incorporate your fix. It worked perfectly. I should also note that even though my scripts are not signed anymore, using the second reg command as-is still worked just fine. (I thought I might have to set it to bypass or some other setting, but nope - RemoteSigned works).

    Thank you so much for your reply. It certainly helped me!

    --Russel

    Thursday, July 18, 2013 4:48 PM
  • Deleted
    Monday, December 9, 2013 2:24 PM
  • There may be some solutions in this thread, but it seems unnecessarily complicated.  Try using a simple cmdlet and let it return results (successful detection), or fail with an error (not detected).  Or use a package model in OSD.

    Detection method for WMF 3.0 (powershell script)
    Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB2506143'"

    Detection method for RSAT for Windows 7 (powershell script)
    Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB958830'"

    Detection method for RSAT for Windows 8.1 (powershell script)
    Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB2693643'"

    Monday, June 8, 2015 8:57 PM
  • Hi Stephen,

    Your solution isn't really much different than the detection method I posted in my original question. The problem is that during OSD Configuration Manager wouldn't run any PowerShell cmdlets for application detection at all because of the signing issue. Even single-line scripts would not run. Zandarian's post with the two reg commands truly does resolve the issue. and is very simple to implement. Everything else in this thread seems to just be a work-around.

    It is worth noting that this thread is pretty old now, I don't know if the issue still exists if you have the latest service packs or CUs applied. Once I put the changes in place, I haven't removed them from my task sequences.

    As an aside, I did discover that if you set these two policies and have an MDT-integrated task sequence that enables server roles on Windows Server 2012 R2, you have to remove the two registry keys before enabling features. Otherwise the script MDT uses to enable the features will fail.

    --Russel


    • Edited by Russel Riley Tuesday, June 9, 2015 4:25 AM Added note that the bug may be resolved in latest SP/CU
    Tuesday, June 9, 2015 4:23 AM
  • One question on the back of this:

    Do you have to run a 'Content Update' after you change the Deployment Type Detection Method?

    Thursday, June 18, 2015 3:05 AM
  • Don't worry, found that the answer if no, a content update doesn't have to be run for the change in detection method to be applied out
    Thursday, June 18, 2015 3:17 AM

  • So to mimic Group Policy you can set these two registry settings prior to your Install Application step and voila, powershell detection methods start working during OS Deployment.
    reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v EnableScripts /t REG_DWORD /d 1 /f
    reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v ExecutionPolicy /d RemoteSigned /f

    I hope this helps someone as much as it did me.


    +1 for me too.
    Monday, September 7, 2015 10:06 AM
  • There may be some solutions in this thread, but it seems unnecessarily complicated.  Try using a simple cmdlet and let it return results (successful detection), or fail with an error (not detected).  Or use a package model in OSD.

    Detection method for WMF 3.0 (powershell script)
    Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB2506143'"

    Detection method for RSAT for Windows 7 (powershell script)
    Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB958830'"

    Detection method for RSAT for Windows 8.1 (powershell script)
    Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB2693643'"


    Because of the Skype for Business multiple patches, how to modify this script to have KBxxxx OR KBxxxxx? OR KBxxxxx? Any idea?
    Thursday, January 14, 2016 6:15 AM