We have 2008 server setup as PDC and 2k server as BDC. The 2008 server won't let us login to our 2008 TS (access denied). All roles were set to the 2008 server before the fail. I set the global catalog to the 2k box to permit user and share logins, but the TS still won't let anyone login with access denied.

DNS has no info and all options are greyed out. I set DNS starup to manual and rebooted. After restart, I startup DNS and it throws event id 708 DNS server did not detect any zones. Then 4000 DNS was unable to open Active Directory. Then 4521 DNS started with error 13 unable to load zone...

I was wondering if this seems beyond repair and what would happen if I dcpromo'd it out of the domain, transferred the roles and then brought it back in after a day or two. The 2k box is handing out logins and serving files pretty much normally except it also won't authorize TS logins. Otherwise, the domain is alive - just barely.

Now we need to figure out the if the FSMO roles are correctly sourced and all the DCs agree on who is holding them:

On each DC run the following two commands:

NETDOM QUERY FSMO

With this command, all of the servers should agree on which server is holding the FSMO roles.

NET SHARE

Each domain controller should have the NETLOGON and SYSVOL shares.

If that all checks out then you should be back in a healthy state. Review the DNS and AD event logs for any errors, particularly after a reboot of any of the DCs.

Now as to the being able to access \\fqdn on the DCs but not \\netbios then check your IP settings on the DCs is they are statically assigned. Look at the IPv4 properties under DNS and see if you have the 'DNS Suffix for this connection' defined. If it isn't, then enter your DNS domain name. That should resolve the netbios name query issues.

Ideally they should be set to an alternate DNS server with themselves as the last entry in the DNS list.

Do you a DNS zone on the 2K box? If so you could always export it from there using dnscmd and then import it into your 2K8 box and make it primary. I'd advise doing a full ad backup first.

Interesting. I thought that AD DNS was supposed to point to itself.

Yes, the 2k box is setup with an AD zone. I'll read up on the dnscmd and see if I can make any progress.

After digging further, I see that FRS is also not working. I wonder if my SYSVOL is also fragged. I'm thinking that I might be able to dcpromo out the 2008 box, force the FSMO roles back to the 2k box, wait a few days for the domain to settle down and then reload the 2008 box from fresh and move the domain back to the 2008 box as role holder. In the mean time, I'm getting pricing on moving all my servers to 2008R2 and may be ok with leaving things as they are and just bring R2 in as the role holders <- I intend to load two this time.

First, they aren't PDCs and BDCs anymore.. they're all just DCs now and it;'s been that way since Windows 2000.

Anyway:

Sounds like your Windows 2000 AD and replication environment wasn't healthy and the new Win2008 server never dcpromoed up properly.

To validate: Simply check to see if you can access the sysvol and netlogon shared on the new 2008.

There's really no point in DCpromoing it down as you can simply fix whatever is preventing the DC replciation from completing from the existing 2000 AD servers.

HINT: It's likely a name resolution (aka: DNS) problem :)

Check your DNS settings on the 2000 PDC emulator server and make sure they are pointed to themselves as primary and the other as secondary , then for the other 2000 DC, point it's DNS at the PDC emulator as primary and itself as secondary.

Next set the 2008 server to the PDC emulators DNS server as primary and the other 2000 server as secondary.

I know this is contrary to what you've read, but you need to point everything to trhe PDC emulator to allow all the DNS entries to be the same and allow the replication to complete and become healthy again.

Now as to the FSMO roles: where they transferred gracefully to the new 2008 DC or were they seized? If they were seized then you'll need to seize them back to the 2000 server that still have a valid copy of AD, then transfer them gracefully once everything is healthy again.

First, they aren't PDCs and BDCs anymore.. they're all just DCs now and it;'s been that way since Windows 2000.

I understand your comment about PDC, BDC. Would you rather I use FSMO role holder, Schema Master, GC? In this case, the older monikers may suffice.

Anyway:

Sounds like your Windows 2000 AD and replication environment wasn't healthy and the new Win2008 server never dcpromoed up properly.

To validate: Simply check to see if you can access the sysvol and netlogon shared on the new 2008.

There's really no point in DCpromoing it down as you can simply fix whatever is preventing the DC replciation from completing from the existing 2000 AD servers.

HINT: It's likely a name resolution (aka: DNS) problem :)

Check your DNS settings on the 2000 PDC emulator server and make sure they are pointed to themselves as primary and the other as secondary , then for the other 2000 DC, point it's DNS at the PDC emulator as primary and itself as secondary.

Next set the 2008 server to the PDC emulators DNS server as primary and the other 2000 server as secondary.

I know this is contrary to what you've read, but you need to point everything to trhe PDC emulator to allow all the DNS entries to be the same and allow the replication to complete and become healthy again.

DNS is back. I set the DNS service on the 2008 box to startup ->manual and pointed both servers to the 2k box and let it cook until evening. On the 2k box the WINS-R tab resolved My 2008 box to an internet address rather than my local one. I fixed this manually. I started DNS on the 2008 box and the zones came back.

Now as to the FSMO roles: where they transferred gracefully to the new 2008 DC or were they seized? If they were seized then you'll need to seize them back to the 2000 server that still have a valid copy of AD, then transfer them gracefully once everything is healthy again.

The roles were not transferred correctly and I seized them using the guide I found at http://www.petri.co.il/seizing_fsmo_roles.htm This was not done recently and have had little problems prior to two Saturday's ago. (6/17/12).

Right now, I can access \\fqdn and can navigate freely from my laptop. I cannot do this from either domain controller. If I do a runas cmd and run a net use, here is what I get

Now we need to figure out the if the FSMO roles are correctly sourced and all the DCs agree on who is holding them:

On each DC run the following two commands:

NETDOM QUERY FSMO

With this command, all of the servers should agree on which server is holding the FSMO roles.

NET SHARE

Each domain controller should have the NETLOGON and SYSVOL shares.

If that all checks out then you should be back in a healthy state. Review the DNS and AD event logs for any errors, particularly after a reboot of any of the DCs.

Now as to the being able to access \\fqdn on the DCs but not \\netbios then check your IP settings on the DCs is they are statically assigned. Look at the IPv4 properties under DNS and see if you have the 'DNS Suffix for this connection' defined. If it isn't, then enter your DNS domain name. That should resolve the netbios name query issues.

Now we need to figure out the if the FSMO roles are correctly sourced and all the DCs agree on who is holding them:

On each DC run the following two commands:

NETDOM QUERY FSMO

With this command, all of the servers should agree on which server is holding the FSMO roles.

Netdom points to the 2008 box on both dc's

NET SHARE

Each domain controller should have the NETLOGON and SYSVOL shares.

Net share shows both netlogon and sysvol in the list

If that all checks out then you should be back in a healthy state. Review the DNS and AD event logs for any errors, particularly after a reboot of any of the DCs.

I've not rebooted yet, but I do have some errors in the event logs. I'll restart tonight and post back any errors.

Now as to the being able to access \\fqdn on the DCs but not \\netbios then check your IP settings on the DCs is they are statically assigned. Look at the IPv4 properties under DNS and see if you have the 'DNS Suffix for this connection' defined. If it isn't, then enter your DNS domain name. That should resolve the netbios name query issues.

To clarify - I can access \\fqdn\* from my laptop not the dc's. From either dc, I get access denied doing a start run. I can however browse to the folders locally and navigate freely from the dc's. Browsing the \\fqdn\netlogon and \\fqdn\sysvol from the dc's fails. Again, I'll post back after I restart tonight unless you have a suggestion.

Scott

EDIT: net use shows netlogon, sysvol and srv_2008 as disconnected and I can't connect using net use either unless I'm using it wrong.

Have you checked the security event log? Turn on audit logging to the max and see if that gives any pointers. Try Kerberos logging too as I had issues with spns and that really helped. Try turning the firewall back on and logging on the firewall. I take it these machines are on the same subnet?

and resetting the domain user password, after a restart on both dc's sysvol and group policy is now available and online on the 2008 box. Replication and FRS is still not working but may be a moot point since I intend to dcpromo out the 2k box and bring in 2008 R2 for my boss dc.

I think that I'm going to let this cook overnight and see what's what.

Thank You sooooooo much. I really wanted this at least mostly fixed before I brought in the new dc's since my joy at rebuilding and reloading things died about 15 years ago.

You need to get FRS (sysvol) replication working before you try to DCpromo anything else down or up. If you DCpromo down the 2000 system without having a funcitonal and replicated sysvol, you'll lose your default domain and default domain controller polices (along with all the rest of your group policy objects) which anyone will tell you is not exactly fun to recover from.

Before you do anything, make sure that name resolution using both netbios and FQDN is working. between the DCs.

Then repeat that same step on he 2000 DC trying to access the 2008 machine.

Next, check the FRS log on each DC and upload the last five events from each DC. What you want to see is event 13516 as the last logged event on all of them.

Also, do the same thing with the Directory Service log so we can look for any errors there.

If replicaiton has been broken on the 2008 server for any length of time (more than 30 days or so), it possible it has tombstoned itself and you'll need to use the burflag trick to reinitialize it and get it to start replicting again.

You need to get FRS (sysvol) replication working before you try to DCpromo anything else down or up. If you DCpromo down the 2000 system without having a funcitonal and replicated sysvol, you'll lose your default domain and default domain controller polices (along with all the rest of your group policy objects) which anyone will tell you is not exactly fun to recover from.

Before you do anything, make sure that name resolution using both netbios and FQDN is working. between the DCs.

Then repeat that same step on he 2000 DC trying to access the 2008 machine.

Next, check the FRS log on each DC and upload the last five events from each DC. What you want to see is event 13516 as the last logged event on all of them.

Also, do the same thing with the Directory Service log so we can look for any errors there.

If replicaiton has been broken on the 2008 server for any length of time (more than 30 days or so), it possible it has tombstoned itself and you'll need to use the burflag trick to reinitialize it and get it to start replicting again.

I'll do that...tomorrow. The replication has been fragged since last Saturday (6/17) starting around 5:30 AM. Hopefully this can hold until tomorrow. Right now logins and shares are working nicely and I can access the GPO's normally. I'll definitely follow your advise and hopefully get this back to working 100%.

In all honesty, at this point I'm not sure. I can see both servers in both consoles and can access their properties. The 2008 box is the FSMO role holder for all roles, schema master and global catalog on both DCs.

If I bring up the Operations Masters dialog to transfer roles, on DC2 the dialog looks normal. Both DCs are available. However, bringing up the same dialog on DC1 shows only DC1(itself).

I'm getting the feeling that I have one>way replication or at least partial replication in one direction.

Yesterday after I reset the domain administrator password, I pointed the DNS servers back to DC1 on both DCs. At this point should I have them pointing at each other for primary DNSs or should I leave them pointing at DC1?

This event is concerning - So what are the REEFS1 and REEDC machines? Are both online and operational?

From REEFS1 to REEDC
Naming Context: DC=21CEG,DC=com
The replication generated an error (8453): Replication access was denied.
The failure occurred at 2012-06-28 09:55.15.
The last success occurred at 2012-06-18 00:46.57.
375 failures have occurred since the last success. The machine account for the destination REEDC.
is not configured properly.
Check the userAccountControl field.
Kerberos Error.
The machine account is not present, or does not match on the.
destination, source or KDC servers.
Verify domain partition of KDC is in sync with rest of enterprise.
The tool repadmin/syncall can be used for this purpose.

This event is concerning - So what are the REEFS1 and REEDC machines? Are both online and operational?

From REEFS1 to REEDC
Naming Context: DC=21CEG,DC=com
The replication generated an error (8453): Replication access was denied.
The failure occurred at 2012-06-28 09:55.15.
The last success occurred at 2012-06-18 00:46.57.
375 failures have occurred since the last success. The machine account for the destination REEDC.
is not configured properly.
Check the userAccountControl field.
Kerberos Error.
The machine account is not present, or does not match on the.
destination, source or KDC servers.
Verify domain partition of KDC is in sync with rest of enterprise.
The tool repadmin/syncall can be used for this purpose.