Last week I deployed a new server computer for a Customer, and had some difficulty getting to the VLAN settings for the NICs. After a lot of searching, I eventually figured out what I needed to do. In another of my series of posts to assist other frustrated IT professionals, here's the detail about what I found.
My Customer's server computer needed to be configured to be plugged directly into a switch port configured as an 802.1q VLAN trunk such that the server computer would appear as a device on multiple VLANs. We're configuring this server computer to move a lot of data and I don't really want that data being routed between the VLANs when we can just put the server on each VLAN directly. So, this is all just to save unnecessary traffic hitting the intra-VLAN router.
The newest versions of Intel's PROSet NIC configuration software add tabs to the properties of NICs in the Windows Device Manager. A few months ago, when I'd first had occasion to install this version of PROSet, I fumbled around looking for the NIC properties before I "discovered" that they were accessible in the Device Manager. Previous version of PROSet were a freestanding application, and it was very easy to find and use. Adding the tabs to the Device Manager didn't help me at all, and, in fact, cost my Customer some money.
During this installation, I was frustrated to find that the tabs weren't visible in the Device Manager at all. Initially, my thoughts were something like: Did these idiots think it would be fun to move this configuration again? A little reading of documentation, though, confirmed that the tabs I was expecting should have been added to the Device Manager properties sheet for the NIC.
After a couple of hours playing around uninstalling and reinstalling, and doing lots of Gooogle searches that, unhelpfully, turned up mostly references to the PROSet Wireless version (thanks bundles, Intel, for naming that PROSet, too), I finally elected to quit for the day and redouble my efforts on the following morning.
As I drove back from the Customer's site, I started thinking about the differences between the installations of several months ago and today. Sure-- several months ago I was installing Windows Server 2003 R2 Standard Edition x64, and today I was working on a Windows Server 2003 R2 Storage Server (32-bit) machine-- but that shouldn't really have any effect. If it'd been the other way-- the new installation on the x64 version of Windows Server 2003, I might have been inclined to believe that the x64 version of PROSet was the problem, but the 32-bit version isn't bleeding-edge at all. A few months ago, I'd cleanly loaded the operating system myself on the bare metal, whereas today's server computer was a pre-load from the manufacturer. That, also, shouldn't really make a difference. A few months ago I was working on a workbench with the server computer's console, and today I was working through Terminal Services. Hey-- wait... Terminal Services, eh? Hmmm...
The following morning, I logged-on to the console of the server computer, and sure enough, the tabs were visible. One short Gooogle search later, I was in possession of this article that explained the issue. Interestingly, the Event ID 20 that their article references never showed up. I check event logs as a first step when investigating anomalous behaviour, and I never did see it. If I'd seen that, it would've tipped me off.
I find the underlying nature of this issue interesting, and I'd have to speculate that the footprint of this type of problem could be fairly large. I'm not going to go dig thru an SDK to figure out if what Intel did was really The Right Way to go about doing what they did. I've done some reading, though, and found that COM+ never recognizes a user logged-on with Terminal Services as the "Interactive" user for the purposes for invoking requests. That seems wrong, but then I don't really ever work with COM+.
I think that adding tabs to operating system properties sheets is a dumb idea, underlying architecture nonwithstanding. My intuition doesn't tell me to go look at places in the OS where I _know_ the settings I'm looking for aren't located, and to put them there serves only to delay my finding them.
This kind of behavior smacks of an idiotic attitude that a former boss of mine had. He commented once that he liked peripherials that had space for our logo sticker and no visible manufacturer logo. Putting our logo there, he felt, would make the Customer see the entire PC as one of our PC's, like a Compaq / IBM / Dell / etc, rather than just a white-box PC cobbled together out of off-the-shelf parts. Any Customer who felt better about our white-box PC's on account of the logo isn't somebody I'd want buying my product, because they're an idiot. This is the same think I think of people who are wowed by the novelty of modified operating system dialogs and properties sheets.
