by on September 3, 2013, in

Software Installation Very Slow without Internet Access

I have been using Windows 8 Client Hyper-V for a while now and must say it works like a treat – except for one thing: it is practically impossible to give VMs at the same time NATted internet access and connect them to other VMs and to the host. Windows Internet Connection Sharing (ICS) just does not work reliably and I have found no other product to use instead.

For that reason the VMs in my lab are without internet access most of the time. Generally that is no problem, but once in a while they are slow bordering on standstill. These periods of slowness coincide suspiciously with me installing software and they are worse the more complex the installer is. Installing small tools is still bearable (single delays of 20-30 seconds), but larger suites like Citrix XenApp take dozens of minutes. So what’s wrong?

It’s Always the Network

When things take annoyingly long and there is no obvious bottleneck on the local machine the network is always the prime suspect. You might ask what you need internet access for when installing software. As you probably know, most software vendors diligently sign their executables and also their MSI files with a digital certificate. That gives your computer the chance to verify that the software is genuine and has not been tampered with. To do so it checks the signature – which is done quickly. But it also checks if the certificate used for signing might have been deemed “illegal” in the meantime and been put on a list of “outlaw” certificates, the so-called certificate revocation list (CRL). Now guess where the CRL is stored: online, on a web server, of course, or else it could not be updated quickly.

As it turns out the Windows operating system’s cryptographic libraries seem to be pretty inefficient in detecting whether a connection to the server hosting the CRL is possible. Apparently they simply try to download the CRL – and wait until a timeout expires before they accept defeat. Knowing that network timeouts are typically in the 20-30 second range it is easy to imagine how this constitutes a very effective denial of service, or rather denial of installation.

Ignore Evil CRL DoS

Given the sad state of SSL security and the frailty of an online-only revocation list it is no big loss to disable CRL checking altoghether, especially in non-production environments. Do do so open the control panel applet Internet Options, navigate to the Advanced tab and uncheck:

  • Check for publisher’s certificate revocation
  • Check for signatures on downloaded programs

Disable CRL checking

The latter is not related the CRL checking but it helps speed things up.

.NET 2.0 Applications

A bug in the .NET Framework 2.0 causes the Authenticode signature to be verified every time an application is started. This is a famous cause for long delays when no internet connection is available. To work around it, create an ApplicationName.exe.config file next to the executable with the following contents:

<configuration>
   <runtime>
      <generatePublisherEvidence enabled="false"/>
   </runtime>
</configuration>

If the application is hosted by IIS, like the Citrix Web Interface, the section above must be added to C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config as described by Matthew Allen.

Other Causes for Delays in an Internet-Less World

CRL checking is by far the biggest nuisance if you are not connected to the internet, but there are others, too. Windows 8’s Defender checks downloaded executables in an online database when they are first run. Although it is much less stupid at detecting if internet access is available, it is a potential source for delays, too.

On my laptop, double-clicking an XLSX file causes – nothing at all, at least for 5-10 seconds. Only then is Excel (2013) started. I am pretty sure this is the doing of Defender, too, but I have not bothered to investigate yet.

Previous Article How WinPE 4.0 Breaks ICA Connections
Next Article Script: Gracefully Shut Down all VMs on a Given Set of Hosts (VMware/XenDesktop)