Link to home
Start Free TrialLog in
Avatar of JojoSantovenia
JojoSantovenia

asked on

Can you describe what steps you would take if you receive a call that a User can’t login to the domain, but the Network Card (NIC) has a green light illuminated?

User is using Windows 7. System ip address can be pinged.
ASKER CERTIFIED SOLUTION
Avatar of Kimputer
Kimputer

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of JojoSantovenia
JojoSantovenia

ASKER

Usable solution, thanks!
Ok, if I cover anything you already tried, forgive me.  Here's what I do.

(assuming the DC is on the same LAN as the client)  

1)  Ask the user what the specific error is.  If they don't know, I remote in to see the error for myself.  Common errors:

a)  No Logon Server is Available to Process Your Request (This points to a network issue of some sort, it may not just be connectivity, it could also be DNS.  If the client is resolving the DC incorrectly with DNS, or can't reach the DC, then you'll get this error)

b)  Username or Password is Incorrect

c)  Account locked out

If it's b) or c), then I log into the DC and reset their password, check the box to unlock the account and force password change on login.

Then I remote into the end user's machine and then ask them to log in with the new password while I watch (I want to see what they are putting in as the username as well, check for caps lock being on, and I watch carefully when they type in the password to make sure that the last three characters go through (I use an easy to spell word followed by 123 at the end for the generic reset password).  

The reason for this is that the user may have their NumLock turned off, and are using the keypad to input the numbers portion of the password.

If this works, then I walk them through (or watch them) change their password to something else, and stay remoted in until the user profile loads and I get the green light from the user that they are ok.

If that doesn't work, or if it's a), I remote into the user's machine and attempt to log in with my domain credentials.  If that works, I cycle back to step b above, and this time I put in the credentials instead of allowing the end user to do so.  If it doesn't work, then I log in as the local administrator.

From this point forward, all steps are done on the client machine unless otherwise noted.

1)  FROM the client machine, ping the DC IP

->  If it doesn't, then it's a networking issue between the client and the DC.  I may run a tracert to see where the issue may lie (depending on the complexity of the network...)

->  If it does work, move on.

2)  FROM the client machine, ping the DC hostname to see if it resolves to the correct IP

->  If this doesn't work, it will probably be one of three things, which I will then check.  As a secondary test, I also try to ping another machine on the same LAN as the DC and the client FROM the client by both IP and hostname, to see if they resolve properly.  This will give me some clues to work with as to what the exact issue is.

   a)  The ping to the hostname doesn't resolve at all.  I check the DNS settings on the client machine to be sure it's pointed to a DNS server that has the proper AD entries, generally a DC (or on a small network the ONLY DC).

   b)  The ping to the hostname does resolve properly, but the pings fail.  This points to a networking issue between the client machine and the DC.

   c)  The ping to the hostname does NOT resolve properly, but it does resolve with an IP, just the wrong IP (this can happen on multihomed Domain Controllers).  I check the DNS settings on the local machine.  If the DNS settings are incorrect, I fix them and try again.  If they are correct, I open the command line and run ipconfig /flushdns.  Then try again.  If it still fails, then I log onto the DNS server and check the DNS settings (specifically, the A record).  Once checked, I go back to the client, run ipconfig /flushdns again and try the ping again.  If it works, then I log out and let the user try to log in.

->  99% of the time (at least on my networks), by now these steps would have resolved the issue.  If all that fails, I move on

3)  I reboot the machine and try to log into the domain again using MY credentials or the reset user credentials (heck, I know the password, I just reset it!)

->  If this doesn't work, I move on.  I log back in as local admin.

4)  I open compmgmt.msc and go to local users and groups.  I open the administrators group (which should have domain groups in it, like domain admins), and if I see SIDs there instead of resolved names (so, a bunch of numbers instead of the nice clean name), this confirms the machine is having an issue communicating with the domain.

5)  I re-check the DNS settings on the local machine.  Both in the command line (ipconfig /all) and in the network interface itself (assuming DNS isn't assigned through DHCP, which is the best way to do it).

From this point forward, I try to ping the hostname of the AD server between each step.  Also, at this point, I must have the user on the phone.

6)  I ask the end user to type ipconfig /release.  Count to 30, then ask them to type ipconfig /renew.  This will generally kill my remote session.  Before asking them to do this, I setup a ping -t to see when it comes back up.  However, that requires that you have static assignments either on the client, or through DHCP reservations.  On my network, I have that (the latter), so I know their leased IP will be the same when it comes back up.  I remote back in.

7)  I repeat all the tests from above, starting at step 1.

8)  IF IT STILL IS FAILING....I give it one more reboot and start again at step 1.

9)  IF IT STILL IS FAILING....I walk over to the client machine, and beat it with a sledgehammer.  Now I have a reason to replace it with a new one.  :P