Visual Studio 2015 Enterprise Offline Installation Fails

Question

I'm attempting to evaluate Visual Studio 2015 Enterprise, but have encountered some trouble during installation. Here's what I did:

1. Download the complete installation by using the /layout switch.
2. Launch the installation with the /NoWeb switch.

I am using a clean Windows 8.1 virtual machine for this purpose, so as not to mess up my host system. The virtual machine is not connected to a network.

The installation fails with the following entries in the log:

MUX:  ExecuteError: Package (VSSecondaryInstaller_box) failed: Error Message Id: 1603 ErrorMessage: Visual Studio Extensibility Item Templates with Assembly References in Nuget Packages : This product did not download successfully: Unable to download 'http://go.microsoft.com/fwlink/?LinkId=558768'.  Web downloads are not allowed when the /NoWeb switch is used.
MUX:  ExecuteError: Package (VSSecondaryInstaller_box) failed: Error Message Id: 1603 ErrorMessage: GitHub Extension for Visual Studio : This product did not download successfully: Unable to download 'http://go.microsoft.com/fwlink/?LinkId=616986'.  Web downloads are not allowed when the /NoWeb switch is used.
MUX:  ExecuteError: Package (VSSecondaryInstaller_box) failed: Error Message Id: 1603 ErrorMessage: PowerShell Tools for Visual Studio : This product did not download successfully: Unable to download 'http://go.microsoft.com/fwlink/?LinkID=616995'.  Web downloads are not allowed when the /NoWeb switch is used.

I have noticed that these are the only VSIX packages in the installer. I could, of course, install these packages manually, but I want to understand the reason for this error.

Any ideas?

Answer 1

Intro

Well, a week later I have figured it out and I have a solution. Bear in mind that this is a bit hacky and may fail if and when Microsoft decides to update their installer.

But first, we have to understand the source of the problem.

The Problem

As I mentioned in the question, the installation log states that it failed to download the VSIX packages because of the /noweb switch. A reasonable question at this point is why was the installer trying to download them in the first place.

To answer that, we have to look in the Secondary Installer log (dd_vs_enterprise_<timestamp>_SecondaryInstaller_UX.log, inside the %temp% directory). As I understand it, the Secondary Installer is responsible for installing all of the extra packages that come with Visual Studio. This log clarifies the picture a little.

DownloadManager Information: 0 : Using cached file at C:\ProgramData\Microsoft\VisualStudioSecondaryInstaller\14.0\installers\VS_Extensibility_TemplatesV1\en\0\Microsoft.Vsix.TemplatesPackage.vsix instead of downloading from http://go.microsoft.com/fwlink/?LinkId=558768
DownloadManager Error: 0 : Signature verification failed on downloaded file. URL: http://go.microsoft.com/fwlink/?LinkId=558768. File location: C:\ProgramData\Microsoft\VisualStudioSecondaryInstaller\14.0\installers\VS_Extensibility_TemplatesV1\en\0\Microsoft.Vsix.TemplatesPackage.vsix. File size: 3965 kb
DownloadManager Error: 0 : BITS download failed. Exception: System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Web.PlatformInstaller.InstallManager.BITSDownloadInstallerFile(InstallerContext currentInstall, String& failureReason, String& failureErrorCode, Boolean& downloadNotAllowed, Boolean setFinalReturnState)
DownloadManager Warning: 0 : BITS failure: BITS download failed. BITS service may have been disabled on the machine.. Retrying download for 'Visual Studio Extensibility Item Templates with Assembly References in Nuget Packages'
DownloadManager Warning: 0 : WinInet failure: Unable to download 'http://go.microsoft.com/fwlink/?LinkId=558768'.  Web downloads are not allowed when the /NoWeb switch is used.. Retrying download for 'Visual Studio Extensibility Item Templates with Assembly References in Nuget Packages'
DownloadManager Information: 0 : WebClient downloading file 'http://go.microsoft.com/fwlink/?LinkId=558768' to: C:\Users\John Gallegos\AppData\Local\Temp\evlyeg3i.fmr
DownloadManager Error: 0 : WebClient error while downloading file 'http://go.microsoft.com/fwlink/?LinkId=558768'. Exception: System.Net.WebException: The remote name could not be resolved: 'go.microsoft.com'
   at System.Net.WebClient.OpenRead(Uri address)
   at Microsoft.Web.PlatformInstaller.InstallManager.WebClientDownloadInstallerFile(InstallerContext currentInstall, String& errorMessage, Boolean setFinalReturnState)
DownloadManager Warning: 0 : WebClient failure: The remote name could not be resolved: 'go.microsoft.com'. Retrying download for 'Visual Studio Extensibility Item Templates with Assembly References in Nuget Packages'
DownloadManager Warning: 0 : WinInet failure: Unable to download 'http://go.microsoft.com/fwlink/?LinkId=558768'.  Web downloads are not allowed when the /NoWeb switch is used.. Retrying download for 'Visual Studio Extensibility Item Templates with Assembly References in Nuget Packages'
DownloadManager Error: 0 : BITS failure: Unable to download 'http://go.microsoft.com/fwlink/?LinkId=558768'.  Web downloads are not allowed when the /NoWeb switch is used.. Download failure for Visual Studio Extensibility Item Templates with Assembly References in Nuget Packages.

That's more like it! Now we know the real reason for the failure is signature verification on the VSIXs! We can now reconstruct the chain of events:

1. The installer tries to verify the signature on the VSIXs, and fails.
2. The installer goes on to download the VSIX packages from the Internet. The rationale here is probably that the signature verification failed because the cached VSIX is corrupt, so downloading it again is the only solution.
3. The installer, of course, fails again because we disallowed all downloads.

But the funny thing is that on a machine that is connected to the Internet, this does not happen at all! Even when the /noweb switch is specified!

In Search of Answers

Why does the installation succeed on a networked machine, even when all downloads are disallowed? It would appear that the trust verification component of the operating system goes to the Internet when it fails to verify trust using the certificates it has available locally.

Microsoft has a knowledge-base article about VS 2015's known issues and fixed bugs (right here), that seems to support my theory. Here's what the article says:

If you do not set the Windows Update option to automatically update the root certificates, and you choose to install optional components, you receive the following Visual Studio setup warning at the end of the process:

PowerShell Tools for Visual Studio: This product did not download successfully: Signature verification failed on downloaded file.

If the automatic update is turned off, your computer will not have the latest root certificates. Therefore, Visual Studio setup will not recognize the certificates that are used to sign the VSIX files as valid certificates and will not install the components.

At first, I thought I found what I was looking for. All we have to do is obtain the right certificates, and be done with it! But how do you do it?

A diff of the installed certificates (using certmgr.msc) before and after a successful VS 2015 installation on a networked machine supplied several certificates that seemed to be responsible for my troubles. However, installing them manually on a disconnected machine yielded no results. You can see my question on the subject, however it has no bearing on the installation: the same thing happened when I tries installing on Windows 10.

Maybe the problem is wider? In the past, Microsoft supplied root certificate update packages (rootsupd.exe) that could be installed on offline machines. Although the latest package can be installed even on Windows 8.1, it does not include the certificates I knew were required. And so, I went looking for alternative ways of installing certificate updates on disconnected machines.

Microsoft describes the recommended way of doing so, in this TechNet article. Because I do not have a Windows Server machine, I tried applying the required registry changes manually, but to no avail.

The Visual Studio forums did not provide much help, either.

But, in a moment of sudden clarity, I thought to myself: What if I can avoid the problem altogether? What if instead of trying to get the certificates on the VSIXs to validate, I could replace those certificates with my own? After all, I'm in a disconnected environment, and therefore trust is not an issue.

The Solution

Signing VSIX packages is possible using vsixsigntool.exe, available here. Luckily, it is possible to feed an already-signed VSIX to this utility, and it will replace the embedded certificate with the one you specify. Piece o'cake!

Well, not exactly. There are two problems with this approach:

1. The certificate's subject must be CN = Microsoft Corporation. Why? The installer uses a special XML "feed" that describes the different components it has available (look in the OfflineCache\feeds directory). When installing a VSIX package, it verifies that the embedded certificate's subject matches the subject specified in the XML feed. The XML feed is signed as well, so fun is all around.
2. A special file, cache.bin, provides the installer with the information required to find the cached version of a package (see, for instance, OfflineCache\installers\VS_Extensibility_TemplatesV1\cache.bin). Problem is, the file contains the SHA256 hash of the package. The file is really just a serialized .NET object, but we cannot deserialize it without access to the assemblies that contain the class of the serialized object, and the classes of its members. Besides, this is not how real programmers do it! The hash is stored as a simple ASCII string, so it's just a matter of search & replace.

That's it! Using this method we can re-sign all the VSIX packages, import the certificate used to the Trusted Root Certification Authorities store, and Bob's your uncle.

The Code

I wrote a script that performs all the operations I described above. It is available here. Have fun!

Answer 2

This issue happens because the machine needs to have the updated certificate revocation lists for each of the certificates used by these files. If the latest CRL is not installed, it needs to use the internet to check for it.

With the release of Update 2, Microsoft updated the Secondary Installer from Visual Studio not to check the certificate revocation list for VSIX extensions if the machine is offline. This fixes the issue described in this topic.

They also recently released an article with instructions for an offline installation at https://msdn.microsoft.com/en-us/library/mt706497.aspx. The section "Troubleshooting an offline installation" contains information that would help you resolving the offline installation issues by using a special feed when creating the layout.