This blog post describes how to enable .NET Framework 3.5 on Windows 8.1 after the computers already have been deployed.This can be quite annoying because the SXS source folder is needed when installing + this bug (https://support.microsoft.com/en-us/kb/3005628) can also kick in.
The installation is done using an SCCM application containing an installation powershell script and powershell detection method. An easier alternative is using a package and task sequence to run the powershell script (no detection method needed here). Using the application has the advantage that it can be used as dependency and requirements can be added.
The installation script contains different phases
- Downloading the source to a local folder in C:\windows\temp\NetFX3
- This folder contains the installation powershell script and the SXS folder from the Windows 8.1 PRO ISO
- Installing KB2966828 (to avoid the bug)
- Enable .NET Framework using the downloaded SXS folder as source
- Detect if .NET Framework was installed successfully
- Delete temp folder C:\windows\temp\NetFX3
First of all a little thing about using Powershell as an Application Detection Method
The main purpose is to make sure the detection method exits with exit code = 0 (no errors during the script) + Depending on the value of STDOUT (Write-Output) the detection method will return that the application is installed or not installed.
|Script exit code
||Data read from STDOUT
||Data read from STDERR
||Application detection state
Additional details: http://blog.kloud.com.au/2014/08/12/powershell-detection-method-for-sccm-2012-application-compliance-management/
Now we’ll try to apply this to the .NET Framework 3.5 feature we want to get installed here, the script I use is this:
$Framework = Get-windowsoptionalfeature -FeatureName NetFx3 -Online | Select-Object -ExpandProperty State
if ($Framework -eq “Disabled”)
Write-Host “.NET Enabled”
This script is quite easy to understand and does the following
- If .NET is not installed (disabled): exit script with exit code 0 –> Detection method sees this as “Application Not Installed”:
- Exit code = 0
- STDOUT (Write-Host) = Empty
- If .NET is installed (enabled): exit script with exit code 0 –> Detection method sees this as “Application Installed”:
- Exit code = 0
- STDOUT (Write-Host) = Not Empty
Now let’s start adding this into SCCM: Create an Application and give it a suitable name. When creating a Deployment type give in the path to the source and the commandline. This is the commandline I used: “Powershell.exe -executionpolicy Bypass -file .\install.ps1” (without quotes)
When prompted for the detection method, select “Use a custom script to detect the presence of this deployment type and Click Edit, Select powershell and copy the detection method script in here
Finish creating the deployment type adding needed requirements (here I have added Operating System = Windows 8.1 x64)
After the application is created, update distribution points, deploy it to a test machine and see the result
Using the “Retrieve Machine Policy” on the test client we should rapidly see the new deployment, but this didn’t happen. I went to look into the ConfigMgr Client logs and found something interesting in the AppDiscovery.log
The Detection method couldn’t be run because it was not signed “CScriptHandler::DiscoverApp failed (0x87d00327).” I stumbled upon this post by someone who experienced the same error http://www.petervanderwoude.nl/post/deployment-of-configuration-baseline-failed-with-error-script-is-not-signed-in-configmgr-2012/. So I did what he highlighted: Enabling the Powershell Bypass option for the ConfigMgr Client.
A next test should result in the application being successfully added in the Software Center doesn’t it? Yes, it’s there but it says “Installed” while the .NET Framework wasn’t installed . Let’s go back to the AppDiscovery.log. Now no errors were listed but only warnings stating the script returned some error message (The application is detected as shown in the log “Detected App Deployment Type…”, but the application is not installed)
This one was tackled by disabling by unchecking “Run script as 32-bit process on 64-bit clients” on the detection method
After this little adjustment and another try everything looked good. The application was listed as “Available” in Software Center and the AppDiscovery.log showed the following: The App Deployment type was not detected.
Great! Hope this helps in helping you guys out!