SYSVOL GPO's re:copying

[Guest]

I have a former FSMO with an FRS problem. I don't care to fix the FRS
problem becasue the server is being replaced by one of the same name but
without the DC role. Apparently becasue of the FRS problem, my GPO folders
(c:\winnt\sysvol\<my domain name>\polices\) did not replicate to my new FSMO
when I transferred the roles. They still get applied when users logon to the
domain but I can not longer manage them--I get an error, "the sytem cannot
find the path specified", and as I stated, the folders are not in the same
folder on my PDC.

Can I simply copy the folders to my FSMO server?

 

[Meinolf Weber]

Hello TheMammothMan,

So is the old machine still existing and the new with the same name is running
or not? If the old one is still there and you did not add the new one with
the same name it will be really better to fix the problem before taking it
out. Please describe what you have done until now, that we can better understand
and help you to fix all problems.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.dts-l.org/goodpost.htm

 

[Guest]

I added a 2nd DC and transferred my FSMO roles to it without noticing that
the FRS was not running. My "old", still operational 2000 SP4 server is in a
journal wrap error state because the FRS was disabled. It also has the 5
folders in the "policy" folder and my two other DC's have none. It seems
clear to me that if I solve the journal wrap error state with an
authoritative restore (BURFLAGS=D4) that I will lose these folders since the
upstream folders are empty. Right?

The effort and/or risk in fixing this server seems (to me) to exceed the
effort required to recreate the policies that are in effect--stuff like:
screensaver in 20 min, can't change screensaver, "IE Provided by <My Company
name>", where our WSUS server resides . . . simple stuff like that.

I've DCDIAG'd and FRSDIAG’d which told me about the state I’m in. This
server is also my main end-user file server.

My plan is to restore and verify the end-user files to the new server (named
differently), uninstall AD on the old server, take it off the domain or
rename it, bring the new one up, and change it's name.

Remember, the old server is old. It due to be replaced anyway, so why fix
it when all I want is the end-user data.

My question is if I can just simply copy the contents of the policy folder
over to the FSMO roles server?

 

[Mark Renoden [MSFT]]

Hi

I think the path forward here depends greatly on what is working as much as
what it not working. When the new DCs were promoted in, did they
successfully obtain a copy of AD? If you create a test user account on each
DC, does it successfully replicate to each of the other DCs? If this test
is successful, I'd suggest the following:-

1. Physically disconnect the old problematic DC from the network. Keep it
plugged in to an isolated switch so that the network stack stays up.
2. Install GPMC on an XP client and plug it into the same switch as the old
DC. Make sure the XP client has an IP and can communicate with the old DC.
I'm assuming the old DC is running DNS and that the XP client is configured
to use the old DC for name resolution.

Grab GPMC here -
http://www.microsoft.com/downloads/...24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en

3. Open a command prompt and change directory into the scripts directory
under the GPMC install path (usually \program files\gpmc\scripts).
4. At the command prompt run

cscript BackupAllGPOs.wsf <backup location> /Domain:<domain_name>

You should get all your GPOs backed up to the folder in <backup
location>. Make it a local directory on the XP client.

5. Move the XP client over to the production environment and reconfigure the
DNS client so that it is able to resolve properly. Give it a reboot so that
it picks up the new DCs and disregards the old DC.

6. Using GPMC, take note of where each GPO is linked and then delete all the
GPOs in the domain. If AD replication was working, the GPO reference will
exist in AD but have no data in SYSVOL. We need to clear this out before
restoring the GPOs backed up in 4.

7. Stop FRS on each of the new DCs.

8. Choose one of the new DCs and set the Burflags value to D4 under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
at Startup.

9. Start FRS on this DC.

10. On every other new DC, set the Burflags value to D2 under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
at Startup

11. Start FRS on these DCs.

12. On the XP client, open a command prompt and change directory into the
GPMC scripts folder. Run

cscript ImportAllGPOs.wsf <backup location from 4>.

This will import all the GPOs back into AD and into SYSVOL.

13. Re-link the GPOs as noted in step 6.

This should get you out of the woods. Keep in mind I'm assuming reliable AD
replication and name resolution. Once this is done and confirmed to be
working, you should format the old DC and rebuild it before re-connecting it
to the production network. Also perform a metadata cleanup of the
production AD to remove references to the old DC by following

216498 How to remove data in Active Directory after an unsuccessful domain
controller demotion
http://support.microsoft.com/default.aspx?scid=kb;EN-US;216498

Hope that helps.

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.