Blog: NIC

A customer who has two terminal servers (TS1 & TS2) that can be accessed using a shared name (TS) was unable to access them from their remote sites. I was able to access TS1 and TS2 from a remote server but not TS. I could also connect using the IP of each server but not the shared IP. What I found was that there was a static ARP entry on the main and backup router for TS. The MAC address on the ARP entry did not match the one on the servers. Both of the servers are virtual machines and this was caused by the ESX update and installation of the updated VMTools on the terminal servers the night before. The MAC addresses on the virtual NICs had changed. The ARP entry was removed and they could connect using the shared name.

A coworker and I ran up against a very interesting situation at a virtualization consulting customer's site the other day. We got an after-hours call from the customer that said he was working on the console of a new Windows 2008 virtual machine. He was trying to set the IP address on the NIC and accidentally choose the “bridge network adapters” setting. Afterwards, he was unable to get to anything in the internal network from this server and several other VMs could not communicate with the internal network either. My coworker connected via VPN just fine, but was unable to ping the vmhost2. He could ping the SBS server, one terminal server, and the ISA server. We discussed over the phone that the particular ESX server that those servers were on must have somehow gotten isolated from the network. Sure enough, when my coworker checked the NIC status on vmhost1, it showed that all NICs connected to the LAN network were disconnected. We decided to go onsite and check out what was going on. On the way out, I realized what had happened. When the two NICs got bridged on that VM, it created a loop and must have looped a BPDU and err-disabled the port. Once onsite we confirmed that the port was down and portfast was NOT enabled on that port.

So, the warning here is two fold…yes, a VM can take down the whole ESX server. And second, its best to turn on portfast for ports connected to ESX servers. They don’t understand STP anyway.

I was working remotely on a customer’s network using a PPTP VPN connection. When my work was completed, I clicked on the network icon in my system tray expecting to find a “disconnect from” option for the connection.  It was not there.  I opened up Network and Sharing Center, but could not find a way to disconnect the session.  Finally, I disabled my network interface card (NIC) and re-enabled it.  That disconnected the session.

I knew I didn’t want to have to disable my NIC every time I used a PPTP VPN connection, so I looked for a solution.  I found an online forum that mentioned that this was a known issue. The workaround for this problem is: [more]

Open up a command prompt window.  At the prompt, type rasdial “connection name” /disconnect and then enter.  That will disconnect the session.  The connection name will need to be in quotations if the name of the connection has spaces in it.  If it does not, then quotations are not needed.  If you need to identify the connection name, you can just type rasdial and then enter.  This will give you a list of all your active connections.

If you utilize the same PPTP connection(s) quite often, you can also create a disconnect shortcut for each connection, which will simplify the process.  Just create a new shortcut and add the listed command string in the location.  Then, when you need to disconnect from the PPTP session, just use the shortcut.

A customer had a problem with a server’s network connection disconnecting and reconnecting often.  When I got onsite, I checked the event log and noted disconnect/reconnect messages occurring quite frequently.  I checked the NIC properties and noted the server was set to 100/full.  I noticed the server, and another server, were both directly connected with new cables, to gigabit ports on a switch.  I also noticed the presence of APC Ethernet surge protectors being used on both server’s network connections.  I removed the surge protector from the server I was working on and ran some ping tests.  The NIC was no longer being disconnected.  I set it to autonegotiate and it went to gigabit speed. [more]

I then checked the NIC properties and event log on the other server. It too was getting disconnected regularly.  The NIC was set to autonegotiate, but was only running at 100/full.  I removed the APC Ethernet surge protector from that server’s network connection.  The NIC autonegotiated to gigabit and was no longer getting disconnected.

We have a VMWare ESXi 4 infrastructure that we wanted to have VM’s with two separated networks: DMZ and Internal. This was accomplished by using the VLAN tags within the virtual switches to separate the traffic. However, when the VLAN tags were implemented on the separate switches, then we could no longer access the host itself at it’s ip address. The reason was that we did not assign a VLAN ID to the host itself. This can be done at the configuration option of the ESXi console (F2). Alternatively, one could have a completely isolated NIC card that is just for servicing the host machine that is independent of the NIC card(s) for the embedded VM’s.

Working on an ISA server the other day I had to change the LAN IP addresses.  I was RDP’d into the server from the internal network when I made the change and applied it.  I waited a few seconds and tried to reconnect to the server (by name).  DNS has updated properly with the correct IP address, and I could ping the address, but I couldn’t RDP back to the server.  The server was virtual, so I used VI to connect to the server console.  I didn’t see any issues, but rebooted the server to be sure.  When the server came up, I still couldn’t RDP.  I checked the Terminal Services service and it was not running.  I tried to start it, but it failed.  I checked the event log and it mentioned something about the service binding.  I ran the Terminal Services Configuration console, checked the Properties of the RDP-Tcp object.  On the Network Adapter tab, the “All network adapters configured with this protocol” was selected (which is the default, but wasn’t working).  I manually selected the LAN NIC and hit Apply, and RDP started working again. [more]

A client of ours uses the Cybernet iONE all in one PCs for customer internet stations at several of their locations. One oddity of these machines is that they ship with dual Gigabit onboard NICs. On these internet stations we typically use just one and disable the other NIC. While building out a particular machine, I needed to install several pieces of software that we deploy via Group Policy Software Installation. The problem is that any time I would attempt to deploy the software via Group Policy, it would fail and I would see event ID 1054 in the event logs… “Windows cannot obtain the domain controller name for the computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted. Data: (unavailable)”.  Everything else was working fine. The machine was a member of the domain, I could ping the domain controller that DHCP had assigned to the machine, I could resolve internal and external addresses, gpresult showed that the PC was successfully linked to the software installation OU, etc. [more]

After conducting some research on this error and on these machines, it turns out the problem was that the onboard Broadcom gigabit NIC was taking too long to auto-negotiate its link speed, creating a “race condition” between the TCP/IP protocol and the NIC driver when they try and register with the MS Nework Driver Interface Specification. The local Userenv process (what actually performs GP’s instructions) would attempt to install the software before the NIC was fully available, thereby causing it to fail when it would attempt to run the assigned MSI over the network. Here’s how to rig the race so that the NIS driver always wins the “race”. There is a MS hotfix available for this along with a more detailed problem description at http://support.microsoft.com/kb/840669. After installing this hotfix you must add the DWORD registry entry GpNetworkStartTimeoutPolicyValue in  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and set the value of that DWORD entry to the number of seconds you would like the OS to delay processing Group Policy Startup scripts.