I’ve been building some new Dell PowerEdge 1950 servers for a new deployment running Windows Server 2003 SP2. I had originally configured the servers to use the integrated Broadcom NICs, but wanted to change to my new Intel Quad Port VT 1000 PCIe card. I went with the quad port since I was planning on doing some teaming/link aggregation, and have always had sporadic at best luck with the Broadcoms. My server only had one free slot for the NIC, and since a dual port card was not available I had to go with the quad port.
Intel PROSet is traditionally configured through a Control Panel applet, but the current version is integrated directly into the NIC configuration, so it can be setup inside Windows Device Manager.
I RDP’d into the server using the Broadcom NIC’s IP address, installed the intel drivers from the Dell support site, accessed the NIC inside Device Manager, and saw the four tabs I was used to seeing. After a server reboot, I still saw the usual four tabs in device manager and no Advanced Network Services (ANS) configuration for PROSet.
I tried a different driver off the Dell site, which still did not allow me to view the ANS settings. I moved onto drivers directly from Intel, but my situation did not change despite uninstalling, rebooting, and reinstalling the drivers.
I finally ran up to the data center and physically moved the cables from the Broadcom NIC to the Intel NIC. Since the Intel NICs did not have the static IP assigned to them like the Broadcom did, and I had no idea what address DHCP had assigned to them, I accessed the server via the DRAC remote access card. When I went into Device Manager I could see the additional ANS tabs that would allow me to configure the teaming.
I disconnected from the DRAC and reconnected via RDP. No teaming options appeared. I then connected to the server console by running mstsc /console, and the teaming options were there!
The moral of the story appears to be you must be connected to the server console in order to see the PROSet ANS settings inside Device Manager. I assume this is so administrators do not accidently lock themselves out of the server when remotely configuring the NICs.
