• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1461
  • Last Modified:

Missing SYSVOL Share folders

Two DCs w/ integrated DNS. Good DC has all the FSMO roles and the GC.
On my second DC, I am missing the SYSVOL share folders after doing a DC restore. I have tried the following:

Followed the procedures to modify the registry burflags  (D4 on authoritative DC, D2 on problem DC). That didn't work.
Wouldn't let me demote as SYSVOL shares were missing so I did a /forceremoval. Demoted problem DC, deleted all references using adsiedit and deleted all references in DNS and Sites and Services. Then promoted again to a DC.

Problem DC shows both both servernames and _msdcs folders - all entries are OK
However authoritative DC does not show problem DC in DNS.

SYSVOL folders still missing.
Anyone have any suggestions?
0
PWyatt1
Asked:
PWyatt1
  • 13
  • 9
  • 5
  • +2
3 Solutions
 
HousammuhannaCommented:
This maybe a replication problem
you will need to wait until the KCC finish its check so the server will be allowed to host the SYSVOL.
try this
make sure that the time is Totally OK and sync together
also try to restart the NTFRS
Also you will need to open the new server DNS
is it working fine
Forward zone and Reverse zone
in ADSS are the Automaticlly generated replication connectors are OK
0
 
PWyatt1Author Commented:
Thanks. I already did most of your suggestions:
Time is matched
Increments match
Restarted frs and net logon on both servers
However
In ADSS, there is no NTDS entry for the problem server
0
 
Henrik JohanssonSystems engineerCommented:
See the following KB for troubleshooting:
http://support.microsoft.com/kb/257338
0
Take Control of Web Hosting For Your Clients

As a web developer or IT admin, successfully managing multiple client accounts can be challenging. In this webinar we will look at the tools provided by Media Temple and Plesk to make managing your clients’ hosting easier.

 
PWyatt1Author Commented:
Hello henjoh09:
Unfortunately this KB article was not helpful. It just discussed what happens on a DCPROMO etc. rather than HOW to fix a problems. Thanks anyway for the help.
0
 
Henrik JohanssonSystems engineerCommented:
I thaught that 1) in that KB matched as a possibly thing to do based on info in your followup:
"If no connection objects exist for the new replica member, use the Check Replication Topology command in Dssite.msc to force KCC to build the necessary automatic connection objects (press F5 to refresh the view afterwards). "

Have you seen this this KB:
http://support.microsoft.com/kb/316790
0
 
ChiefITCommented:
""Problem DC shows both both servernames and _msdcs folders - all entries are OK
However authoritative DC does not show problem DC in DNS""

You have to fix DNS prior to doing the burflag restore. FRS uses DNS heavily.
0
 
PWyatt1Author Commented:
Hi everyone:
DNS is working fine. All folders and entries are correct. Netdiag on both servers is fine except for "domain Membership" error on prblem DC, which is expected with the sysvol problem I am having. I am currently working through KB 315457 to get the SYSVOL correct. I should have an answer for you all by this afternoon (Thursday)
0
 
Henrik JohanssonSystems engineerCommented:
On problem DC, try netdiag/fix
0
 
PWyatt1Author Commented:
Hi henjoh09:
I've tried netdiag /fix many times. In all cases when I run it on the problem server, I get the Domain Membership failed - [warning] The system volume has not been completely replicated.......
0
 
Henrik JohanssonSystems engineerCommented:
Is problem DC pointing on itself as DNS? Change it to use a working DNS/DC as DNS server and re-run ipconfig/registerdns and netdiag/fix to register missing DNS records.
0
 
PWyatt1Author Commented:
Hi henjoh09:
I did as requested ( I also flushed dns before registering). The domain membership error has gone and now I get replication latency warnings.

Something new. On the good dc, I'm getting kcc errors 0X*0000785

As an aside, I also copied the policies from the good dc to the proper folders in the registry of the problem dc.
0
 
Henrik JohanssonSystems engineerCommented:
On the problem DC:
* Disable Kerberos KDC service
* Reboot server
* Run 'netdom  /resetpwd /s:<pdc-emulator-role-dc> /ud:domain\administrator /pd:*'
* Set Kerberos KDC service back to start automatic and reboot
* Reboot server

http://support.microsoft.com/kb/325850
0
 
PWyatt1Author Commented:
hi henjoh09:
The kcc event was on the authoritative (good) server. Are you sure the directions you gave in the prior post apply to the problem DC instead on the authoritative DC?>
0
 
ChiefITCommented:
PWyatt:
Can you provide some details for us to sort through:
example: DCdiag report, Event log errors. I still think this is a DNS error:

Henjo has a good idea: (To help you with you and Henjo with your question)
Henjo is trying to assist you in resetting the secure channel and getting a kerberose ticket from the other DC. This links the two up. What he said should be taken verbatum.

On the bad DC, disable KDC. This forces the bad computer to get a kerberos ticket from the other DC.
Then, reset the secure channel through netdom.
Then, restart the KDC service and reboot.

However, if you have a DNS discrepancy and your DC can't find the KDC of the other DC, you find yourself locked out because you don't have a KDC ticket grantor to provide access. This is why a bit of information is important. We really need to determine if DNS is acting as it should. DCdiag and event log errors will point us in the right direction. Whatever you do, DO NOT log off when you have the KDC disabled, and make sure the local logon is in order on this DC. We are playing with kerberos in an attempt to fix your server.
0
 
PWyatt1Author Commented:
Thanks ChiefIT.
Let me go through the EventLogs and Netdiag and dcdiag for you (Friday morning):
ADC(Authoritative DC)  now shows :
Security - periodic failure audits for my workstation and other programs using the admin password
System - No errors
Directory Service - Periodic KCC warnings
DNS Server - No Errors
FRS - No errors
DCDIAG no errors
Netdiag - No Errors

Problem DC Event Logs
Security - periodic failure auits for my workstation and other programs using the admin password
System - No Errors
Directory Service - No Errors
DNS Server - Periodic DNS 4515 warnings (ARP cache error?)
FRS - many NTFRS warnings in groups of three - 1 x Error13565, then 2X Error 13508
NETDIAG - Failed membership test, and
                  DNS test does not show itself...only the ADC
DCDIAG - Replication Latency Warnings
                netlogons - Unable to conect to the NETLOGON share
                Advertising failed - DsGetDcName reached ADC instead of itself (problem DC)
                frsevent - Failed SYSVOL replication

Thanks everyone. I am getting very frustrated with this situation. as I am sure you all are. If we don't fix this by tonight, this weekend I'm just going to pull a spare and create a whole new DC.




0
 
ChiefITCommented:
YOU ARE IN JOURNAL WRAP:

FRS - many NTFRS warnings in groups of three - 1 x Error13565, then 2X Error 13508<----JOURNAL WRAP
NETDIAG - Failed membership test, and
                  DNS test does not show itself...only the ADC<<<<----CAUSE OF THE PROBLEM
DCDIAG - Replication Latency Warnings
                netlogons - Unable to conect to the NETLOGON share<<<---------SYMPTOM OF JOURNAL WRAP
                Advertising failed - DsGetDcName reached ADC instead of itself (problem DC)
                frsevent - Failed SYSVOL replication

_____________________________________________________________________
Can you provide full details on the 4515 error, I don't recall looking into this one.


________________________________________________________________
From what I am seeing, you need to register the DNS settings to itself and then open the burflags doing a D2 from the PDCe.
0
 
PWyatt1Author Commented:
4515 warning is "The zone 76.95.67.in-addr.arpa was previously loaded from the directory partition MicrosoftDNS but another copy of the zone has been found in directory partition DomainDnsZones.MCOL. The DNS Server will ignore this new copy of the zone. Please resolve this conflict as soon as possible. "

The buflags on the problem server are set to D2; the burflags on the ADC are set to D4.

Register the DNS to itself? You mean uninstall/ reinstall the NIC?
Thanks
0
 
PWyatt1Author Commented:
I'm taking a look at KB292438 to see if I can get something out of that.
0
 
ChiefITCommented:
Prior to doing anything, we have to clean up DNS:

4515 warning is "The zone 76.95.67.in-addr.arpa was previously loaded from the directory partition MicrosoftDNS but another copy of the zone has been found in directory partition DomainDnsZones.MCOL. The DNS Server will ignore this new copy of the zone. Please resolve this conflict as soon as possible. "

This means your reverse lookup zone has a copy on top of itself. This is partially why you are having problems with DNS. I say Nuke the reverse lookup zone and let it rebuild istelf.

Now you will have to register your server's DNS Host A and SRV records to itself: To do this, follow this link: Also follow the followup advice to see if you can force replicate between the two partners.

http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_23356031.html
0
 
ChiefITCommented:
Chris Dent and I  are working on a very similar post to yours:

This guy has reverse lookup problems as well as journal wrap. I thought you might want to look at that for reference:
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_23730976.html#a22639526
0
 
PWyatt1Author Commented:
I have worked on this all weekend and I got nowhere. This is a goddam bug in windows 2003 server and Microsoft should fix it or not allow it to happen. It's been 5 years since this OS was delivered to the market and to have to work with mickey mouse problems like this is just intolerable. What a crock!!!

I was getting 4515 errors again after letting the Reverse Lookup zone rebuild itself overnight. I went ahead and flushed dns again, registered, and restarted netlogon.

I have NO SYSVOL Folders in the problem server. I am essentially back to square one !!!

I then stopped kcc on the problem server and reset the password.

I stopped frs and set the burflags to D2 in the problem server, and restarted frs. Nothing . No SYSVOL folders were recreated.

I then tried an authoritatve restore by stopping frs on the ADC and enetring D4 in the burflags, then restarting frs. No SYSVOL folders were recreated on the problem server.

Screw it! I'm going to add another member server to the domain and promote it to a DC. I don't have time for this crap!

I want to thank all of you for working with me on this problem, but I know when to cut my losses. I have worked over 10 hours on this problem. It takes only 3 hours to rebuild a server with a clean OS, and only 20 minutes to add a new DC to a domain. My time is worth more money that trying to fix problems that Microsoft should have fixed years ago.
0
 
ChiefITCommented:
It's that extra reverse lookup zone that is causing you problems. When looking up a remote site, by IP, it will have to go through the reverse lookup zone to get a Name associated with it.

I looked it up and this article recommends using the ADSI util to remove that zone>
http://support.microsoft.com/kb/867464

Once the second zone is removed, DNS should be able to resolve and the D2 rebuild should go as you wished.

I know this is frustrating. If you stick with us, I think we can resolve these issues without having to bring up another server.
0
 
PWyatt1Author Commented:
Thanks ChiefIT:
I followed KB 887464 to the letter for both Forest and Domain and got a message in both cases "A referral was returned from the server", but the contoso.com containers did not appear in the list. Is this message an error, or is it a "completed" message?
0
 
ChiefITCommented:
OK, I am requesting a wee bit of DNS help on this one....

"Contoso.com" is an example domain. Your domain is different and you are trying to rid yourself of the reverse lookup zone, not the forward lookup zone of  the "Contoso.com" domain. The reverse lookup zone is:
76.95.67.in-addr.arpa

I don't remember enough about the ADSI utilitiy to guide you there verbatum.
0
 
Chris DentPowerShell DeveloperCommented:

Hey guys :)

I've not read through all of the thread so apologies if I've missed anything pertinent.

> I followed KB 887464 to the letter for both Forest and Domain and got a message in both cases
> "A referral was returned from the server"

Does this occur on all DCs?

And if you open up the DNS Console, what replication scope has been set for each of the zones? I hope to see "All Domain Controllers in the AD Domain", that indicates that it is accessing the zone from the main directory partition (System\MicrosoftDNS under AD Users and Computers).

If it does occur on all DCs and no zones load from there at the moment we can delete both of the partitions (ForestDNSZones and DomainDNSZones) then recreate them.

Chris
0
 
ChiefITCommented:
Hey Chris:
Wow, do I appreciate your assistance on this one. Thanks again, bud.

This is what we have:
1)Duplicate reverse DNS zones on the server and it appears on this server only. He tried the KB article "to the letter", but I think he thought contoso.com was suppose to be "to the letter" as well.
2)The duplicate reverse DNS has him in journal wrap and the sysvol share is not appearing.
3) The DNS problems are rendering the burflag method of rebuilding the Sysvol, useless.
--This is what I concluded, so far:
We need to remove the duplicate reverse DNS zone and set the burflags to rebuild the sysvol and netlogon shares. Then, we should look at the replication set configuration.

We need your help in using the ADSIutility to remove the zones and straighten out DNS.

Thanks again Chris.
0
 
ChiefITCommented:
One last thing Chris:
The author has put in some serious hours on this and may be tired. So, your crystal clear explanations, that you always provide, will be very helpful.
0
 
Chris DentPowerShell DeveloperCommented:

Hey Chief :)

Understood, these are the explicit instructions then :)

Before we continue we need to clarify one thing. The Domain Name:

1. Open AD Users and Computers
2. Directly beneath the "Active Directory Users and Computers" heading should be the Domain Name. From the above that should just be MCOL, is that the case?

If MCOL is the domain name this is a single-label domain name and some special considerations apply, documented here:

http://support.microsoft.com/kb/300684

Once we have the domain name we can construct our connection to the DNS Partitions in Active Directory:

1. Log onto the server
2. Start, Run, ADSIEdit.msc
3. Right click on ADSI Edit and select "Connect to..."
4. Under Name enter DomainDNSZones
5. Select "Select or type a Distinguished Name or Naming Context"
6. Enter "DC=DomainDNSZones,DC=MCOL"
7. Leave Computer as default and press OK

That should create a DomainDNSZones folder in ADSIEdit, expanding that should allow you to select CN=MicrosoftDNS. Beneath that we have each zone stored stored in Active Directory where the replication scope in the zone properties is set to "All DNS Servers in the Active Directory Domain".

Don't do anything with that yet, we just need to know if you have an entry for "76.95.67.in-addr.arpa". Leave ADSIEdit open for now.

Next, we need to check for the other version (this checks the Directory partition):

1. Open AD Users and Computers
2. Select View and Advanced Features
3. Expand System
4. Expand MicrosoftDNS

Again look for zone names. Do we have a "76.95.67.in-addr.arpa" version here as well?

The error message implies the version under DomainDNSZones is in error, but we need to check that. On any Domain Controller:

1. Open the DNS Console
2. Expand Reverse Lookup Zones
3. Select "67.95.76.x Subnet"
4. Open the zone Properties
5. Verify the "Replication" scope

A Replication Scope is set to "To all Domain Controllers in the Active Directory Domain" indicates we are actively using the Directory partition version (as seen in AD Users and Computers). In this instance we would delete the "DC=76.95.67.in-addr.arpa" version from DomainDNSZones\MicrosoftDNS in ADSIEdit.

If the replication scope is set to "To all DNS Servers in the Active Directory Domain" we would delete the version of the zone from AD Users and Computers.

HTH

Chris
0
 
PWyatt1Author Commented:
Thanks Guys:
I dcpromoed the problem server and re-promoted it. At least now I have the sysvol folders in the problem DC, but i am still not replicating properly. Please let me work on this for today on my own then conact you guys tomorrow if I have not solved it.
0
 
PWyatt1Author Commented:
Hi Guys:
I'm going to abandon this question but assign the points because of the work that all of you did in trying to help me. I decomissioned the problem DC and added  a new DC to the domain. Problem solved. I'm still upset with Microsoft for having an OS that breaks so easily. Thenk everyone.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 13
  • 9
  • 5
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now