Archive for February, 2011

Windows 7 Static IP conflicts and Duplicate APIPA

Wednesday, February 2nd, 2011

This is an interesting one. I purchased a new laptop for work last week with Windows 7 Professional 64 bit edition installed on it. Pretty routine I thought.

Well, I plugged the laptop into our network (Yes, plugged in, we don’t have a WLAN) and assigned the laptop a static IP address on our network. Since we don’t use DHCP this is fairly routine and I have a comprehensive database of what IP Addresses are assigned already.

The problem is that instantly I got an IP address conflict. I thought that was odd but proceeded to assign a different IP address but I got the same error. At this point I thought it was unlikely that my database was that incomplete, so I simply attempted to ping that IP address from a known working PC on the Network…. No replies.

The next step… Run IPCONFIG /all under command prompt and at this point I felt it got weird. Both my static address and the autoconfiguration IPv4 address showed (duplicate) after them. I then checked the event log and found the MAC address (in every IP conflict case) that the laptop was conflicting with. It was the same MAC in every case. I figured it had to be a local adapter on the computer, but to be sure I ran Wireshark and Colasoft MAC Scanner but failed to return that MAC address.

Since I had a little time on my hands, I was curious if doing a fresh install would fix the issue, so that’s what I did next. Unfortunately, no, when the newly installed OS came up I had the same issue.

I still thought this was coming from an internal adapter but couldn’t find the MAC internally. So, I decided to go into Device Manager and Show hidden devices.¬† Here I saw Microsoft’s ISATAP adapter which is responsible for running IPv6 over an IPv4 infrastructure. You can read more about it on

The above link does not address my issue it simply illustrates the purpose of the adapter at the bottom of the article. For my issue, I really couldn’t see why this adapter would cause an issue, but for the heck of it I decided to disable it anyway. Miraculously once I did so I had access to my network and the internet!

Since we are not going to IPv6 in our local infrastructure anytime soon I figured I would leave it disabled for now. It’s not a fix but it is a temporary work around for an interesting problem.


So, I just couldn’t let this issue go. I ended up running Wireshark again and this time I found the device transmitting DCHP Discover requests. The Device talks IPv4 and IPv6 and for whatever reason the DHCP Discover broadcasts from this device kept causing issues with my static IPv4 Clients until the IPv6 adapters were turned off. I’m still unsure as to why this is the case but at least I have found the MAC address.

Upon further investigation I found the device with the MAC address in question was also sending ARP requests to an outside source. After speaking with one of our network contractors I found out that the device attached to our network is something they put in that communicates with an internet service specific for an upcoming project. At this time I had to turn DHCP on for one of our Routers to allow this device to work (Although I only turned it on for 1 address at the moment).

Cannot connect to the configuration database

Wednesday, February 2nd, 2011

If you are running Windows Sharepoint Services 3.0 like I am, then you may have seen the error above. This error can sometimes occur when you are attempting to go into the central administration tool for Sharepoint Services.

Some of the suggested fixes for this include reinstalling WSS 3.0 or reinstalling Windows Internal Database Services. Both of which will work but can require a bit of effort. I propose simply trying to restart the Windows Internal Database Server  to see if the administration tool comes up after that.

I’m not saying it will always work, but it’s a simple troubleshooting technique you can try before reinstalling services. To do this you can go to you RUN prompt “Windows Key + R” and type services.msc then hit enter. From here find the Windows Internal Database Service, right click and choose Restart.