We help IT Professionals succeed at work.

New podcast episode! Our very own Community Manager, Rob Jurd, gives his insight on the value of an online community. Listen Now!


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

whoam asked
Last Modified: 2012-08-13
I receintly did a VMWare physical to virtual conversion.  AFter converstion, all seemed well, however, I had event id 1113 so I had to use repadmin / options -DISABLE_OUTBOND_REPLICATION AND repadmin / options -DISABLE_INBOUND_REPLICATION.  That solved the event and allowed relication in sites&services, but I am still left with a netlogon service that pauses on start (manual start command works fine) and a bevy of error surrounding sysvol replication to my DC (w2ksp4).  dcdiag gives  Starting test: frssysvol
    Error: No record of File Replication System, SYSVOL started.
    The Active Directory may be prevented from starting.
 Starting test: kccevent
    ......................... TB105007 passed test kccevent
 Starting test: systemlog
    An Error Event occured.  EventID: 0x0000165B
       Time Generated: 10/02/2007   16:24:11
       (Event String could not be retrieved)
    ......................... TB105007 failed test systemlog

I get an event ID 1000
Windows cannot access the file gpt.ini for GPO  The file must be present at the location <>. (). Group Policy processing aborted.

All AD partitions in replmon are happy.


Watch Question


Oh, and the affected dc cannot see the \\domain\sysvol


I demoted the server, and after a few hours, the problem was solved.  I end through the metadata cleanup, but no record of the server.  I went into site&services, deleted the instance of server.  I went into DNS, removed all but the A record.  I then made sure all this replicated in enterprise.  I then re-promoted the server, even putting sysvol on a different partition, and the problem came back in 10 minutes after promotion/reboot, although there were a few minutes after reboot during which the problem was absent
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.

-staging area
-sysvol (shared)
--------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.



Thanks, but I have tried this to no avail.  Now, when I did demote the server, it was still unable to see \\domain.com\sysvol, error was "this folder was moved or removed."  When it was repromoted (with proper reboots in between) the local sysvol copy repopulated just fine, but no domain sysvol access.  It is currently back to a member server.  I'm thinking of disjoining it from the domain, reboot, rejoin, check \\domain.com\sysvol, then repromote.

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.


We have 5 sites with DC's, the main site had 2 until now, the DC in question was the 2nd DC at the main site.  A small 6th site has no DC.  All DC's are GC's.  FSMO roles are held by the other DC at th emain site.  Pinging 'mydomain.com' gets replies from the DC at the main site (I'm at the main site).  Browsing to \\mydomain.com does show a sysvol and it is correctly populated with policies, DO_NOT_REMOVE..., etc.  The primary DNS used by the now member but once promoted server is the FSMO role holder at the main site where the now member but once promoted server is located.  The now member but once promoted server holds only a few printers, it is not a CA and we have no Enterprise trusts.  

I want to turn on the old physical box today and see, with the network cable disconnected, if the problem was there at that time.


 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) and, 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.




Went through all the steps, even gracefully disjoined, looked at metadata, and rejoined, same issues.  I have scowered the the AD section of DNS with nothing unusual seen.  The only thing was that a service on the Server uses an account to run.  That account would become locked out consistently when the service would run.  However, if the bad server was a DC, ADU&C on the bad server would never see the lockout status, but the other DC's would.  I continue to see "Windows cannot access the file gpt.ini for GPO  The file must be present at the location <>. (). Group Policy processing aborted. " Event ID 1000 in the app log, but nothing else really interesting.

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?




I have created another DC purely in VMware and it has non of the issues (2003), nor do any of the other DC's.  I have 2 2000 DC's (one of which is the bad DC) on SP4, the rest of the DC's are 2003 sp2 (~5).  Client events?  No trouble viewing AD objects from clients.


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.



I should be able to do this tomorrow PM.


No dice.  I think there must have been some corruption in the p2v conversion
Unlock this solution and get a sample of our free trial.
(No credit card required)


Fresh install as well as a cold p2v.  I'm chalking it up to p2v trouble.  I think we can close this question, but thanks for the help.
Forced accept.

Community Support Moderator
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.