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

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.

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. Tip 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

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. Tip 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

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

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?

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.

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 VBS

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

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

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

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 01, 2013 3:19 PM

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 01, 2013 3:19 PM

• Edited by yannara Monday, April 01, 2013 3:20 PM

• Edited by yannara Monday, April 01, 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

• Proposed as answer by Emil_78 Thursday, September 26, 2013 12:21 PM

• Proposed as answer by Emil_78 Thursday, September 26, 2013 12:21 PM

In 50% cases, installation of WMF fails 0x8004005 as application, I had enough of this, so I just mounted it to wim with DISM :)

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.

Were 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 hasnt 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

Were 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 hasnt 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

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

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.

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'"

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 3 hours 23 minutes ago Added note that the bug may be resolved in latest SP/CU

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 09, 2015 4:25 AM Added note that the bug may be resolved in latest SP/CU

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 09, 2015 4:25 AM Added note that the bug may be resolved in latest SP/CU

One question on the back of this:

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

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.