Broken Domain

[Rob Milman]

We had a rogue administrator, who is no longer employed
with us, do something really stupid. He deleted the Sysvol
folders on all of our DC's. It tooks us a while, but we
were able to restore most functionality to our domain.
However, some things are still broken. We are unable to
add additional domain controllers or setup trusts between
a new domain. Is there any troubleshooting or other
suggestions that can be made for us to fix this busted
domain? Or should we admit defeat and just rebuild from
scratch?

Thanks in advance for your help.

Rob Milman

 

[Herb Martin]

We had a rogue administrator, who is no longer employed
with us, do something really stupid. He deleted the Sysvol
folders on all of our DC's. It tooks us a while, but we
were able to restore most functionality to our domain.
However, some things are still broken.

I suppose backp tapes are out of the question?

We are unable to
add additional domain controllers or setup trusts between
a new domain.

That should NOT (though it might) be related to the SysVol;
usually that problem is due to DNS being wrong.

DNS
1) Dynamic for the zone supporting AD
2) All internal DNS client NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

Restart NetLogon on any DC if you change any of the above that
affects a DC.

Is there any troubleshooting or other
suggestions that can be made for us to fix this busted
domain? Or should we admit defeat and just rebuild from
scratch?

If the DNS fixes the "add a DC" problem you might as well
try that -- perhaps the "basic" Sysvol will load on a new DC,
but I suspect that gets copied from the other DCs as well.

 

[Tomasz Onyszko]

We had a rogue administrator, who is no longer employed
with us, do something really stupid. He deleted the Sysvol
folders on all of our DC's. It tooks us a while, but we
were able to restore most functionality to our domain.
However, some things are still broken. We are unable to
add additional domain controllers or setup trusts between
a new domain. Is there any troubleshooting or other
suggestions that can be made for us to fix this busted
domain? Or should we admit defeat and just rebuild from
scratch?

Check Your FSMO role holders - it looks like they are not working properly

 

[Paul Bergson]

We had some problems and ended up calling Microsoft. They had me run the
tool in the link. Run it and start looking through the logs. My guess is
your are having replication problems. Do you even have the RID fsmo role
running. You should have some rids available in your pool but your rid pool
may be shrinking. I ran this, turned it over to Microsoft but, while
waiting could see where the errors were. In your instance I think spending
$250 for Microsoft Support might be money well spent. Anyways see the info
below.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++=

To help trouble shoot this issue download the Microsoft Product Support
Reporting tool from the link below:

http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706/MPSRPT_DirSvc.EXE

This information will help you to determine what factors are involved.

The MPS utility will take about 5 to 15 minutes to gather information. This
can be run at any time and will utilize minimal processor time and memory
and is quite unobtrusive to clients currently accessing the server.

It is required that the currently logged on user have Administrative rights
in order to allow for proper operations of the MPS Reporting Tool.

If you have any questions regarding the usage or operations of the MPS
Reporting Tool please review the link below:
http://download.microsoft.com/downl...e5-a579-30b0bd915706/MPSRPT_DirSvc_Readme.txt



DIRECTORY STRUCTURE:
========================
%SystemRoot%\MPSReports---|
|-- DirSvc--|
|--
Bin --|

|-- Logs--|

|-- Cab

ADDITIONAL INFORMATION:
=======================
On your system a CAB file will be generated for your convenience in the
%systemroot%\MPSReports\DirSvc\Bin\Logs.x\Cab directory called:

%COMPUTERNAME%_MPSReports.CAB.

The CAB file will contain the reports generated by the MPS Reporting Tool.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++


--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

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

 

[Tim Springston [MSFT]]

Hi Rob-

If the contents of the SYSVOL are gone, the best option is to restore from a
system state backup from when they were present, or simply a restore of that
directory. Or a GPMC backup of your policies.

If no backup is available, there is are tools to recreate the default
policies. This will not recreate any GPOs created by you or your team; it
will only recreate those which would be present by default.

In Windows 2000 there is a tool called RECREATEDEFPOL.EXE to do this. It
is available from Microsoft PSS (http://www.microsoft.com/support). You
should not be charged for the call if all you want is that file.

For Windows Server 2003 domains we include a tool called DCGPOFIX.EXE
(installed by default).


C:\Documents and Settings\Administrator>dcgpofix /?

Microsoft(R) Windows(R) Operating System Default Group Policy Restore
Utility v5.1

Copyright (C) Microsoft Corporation. 1981-2003

Description: Recreates the Default Group Policy Objects (GPOs) for a domain

Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

/target: {Domain | DC | BOTH}
Optional. Specifies the GPO to be restored -- the Default Domain Policy
GPO, th
e Default Domain Controllers Policy GPO, or both.

/ignoreschema:
Optional. Use this switch to have this tool ignore the schema version of the
Act
ive Directory. Otherwise this tool will only work on the same schema
version as
the Windows version in which the tool was shipped.

Please repost if you have any additional questions or concerns.

 

[Guest]

Check Your FSMO role holders - it looks like they are not
working properly

Thanks I did that. I ended up running ADSIEDIT to fix
everything and sieze all the roles. It did not help. There
were some DNS problems as well. But those were fixed too.
I'll try some of the other suggestions, thanks.

 

[Guest]

Thanks,

Backups did not help us. We actually built a new server
with the same domain name and copied the sysvol onto the
existing DC.
DNS was is bad shape too, but I thought we had fixed most
of the problems. I'll try your suggestion for setting DNS
to just the one DNS server I know is AD Integrated. I'll
give the DC a kick this weekend and see if it will allow
me to add a second DC.

Thanks again.

 

[Guest]

We did manage to get the SYSVOL restored but you are right
in that the Default Group Policies are messed up. They
exist but we can not edit them. I found a copy of
recreatedefpol.exe and it restored them. Thanks for that.
I need to reboot this weekend and I hope I'll be able to
add a second DC after that.

Thanks again.

-----Original Message-----
Hi Rob-

If the contents of the SYSVOL are gone, the best option is to restore from a
system state backup from when they were present, or simply a restore of that
directory. Or a GPMC backup of your policies.

If no backup is available, there is are tools to recreate the default
policies. This will not recreate any GPOs created by you or your team; it
will only recreate those which would be present by default.

In Windows 2000 there is a tool called

RECREATEDEFPOL.EXE to do this. It

is available from Microsoft PSS

(http://www.microsoft.com/support). You

should not be charged for the call if all you want is that file.

For Windows Server 2003 domains we include a tool called DCGPOFIX.EXE
(installed by default).


C:\Documents and Settings\Administrator>dcgpofix /?

Microsoft(R) Windows(R) Operating System Default Group Policy Restore
Utility v5.1

Copyright (C) Microsoft Corporation. 1981-2003

Description: Recreates the Default Group Policy Objects (GPOs) for a domain

Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

/target: {Domain | DC | BOTH}
Optional. Specifies the GPO to be restored -- the Default Domain Policy
GPO, th
e Default Domain Controllers Policy GPO, or both.

/ignoreschema:
Optional. Use this switch to have this tool ignore the schema version of the
Act
ive Directory. Otherwise this tool will only work on the same schema
version as
the Windows version in which the tool was shipped.

Please repost if you have any additional questions or concerns.

--
Tim Springston
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

We had a rogue administrator, who is no longer employed
with us, do something really stupid. He deleted the Sysvol
folders on all of our DC's. It tooks us a while, but we
were able to restore most functionality to our domain.
However, some things are still broken. We are unable to
add additional domain controllers or setup trusts between
a new domain. Is there any troubleshooting or other
suggestions that can be made for us to fix this busted
domain? Or should we admit defeat and just rebuild from
scratch?

Thanks in advance for your help.

Rob Milman

.

 

[Guest]

Thanks, I'll give it a try.

Rob

-----Original Message-----
We had some problems and ended up calling Microsoft. They had me run the
tool in the link. Run it and start looking through the logs. My guess is
your are having replication problems. Do you even have the RID fsmo role
running. You should have some rids available in your pool but your rid pool
may be shrinking. I ran this, turned it over to Microsoft but, while
waiting could see where the errors were. In your instance I think spending
$250 for Microsoft Support might be money well spent. Anyways see the info
below.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++
++++++++++++++++++++++++++++++++++++=

To help trouble shoot this issue download the Microsoft Product Support
Reporting tool from the link below:

http://download.microsoft.com/download/b/b/1/bb139fcb- 4aac-4fe5-a579-30b0bd915706/MPSRPT_DirSvc.EXE

This information will help you to determine what factors are involved.

The MPS utility will take about 5 to 15 minutes to gather information. This
can be run at any time and will utilize minimal processor time and memory
and is quite unobtrusive to clients currently accessing the server.

It is required that the currently logged on user have Administrative rights
in order to allow for proper operations of the MPS Reporting Tool.

If you have any questions regarding the usage or operations of the MPS
Reporting Tool please review the link below:
http://download.microsoft.com/download/b/b/1/bb139fcb- 4aac-4fe5-a579-30b0bd915706/MPSRPT_DirSvc_Readme.txt



DIRECTORY STRUCTURE:
========================
%SystemRoot%\MPSReports---|
|-- DirSvc--|
|--
Bin --|

|-- Logs--|

|-- Cab

ADDITIONAL INFORMATION:
=======================
On your system a CAB file will be generated for your convenience in the
%systemroot%\MPSReports\DirSvc\Bin\Logs.x\Cab directory called:

%COMPUTERNAME%_MPSReports.CAB.

The CAB file will contain the reports generated by the MPS Reporting Tool.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++
+++++++++++++++++++++++++++


--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

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






.

 

[Herb Martin]

Thanks,

Backups did not help us. We actually built a new server
with the same domain name and copied the sysvol onto the
existing DC.
DNS was is bad shape too, but I thought we had fixed most
of the problems. I'll try your suggestion for setting DNS
to just the one DNS server I know is AD Integrated.

I didn't actually suggest that -- although it can be a temporary
expedient sometimes.

What I indicated was that you must ONLY have the "internal"
DNS servers listed -- whether you list one or all of them,
you must NOT list any outside DNS servers.

The above applies to DCs as well. (Even DNS servers.)

I'll
give the DC a kick this weekend and see if it will allow
me to add a second DC.

I have serious doubts about that "copying" trick but did
consider 'suggesting' it -- it (probably) cannot hurt, especially
if you NOW have backups.

 

[Herb Martin]

Thanks I did that. I ended up running ADSIEDIT to fix

everything and sieze all the roles. It did not help. There
were some DNS problems as well. But those were fixed too.
I'll try some of the other suggestions, thanks.

Seizing roles is a BAD idea. If you actully do this, then
all "former role holders" must be removed as DCs.

(DCPromo "cycle" them.)

 

[Herb Martin]

There is a procedure/tool for restoring default policies
which might get you from where you are to a stable state.

I don't remember the name but a quick search of the Help
or MS site will find it -- or someone will post it here.


--
Herb Martin

We did manage to get the SYSVOL restored but you are right
in that the Default Group Policies are messed up. They
exist but we can not edit them. I found a copy of
recreatedefpol.exe and it restored them. Thanks for that.
I need to reboot this weekend and I hope I'll be able to
add a second DC after that.

Thanks again.

-----Original Message-----
Hi Rob-

If the contents of the SYSVOL are gone, the best option is to restore from a
system state backup from when they were present, or simply a restore of that
directory. Or a GPMC backup of your policies.

If no backup is available, there is are tools to recreate the default
policies. This will not recreate any GPOs created by you or your team; it
will only recreate those which would be present by default.

In Windows 2000 there is a tool called

RECREATEDEFPOL.EXE to do this. It

is available from Microsoft PSS

(http://www.microsoft.com/support). You

should not be charged for the call if all you want is that file.

For Windows Server 2003 domains we include a tool called DCGPOFIX.EXE
(installed by default).


C:\Documents and Settings\Administrator>dcgpofix /?

Microsoft(R) Windows(R) Operating System Default Group Policy Restore
Utility v5.1

Copyright (C) Microsoft Corporation. 1981-2003

Description: Recreates the Default Group Policy Objects (GPOs) for a domain

Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

/target: {Domain | DC | BOTH}
Optional. Specifies the GPO to be restored -- the Default Domain Policy
GPO, th
e Default Domain Controllers Policy GPO, or both.

/ignoreschema:
Optional. Use this switch to have this tool ignore the schema version of the
Act
ive Directory. Otherwise this tool will only work on the same schema
version as
the Windows version in which the tool was shipped.

Please repost if you have any additional questions or concerns.

--
Tim Springston
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

We had a rogue administrator, who is no longer employed
with us, do something really stupid. He deleted the Sysvol
folders on all of our DC's. It tooks us a while, but we
were able to restore most functionality to our domain.
However, some things are still broken. We are unable to
add additional domain controllers or setup trusts between
a new domain. Is there any troubleshooting or other
suggestions that can be made for us to fix this busted
domain? Or should we admit defeat and just rebuild from
scratch?

Thanks in advance for your help.

Rob Milman

.