I mentioned last time that any version of the .NET Framework beginning with ‘4’ is an in-place upgrade for any similar version with a lower minor version number. Applications that depend on .NET 4.0 as a minimum should run fine on any subsequent 4.x version. We need something to use as a prerequisite for such applications. Rather than force every computer in an organization to move up to the latest version, it would be more efficient to just use whatever version of .NET is included in the operating system. Note, though, that the .NET Framework feature can be turned off in some versions of Windows, so we do need an application package to ensure that it is turned on. With this in mind, let us build a new Configuration Manager Application.
Acquiring the Installation Files
We actually have everything we need already. All supported versions of Windows except for Windows 7 and Windows Server 2008 R2 have some 4.x version of .NET built in, and we can reuse our .NET 4.6.1 installer from last time to take care of the exceptions.
On your application staging file share (wherever you put application source files for Configuration Manager to find), create a folder for .NET 4.x. Mine will be \\fileserver\software$\Microsoft\.NET Framework 4.x. We don’t actually need any source files, and so as with .NET 3.5 on Windows 7 and .NET 4.6.1 on Windows 10 November Update, we will just provide Configuration Manager with a single file in that folder. I created a text file with Notepad in the folder containing the following text:
The following Microsoft .NET Framework 4.x versions are included as operating system compoments in the corresponding Windows versions, and so no content is required or available to install them on those versions. -Windows 8/Windows Server 2012 .NET Framework 4.5 -Windows 8.1/Windows Server 2012 R2 .NET Framework 4.5.1 -Windows 10 .NET Framework 4.6 Configuration Manager applications require a content folder, so this folder serves that role for the "Microsoft .NET Framework 4.x [Deploy as prerequisite only]" application's deployment types for these Windows versions.
That explains the presence of the otherwise empty folder to anyone reviewing this folder structure.
For Windows 7 and Windows Server 2008 R2, we will just install the latest version of .NET (4.6.1 at the time of this writing) in order to satisfy the requirement unless a lower 4.x version is detected.
Building the Configuration Manager Application
Windows 7 and Windows Server 2008 R2 (64-bit and 32-bit)
In the Configuration Manager Console, create a new Application. We are going to reuse the source folder and settings from our .NET 4.6.1 application package for our first deployment type. Here are the values I provided in mine:
|Name||Microsoft .NET Framework 4.x [Deploy as prerequisite only]|
|Deployment Type Properties|
|Name||Microsoft .NET Framework 4.6.1 – Windows 7 and Windows Server 2008 R2 (64-bit and 32-bit)|
|Content location||\\fileserver\software$\Microsoft\.NET Framework 4.6.1\PreWin10v1511\|
|Uninstall program||None (leave blank)|
|Detection method||Rule 1:
Hive/Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
Data type: Integer
|Installation behavior||Installation behavior: Install for system
Logon requirement: Whether or not a user is logged on
Installation program visibility: Hidden
Configuration Manager behavior: Determine behavior based on return codes
One of Windows 7 SP1 (64-bit), Windows 7 SP1 (32-bit), Windows 2008 R2 SP1 (64-bit)
|Return Codes||0||Success (no reboot)||Installation completed successfully.|
|1602||Failure (no reboot)||The user canceled installation.|
|1603||Failure (no reboot)||A fatal error occurred during installation.|
|1641||Hard reboot||A restart is required to complete the installation. This message indicates success.|
|3010||Soft reboot||A restart is required to complete the installation. This message indicates success.|
|5100||Failure (no reboot)||The user’s computer does not meet system requirements.|
I included the suffix “[Deploy as prerequisite only]” in the name of the package because it doesn’t make sense to show this package to users. If a user opens Software Center, he/she should see normal applications that can be installed, not supporting libraries with ambiguous names. Don’t deploy this Application on its own; just set it as a prerequisite for other Applications that need it. The bracketed text serves as a reminder of this principle.
Speaking of principles, I violated one of my own rules: There is no uninstallation program. This is acceptable because again, this is a prerequisite application, and also because this application package just ensures that an on-by-default feature is still turned on, on most systems. If you want users to be able to uninstall this application from Software Center in Windows 7, deploy the .NET 4.6.1 package we built last time as “available”, and it will be detected as already installed when this application is installed. Then the user can choose to uninstall it.
Finally, notice the detection logic. We don’t actually test for version 4.6.1; we merely test that some version of .NET 4.x has been installed. If the user has previously installed .NET 4.0, 4.5, 4.5.1, 4.5.2, 4.6, or 4.6.1, these will all signify that this application is already installed. Only if none of these is installed will .NET 4.6.1 be installed by Configuration Manager.
All Other Platforms
All of the other operating systems we are targeting can be satisfied by a single deployment type that merely turns on their built-in NetFx4 feature if it is turned off.
|Deployment Type Properties
|Name||Feature Installation – Windows 8, Server 2012, 8.1, Server 2012 R2, and 10 (64-bit and 32-bit)|
|Content location||\\fileserver\software$\Microsoft\.NET Framework 4.x\|
|Uninstall program||None (leave blank)|
|Detection method||Same rule as Windows 7 and Windows Server 2008 R2 deployment type|
|Installation behavior||Same settings as Windows 7 and Windows Server 2008 R2 deployment type|
One of All Windows 8 (64-bit), All Windows 8 (32-bit), All Windows Server 2012 (64-bit), All Windows 8.1 (64-bit), All Windows 8.1 (32-bit), All Windows Server 2012 R2 (64-bit), All Windows 10 Professional/Enterprise and higher (64-bit), All Windows 10 Professional/Enterprise and higher (32-bit)
|Return codes||Leave defaults|
Here we use a Dism command to turn on the NetFx4 feature. This feature name refers to whichever 4.x version is built into the target platform, or, if it has already been upgraded, it turns on the upgraded replacement version. For example, Windows 8 includes .NET 4.5 as an OS feature, so turning on NetFx4 enables .NET 4.5 functionality. If .NET 4.5.2, for instance, has already been installed on Windows 8 and then disabled, turning on NetFx4 enables .NET 4.5.2 functionality.
Notice that we didn’t have to worry too much about Server Core in this application package. For the Windows 7/Server 2008 R2 deployment type, we just omit Server Core from the requirements as we did with the .NET 4.6.1 Application. For the other deployment type, since we are enabling an already-installed feature rather than running Microsoft’s buggy .NET 4.6.1 installer, there is nothing to worry about here regarding Server Core. The application package we just build will run fine on all supported platforms except a Server Core installation of Windows Server 2008 R2.
That wraps up our three-week focus on .NET Framework installation. Next time, we’ll build one more Global Condition to check a prerequisite, and then we’ll move on to the home stretch of building a robust Microsoft Office 2016 Application in Configuration Manager.