Event ID 1000 Sysvol Rep & Access Problems after P2V VMWare ESX 3 Conversion

The problem comes from doing what Windows considers a "non-authoritative" restore. Because of this the trusted mappings between the SYSVOL folder and the System State are lost.

In previous experience a demotion followed by a promotion fixes the problem. I noticed that when you did that you chose to redirect the SYSVOL folder. I would recommend keeping most of that default. Try the following.

1. Demote said server
2. Locate current SYSVOL folder (standard path is under the Windows Directory)
3. Delete the SYSVOL folder
4. Depending on your site structure and replication schedule give the domain time to process the demotion, look through DNS and sites and services to make sure the referenced server is no longer present
5. When you are sure it is gone promote the server using dcpromo and reboot, if everything is configured correctly you should get a message about the server being promoted and joined to a site based on its subnet
6. Reboot
7. Once you have rebooted locate the SYSVOL directory, if it has not been created you have a bigger issue. If it has been created you should see a structure to this.

SYSVOL
-domain
----policies
----scripts
-staging
-staging area
-sysvol (shared)
----"FQDN"
--------policies
--------scripts (shared)

It might take some time for the replication to occur depending on your replication schedule and netowrk topology.  Once replication has happend the shares will appear and you should be good.

If you look under the File Replication Service Log in the Event Viewer you should see specific events pertaining to this replication process. Eventually an event will occur explaining that FRS is no longer preventing this DC from being a DC.

Hope that helps.

whoam,

Try the following and answer the below questions so I can provide more info?

I am assuming your environment has several DCs at this site, am I correct? How many? Can you break down the Operations Masters for the DCs at that site? Which are global catalog servers?

Ping "domain.com" (your FQDN here) and note the reply - is the reply from the expected server as noted above?

Type \\"domain.com" (your FQDN here) - is there a browsable SYSVOL folder and is it populated correctly?

What DNS servers are you using for the now member but once promoted server?

Is it essential that this server be in production?  Do you have an Enterprise trust setup and is this a CA?

You may just want to deploy an additional DC and simply remove the previous from the org.

Hope this info gets us closer.

Whoam,,

 I would not power on the physical server as its PM state is not one the domain would recognize at this moment since being demoted.

Try the following. Lets call your "messed up DC" dc02.domain.com

1. Check AD Sites and Services from the main DC for any references to dc02.domain.com. Sometimes the demotion will not removed these entries.

2. On the main DC open the DNS MMC and look through the AD polutated forward lookup zones, make sure the previous server is not present as a Service Host anywhere.

3. Remove DNS from dc02, set the staic primary dns server on the primary NIC to the main DC and reboot

4. Reinstall DNS, set the primary DNS server back to the localhost and add the secondary as the main DC

5. Reboot.

6. Verify that the Subnet Mask on both servers is the same (example) 10.0.0.1/24 and 10.0.0.2/8, make sure they have the same subnet mask.

7. Look under the Windows DIR and wherever else you referenced the SYSVOL folder previously, make sure there are no lingering SYSVOL folders. If there are delete them.  Look at the security setting for the Windows Directory, are there any unknown SIDs?

8. Run dcpromo and promote the server to a DC in the current domain, make sure to select the default placements for AD and the SYSVOL share.  Verify that the server is assigned to the correct site. If a reboot is requested then reboot.

9. On the main DC verify that dc02 has been created in AD Sites and Services, force replication to your sites (are you hub and spoke?)

10. WAIT.......Verify replication of the new DC to all Sites, do not pay attention to any errors in the event viewer on dc02 until replication has completed

11. Once dc02 is visible in all sites go to ADS&S on dc02 and make it a global catalog server

12. WAIT......Verify replication of the GC setting to all sites, do not pay attention to any errors in the event viewer on dc02 until replication has completed

13. Look through your DNS AD forward lookup zones on the main DC and verify that DC02 shows as a gc host throughout your sites.

14. Clear all event logs and restart dc02

15. Login and look for the newly created SYSVOL folder, are all GPOs there as expects under both the primary domain folder and the sysvol share?

16. Look at the Event Viewer for errors, what is there?

Let me know how it goes.

AJ

whoam,

Do you have the ability to create a new VM and promote it to DC status. If you have issues with a freshly installed server then you must have somethiing going on with AD elsewhere.

Let me know if you can do that and get back to me when you can.

Also, what version of Windows Server are you running on the other DC's? What service pack?

Are you seeing client events pretaining to gp objects not being accessible?

-alexjasper

whoam,

Have you tried promoting a clean install of Win2K SP4? Does this server run anything else (DHCP or otherwise at this point)?

If you are dead set on "finding" the answer I understand but you may be better off just going from a fresh install and powering off the bad VM.

Also, are there any other limitors keeping you from upgrading to 2K3 throughout and raising the domain functional level? (Exchange, licenensing, etc...)

You may also want to try the following.

1. Demote bad DC
2. Uninstall DNS
3. Disjoin from domain
4. Login locally and remove all domain profiles
5. Rename computer
6. Confirm that the computer is no longer in ADU&C and if it shows disabled then delete it
7. Join computer to domin under new name and confirm that it is added under the computers OU
8. Install DNS
9. Promote
10. TEST

To me it seems as if this computer has lost its TRUST to the domain, which could be preventing replication. A disjoin rejoin will hopefully recreate that trust.

Let me know how it goes.

-alexjasper