Announcement

Collapse
No announcement yet.

There are currently no logon servers available to service the logon request

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • There are currently no logon servers available to service the logon request

    Environment:
    Windows Server 2012R2 std
    Roles: AD/DS, DNS, Print Server, RD Licensing,
    Windows 7/8 Pro workstations

    Scenario: one user acct that I can"t get to log-in to the domain. It doesnít matter which computer I use to log-in. I get one of the two error messages below:
    1. There are currently no logon servers available to service the logon request --or--
    2. The security database on the server does not have a computer account for this workstation trust relationship
    Tried:
    1. Removing/re-adding user account (server)
    2. Removing/re-adding computer account (server)
    3. Unjoining/rejoining computer to domain
    4. Setting workstation credentials
    Any thoughts on how to resolve this problem? Itís just this one account out of 12 this is giving me fits.

    Thanks ~ Jae

  • #2
    Has the user ever been able to log on?
    Can you clarify Step 1 (remove/re-add computer account) - do you mean delete the account in AD or something else?
    If you create a brand new user account, does it have any problems - if not, I would just delete the problem one in AD and create a new one (same name, but will have a different SID)
    Tom Jones
    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
    PhD, MSc, FIAP, MIITT
    IT Trainer / Consultant
    Ossian Ltd
    Scotland

    ** Remember to give credit where credit is due and leave reputation points where appropriate **

    Comment


    • #3
      Not since this server was put into production. #1- I deleted the account and then recreated it on the server. Tried creating a new account and I get the first error msg. Everyone else can log fine. I have more than enough licenses for users and devices.

      After I posted yesterday I had two accounts (one is an administrator acct. not "the Administrator acct.") that have been connecting to the server with no problems spit out the 2nd error msg. Is there a setting or something that I'm missing that would cause these computer to suddenly lose the connection between the server and workstation? These are wired computers not wireless.

      Comment


      • #4
        When you say "on the server", do you mean in Active Directory?
        Have you checked the client PC clock is within the allowed skew (typically 5 mins) of the DC holding the PDC emulator FSMO?
        Tom Jones
        MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
        PhD, MSc, FIAP, MIITT
        IT Trainer / Consultant
        Ossian Ltd
        Scotland

        ** Remember to give credit where credit is due and leave reputation points where appropriate **

        Comment


        • #5
          Yes it was changed in AD. There was a 1m 38s difference in time. I've synced it to where there is a 5s difference.

          I did unplug the network cable and log in, once I'm logged in I can connect to the mapped drives and do whatever I need to do. But if I log off, switch user or restart I'm unable to logon unless I unplug the cable. Any other thoughts??

          Comment


          • #6
            If you restart the domain controller do you see any warnings etc., in the System event log?
            A recent poll suggests that 6 out of 7 dwarfs are not happy

            Comment


            • #7
              Originally posted by Jae View Post
              I did unplug the network cable and log in, once I'm logged in I can connect to the mapped drives and do whatever I need to do. But if I log off, switch user or restart I'm unable to logon unless I unplug the cable.
              This is something of a classic. The trust relationship between the domain controllers and the workstation in question has somehow become corrupted, and you'll have to log in to the computer with an admin account and have it re-join the domain. It happens from time to time, and to this day, Microsoft has no fix and no real explanation as to why it happens. In my experience, Windows 7 clients seem particularly vulnerable.

              The reason you can log in when you unplug the cable is that you've logged in using that account previously, so the PC will allow the use of cached credentials when no domain controller is available. And as long as the AD account has the same password as the one that's cached on the PC, you'll be able to access network resources when you plug the cable back in. GPOs won't be processed, though, since the machine account can't log on.

              Tip: When re-joining the domain, try just changing the domain name from <fqdn.domain> to <NETBIOS_NAME> (the shorter, all-caps domain name). You will then be able to re-join in one operation rather than having to reboot, log on using a local account with administrative privileges, join the domain, and reboot again.

              Comment

              Working...
              X