Obscure IIS 7 Issue

Server Support,

On my WSUS implementations on my Windows 2008 servers I’ve an issue on two occasions where clients become unable to download the wuident.cab file.  Attempting to manually download the file results in a “403-Forbidden: Access is denied” error.  The first time I was getting the error I had an update to the Windows Update Service that I had been putting off, and after installing it the error cleared up.  The second time it came up only one of my update servers had the issue and I was befuddled as (just like the first time) the server was working fine and then began getting the issue seemingly out of the blue (more than likely due to an update of some sort?  The DPM install on the same server?).  One caveat though was that it all worked fine locally.

After hunting through the GUI and checking permissions I finally tracked down this web link.  For some reason the ‘<location path=”Default Web Site/SimpleAuthWebService”>’ section of the applicationhost.config file was getting set to all the ‘NoRemote’ settings.  After setting the handler section to “<handlers accessPolicy=”Read, Script” />” the WSUS began functioning properly again.

I’m not a total gluten for the GUI, but it would be nice to know where it’s purview ended and the text based editing began (maybe an embedded link in the GUI?).  It could also be that I’m not quite familiar enough with it as well since I’m constantly having to switch between the 6 and 7 interfaces.

All for Naught

Desktop Support

We’re going to be getting some very nice business desktops at work which will have quite a bit more CPU power and six (!) times the memory of our current systems.  This of course means that it will now take a little bit longer for my PC to be brought to it’s knees by the Java memory leaks that plague every web management app that I use.

SharePoint upgrade with a side of Metabase

Server Support,

After upgrading from SharePoint 2 to 3 our content came up, but no changes could be made and when trying to sign on (via the “Sign In” link) I was getting an error of “Server Application Unavailable” and an event 1062 on the server with the text:

It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process.

What was aggravating on this count was that everything looked to be ASP ‘2’ (2.0.50727), but while digging I discovered that the ‘images’ and ‘inc’ virtual directories under ‘_layouts’ were set to ‘1.1’ (v1.1.4322).  The ‘inc’ path didn’t even exist and after creating it, it stuck to the ASP.net setting of 2.  The ‘images’ virtual directory was a different story as it kept reverting back to 1.1.  I finally recalled from a certification test that if nothing else the metabase.xml file for IIS contains all the settings for the web server and it can be edited by hand.  After looking into the file I discovered that the ‘images’ virtual directory had two entries, one with 2 and one with 1.1.  I deleted the 1.1 and the settings stuck to 2 when IIS was cycled; but unfortunately the error persisted.

It turned out that, even though it couldn’t be changed in the GUI, the ‘_layouts’ directory was set to 1.1.  I manually changed it in the metabase.xml file by copying the settings over from the ‘inc’ section and after cycling IIS the sign-in function worked and the error was gone!

Now to fix all the permissions on our custom web parts that got copied by the upgrade process and were set to the default folder permissions.

Bandwidth Issues Are Odd

Network Communications

A couple of days after I had updated a series of products within the McAfee EPO, I started getting complaints from users about slow access times over the WAN.  After running a technically intensive test (ping) I determined that their complaints were well founded.  In an earlier time I would hop on the router and do who knows what to find the offending party, but I’ve been spoiled these last couple of years by having inaccessible (by me) outsourced routers with our MPLS setup.  Not knowing what was causing the issue I tried toggling some Internet services, investigated file shares, e-mail usage, etc. before taking a ‘what the heck approach’ and stopped the EPO Server service.  The instant I stopped it, the bandwidth issue cleared up.  Started it up, and it comes back.

Thinking that the issue lied with the EPO program itself, I figured the best approach would be to try and upgrade myself out of this issue by moving from EPO 4.0 to EPO 4.5.  This was an event all to it’s own and required a bit of work to get past a database upgrade issue.  After I was done the system came back up and…same issue, the WAN pipe gets completely clogged (apart from our class of service specs of course).  I tried following some bandwidth minimization strategies put forward by McAfee but they weren’t really a good fit for the issue we were having.  I wasn’t getting anywhere with the logs in trying to determine what the huge chunk of data was that being sent into the server, so I fired up network monitor on the off chance that some XML file was being sent in clear text and that it would allow me to determine what the data was.

When I got into the captured data I began scanning some packets, and while none of them were plain text, I did notice that there was a huge disparity in which machines were communicating with the server.  It was so large that it appeared that two PCs, one at each of our remote locations were the sole users of the servers over that brief time.  These PCs were also communicating over port 8085 which is the agent communication port for the EPO server.  I opened the services on the trouble units, stopped the McAfee Framework service and the bandwidth issue cleared up immediately.  I started the services back up and although it took a variable amount of time the bandwidth issue would spring back up.

I’m going to try and redo the agents on the affected system to see if I can clear this issue up…..

UPDATE: Forcing a reinstall of the agent through EPO cleared the issue up on the affected systems.

UPDATE 2: Not so fast!  It appears that for whatever reason my two problem PCs were not applying the second patch for McAfee VirusScan 8.7.  If I had to guess they were constantly trying to download the patch, leading to my bandwidth issue.  The problem now seems permanently cleared up after manually applying the patch to the systems.  The misdiagnosis from the earlier update was caused by a very long lag time from when the agent was installed to when it checked in with the EPO.

SQL Express Upgrade Error

Server Support,

I went to upgrade my old MSDE database to SQL 2005 Express on our McAfee EPO server and I was receiving a ‘-1’ error during the upgrade process with the detail of:

You selected Mixed Mode authentication, but did not provide a strong password. To continue you must provide a strong sa password.

I went through a bunch of different items, but this link detailed that the error is in fact caused by a bum installer of Microsoft’s design:

Copy C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\BPA\bin\BPAClient.dll to C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\BPA

This was one of those ‘no way’ errors that aggravated me to no end.  Why didn’t they fix this?