** Fixed ** Error: 0x800f081f 0x800f0907. The source files could not be found. Installing .Net Framework v3.5 on Windows Server 2012

Scroll down to the update for the fix, continue reading below for some background.

Today I thought I would write about the process of installing .Net Framework v3.5 on Windows Server 2012 when the server does not have an internet connection. This process caused me a lot of problems and I wasted a lot of time on it today. It seems many others are experiencing the same problem.

Windows Server 2012 requires that .Net Framework is enabled via as a feature rather than using the installation file method that we are used to in previous versions of Windows. For servers with an internet connection this works fine, and can be achieved in a number of ways (eg. Add roles and features wizard, PowerShell). My problems began when I started working on a server without internet access.

The official guide from Microsoft is here, and it all sounds simple enough. Doing this with the wizard displayed a warning before I started.

Selecting the Install option (as expected) caused the installation to fail:
"Installation of one or more roles, role services, or features failed.
The source files could not be found. Try installing the roles, role services, or features again in a new Add Roles and Features Wizard session, and on the Confirmation page of the wizard, click "Specify an alternate source path" to specify a valid location of the source files that are required for the installation. The location must be accessible by the computer account of the destination server"

I followed the advice in the error, and copied the .\sources\sxs folder from the installation DVD to a local folder, then selected that folder within the "Specify an alternate source path" option of the wizard.
This did not make any difference and the installation failed with the same error.

A few google searches led me to this article, which references KB3005628 as a fix for this problem. However, this fix corrects the problem when it was caused by the installation of security update 2966827 or 2966828.

Get-Hotfix | where { ($_.HotfixID -eq "KB296682" -or $_.HotfixID -eq "KB2966828") }

This PowerShell command will reveal whether or not these updates have been installed. In my case the server was not patched and so this was not the cause of the problem.

Various further google searches revealed many other users have similar issues, and I tried several other methods of installing .Net Framework v3.5, and all of them failed. Here are a few examples:

Dism /online /enable-feature /featurename:NetFX3 /all /Source:d:\sources\sxs

Dism /Online /Enable-Feature /FeatureName:NetFx3 /Source:X:\Sources\WinSXS /all /limitaccess

Install-WindowsFeature –Name NET-Framework-Features –Source D:\Sources\sxs

I also tried to enable the policy Specify settings for optional component installation and component repair.
This is located in Computer Configuration\Administrative Templates\System

I enabled the policy and enabled "Never attempt to download payload from Windows Update". This made no difference, and the installation still fails no matter how I attempt to install it.

 

** Update **

01 Feb 2016

Today I finally resolved this problem, below are the steps I had to take to get it working, hopefully this method can save someone some time. Note that this fix requires a Windows Server 2012 r2 machine on which the .Net 3.5 installation has been successful

First, follow the steps in this Microsoft support page. If these steps don't help, as was the case for me, try using my method.

Step 1
On a server where the installation fails, get a list of all folders in the WinSXS folder.

I used the following PowerShell command
Get-ChildItem -Path C:\Windows\WinSxS | select name | out-file D:\WinSXSfiles.txt

Then I copied WinSXSfiles.txt to a server where a previous installation had been successful.

Step2
Copy the list of folders to a (Windows 2012 r2) server where the installation has been successful. Compare this list to the contents of the WinSXS folder (on the successful server), and get a copy of all the folders that are missing on the server where the install fails.

I used the following PowerShell script:

#Get the folder contents of local WinSXS, select only the name, pass to foreach command
Get-ChildItem C:\Windows\WinSxS | select -ExpandProperty name | foreach {

#Foreach folder name, check whether it exists in the list of folders from the problem machine
if ( !(select-string -Path D:\WinSXSfiles.txt -Pattern $_) ) {

#Write any missing folder names to the console
Write-Host $_ -ForegroundColor Yellow

#Copy missing folders to a temporary folder D:\WinSXS
Copy-Item "C:\Windows\WinSxS\$_" -Destination D:\WinSXS\ -Recurse
}
}
 
Step 3
Copy the missing folders to the server where the installation fails

Step 4
Use Dism, with the Source option pointing at both WinSXS folders.

Dism /Online /Enable-Feature /FeatureName:NetFx3 /Source:C:\Windows\WinSXS /Source:D:\WinSXS /all /limitaccess

In my example I use 2 WinSXS folders. I didn't want to copy nearly 700 potentially unnecessary folders into the WinSXS folder on the C: drive. To get around this I created a temporary WinSXS folder (D:\WinSXS) and gave the DISM command a second /Source folder.

I found this page useful for explaining the DISM switches.

I had nearly 700 extra folders in WinSXS on my machine where the installation was successful. Looking through these I found a large number with names that started amd64_netfx

I expect that with some trial and error I could work out the exact folders that were necessary for the installation to be successful - probably some/all of those with names starting amd64_netfx.
However, to save time, my method of creating a temporary WinSXS folder works fine.