Petergal's SBS Blog

Providing an insight to the day to day technical issues a Microsoft SBS Support Engineer faces.

Blogs

The local policy of this system does not permit you to logon interactively

  • Comments 5
  • Likes

This is not a fun error to greet you after you enter your administrator username/password at the SBS2003 console!  The popup is:

 

The local policy of this system does not permit you to logon interactively.

 

Note this error is completely different than:  The system could not log you on.  Make sure your user name and domain are correct, then type your password again.  Letters in passwords must be typed using the correct case.

 

Registry hives had been swapped, a "parallel" install of Windows 2003 Server was already in-place on a separate partition. The “cause and effect" here was that a popular antivirus software package was installed on the server that required a reboot after the install completed.  The server was dutifully rebooted and the user was presented with the "The local policy of this system does not allow you to logon interactively" message.  The obvious assumption was that the install caused the problem, thus the registry hive swapping and parallel install.  Actually, the registry hive swapping complicated the issue.  The server was in such an unhappy state that it would simply reboot after putting in the Administrator username/password.

 

The key to this message is that it is saying "Hey, there is a policy somewhere that is screwed up and you can't logon!".  It is NOT saying "you fat-fingered your password".  The “fat-fingered password” error is:  The system could not log you on.  Make sure your user name and domain are correct, then type your password again.  Letters in passwords must be typed using the correct case.”  It could mean that the Administrative Assistant is trying to logon to play Solitaire!  Hey, the performance of Solitaire on a RAID array is awesome!  We assumed the account we were trying to logon with was actually the “real” Domain Administrator account.

 

Here’s how we got out of this quagmire!  First, we need to get back to a “know bad state”.  Since I knew the issue got worse after registry hives were swapped, the first order of business was to get the registry back to it’s “happy place”.  I got Office Live Meeting --- http://office.microsoft.com/en-us/FX010909711033.aspx -- access to a workstation on the LAN.  I then started poking around.  Could I ping the server?  Yes.  Could I open Event Viewer on the workstation and connect to the server’s Event Viewer?  Yes.  Could I open the Services MMC on the local workstation and connect to the server’s Services MMC?  Yes.  Could I open Regedit on the local machine and connect to the server’s registry?  No.  Could I open shares on the server via \\servername?  Yes.  Could I drill down into the shares?  Yes.  Could I access \\servername\c$?  Yes.  I went to \\servername\c$\windows\system32\config and I right clicked on config and hit Properties.  What’s that?  A “Previous Versions” tab at the top!!  This tells me that Shadow Copies are enabled on the C drive.  This is a very good thing!  What are Shadow Copies?  It allows you to copy/restore files on a partition if it is enabled.  Click here for some TechNet stuff on VSS/Shadow CopiesOn the Previous Versions tab, I selected a time/date prior to the install of the antivirus package (two days prior) and clicked COPY.  I chose a folder on the local Windows XP workstation and hit go.  After about 30 seconds, I had a copy of the “good” registry sitting on the Windows XP desktop!  Now...how to get it back into the right place on the server?  I can’t simply copy and overwrite as the files are in-use.  I copied them to the server’s F drive.  I then rebooted the server into the “parallel” install, opened c:\windows\system32\config on the original install, renamed “software” to “software.peter” and “system” to “system.peter”.  I then copied the “system” and “software” files (hives) from the folder on the F drive to the c:\windows\system32\config directory and rebooted the server into the SBS install.  I did not mess with the other registry hives as they were probably fine.  Now we are back to our “known bad state” getting the error ” The local policy of this system does not permit you to logon interactively”.  (I was told that Remote Desktop to the server did not work as well, same error.)  Now what?  I tried to access the shares again on the server and was greeted with a “username/password” prompt.  That’s not good.  Hmmm…  I then loaded “adminpak.msi” (which can be found on almost any Win2k or higher install CD…or various other locations) on the Windows XP client machine, which included the Active Directory Users and Computers snap-in.  I then launched Active Directory Users and Computers on the Windows XP machine, which hung for about 30 seconds and then popped up this lovely error:  “Naming Convention could not be located because:  No authority could be contacted for authentication.  Contact your system administrator to verify that your domain is properly configured and is currently online.”  Geeze!  Can’t a Support Engineer catch a break?  I found out two things then:  1)  we were logged onto the workstation with the local Admin account, not the Domain Administrator account, and 2)  the parallel install of the server had the same computername as the SBS box.  The client machine was confused!  A quick ipconfig /all confirmed my suspicion; the workstation was pointing to the ISP for DNS.  We set the client to point to the SBS box for DNS, rebooted the client machine and logged on with the Domain Administrator account successfully.  We were also able to open up Active Directory Users and Computers from the Windows XP workstation.  A quick look around revealed the Administrators group had been added to the “Remote Operators” group.  Referencing this article, we removed the Administrators group from the “Remote Operators” group and were able to logon successfully!

 

There are some important takeaways from this experience:

1.     Always enable Shadow Copies on the system partition!  Right click on the C drive, Properties, Shadow Copies, ENABLE for the system partition.  The SBS install routine will enable Shadow Copies on the drive that was selected during the original install for “Users Shared Folders”.  So if you (like many people do) put the Users Shared Folders on a separate drive, Shadow Copies are NOT enabled on your C drive, go turn them on.

2.     If what you are being told “caused the problem” just doesn’t sound right…you probably are!  Keep digging for more information.  Keep asking open-ended questions.  At the end of this support call, we found out that the group membership of the Administrators group was changed earlier in the day prior to the antivirus install and they had never logged off/rebooted. 

3.     Always know how to install and use the remote administration utilities from a client machine.  Click here for more info.

4.     Know your error messages!  “The local policy of this system does not permit you to logon interactively” is an error relating to a policy somewhere.

5.     Know what you can and cannot do with “Shadow Copies”. 

·       I personally NEVER choose “Restore”!  I always choose COPY and select an alternate location. 

·       The Previous Versions tab will only be available if you access the folder via UNC path ( ie, \\servername\sharename ). 

·       You don’t have to be at a client to get access to Previous Versions.  From the server itself, you can do \\servername\c$ and have access to Previous Versions for every folder on the C drive

·       You cannot “restore” or “copy” files, only folders

·       I have personally used “Previous Versions” to restore the following as a LAST RESORT:  Active Directory (c:\windows\ntds\ntds.dit), the IIS Metabase (c:\windows\system32\inetsrv\metabase.xml) and my favorite…Exchange databases (c:\program files\exchsrvr\mdbdata\priv1.edb, priv1.stm, pub1.edb and pub1.stm)

·       Even if you have Shadow Copies turned on, they can be deleted in the blink of an eye by the Operating System.  I believe there is an article that explains this in detail.  Bottom line, if Shadow Copies are enabled on a drive and that drive experiences high I/O, the Shadow Copies may be deleted. 

 

 

 

As always, thanks for stopping by…

 

Petergal

 

Comments
  • What exactly was the resolution to this?

  • Excellent!  Such a simple concept too.  My lack of IT experience is showing here, but this used to make me frustrated because until reading your article I never thought to go onto the server and type \\servername\d$ to access my shadow copies.  I always went to a client and did it there.  DUH!!  Thanks for posting that!

  • tears of joy stream down my face as i apply what i read here and it works.  kudos. kudos...

  • PingBack from http://www.keyongtech.com/4219406-logon-interactively

  • PingBack from http://www.keyongtech.com/4187247-users-cant-log-in-urgent