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:

Download the complete installation by using the /layout switch.
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?

Just a note: Same issue happened while installing Visual Studio 2017 offline installation, but the offline cache also has the required certificates in the `certificates` folder. Just import them and restart the installation and all is fine. — Vijay, Mar 09 '17 at 04:14

score 9 · Accepted Answer · answered Sep 23 '15 at 18:41

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:

The installer tries to verify the signature on the VSIXs, and fails.
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.
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:

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.
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!

score 2 · Answer 2 · answered May 06 '16 at 16:42

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.

This helped me resolve this issue, but I had to download the feed separately, copy it to local, then reference the feed.xml using a conventional path, (like c:\blah\feed.xml). Together with the updated certificate revocation lists, the offline installer worked normally. — Paully, Jun 28 '16 at 15:43

AdamantineWolverine · Answer 3 · 2017-04-10T03:02:50.703

Mr. Anderson Cassimiro's answer provided me with some great clues on how to resolve the issue for my offline install which was caused by Certificate Validation Errors.

SUMMARY: Basically, I had to get a copy of the latest Certificate Revocation Lists and install them on my offline system:

http://crl.microsoft.com/pki/crl/products/MicCodSigPCA_08-31-2010.crl

http://www.microsoft.com/pkiops/crl/MicCodSigPCA2011_2011-07-08.crl

http://crl.microsoft.com/pki/crl/products/MicrosoftTimeStampPCA.crl

http://crl.microsoft.com/pki/crl/products/MicTimStaPCA_2010-07-01.crl

http://crl.microsoft.com/pki/crl/products/CSPCA.crl

http://crl.microsoft.com/pki/crl/products/tspca.crl

http://crl.comodoca.com/COMODOCodeSigningCA2.crl

http://crl.comodoca.com/COMODORSACodeSigningCA.crl

http://crl.usertrust.com/UTN-USERFirst-Object.crl

http://crl.microsoft.com/pki/crl/products/MicCodSigPCA_2010-07-06.crl

http://ts-crl.ws.symantec.com/tss-ca-g2.crl

There were two packages that I couldn't get the certificate to validate regardless of CRLs installed:

sqlcmdlnutils_amd64\SqlCmdLnUtils.msi

DotFuscator

You can install these after installing VS 2012 by going directly to the packages folders for these tools and installing them.

CRLs are probably good for 24 hours or whatever your CRL cache timeout is set to. So, if you need to install on a different system a few days later, you will have to download and install the latest CRLs on the other system.

I wrote out the longer troubleshooting steps I took below.

Symptoms: Visual Studio installer indicates that it failed to install one or more packages and asks that you specify the location of the package executable. You specify the location in packages directory of the installation media, but it prompts you again.

STEP 1: Determining if it is a certificate issue

You can right click on the Visual Studio executable and Click Properties. Under the Digital Signatures tab, select one of the signatures and click Details.

Under Digital Signature information, if it doesn't say "This digital signature is OK." Then, it's probably a signature issue.

Also, you can check in your c:\Users[username]\AppData\Local\Temp directory for a file called dd_vs_professiona_[Timestamp].log, and note that there are certificate validation errors in the log.

STEP 2: Fixing the Certificate Issues

a. If the error indicates the certificate is not trusted:

Ensure that all the certificates from the digital signature are trusted.

1) Launch the Certificates MMC for your local computer by:
  -Open command prompt as admin and type mmc and enter.
  -File -> Add Remove SnapIn
  -Select Certificates and click add
  -Select Computer Account and click Next.  
  -Select Local Computer and click Finish.

2) Go back to the Visual Studio executable dialogs.

Click on the Visual Studio executable and Click Properties. Under the Digital Signatures tab, select one of the signatures and click Details.

Click View Certificate. Click the Certification Path Tab.

3) If there is a certificate that is not trusted in the certificate path, click it, and View Certificate. Click Details and Click Copy to File. Save the certificate to a location you can find easily.

4) Go back to the Certificates MMC. Navigate to Trusted Root Certificates. Right Click -> All Tasks -> Import

5) Import the certificate you just saved to file.

You must do this for all certificates in the certificate path.

b. If the error indicates it is unable to validate the CRL.

Click on the Visual Studio executable and Click Properties. Under the Digital Signatures tab, select one of the signatures and click Details.

1. Click View Certificate
2. Under Details Tab -> Click CRL Distribution Points
3. Download the crl from the URL specified in the CRL Distribution Points.
4. Copy the file to your offline system.
5. Right click on it and Click Install CRL, Next, Next, Finish.

See the summary section above for a list of CRLs I had to download.

c. If the error indicates "One of the countersignatures is not valid. The file may have been altered.", then:

Click on the Visual Studio executable and Click Properties. Click Digital Signatures. Click on a signature and click Details.

Instead of clicking View Certificate of the Digital signature, click on the Timestamp under the Counter Signatures section.

-Click Details, then click View Certificate for the time stamp cert -Click CRL Distribution Points in the Details tab

-Download the timestamp crl. -Copy it to your offline system and right click the crl file and install crl, Next, Next, Finish.