Getting Windows Update to Work - Feb. 15, 2005

Internet Explorer Doesn't Use Proxy for Updates - Feb. 15, 2005

This one can get ugly. Read all of the text below before trying my Dec. 16 workaround!!!

Feb. 15, 2005: Summary of the V5 Update Problem Since updating to version 5 of the Windows Update system, many PC's around the world have quit working when trying to do Windows Update through a proxy. This means ANY proxy, including the Microsoft ISA proxy. The reason is fairly simple - Microsoft changed something in the Windows Update portion of Internet Explorer, and the last part of the Windows Update process quit using a proxy to access the Internet.

The classic symptom: You can do all of the Windows Update procedure until you get to the last step where you click on the Install buttons. At that point, a new window pops up where you are supposed to see the updates being downloaded and installed, and instead you just see each update time out. Checking the windowupdate.log file shows one or more 80072efd or 0x8024502D error messages.

If I do packet traces or filter debug on the proxy server, I can clearly see that the PC is NOT USING THE PROXY to request the updates, but instead is GOING DIRECTLY TO THE INTERNET ON PORT 80. This is NOT a BorderManager (or proxy) issue, it is a problem with Windows not honoring what you set in the browser proxy settings.

Note: Some firewall products simply allow all outbound traffic, and only try to filter inbound traffic. BorderManager (properly configured) is not one of them. When the situation described above occurs, BorderManager filters the outbound traffic, as it is supposed to. (You do not want your typical corporate user to be able to browse the Internet at will, without being subject to the access rules that are part of BorderManager HTTP proxy, therefore such traffic needs to be filtered in order to force the users through the proxy).

OK, so now we see what the problem is - an Internet Explorer bug (in my opinion). The question is "What can we do to get Windows Update working again, in spite of this bug?"

Feb. 7, 2005: Possible Fix #1 This will not always fix the problem, but it does fix it for a lot of people, is easy, fast and has no risk. Open a CMD window (DOS window) and type PROXYCFG. If you do not see the browser using a proxy setting, then type

PROXYCFG -U
Now see if Windows Update starts working through BorderManager.

The PROXYCFG -U command transfers whatever browser proxy settings you have in Internet Explorer's Proxy Server field into what appears to be a minibrowser dedicated to Windows Update downloads. This command does NOT work if you have nothing set in that field, or if you are using an autoconfiguration file (proxy.pac file).

If you have nothing set in the Proxy Server field, or you are using a proxy.pac file, you will need to try something else. You can set the proxy setting manually using the PROXYCFG command with a -P parameter, as in the following example:

PROXYCFG -P "http://192.168.10.254:8080"
(Where I use 192.168.10.254 as the proxy server address, and port 8080 as the proxy port in this example).

Nov. 12, 2004: Possible Fix #2 - I have tried numerous settings, including running the PROXYCFG.EXE file, [PROXYCFG -p "http://x.x.x.x:8080"] to try to make Internet Explorer work with the proxy, and nothing is working on the one PC of mine that has the problem. (Four others here are fine). This is just plain an ugly Internet Explorer bug. I've checked registry settings, proxy settings, tried toggling them off and on, and changed to different proxies. Nothing is working to get IE to use the proxy during the final stage of the Windows Update process. I have taken to putting in filter exceptions for some of my clients to allow HTTP to the Microsoft Windows Update subnet addresses as a temporary workaround.

Dec. 16, 2004 update: - The problem has gotten worse for me, with more of my PC's deciding not to use proxy anymore for the final stage of the Windows Update process. In fact, I have to wonder why all XP SP2 PC's I see don't have the issue, since it apparently is something Microsoft has done on purpose.

Update from February, 2005: I've now seen even more IP addresses being used for Windows Update servers, including at least one 64.4.x.x subnet. You may need to add a few more exceptions to get this workaround to work all the time.

For now, I have an ugly workaround, involving adding 255 stateful filter exceptions allowing HTTP to Microsoft network addresses.

Use this procedure at your own risk! It works for me, but I'm careful and know what to do, and what not to do!

Microsoft Windows update servers may be on any address from 207.46.0.0 through 207.46.255.255. Unfortunately, as of this writing, you cannot supernet filter exceptions (e.g. 207.46.0.0 / 255.255.0.0). Such an exception will fail to work. So you must add network filter exceptions for each class C subnet (207.46.0.0, 207.46.1.0, 207.46.2.0....207.46.255.0). This means 255 separate filter exceptions. I have taken the trouble to do this on my own servers, and provide the exceptions you can paste into your filters.cfg file HERE. BUT, read the instructions and warnings below before you try this!!!

Now - if you want to do this the risk-free way, you would simply have to make a stateful HTTP-ST exception (you can use the built-in www-http-st definition as well) for the first Windows Update address, and then just repeat it 254 more times for each class C subnet, using FILTCFG or iManager. Take 10 minutes/day, and by the end of the week you should have it done. If you want to use my cut/paste method to push them all in quickly, read on below.

WARNING My sample file is for interfaces named PUBLIC and PRIVATE. If you have different interface names (see FILTCFG, Interfaces menu), then you need to modify my file to replace my interface names with yours. (Otherwise, these exceptions will be ignored).

1. Back up your SYS:ETC\FILTERS.CFG file.
2. Using FILTCFG, make a new filter definition called HTTP-ST, if you don't already have one. Use protocol TCP, source ports 1024-65535, dest. port 80, and stateful Enabled. Add a comment 'Stateful HTTP'. (I included a file called fhttpst.cfg so you can see what it should look like in filters.cfg when you get done.)
3. Use the FILTSRV_BACKUP_FILTERS FILTERS.CFG command from the console prompt, to copy filters from NDS to a file (FILTERS.BAK is the default). Check the file data after you do this to be sure you got the data backed up OK.
4. Make another backup of FILTERS.CFG. You can't be too careful with this!
5. Using a copy of FILTERS.CFG on your PC (not from the ETC directory), copy in the filter exceptions from my example file fwinupdate.cfg HERE. Put in the exceptions into the PACKET-FILTER-LIST IP, ENABLED, DENY section, right in front of the first exception you see that starts with EXCLUDE ENABLED NOLOG. (Be careful you know what you are doing here). Note - each filter exception line needs to be indented at least one space. And you CANNOT leave spaces between the filter exceptions you paste in and the other entries already there! I recommend you turn off word wrap in Notepad when editing the file to make sure none of the pasted entries are split onto an extra line.
6. If using BorderManager 3.6 or earlier, you should be able to copy the modified file to SYS:\ETC and unload/load IPFLT. If using BorderManager 3.7 or 3.8, use the following steps instead.
7. If using BorderManager 3.8, STOPVPN to stop BorderManager VPN services. (This is just to unload VPMASTER, which will prevent you from unloading FILTSRV if you have VPMASTER loaded. If not using VPN services, you can leave BMgr up.
8. If using BorderManager 3.7, unload VPMASTER (or VPSLAVE, as required).
9. Unload IPXFLT, if loaded
10. Unload IPFLT, if loaded
11. Unload FILTSRV
12. Copy the edited FILTERS.CFG file to the server's SYS:ETC directory, overwriting the old one. Don't do this until FILTSRV is unloaded.
13. Be sure time is in sync on the server!
14. If up to date on BorderManager 3.7 & 3.8 patches, LOAD FILTSRV MIGRATE -CF. This should delete the existing filters from NDS and migrate in the modified ones from FILTERS.CFG. You may get a lot of -6001 errors on the logger screen, but they seem to be cosmetic in this procedure. It is NOT cosmetic to see error messages about time not in sync or invalid keywords (means you didn't indent the exceptions usually, or left blank lines in filters.cfg where you were not supposed to).
15. Unload FILTSRV.
16. Load FILTSRV.
17. Use FILTCFG to look at the exceptions. All your old ones should be there, along with a bunch of new ones for HTTP-ST.
18. Restart VPN as needed. (Load VPMASTER or VPSLAVE, or STARTVPN on BorderManager 3.8).
19. Test Windows Update. It should work now.

Feb. 15, 2005: Workaround: I don't recommend this, because of reasons given below, but it should work OK, is easy to do, and could be a useful stop-gap measure to get Windows Update working if you have been having the problem described above and can't easily run the PROXYCFG command on all the PC's yet. (Or if that technique isn't fixing things for you). You can use Transparent HTTP Proxy in BorderManager to automatically proxy any port 80 requests going out to the Internet. Simply enable it in NWADMN32, BorderManager Setup, Transparent Proxy, Transparent HTTP Proxy, for port 80. (Port 443 can also be used, but new versions of PROXY.NLM require tunneling control parameters to be set in PROXY.CFG - see tip #63 here).

Why I don't like this method: Transparent Proxy itself has a number of issues, including the major one that it does not always work well with Access Rules. (Will typically sometimes allow things you normally block with a rule. SurfControl rules, for instance). You also get IP addresses of web sites in the log files instead of URL's, as a consequence of how transparent proxy works. There are some other minor issues (slower, requires DNS lookups at the browser, requires default gateway to be set on the PC, etc.), but these are the big ones.

Windows Update Error 0x80072F76 - Sept. 4, 2003

I worked on a server that had a problem going to Windows Update through the proxy, where accessing the update site give a 0x80072F76 error message. Windows Update worked when bypassing the proxy. This one had me going for a bit, since the patch level was current (PXY043, from BM37FP3C), and the PROXY.CFG file (tip #63 here) was the same as I was using. I isolated the issue to a proxy setting for persistent connections to servers. I normally leave the persistent connections settings (to browsers and servers) enabled, but this server had it disabled from the previous admin.

In NWADMN32, go to BorderManager Setup, HTTP Proxy Details, and under the HTTP tab, be sure to Enable Persistent Connections to Origin Servers.

As soon as this change was in effect, the Windows Update error went away.

Miscellaneous Windows Update Issues/Tips

June 6, 2003 - Andy Rowland in the forums passed on some interesting information.

June 15, 2002 - I have found an issue in my PROXY.CFG file that was preventing Windows Update patches from installing on my Win2k Pro and XP Pro PC's. See tip #63 on PROXY.CFG here.

General Tips on Windows Update through BorderManager Proxy

A lot of people have had difficulty with getting the Windows Update feature to work through BorderManager. Here is something to try for BorderManager 3.5, but you will need to be at a patch level that includes the BM35C11.EXE Proxy/ACL patch (or later):

1. Have BM35C11.EXE (or later( installed (see tip #1 at this web site for a list of current patches)
2. Unload PROXY.NLM
3. Edit the SYS:ETC\PROXY\PROXY.CFG file, and add the following to the end of the file



[Extra Configuration]
TurnOffPersistantPassThru=1

4. In NWADMN32, BorderManager Setup, HTTP Proxy Details, HTTP, enable both Persistent Connections to Origin Servers and to Browsers
5. LOAD PROXY -CC

Step #4 above is critical. This patch and configuration procedure should also help cure most problems receiving.ASP page through the proxy.

Finally, Mike Thorp in the Novell Public Forums passes this tip along for BorderManager 3.0 users:

" I found a knowledge base article (Q241783) at microsoft discussing using windows update through a proxy or firewall. The article does not specifically address BM (not surprising) but does discuss some of the common problems with proxies. The TID recommends NOT caching the windows update pages on the proxy. I turned caching off on my BM3.0 server for windowsupdate.microsoft.com and it seems to work now. Don't know if this will work for BM3.5."

Turning off caching for windowsupdate.microsoft.com seems to be critical for both BorderManager 3.0 and 3.5. (Set as noncacheable in NWADMN32, BorderManager Setup, HTTP Proxy Caching, Cacheable Object Control. Select Specified Host Name and enter windowsupdate.microsoft.com.)

Some comments on the BM35C11.EXE patch:

"From: Erik Reuter <er@servicegruppen.dk>
Newsgroups: novell.support.internet.bordermanager.install-setup
Subject: BM35C11 - What a difference this makes!
Date: Sat, 13 Jan 2001 00:44:14 GMT

I installed NW51SP2a and the BM35C11 patches the other day and was surprised in several ways!

I actually did the C11 install first, modifed the proxy.cfg file to include the new performance parameter TurnOffPersistantPassThru=1", booted the server and began the download of SP2a.... Usually I'm getting around 200Kbps (max 210) on out 2Mbit line, this time around the download averaged out on 237Kbps!!! Wow!! I was stunned!!

We've also had some problems accessing certain sites where we got the usual "gateway timeout error", these problems are gone!! Looking at the "fastcache current activity" screen showed me, that the failed client connection attempts has dropped from around 1000 a day to below 20....

On average (talked to some users) access to and download from sites are a lot faster after applying the C11 patch....

I just can't stop smiling - been working a lot on ways to optimize the BMEE server, but this really hit the spot!!!

Erik Reuter
CNE"

And also:

"I had to exclude windowsupdate.microsoft.com from being cached at all, to get the feature working."

Return to the Main Page