Users unable to logon to only one server in domain through RDP

0

Today one of my colleagues decided to try and free up some space by taking the entire users directory from our Windows Server 2008 R2 installation to another drive. This has caused the problem of users not able to logon to the server at all, even when the directory was replaced. Through some trial and error I found that I could once again logon to the server if I renamed the ntuser.dat file. This only allows for one logon and only to a temporary profile. Regedit shows that renaming the ntuser.dat file will create a new registry key for that user with the same extension.

The problem is that this server houses a business critical application and needs to be available to everyone through RDP. Aside from recreating all users, is there any way to get the logon's working again?

We are in a domain and the domain controller is on another server, so we have access to basically everything except the RDP server.

Does anyone know how to fix this?

Britchie

Posted 2012-01-13T03:20:04.330

Reputation: 103

Answers

0

If all he did was move the folder then boot from a 3rd party OS (ie: a Linux LiveCD of some kind) and move it back.

Be wary of file permissions when you move it.

If that's what you did when you 'replaced' the directory, then double-check ownerships and permissions.

Ƭᴇcʜιᴇ007

Posted 2012-01-13T03:20:04.330

Reputation: 103 763

He moved it back using windows copy. I will check permissions and get back to you. – Britchie – 2012-01-13T03:32:02.007

ntuser.dat file permissions seem to be ok. Each user has full control over their own file, but the owners are marked as system. Is this normal? – Britchie – 2012-01-13T03:40:14.213

1You definitely helped out. I grabbed an ntuser.dat file from another machine and replaced the messed up one and switched the owner to the login name and voila! Everything was back to normal. Now I have a long night copying files over and setting permissions. – Britchie – 2012-01-13T04:51:56.163

Hopefully this has caused you to learn a valuable lesson, do not ever make major configuration changes to a server that is business critical without testing the planned change first. You got lucky and found a quick fix, but this situation could have been much worse I have seen changes like this being made to a live environment go far worse than this. – Richie086 – 2014-03-25T23:38:48.467