0

My organization used to have a Windows 2000 Server Ed. Domain Controller with DNS role also installed. It serviced 5 other servers and about 15 workstations. A few months ago, the motherboard went out and as it was a fairly old server anyway, my supervisor proposed we install a newer version of Windows Server (finally!) on an Intel NUC5i3MYHE we had just purchased, with the intent of installing some light server roles on it (fileserver, DNS, internal webserver, etc.).

The install of Server 2012 R2 on the box went smoothly, as did adding AD DS and DNS roles, and promotion to domain controller (since the existing domain was now offline due to the old server failure, I set the new DC up as the same domain name, and selected the option "New Forest" during dcpromo.exe).

The first time I put the new DC on the LAN, we had problems with people not being able to log into their computers. I realized my mistake (I have a pretty hectic avg. workday), not setting up the User Accounts in AD, and so promptly took it offline, at which time my end-users were able to log back into their workstations using their old accounts (cached on their local computers as "Offline Files"). For the record, I have not set up forward and reverse lookup zones in DNS yet. As I understand, I need AD DS working first and it is apparently not working (100%, anyway).

A couple days later, I got everyone set up with their same usernames they had had before the original DC crashed, with some requiring new passwords to meet complexity requirements. Here's where the snag is.

The EU's who already had passwords that met the complexity requirements had no problems logging in using their classic passwords. But for those whose password was required to change, they get a message when logging in w/ their old account, something to the effect of "Please lock this computer and sign in using the current domain credentials," which they try, but their machines (XP SP3 and W7, Pro Eds) will not let them in w/ the newly-created passwords, using their classic usernames.

I really do not want to set up a whole new round of usernames and passwords for each user, but I fear that the ones whose passwords did not change aren't logging into the new DC at all, but rather their old "Offline Files," and the users whose passwords did change, are able to access Desktop/My Docs, but only by entering their classic password and accessing the locally cached offline files as well.

FWIW, I noticed in my event log on the new server, Error ID 4013, which I found some info on here: https://technet.microsoft.com/en-us/library/cc735842(v=ws.10).aspx

...but when I follow the link for AD DS Troubleshooting found there, it takes me to a generic "Windows Server 2003/2003 R2 Retired Content" page, which is peculiar because it was a 2012 R2 machine that generated Error ID 4013 and yes, it was the correct one on the link (matched verbiage from my server).

I have tried logging in and out several times on several workstations, w/ various credentials and no luck, I can only get on the domain w/ the old passwords. If anyone can point me in the right direction, I'd be very grateful, I really don't deal w/ AD DS that much as my role in the company has shifted over the years from Network Admin to more of a Web Dev kind of role. I have Event Logs I can give you all, if that will help, the other warnings were RE: ADWS (Web Services) which I'm not sure is helpful, so I didn't include it, but let me know! Thanks in advance for your suggestions!

  • ` I fear that the ones whose passwords did not change aren't logging into the new DC at all. You need to confirm they are/not authenticating with the domain controller. Get the value for SET LOGONSERVER` from one of their computers. Also the output of nltest /dsgetdc:domain.com – Greg Askew Dec 27 '16 at 21:29
  • nltest only worked on the W7 computers (only 2 are W7, the rest (13) are XP and that cmd isn't recognized) but those 2 showed the correct hostname of the new domain controller...ironically (perhaps predictably), those are the only 2 machines that use their local accounts, and do not regularly sign on to the domain. All XP boxes here DO log into the domain daily, and they are showing the old (offline) hostname when I run SET LOGONSERVER, so it seems my suspicion was correct and they're running off the domain caches. – Brandon G Dec 29 '16 at 20:01
0

You haven't re-created your old domain, you have created a domain that has similar names to the old domain.

As you suspect, your people continue to log in with credentials cached to the old domain. When they do, if you look in the Event Logs on their machines, and the DC, you will see problems.

You need have each PC "quit" the old domain, and "join" the new domain.

Make sure you have a local administrator password on each PC before tyring this.

Once the PCs are joined to the domain, and the users log in to the "new" domain, they will get a new user profile. It will look line this:

C:\Users\username

c:\users\username.domainname <- this is your new user profile

This may make people (and you) very unhappy. Use ForensIT to fix their profile. The free version works fine when run individually at each workstation.

If they had offline cached copies of files from shares, you have some cleanup to do there.

Change your thinking of "I'm repairing a domain" to "I'm migrating everything to a new domain, and salvaging what I can".

  • First off, thank you for a very helpful response, E.F. I wish that I had studied AD a bit more in my schooling, but when I started here the domain was already "set" and really didn't become any kind of issue til just lately. With the new DC online, I can't log in to the domain accts, but I logged into a seldom-used machine locally, ran the ForensIT pgm, chose an old domain acct, and it asked if I wanted to "join" the new 1 but the other option was grayed-out, so I picked join and now (XP SP3) I get "The sys can't log you on now b/c the domain X is not avail." when I try the new password. – Brandon G Dec 29 '16 at 20:23
  • N/m, I figured it out. :-) Thank you for your help though, suggesting the ForensIT program was a lifesaver. For anyone else who may stumble across this, the steps that worked for me were 1) Join workgroup (in order to "quit" the old domain/DC) 2) Bring new DC online 3) Run ForensIT User Profile Wizard and find the old cached domain acct you want to retain 4) check "Join" and type new domain in domain field and "Finish". You'll be asked to supply credentials throughout so have them all (local and domains) on hand first. – Brandon G Dec 30 '16 at 20:53
2

You created this problem for yourself by not following the most important two rules of Active Directory:

  1. Never have just one Domain Controller. Two is the absolute minimum.
  2. Backup your domain controllers regularly using an Active Directory aware backup utility.

If you don't have a backup of the old domain controller, do you still have the hard drive? Plug it in to a different computer and boot it up. Get it working again. Then erase your new domain controller and start over with it, but this time add it as an additional domain controller to your domain.

If you can't do that, then you will will need to join all of your EU's (whatever that is) computers to the new domain you created.

And don't even get me started on your choice of computer for your domain controller. An Intel NUC? Are you trying to set yourself up for failure?

  • 1) EU stands for "End-User." 2) When our old server benchmarked ~900 and was maxed at 4GB RAM, and the NUC benchmarks ~3000 and can hold 16GB RAM, (not to mention the old svr was running W2000!) I don't consider that "setting myself up for failure" more like "setting myself up for a much lower power bill" (450W PSU vs. NUC's ~5W). 3) If you hadn't assumed I didn't have backups (your 2nd 'rule' of AD) you might not have suggested a rookie mistake, i.e. "Slap a HDD in a diff box." That is a recipe for a cycle of BSODs, FYI. We use Acronis for server img backups, BTW. & there's no $ for RODC. – Brandon G Dec 29 '16 at 20:14
  • I wasn't saying to resurrect your old DC from the hard drive as a permanent solution. To cleanly fix this problem, you need to get your domain back. So boot it temporarily so you can add a second DC and recover your domain. – longneck Dec 29 '16 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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