Failed to install standalone installation of Visual Studio 2015 Enterprise

Question

I am trying to evaluate Visual Studio 2015 Enterprise, but encountered some problems during installation. Here is what I did:

• Download the full installation using the /layout switch.
• Start the installation using the /NoWeb .

For this purpose, I use a clean Windows 8.1 virtual machine, so as not to spoil my host system. The virtual machine is not connected to the network.

The installation failed using the following log entries:

 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 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 cause of this error.

Any ideas?

Answer 1

Introduction

Well, a week later I realized this, and I have a solution. Keep in mind that this is a bit hacked and may fail if and when Microsoft decides to update its installer.

But first we need to understand the source of the problem.

Problem

As I mentioned in the question, the installation log indicates that he was unable to download VSIX packages due to the /noweb switch. A reasonable question for now is why the installer tried to download them in the first place.

To answer this, we need to look in the secondary installer dd_vs_enterprise_<timestamp>_SecondaryInstaller_UX.log ( dd_vs_enterprise_<timestamp>_SecondaryInstaller_UX.log , inside the %temp% directory). As far as I understand, Secondary Installer is responsible for installing all the additional packages that come with Visual Studio. This magazine clarifies the picture a bit.

 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. 

I like it more! Now we know that the reason for the rejection is signature verification on VSIX! Now we can restore the chain of events:

• The installer tries to verify the signature on VSIX and does not work.
• The installer continues to download VSIX packages from the Internet. The rationale here is probably that the signature verification failed because the cached VSIX is corrupted, so downloading it again is the only solution.
• The installer, of course, does not work again, because we have disabled all downloads.

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

Looking for answers

Why is installation performed on a network machine, even if all downloads are prohibited? It seems that the operating system trust verification component is sent to the Internet when it fails to verify the trust using the certificates available to it.

Microsoft has a knowledge base article on VS 2015 known issues and bug fixes (right here ) that seems to support my theory. This is what the article says:

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

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

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

At first, I thought I found what I was looking for. All we need to do is get the right certificates and do it! But how do you do that?

The difference in the installed certificates (using certmgr.msc ) before and after the successful installation of VS 2015 on the network machine provided several certificates that seemed to be responsible for my problems. However, installing them manually on a disconnected machine did not produce any results. You can see my question on this, however, it has nothing to do with the installation: the same thing happened when I try to install on Windows 10.

Maybe the problem is wider? Microsoft used to provide root certificate update packages ( rootsupd.exe ) that could be installed on standalone machines. Although the latter package can even be installed on Windows 8.1, it does not include the certificates that I knew were necessary. So, I went looking for alternative ways to install certificate updates on disconnected machines.

Microsoft describes the recommended way to do this in this TechNet article. Since I do not have a Windows Server machine, I tried to apply the necessary registry changes manually, but to no avail.

Visual Studio forums also did not help.

But, at the moment of sudden clarity, I thought to myself: “What if I can avoid the problem at all? What if, instead of trying to verify the certificates on VSIX, can I replace these certificates with my own? In the end, I'm disabled environment, so trust is not a problem.

Decision

VSIX package signing is possible with vsixsigntool.exe , available here . Fortunately, you can connect an already signed VSIX to this utility, and it will replace the built-in certificate with the one you specified. Piece o'cake!

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

• The subject of the certificate must be CN = Microsoft Corporation . What for? The installer uses a special XML channel that describes the various components available to it (see the OfflineCache\feeds directory). When installing the VSIX package, it verifies that the embedded certificate object matches the entity specified in the XML feed. In addition, an XML feed has been signed, so it's fun all around.
• A special cache.bin file provides the installer with the information necessary to find the cached version of the package (see, for example, OfflineCache\installers\VS_Extensibility_TemplatesV1\cache.bin ). The problem is that the file contains the hash of the SHA256 packet. A file is 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. Moreover, this is not the way real programmers do! The hash is stored as a simple ASCII string, so this is just a matter of search and replace.

What is it! Using this method, we can rewrite all VSIX packages, import the certificate used in the store of trusted root certification authorities, and Bob your uncle.

The code

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

Answer 2

This problem occurs because the certificate revocation lists for each of the certificates used by these files must be updated on the computer. If the latest CRL is not installed, he needs to use the Internet to check it.

With the release of Update 2, Microsoft updated the optional installer from Visual Studio so as not to check the certificate revocation list for VSIX extensions if the machine is offline. This fixes the problem described in this section.

They also recently released an article with instructions for offline installation at https://msdn.microsoft.com/en-us/library/mt706497.aspx . The "Troubleshooting an offline installation" section contains information that can help you solve offline installation problems using a dedicated channel when creating a layout.

Answer 3

Mr. Anderson Cassimiro's answer gave me some great tips on how to solve the problem for my offline installation, which was caused by certificate verification errors.

SUMMARY: Basically, I had to get a copy of the latest certificate revocation lists and install them on my autonomous 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 could not get to verify the certificate, regardless of the installed CRL:

sqlcmdlnutils_amd64 \ SqlCmdLnUtils.msi

Dotfuscator

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

CRLs are probably good within 24 hours or whether your CRL cache timeout is set. So, if you need to install several times on another system, you will have to download and install the latest CRLs on another system.

---

I wrote longer troubleshooting steps that I took below.

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

STEP 1: Determining if this is a certificate issue

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

In the "Digital Signature" section, if it does not say "This digital signature is OK." Then this is probably the problem with the signature.

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

STEP 2: Troubleshooting Certificate Issues

but. If the error indicates that 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) Return to the Visual Studio executable dialog boxes.

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

Click View Certificate. Click on the "Certificate Path" tab.

3) If the certificate is not trusted with the certificate path, click it and view the certificate. Click "Details" and select "Copy to file." Save the certificate in a place convenient for you.

4) Return to the MMC certificates. Go to trusted root certificates. Right click → All Tasks → Import

5) Import the certificate you just saved to the file.

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

b. If the error indicates that it cannot check the CRL.

Click on the Visual Studio executable and click on "Properties." On 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 that I needed to download.

from. If the error indicates that "one of the counters is invalid. The file may have been modified", and then:

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

• Instead of clicking View Digital Signature Certificate, click the Timestamp in the Signature Signatures section.

-Click on "Details", then click on "View Certificate" for the timestamp certificate -Open CRL distribution points on the Details tab

-Download the crl timestamp. - Install it in a standalone system and right-click the crl file and install crl, Next, Next, Finish.

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