Deploying .NET Framework 4.5.2 as a ConfigMgr Application

Deploying .NET Framework 4.5.2 as a Package/Program has always been a possibility, and now it can even be deployed with Software Update Management as a feature pack. But, since the .NET Framework’s only purpose is to support other applications, it makes a lot of sense to be able to deploy it using the Application Model in Configuration Manager. This means the .NET Framework can be defined as a prerequisite for another application. Having .NET Framework 4.5.2 ready to go as an application means any requirement can be covered .NET Framework 4 or above.

Installer
The offline installer can be downloaded here from Microsoft.

Issues
The installer from Microsoft (NDP452-KB2901907-x86-x64-AllOS-ENU.exe) for .NET Framework 4.5.2 suffers from the same issues previous versions exhibited during operating system deployment. In general, the setup will fail because the wrapper cannot successfully decompress the installation files. A generic 0x80004005 task sequence error will come up—and upon closer inspection, the following errors in the “C:WindowsTempdd_NDP452-KB2901907-x86-x64-AllOS-ENU_decompression_log.txt” file:

[2/15/2015, 11:31:14] Error 0x80004005: Failed to extract all files out of box container #0.
[2/15/2015, 11:31:14] Error 0x80004005: Failed to extract
[2/15/2015, 11:31:14] Exiting with result code: 0x80004005

Install Program for Organizations With Only 64-bit Operating System Architectures
For those organizations that do not have any 32-bit operating systems (good job!), the default installer can be used successfully, but it’s necessary to force the install program out of the native environment and use Windows on Windows.

In this case, a simple command line can silently install the product and keep a log file, for example

NDP452-KB2901907-x86-x64-AllOS-ENU.exe /q /norestart /log “C:windowstempnetframework.log”

Then ensure the “Run installation and uninstall program as 32-bit process on 64-bit clients” box is checked. Checking this box will work around the extraction errors.

Microsoft .NET Framework 4.5.2 Properties

Install Program for Organizations With Both 64-bit and 32-bit Operating System Architectures
Unfortunately, the above workaround is only applicable for 64-bit devices. To handle both 32-bit and 64-bit operating systems, the files need to be extracted to remove the broken installer from the equation.

Silently extract the files as such:

NDP452-KB2901907-x86-x64-AllOS-ENU.exe /q /extract:”\cmsourceMicrosoft .NET Framework 4.5extract”
(Substitute a path to the content source location.)

The 64MB installer from Microsoft extracts to over 1.6GB. If that is too large (especially for devices without a local distribution point), create a self-extracting archive with 7-Zip to get things back to a reasonable size. Not only will this reduce the size again, but it will also reduce the overhead and time that comes with trying to download and hash check hundreds of files (think AudoDesk).

Go into the folder from which the files were extracted, select all the content, right click, and select 7-Zip > Add to archive…

To create a self-extracting archive, perform the following steps:

  1. Name the Archive “Microsoft .NET Framework 4.5.exe”
  2. Select an Archive format of “7z”
  3. Select the Compression level to “Ultra”
  4. Select the Option “Create SFX archive”

Self-extract archive .NET Framework 4.5

The resulting .exe file should get it back down to about 280 MB which is still big but much more reasonable. In this example, the folder, “\cmsourceMicrosoft .NET Framework 4.5sfx“, is used as the content source for the deployment type, so the self-extracting archive .exe. can be moved there.

Then, create a batch file which will extract the files, do the install, and then remove the extracted files. This should do the trick:

load_netframework_sfx.cmd

@ECHO OFF
CLS
REM Installs the .NET Framework after extracting the files.

:paths
SET loc=%~dp0

:unzip
REM Run the 7zip self-extracting archive so we get our install files…
“%loc%Microsoft .NET Framework 4.5.exe” -o”c:windowstempnetfw” -y

:install
REM Silently install the .NET Framework…
IF DEFINED ProgramFiles(x86) (
REM Install for 64-bit systems…
“C:windowstempnetfwsetup.exe” /q /norestart /ChainingPackage “ADMINDEPLOYMENT” /log    “C:windowstempnetframework.log” /x64
) ELSE (
REM Install for 32-bit systems…
“C:windowstempnetfwsetup.exe” /q /norestart /ChainingPackage “ADMINDEPLOYMENT” /log    “C:windowstempnetframework.log” /x86
)
SET returncode=%errorlevel%

:delete
REM Clean up the extracted files…
RMDIR /S /Q “C:WindowsTempnetfw”

:end
REM Exit the batch file with whatever the .NET Framework installer returned for an error code…
EXIT /b %returncode%

Create Deployment Type Wizard - Now Micro

Detection Method
Regardless of which install method used, Microsoft prescribes a method for determining which versions of the .NET Framework are installed on a device.

Since future versions within the .NET 4.0 branch will be backwards compatible, don’t worry about downgrading users to an older version. If in six months someone has .NET Framework 4.6 installed, that will satisfy the prerequisite, so simply let the detection rule succeed.

For the detection method, check that the HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4Full key has a Release value greater than or equal to 379893 to show the .NET Framework 4.5.2 or above installed.

.NET Framework Detection Method - Now Micro

Requirement Rules
It’s recommended to not specify any requirements for using this one deployment type unless Windows XP is in the environment. It is ideal for later operating systems to at least leverage the detection method of this application’s deployment type to show at least .NET Framework 4.5.2 installed to handle the prerequisite scenario. This means that if Windows 10 comes out and has .NET Framework 4.6 installed, any “pre-reqs” of .NET Framework 4.5.2 should evaluate and be ok having the later version within the .NET 4 branch installed.

The conclusion should be an application for installing the .NET Framework 4.5.2 which works on both x86 and x64 devices in and out of task sequences.