Link to home
Create AccountLog in
Active Directory

Active Directory

--

Questions

--

Followers

Top Experts

Avatar of Andrej Pirman
Andrej Pirman🇸🇮

GP and gpt.ini under SYSVOL dissapear
Hi,

one of my customers have repeating issue with GPO.
They have 3 DC's, which work fine most of the time, except maybe of a fact, that 3rd DC is on ADSL line, so it gets unaccessible from time to time for few minutes. Also, this 3rd DC's line response is depenant of network traffic, so PING varies from 20 to 800ms.

Ok, the problem:
every few months they get a bunch of  1030 and 1058 Userenv errors on all 3 DC's:

Event Type:      Error
Event Source:      Userenv
Event Category:      None
Event ID:      1058
Date:            21.3.2008
Time:            11:04:33
User:            NT AUTHORITY\SYSTEM
Computer:      DC1
Description:
Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain_name,DC=local. The file must be present at the location <\\domain_name.local\sysvol\domain_name.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (The system cannot find the path specified. ). Group Policy processing aborted.

Event Type:      Error
Event Source:      Userenv
Event Category:      None
Event ID:      1030
Date:            21.3.2008
Time:            11:04:33
User:            NT AUTHORITY\SYSTEM
Computer:      DC1
Description:
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.

These events repeat every 5 minutes, which is normal for this type of error.
Why?
Because whole GPO file structure under \SYSVOL\domain_name.local\ is EMPTY on all 3 DC's! Simply - nothing there.

This vanishing process starts on one of DC's (random one), and then propagates to other 2 DC's when domain replication occures, so in 1 hour all 3 DC's \SYSVOL folders are empty, and GPO's are missing.
Since each client has its local copy of GPO, they continue to function, but whole Active Directory is loosing its functions slowly.

I checked:
- SMB signing is not a problem, all DC's and all Workstations can see \SYSVOL share
- permissions on SYSVOL share are correct, I mean, Domain users have only Read/Execute/List permissions, nothing more
- no Antivirus activity in the time when GPO's were deleted
- no system upgrades were meade
- noone messed with GPO, since this last time it happened at 10:05 hours on Sunday
- on all 3 DC's no other Event is recorded within +/- 2 hours of GPO dissapearance event, except this one:

Event Type:      Information
Event Source:      Windows File Protection
Event Category:      None
Event ID:      64001
Date:            21.3.2008
Time:            10:04:52
User:            N/A
Computer:      DC1
Description:
File replacement was attempted on the protected system file ntfrsutl.exe. This file was restored to the original version to maintain system stability. The file version of the bad file is 5.2.3790.2725, the version of the system file is 5.2.3790.1830.

Ok, I restored GPO from backup, as I did meny times before, and after I restore GPO to 1 DC, replication takes care to replicate GPO files to other 2 DC's. But this is not the sollution.
Any idea what else to look for?

Zero AI Policy

We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.


ASKER CERTIFIED SOLUTION
Avatar of Hypercat (Deb)Hypercat (Deb)🇺🇸

Link to home
membership
Log in or create a free account to see answer.
Signing up is free and takes 30 seconds. No credit card required.
Create Account

Avatar of Hypercat (Deb)Hypercat (Deb)🇺🇸

Well, taking a second look at your problem I'm not sure that will solve it. I've never actually seen the group policies disappear on one of the misbehaving DC's, but it might be worth a try if you catch it before it becomes critical.

Avatar of Andrej PirmanAndrej Pirman🇸🇮

ASKER

Thanx for advice, but this MS articel was already one of my currently opened IE tabs, so I tried everything there already :)

Actually...I don't understand one thing here about my missing GPO files.
All files under C:\Windows\SYSVOL were in one moment MISSING on DC1, and PRESENT on DC2 and DC3. Why did files not replicate back to DC1, but they rather got deleted on DC2 and DC3?

I also checked Domains And Trusts, and there are no entries, so this should not be an issue.
Any other idea?

Avatar of Andrej PirmanAndrej Pirman🇸🇮

ASKER

Hmmm...
looking again at AD Sites and Services, I found this replication scheme. Maybe there is a catch:

DC1 (slow ADSL line)
- replicate FROM: DC2
- replicate to:      DC2

DC2
- replicate FROM: DC3, DC1
- replicate TO:     DC3, DC1

DC3 (should be main DC)
- replicate FROM: DC2
- replicate TO:    DC2

Is such replication scheme correct? Might it be causing troubles?

Reward 1Reward 2Reward 3Reward 4Reward 5Reward 6

EARN REWARDS FOR ASKING, ANSWERING, AND MORE.

Earn free swag for participating on the platform.


Avatar of Hypercat (Deb)Hypercat (Deb)🇺🇸

This type of problem can get pretty difficult to diagnose.  I certainly recommend doing some very close monitoring so that you can figure out where the problem is starting and maybe identify what is triggering it.

That replication scheme looks pretty normal to me.  However, depending on the role of DC1 on the ADSL line, you might not have to replicate from it to DC2.  Does anyone use DC1 to add accounts or manage the domain in any other way (group policies, etc.)? Is DC1 used as a primary DNS server by the workstations at that site?  If neither of those things is true, you wouldn't need to replicate its information to the other 2 DCs, you'd only need to replicate to it from the others.  

Which of these machines has/have the FSMO roles?  If that machine is the one with the problem manifesting first, I would suggest that you move the FSMO roles to another machine.  Also, if you can identify the machine where the problem starts, you would want to remove any "replicate to" settings on that machine.  That way, it will replicate FROM the other DC(s) but not replicate its damaged information TO the others. That might temporarily stabilize things at least until you can figure out what's really going on.

Have you checked the FRS logs on all these machines for any errors or warnings?

One thing I would go with first would be to make sure that all of these servers are free of any viruses, spyware or malware.  Then, I recommend making sure that they are all up-to-date with the latest service pack (SP2) and security updates.  


Avatar of Andrej PirmanAndrej Pirman🇸🇮

ASKER

Hypercat...
I checked operations roles in AD and found, that DC3 is the FSMO, RID, PDC and Infrastructure master for domain. Does this go along with above replication schema?

Problems arived from DC1, which is not operations master.

Partial fix:
I just restored whole SYSVOL structure from backup to DC3 (which is schema and roles master).
It replicated without problems to DC2.

But it does not want to replicate to DC1!
I removed NTDS connection on DC1, and added DC3 as "replicate from" manually. But when I click "Replicate Now" I get this:

the following error occured during attempt to synchronize naming context domain_name.local from domain controller DC3 to domain controller DC1:
The naming context is in the process of being removed or is not replicated from the specified server.

Avatar of Hypercat (Deb)Hypercat (Deb)🇺🇸

Is it possible to go physically to the DC1 location? Is the link between DC1 and the other two DCs a site-to-site VPN connection or other stable, encrypted connection that you can safely work over and maintain the connection to the other two DCs? If that's so, then you should be able to do the following remotely; if not, you might have to bring DC1 physically to the same site as DC3 to do it.

What I would recommend would be to dcpromo DC1 to demote it to a member server first, remove it from the domain, clean it up, make sure it's current on service pack/security updates, and then re-join the domain and dcpromo it to reload AD on it. It's possible the first dcpromo won't go smoothly, though.  If so, here's an article that might help:

http://support.microsoft.com/kb/332199/en-us

After the first dcpromo (demotion), make sure that the server has been successfully demoted and that the demotion has been replicated to both DC3 and DC2.  Make sure you have edited the TCP/IP properties of DC1 so that it points to DC3 or DC2 for DNS, etc. Reboot DC1 and make sure it comes up and you can log on to it as a member server - of course this may be a little slow if you are working over a WAN link, but it should work. Check DC1 and make sure there aren't any left-over traces of the SYSVOL folder.  Then, on DC1, unjoin the domain and manually DELETE the computer account from DC3, make sure that replicates to DC2.

Then, run as many antivirus/antispyware/malware, etc., scans on it as you can and of course fix anything you can find.  Then, make sure that you have installed the latest NIC drivers for that server and install (or re-install) Windows 2003 SP2 and any subsequent security updates. Then re-join DC1 to the domain.  This will make sure the basic computer account trust relationship between DC1 and the rest of the domain is clean.  Then you can re-dcpromo it to replicate AD back to DC1.

What do you think?

Free T-shirt

Get a FREE t-shirt when you ask your first question.

We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.


Avatar of Andrej PirmanAndrej Pirman🇸🇮

ASKER

I think you described excelentlly what has to be done :)

One of issues I found was that all 3 DC's have had ADSL provider's DNS-es entere under TCP/IP properties for NIC card! I mean, beside of (correct) DC2 and DC3 as DNS servers, there were also 2 DNS servers of ADSL provider.
I cleared this immidiatelly and wondered, how this could work at all. I left only DC2 and DC3 as DNS servers, which have properly configured forwarders.

It's now end of shift there, and I'm gonna reboot DC1 remotelly.
As of now, all DC tests pass, but replication still does not work to DC1.
...maybe one thing more:
DC2 and DC3 replicate via RPC, while DC1, which is on ADSL line, replicates via IP protocol. Might there be some issue...we'll see.

Avatar of Hypercat (Deb)Hypercat (Deb)🇺🇸

Removing those DNS entries was a good idea - although as long as they were listed as additional DNS servers, not primary ones, they probably wouldn't interfere with normal day-to-day operations.  The only time they would come into play would be if the primary DNS server was completely down.

Don't think the replication over the ADSL itself is the issue - but as you say, we'll see.

Avatar of Andrej PirmanAndrej Pirman🇸🇮

ASKER

Your comment makes me thinking...
Those additional DNS servers...DC1, which is on ADSL line, had DC2 and DC3 and 2 additional DNS servers from ISP provider. And this ADSL line dropped from time to time, so DC1 was left with only DNS servers from ISP, which is very bad. Might this be the couse of the problems?
Remember, all GPO dissapearance always begun with DC1...

 

Reward 1Reward 2Reward 3Reward 4Reward 5Reward 6

EARN REWARDS FOR ASKING, ANSWERING, AND MORE.

Earn free swag for participating on the platform.


Avatar of Hypercat (Deb)Hypercat (Deb)🇺🇸

I don't see how.  It certainly could cause replication to fail, and it would cause problems with internal browsing at that location and access to any resources at the other office.  However, I can't think of any way that would actually cause the information in the SYSVOL folder on DC1 to disappear or be affected in any way.  If it was causing problems, you would see errors in your File Replication log on DC1 as the first sign.  Are you seeing any errors there?

Avatar of Andrej PirmanAndrej Pirman🇸🇮

ASKER

Sorry for delay in this question, but I was busy with other issues.
We actually did not find the resolution for my problem, but Hypercat was the only one who tried to help, and suggestions were quite good. Thanx for help :)
Active Directory

Active Directory

--

Questions

--

Followers

Top Experts

Active Directory (AD) is a Microsoft brand for identity-related capabilities. In the on-premises world, Windows Server AD provides a set of identity capabilities and services, and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD). This topic includes all things Active Directory including DNS, Group Policy, DFS, troubleshooting, ADFS, and all other topics under the Microsoft AD and identity umbrella.