Late in 2014, I ran into a problem installing Microsoft .NET Framework 3.5 on Windows 8.1 Enterprise with Update (x64) through an SCCM 2012 R2 Build and Capture task sequence.

I was following Microsoft’s instructions at Installing the .NET Framework 3.5 on Windows 8 or 8.1 to first copy the sources\sxs directory from the Windows 8.1 ISO to the C: drive of the reference computer via a package and then enable .NET Framework 3.5 by using the Deployment Image Servicing and Management (DISM) command-line:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\DVD\sources\sxs

This process had worked in the past to successfully enable .NET Framework 3.5 during the Build and Capture task sequence, but when I ran the same Build and Capture task sequence a few months later, the Run Command Line step that executes the DISM command failed. The package that copied the sources\sxs directory was still able to successfully copy the files, but according to the logs, the DISM command couldn’t find files that it needed.

The DISM.log file contained some really unexpected entries, like:

Encountered an unknown option "featurename" with value "NetFx3"
Encountered an unknown option "source" with value "C:\DVD\sources\sxs"

I was using the command line exactly as specified by Microsoft, albeit with a different path to the source files. How could DISM not know the FeatureName and Source options?

When the task sequence failed, the following entries were written to smsts.log:

ProgramName = 'DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\DVD\sources\sxs'	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
SwdAction = '0001'	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Set command line: Run command line	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Working dir 'not set'	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Executing command line: Run command line	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Process completed with exit code 2148468767	InstallSoftware	10/29/2014 10:17:18 AM	1976 (0x07B8)
Command line returned 2148468767	InstallSoftware	10/29/2014 10:17:18 AM	1976 (0x07B8)
Process completed with exit code 2148468767	TSManager	10/29/2014 10:17:18 AM	2804 (0x0AF4)
!--------------------------------------------------------------------------------------------!	TSManager	10/29/2014 10:17:18 AM	2804 (0x0AF4)
Failed to run the action: Install .NET Framework 3.5 (from \sources\sxs\). 
Unknown error (Error: 800F081F; Source: Unknown)	TSManager	10/29/2014 10:17:18 AM	2804 (0x0AF4)

I also found the following errors in DISM.log:

2014-10-29 10:17:17, Info                  DISM   DISM Package Manager: PID=2600 TID=2084  Error in operation: source for package or file not found, ResolveSource() unsuccessful. (CBS HRESULT=0x800f081f) - CCbsConUIHandler::Error
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed finalizing changes. - CDISMPackageManager::Internal_Finalize(hr:0x800f081f)
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 The source files could not be found; their location must be specified using the /source option to restore the feature. - GetCbsErrorMsg
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed processing package changes with session options - CDISMPackageManager::ProcessChangesWithOptions(hr:0x800f081f)
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed ProcessChanges. - CPackageManagerCLIHandler::Private_ProcessFeatureChange(hr:0x800f081f)
2014-10-29 10:17:18, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed while processing command enable-feature. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f081f)

I had not changed the sources\sxs package in this time. The only change that I made between the command working a few months earlier and it now failing was to apply Software Updates to the Windows 8.1 install.wim file using offline servicing, but it didn’t occur to me that this would cause the problem.

Some Googling turned up an informative post at http://www.aidanfinn.com/?p=13351, where two Microsoft hotfixes, KB2966826 and KB2966828, were identified as the cause of the DISM failures.

KB2966826 MS14-046: Description of the security update for the .NET Framework 3.5 in Windows 8.1 and Windows Server 2012 R2: August 12, 2014

KB2966828 MS14-046: Description of the security update for the .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2: August 12, 2014

Because there seems to not be a built-in method within SCCM of removing software updates from an image file (although it can be done through DISM), I chose to start from the beginning:

1. generate a new operating system image from the install.wim file in the Windows 8.1 ISO
2. schedule offline updates to patch the install.wim file, but uncheck the boxes for those two hotfixes
3. install .NET Framework 3.5 by running the install.wim file through a Build and Capture task sequence (putting the Install Software Updates step after the .NET Framework 3.5 installation)

I ran my Build and Capture task sequence using the new WIM that did not have KB2966826 or KB2966828 installed, and .NET Framework 3.5 installed successfully.

Because the KB2966826 and KB2966828 hotfixes are still available to the reference computer during the Build and Capture task sequence, they are installed through a typical Install Software Updates step that occurs after the .NET Framework 3.5 steps. The resulting WIM is fully patched and ready for use in an OSD task sequence.

Note that there is now a KB article addressing this problem, and a hotfix to remove the hotfixes from systems where they are not required: Update for the .NET Framework 3.5 on Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. However, I still follow the steps above to build my reference computers.

It may be helpful to check the registry to determine which versions of .NET Framework are installed. I have found two Microsoft articles dealing with this issue. The first, How to determine which versions and service pack levels of the Microsoft .NET Framework are installed, does not identify registry values for versions 4.5.1 or 4.5.2. The second, How to: Determine Which .NET Framework Versions Are Installed, identifies registry values for determining which version of .NET Framework 4.5 and later is installed, and offers a different method of determining the version(s) of .NET Framework 1 – 4.