How to test DHCP from a distance

I have a 2003 server set up as DC, DNS and DHCP.

DHCP appears ok in the management console but I reset a pc to get its address from dhcp and it didn't work.

The problem is that the office is remote, 8000 miles away, no-one is there to reboot for me and I have now lost VNC access to 1 out of 5 pc's.

I cannot lose any others as they all still need software installs and various other setups.

The pc's can remain as static ip, but we need dhcp to feed any visiting laptops. Is there anyway that I can test dhcp by getting it to give an address to a fake machine of some kind without losing another pc.

Thanks

 

Where is this DHCP server ? Local or offsite ? How are you accessing it ?

 

DHCP server is in the remote office along with 5 pc's.

There is a fixed IPLC link between there and here. We access it using VNC.

 

Is this a new setup or you changed something ?

 

This is a brand new subnet in a new office, the server is a dc that replicates with our domain at our main office.

 

Hi Grunty

Clarify exactly the route you are taking to connect!

Are you vnc'ing into the Server, then vnc again from there to the station?

Or RDP to the server then vnc to the station?

Or vnc'ing directly to the station somehow?

Mike

 

ok, I am vnc,ing directly to each machine, server and pc's.

The problem is not vnc, it is dhcp on the server not issuing addresses. Normally to test this I would set a pc as dhcp client and see what happens. If it fails then I would troubleshoot.

Because I cannot lose anymore pc's from the subnet because I cannot get there to reset (they are in Sinagapore, I am in the Isle of Man) , I need to find a way of testing dhcp remotely - maybe there is some utility to do this?

I would like to read the event logs of the failed client, but cannot get into it now as it has an unknown ip address and has probably also gone into hibernation. Wake-on-Lan fails to get it going again too.

 

Right off I don't know of an easy way to test DHCP remotely!

OK so you lose it after you reboot?

Have you changed the lost stations to DHCP or are they still static IP?

Have you tried VNC'ing to the DC Server then pinging the station that you have lost to see if it is even showing up?

If they show up from the server can you then VNC from the server to the station?

Do the stations you are trying to connect have RDP enabled and if so can you connect directly using RDP?

Or can you connect to the DC server and RDP to the station via the LAN?

More info!

Mike

 

Hi Grunty

I am not ignoring you DHCP primise.

It may or may not be DHCP that is causing this, but your best bet is to somehow reconnect to one of the stations you lost and check its settings.

I am just trying to get you reconnected to one of the stations that you lost, this will be your way of checking DHCP remotely!

So what about my last post?

Mike

 

Hi mflynn,

Thanks for the reply.

Once the pc was changed to dhcp client, it failed to pick up a dhcp assigned address, giving itself an address of 169.254.198.253 (where does it get this from?) nothng like our subnet. If I had been able to ping that, the switch would have routed it out to the internet anyway.

I tried pinging from the remote server as well as our local ones - still no joy

As luck would have it, there was a guy in there putting furniture together. He swiched of all equipment (dont know why) so I phoned him, told him it was all his fault and got him to reset the lost pc to a fixed ip. I checked the event logs of the pc and could find no reason for not finding dhcp, just an entry listing its address of 169.254......

I hadnt thought about RDP, how do I check if the pc's have that enabled?

They are all available now so it isnt so urgent. Users start work in a couple of weeks, but I will still need to get dhcp working eventually for when visitors arrive with laptops. Hopefully one of the users there will be savvy enough for me to talk them through some testing. My firm won't fly me out there just yet.

 

Hi Grunty

Well the reason it picked a 169.xx.xx.xx number (this is a windows default IP when windows can not find an IP by any method) (this is a sure sign something is amiss) and is because it either.......

1. Could not find a DHCP server (confirming your primise)
or
2. The "DHCP Client service" on this station is turned off or not starting in Services.

If the DHCP sevice on this station is off or not starting then then that is the problem. If it is started then you do have a DHCP problem with your server.

It could also be a DNS issue. Can you ping both IP and ComputerName form all directions. From the server to the stations, from the stations to the server. Also can you ping name and IP from here via IPLC?

To turn on RDP go System Properties on the station and click Remote tab and put a check in Remote Desktop. It will need a password to connect, so if you have no password you will need to set one.

Because of the distance involved here (8000 miles) I would have both VNC and RDP working, and also know that I could connnect by name or IP. (If DHCP is working and the station retrievies an different number) then a VNC to to the Server and a VNC or RDP to the station by name should allow connection. If you can not connect by name there is a DNS issue.

Let me know.

Mike

 

Hey Grunt

How goes it?

Have checked DNS?

Mike

 

Sorry for the delay, was away from work yesterday driving one of these : http://www.gibbstech.com/aquada.php - completely off topic but great fun.

I can ping everything from everywhere, even across subnets, so I suppose it isn't a DNS problem.

I turned on RDP and it works but only when IP is fixed to the same subnet.

I set up a pc local to me and tried setting it as dhcp client with a fixed alternate address; stopping dhcp client service so that it failed and then tried to connect through rdp and vnc to the fixed ip. It wouldnt work even though I could ping the fixed ip, I suspect it might have something to do with services not binding to the NIC, although not sure about this.

I am trying not to get stuck with rescusing pc's when all I need to do is to test the dhcp server. I can see nothing wrong with the setup, it isnt exactly rocket science. As I understand it, when the pc starts up, the nic broadcasts the local LAN for a dhcp server, finds one, gets an address - no dns necessary at this point - simple really.

 

Is the server on the same physical network as the client PC? Is there a router between the two? BOOTP/DHCP packets broadcast and therefore won't pass over a router unless you specifically set up the router to pass them.

DHCP server is a service and therefore can be restarted via services in "Administrative tools'. Have you tried restarting the service?

Is your server multi-homed? That is, does it have two or more network connections? If so have you checked that the DHCP service is bound to the correct network connection? To do this, go into the DHCP console on the server and select the DHCP server. Right click and select properties. Select the Advanced tab. Click on the Bindings button. Make sure you active internal network connection is selected.

If none of that works, I'd be tempted to put wireshark on one of the PC and see if can see the DHCP traffic. From that you should be able to see the DHCP packets going back and forth and therefore spot which part of the communication isn't working.

See these pages for more information on Wireshark and DHCP traffic.

http://wiki.wireshark.org/DHCP

http://wiki.wireshark.org/

http://scottledyard.wordpress.com/2007/03/31/mitigating-ip-dhcp-snooping/wireshark-dhcp/

http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Technical_details

http://www.dhcp-handbook.com/dhcp_faq.html

 

One thing to note: Connecting to a server is done through the same RDP client used when connecting to a desktop PC.

However, remote management of a 2003 server is done via terminal server. It works really well, but there is one thing to be aware of if all you've used before is RDP on desktops and VNC. When you connect to server via terminal server you do not get the current desktop - that is the same desktop as someone sat at the console at the server. You get a fresh new desktop. You effectively connect in as a new user. This means windows that you open via the remote connection will not appear on screen at the server. Also screens popping up at the console often don't appear via the remote connection. This has consequences:

1. If you need to run a Windows application on the server, and you start it from the console, the application GUI won't appear on the Terminal services connection desktop. If you start the same application via the terminal services connection you'll end up with two instances of the same application running, which can cause problems.

2. If you terminate a terminal services connection via the Terminal Services Manager, Windows applications being run within that session are usually also closed.

3. If an application error generates an error GUI at the console, when you connect in via the terminal service connection the error GUI is often not there.

These aren't really problems as a server should not really be running standalone application - rather they run services. Services run independently of the logged on user and can be managed simultaneously from both a direct console and remote terminal connection. Also all server errors should generate reports in logs and/or the event log rather than popping up error GUIs.

Out of the box, server remote management via terminal services is great and one of the killer apps that makes Server 2003 so much better than 2000. I love it. But to get the most out of it, you need to be aware that you are not seeing the same desktop as a user sat at the server.

 

Right on Reggie!!
Clap..clap..clap

Execelent execlent posts!

Only thing I can add Grunty is if you do need to connect to the console ( the screen showing on the actual monitor of the sever) then make a shortcut to this

mstsc -v:nameofserver /F -console
(Note this only works with Svr 2003 or possibly Svr 2008)

the /F is optional and invokes full screen.

OK on your pings to confirm! When you did ping, you did ping both name and IP?

And did you confirm the DHCP Client service was starting on the station that retrievied the 169.xx.xx.xx IP?

The only reasons I can think of for this to happen (if NIC and cable is OK) is cable unpluged or DHCP Client service not starting or in fact you do have a DHCP issue on the server. I would find out or it may bite you later!

Mike

PS planning a little trip to the Mainland huh?

 

Hi Grunt

There is one other process that may help diag or cure this DHCP issue if it is not the station.

Temporally enable hardware DHCP on the router at that location.

You would still need to catch someone there in case it did not work to set it back on the PC.

If it does set a 169.xx.xx.xx on the station again by not retrieving a DHCP IP from the server or router then you have an issue with that PC.

Also if no one is there, if it retrieves a 169.xx.xx.xx you may can use a port scanner on the 169.xx.xx.xx subnet to find the live IP.

Mike

 

Hi Mike & Reggie, Thanks for all your help

The dhcp client service seemed to be running on the pc,

The DHCP server service also seems to be ok but that still needs to be checked - something is falling over somewhere anyway.

The server is multihomed (2 cards I will eventually team) but both have consecutive IP's for now and both are bound to the dhcp service.

The problem is now not urgent. It turns out that a colleague will be there in a couple of weeks, (my manager - pulled rank to get there!) well before any users start working so we can test then. It would be good to have a list of things to check though.


Just a thought, but as the server is multihimed, could I set one card to dhcp client? would it give itself an address?

I absolutley dare not lose it from the LAN, it is replicating data that must continue - I can restart, but it must be available most of the time, but I will try with a test machine with 2 NIC's here and see what heppens.

Thanks again for your help.


PS - already got a trip to the mainland to pick up the vehicle, that's where I was yesterday. Unfortunately it is not mine, and it had to be carried in a ferry, Liverpool to IOM is a bit out of range for it.

 

I figured it was too much of a trip to the mainland I was jesting!

Well as things are working now I think with someone on the other end you will be able to iron out these issues.

Good luck

Mike

 

Alarm bells!!!!!!!!!

Are both NICs connecting into the same network? If so this could be the source of the problems. You should only connect two connections into the same network if they are teamed.

The problem is broadcast (and worth pointing out that DHCP relies heavily on broadcast). Basically there is nothing to stop broadcasts going out of one NIC and coming back in on the other NIC. The result is you get the server responding to its own broadcasts.

Disconnect one of the network connections and see if that sorts the problem out!!!!!