Windows Update / Microsoft Update fails with error 0x80072EFD when running McAfee Virus Scan Enterprise 8.0i

System Requirements:

  • Windows 2000 SP4 + BITS 2.0
  • Windows XP SP2
  • McAfee Virus Scan Enterprise 8.0i

The Problem:

This is one of those irritations that could (and should) have been sorted immediately, but lingered for months with a really very simple solution.

When you are using a suitably equipped version of Windows and happen to have McAfee Virus Scan Enterprise 8.0i (Confirmed on Patch 11 and 15, but should apply to any patch version and 8.5i) installed, your computer(s) fail to receive automatic updates through the AUClient Windows Automatic Updates service. In addition, if you attempt to access Windows Update or Microsoft Update, the update detection fails with error code 0x80072EFD.

All contemporary fixes / Microsoft suggestions to fix this fail to resolve the problem.

The Fix:

This is well and truly McAfee’s responsibility, it isn’t their fault – but it is what you get when you blur the line between an anti-virus product and a firewall.

I could argue the point that some foresight in providing some foresight in the product on this, or some reference to the issue on their knowledge base would have been useful, particularly as this ‘issue’ impacts users connecting both to the web based WU/MU and any corporate SUS system.

McAfee Virus Scan has a non-default option to inhibit port 80 downloads from non-approved executives. If through group policy, custom installation script, or distribution agreement (as with local authority school distributions of Network Associates McAfee AV) this policy has been enabled, then the Automatic Updates service is prevented from connecting to the Internet and downloading catalogue information.

Internet Explorer sessions to SUS/WU/MU are impacted because as of version 5 server connections they now rely upon the Automatic Updates service and the Background Intelligent Transfer Service (BITS) to make use of Windows Update.

To fix the error you have two options:

  1. Disable to McAfee Access Protection Policy
  2. Add the Service Host process wrapper used by the AU/BITS services to the approved connections list


Disable the Access Protection Policy

  1. Open Virus Scan Console as an Administrator
  2. Right click Access Protection
    Virus Scan Console: Access Protection
  3. Choose Properties
  4. Remove the check mark next to “Prevent Downloads from the World Wide Web”
    Access Protection
  5. Click OK


Approve the AU/BITS service to perform port 80 downloads

Both the Automatic Updates service and BITS service run as part of the Service Host Process wrapper service (as do many other system services), therefore you must allow the Service Host download permission to resolve this problem without fully disabling the McAfee policy.

As an administrator you should consider this carefully and ensure that if nothing else McAfee is patched and receiving updates properly. If your systems are not adequately protected, they may be vulnerable to exploitation by the plethora of Service Host process resident malware applications and viri, which can potentially embed themselves into a Service Host process. As a direct consequence of disabling this policy any such code will by default receive port 80 (the only port by default) download access.

Disabling through the Interface

  1. In the Access Protection configuration in Virus Scan Console, highlight “Prevent Downloads from the World Wide Web” and click the edit button
  2. Add ‘svchost.exe’ (without the ‘ ) to the exceptions list
    Block Range
  3. Click OK

Disabling through the registry

The fastest way to sort it is to distribute the registry change through group policy (or similar). The information below is correct for VSE 8.0i Patch 15.

HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\TVD\Shared Components\On Access Scanner\BehaviourBlocking
REG_SZ: PortBlockWhiteList_3
Value: (see below for overview of the required change)

McAfee Vanilla Install Settings:

Required Change based upon Vanilla Install:

Updated release of Microsoft IIS Lockdown 2.1 to include URLScan 2.5

System Requirements:

  • Windows NT 4.0 SP6a
  • Windows 2000
  • Windows XP
  • Internet Information Services 4.0
  • Internet Information Services 5.0
  • Internet Information Services 5.1

The Problem:

Microsoft released the very useful (and necessary) IIS Lockdown 1.0 in August 2001, and updated it to version 2.1 in the November of the same year, adding support for IIS 5.1 and bundling the URLScan 6.0.3547.0 filter ISAPI extension.

The URLScan component was updated to URLScan 2.5 (6.0.3615.0) in an unceremonious fashion in May 2003 to provide an updated ISAPI and, presumably, some IIS 6 support.

It’s not easy to even find URLScan 2.5 in the Microsoft download centre, but it is there, appearing in the search listings as “Setup.exe”.

If you want to bring a new Windows NT4/5.x Server box up to spec you will invariably use IIS Lockdown, which will install URLScan 6.0.3547.0, restart the IIS Services (or restart in the case of NT4). Bring the system backup, uninstall the IIS Lockdown URLScan, repeat the service restart and finally install URLScan 2.5 and – you guessed it – restart the services a third time.

The Fix:

My theory is “why bother” with that, I just reintegrated the new 2003 version of URLScan into the IIS Lockdown 2.1 installer and voila one install, one service reset, give yourself a pat on the back and go make a cup of tea.

IIS Lockdown 2.1.1 C:Amie Edition : Download : 193KB

If you don’t believe it works, the server you are connecting too right now is using it! (assuming this is still a Windows 2000 Server when you read this).

What is new in URLScan 2.5?

Good question, there isn’t any documentation on the 2.5 release (the readme in my 2.1.1 redist is the original version’s). The default configuration script has been expanded with some new variables.

You can now control how and where URLScan logs too – useful as the original version dumps logs in the Inetsrv\URLscan folder in a rather untidy manner.

LogLongUrls=0 If 1, then up to 128K per request can be logged.
If 0, then only 1k is allowed.
LoggingDirectory can be used to specify the directory where the
log file will be created. This value should be the absolute path
(ie. c:\some\path). If not specified, then UrlScan will create
the log in the same directory where the UrlScan.dll file is located.

A new query string control and maximum file request is also a new feature, allowing you to prevent people from sucking the life out of a persistent HTTP connection.

The entries in this section impose limits on the length of allowed parts of requests reaching the server.
It is possible to impose a limit on the length of the value of a specific request header by prepending “Max-” to the name of the header. For example, the following entry would impose a limit of 100 bytes to the value of the ‘Content-Type’ header: Max-Content-Type=100
To list a header and not specify a maximum value, use 0 (ie. ‘Max-User-Agent=0’). Also, any headers not listed in this section will not be checked for length limits.There are 3 special case limits:
– MaxAllowedContentLength specifies the maximum allowed numeric value of the Content-Length request header. For example, setting this to 1000 would cause any request with a content length that exceeds 1000 to be rejected. The default is 30000000.
– MaxUrl specifies the maximum length of the request URL, not including the query string. The default is 260 (which is equivalent to MAX_PATH).
– MaxQueryString specifies the maximum length of the query string. The default is 4096.