Hi, I think I must be missing something obvious... I've done a clean install of Beta 3, added the AD DS role (which in turn installed the DNS and FileServer roles). All seems fine except that every 20mins DfsSvc logs an error Event ID 14530, with a description: "DFS could not access its private data from the Active Directory. Please manually check network connectivity, security access and/or consistency of DFS information in the Active Directory. This error occurred on root sysvol" Connectivity seems to be fine (internet access is OK) and the AD was created as a new domain in a new forest - it is a single DC network at the minute. Any suggestions gratefully received. Thanks, Dave

Event 14350 from DfsSvc (DFS Namespace Service) occurrs every 20 minutes referenced to root sysvol. The text of this event is DFS could not access its private data from the Active Directory. Please manually check network connectivity, security access, and/or consistency of DFS information in the Active Directory. This error occurred on root sysvol."Additionally, it occurs every time a manual attempt is made to connect to the sysvol share using the format \\server1\sysvol. (the Connect to dialog does not appear, and no credentials are requested)This error does not occur on a manual connection the sysvol share using the format \\server1.mydomain.local\share (credentials are requested in the "Connect to" dialog).My guess is that a process is trying every 20 minutes to connect to sysvol using the \\server1\sysvol.How can this error be eliminated?Thanks.

does the server have any issues at the time that the error is being logged? if you restart the dfssvc service does the error continue to be written to the log as often? the connectivity that the error is speaking of is connectivity to the DC, which is the same server of course. try removing and reinstalling the fileserver role, and see if that fixes it.

I installed it as a aditional domain controler on a existing forest and also have the same problem, along with other critical errors like IIS not working with the AD services, etc... Solution format and wait for beta 4, cause this one is still sucking...

Thanks for the suggestions. The server looks fine - everything else is behaving itself. If I stop the DFS Namespace service, then the errors stop, but they restart (at the same frequency) when I restart the service. I can't remove the FileServer role without first removing AD DS role. Any other suggestions? Thanks, Dave

I have the same problem. Anyone from "Longhorn" team?

Same issue as prior posters. Set up Server 2007 Beta 3 on PC - Joined it to a Windows Server 2003 (SP1) domain. The Server2003 machine is a DC and an enterprise CA. Prepared the forest/domain on Server 2003 PC. Iinstalled AD DS ... and DNS ... pointed this machine to Server 2003 DC for the DNS server. AD/DNS install ok. Promoted the Longhorn server to a DC - and it seemed fine at first - but here is what I have been able to find out. Longhorn server does *not* have a DC certificate! In fact, no certificate at all shows up. Requesting one via Certificates snapin states "The RPC server is unavailable. The certificate request could not be submitted to the certification authority." I did a network capture and the machine sure as heck IS talking to the RPC endpoint mapper on the Server2003 server. I exported a manual PKCS#10 key request file for a DC Certificate on the Longhorn Server, and attempted to manually submit it to the Server2003 CA, and it pulled up an error message "The DNS name is unavailable and cannot be added to the Subject Alternate name. 0x8009480f. Denied by Policy Module." The Longhorn server has both DNS A and PTR records in DNS. Getting file replication issues same as previous poster (not surprising since the machine has no certificate!)

Just a followup ... demoted the Longhorn back to a member server, and was able to enroll a computer certificate, no problems.

I would suggest - Change your advanced TCP/IP settings ... DNS to "Append these DNS suffixes (in order):" then add "mydomain.local", put "mydomain.local" in DNS suffix for this connection... and tick off the last two checkboxes.

Thanks for the suggestion.I tried it, but it did not eliminate Event 14350 (still recurs at 20-minute intervals).

Have you received any NTFRS errors? Try restarting NTFRS, then wait for the log message stating that SYSVOL has been created. Then restart DFS. You don't say what you were doing right before the DFS errors started showing up. Last time I received the SYSVOL message was right after an ASR restore (but Ionly restored system state, not then entire ASR backup). NTFRS was hangingand not coming completely up (no message in logs stating that it has come up and SYSVOL has been created), I had to bring the service down, mark NTFRS as authoritative (http://support.microsoft.com/kb/290762, D4 option), bring it back up, then my Group Policies were missing - reboot in Directory Services Restore mode, and restore system state again. Then I had to do a little bit of troubleshooting but MS already had knowledge base articles about the issues I had.

Thanks for taking the time to reply.1. I did not receive any NTFRS errors. As you suggested, I tried restarting NTFRS, waiting for the log message that SYSVOL has been created, and then restarted DFS. Event 14350 continued to recur at 20-minute intervals.2. Event 14350 started occurring after I added the Active Directory Domain Services (AD DS) role and the domain controller role, which I did immediately after installing the OS (Longhorn Server Standard x64, Beta 3). The DNS Server role and File Services role were added with AD DS, as opposed to prior. If the DNS Server role and/or the File Services role were added prior, would that make any difference?3. The SYSVOL share, as well as the Active Directory database, transaction, and log files are on volume D; volume C is the system volume. If they were on volume C, would that make any difference?4. I can understand why the DFS Namespace Service (DfsSvc) would want to access Active Directory for SYSVOL purposes, but I don't understand why accessing other shares manually (via net use \\server\share) would involve Active Directory and why it would trigger Event 14350.5. There seems to be some caching. If the SYSVOL share is accessed manually (net use \\server\SYSVOL), Event 14350 is triggered, but if done near a 20-minute interval, the instance of Event 14350 that would "normally" occur is skipped.

I'm seeing a very similar pattern. DFS Event ID 14530 every few minutes on a Longhorn Beta 3 running as a second DC in a WS2003 forest. The other DC is a WS2003 R2/SP2 machine and is also the enterprise CA servers. However the DC did manage to autoenroll a Domain Controller Authentication and a Computer certificate. And despite the logged Errors, SYSVOL file replication seems to be working OK (if I drop a file on my WS2003 DC it quickly shows up on the Longhorn DC and vice versa).

I have seen this error (and made a separate post about it) on several different instances of Longhorn Server Beta 3 Standard. In each case, I added the Active Diretory Domain Services (AD DS) role immediately after completing Windows Setup (before adding any other roles or installing any applications). In the most recent instance, I noticed that the DFS Namespace service was running, but that the DFS Namespace role had not been automatically added with AD DS. I thought this could have caused this event. I added the DFS Namespace role manually, added a namespace, added a root folder and made SYSVOL a target under the root folder. The event still recurs every 20 minutes.

I posted this in another forum. This is a known issue and is being worked. As part of the research done on this issue, it was determined that SYSVOL replications is not adversely impacted.

Hi Chuck, Which forum did you post in? I'm always keen to check out other useful sources of info. I did Google for other references to the error before posting but couldn't find any. Thanks, Dave

I believe it was Windows Server 2008 Directory Services.

Any updates to this issue? I didn't have much luck searching Google or support.microsoft.com. I'm running v6.0.6001.16510.