Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

up vote 0 down vote accepted

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.

share|improve this answer
    
He moved it back using windows copy. I will check permissions and get back to you. –  Britchie Jan 13 '12 at 3:32
    
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 Jan 13 '12 at 3:40
1  
You 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 Jan 13 '12 at 4:51
    
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 Mar 25 at 23:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.