To many SYSVOL's

Having two sysvol folders is normal.  

Here is a Microsoft reference article on sysvol folders:

http://64.4.11.252/es-es/library/cc778037(WS.10).aspx

... Thinkpads_User

According to your screen shot you have some morphed folders (scripts_ntfrs_xxxxxx and policies_ntfrs_xxxxx).

You should fix that.

http://support.microsoft.com/?id=328492

so MS being MS and not always very clear, at least to me,  should the following information ...................

To resolve this problem, follow these steps:

    Rename the original folders and the changed folders to different names, and then wait for the new names to propagate through the system.

    This makes sure the folder then has a common name throughout the SYSVOL, and that the names and GUIDs match on all members.

    Note Do not delete the undesirable folder and rename the other one. This can lead to even more naming conflicts.
    After the rename has propagated, choose the folder that you want to keep, and then rename it back to the original name. Other changed folders can then be safely deleted.

    Note Before you delete any of the folders, it is a best practice to make sure that you have a backup of the original (and complete) data.

........ be done as the PDC and all BDC?

Looking at the following images.........  my shares on the PDC do not have a SYSVOL or Scripts like the BDC's


     



SO i ran a search for SYSVOL on the PDC and came up with the following.........


 

These listings look much different than from the ones above from the BDC set.

I do find it curious that I found in the recycle bin the a SYSVOL folder but did not want to add/restore it into the mix but is dated a month prior to my arrival to the position (which is just this month) and I will be the first to admit my server knowledge is a bit weak.

being this seems to becoming a pain in the XXX rather quickly I'm also going to raise the points

TIA

here is a capture of the PDC SYSVOL tree



 

yes the PDC is the one without shares although the structure seems to be there, running the D2 burflag SRVADC1 has had no affect, re-running dcdiag produced these errors:


Starting test: NetLogons
  Unable to connect to the NETLOGON share! (\\SRVPDC\netlogon)
   [SRVPDC] An net use or LsaPolicy operation failed with error 53, The network path was not found..
    ......................... SRVPDC failed test NetLogons


all other dcdiag events passed testing

Can you run "dcdiag /v /e /c /f:dcdiag.txt" on one of the DCs and attach the log?

nothing like a virus outbreak to change focus,       anyway you will find output from the PDC and ADC attached, thanks

dcdiagSRVPDC.txt
dcdiagSRVADC1.txt

Virus, nah :)

First you should get your DNS correct. It looks like you got two sites, but you have public and some unreachable DNS servers configured on the NIC on your DCs.

like:

SRVADC1:
IP address: 10.154.152.11
DNS servers:
10.154.152.11 (<name unavailable>) [Valid] (OK)
Warning: 10.154.203.133 (<name unavailable>) [Invalid] (looks odd)
Warning: 10.154.254.72 (<name unavailable>) [Invalid (unreachable)] (not ok)
Warning: 10.154.203.137 (<name unavailable>) [Invalid] (looks odd)
Warning: 165.201.25.5 (<name unavailable>) [Invalid] (looks odd)
Warning: 8.8.8.8 (<name unavailable>) [Invalid] (not ok. Can be used as forwarder)
Warning: 8.8.4.4 (<name unavailable>) [Invalid] (not ok. Can be used as forwarder)

You should set it to use itself on the NIC, and a replication partner as secondary DNS. Never use public DNS servers on the NIC!

You should also look at the forwarders as they didn't look ok.

When this is fixed, restart the netlogon service on all three DCs and see if the PDC shares out the NETLOGON share.

I did not set the DNS was already in place the 10.154.xxx im told are DNS outside our agency but within the organization, I asked the agency that administors the WAN and Firewall about the entries so I could get some resolve but have never heard a response to my email or voice mail so I guess I will just delete them 165.201.xxx actually is a NS @ ks03.state.ks.us but again I think there is some blocking going on by the aforementioned so will just pull those too I guess and run with your suggestions and see where it takes me.

Thanks

I have items for DNS squared (I think) and D2 is still not replicating to the PDC, beginning to think I take FRS offline on ADC2 and run D4 from ADC1 then run D2 while bringing ADC2 back online.... thoughts? dcdiag2PDC.txt

 dcdiag2ADC.txt

I would not go for the D4 Burflags.

On SRVPDC try setting the DNS on the NIC to: 10.154.152.11
Remove the loopback address as DNS server.

On SRVPDC:

ipconfig /flushdns
ipconfig /registerdns

Restart ntfrs service
Restart netlogon service.

Stop ntfrs, and set the Burflags to D2 (hex), start ntfrs. Verify that event id 13516 is logged in the FRS event log.

Any luck with the netlogon share?

I assume SYSVOL is shared(?) (cmd -> net share)

SYSVOL and NETLOGON share on ADC1 and 2  still not sharing on PDC and why I was thinking about the D4 set

I have ran the D2 a few times now an received back the 13516 but see no changes on PDC, will run your suggestions and being this has become a pain in my tush I jacked points to max  LOL

Are both SYSVOL and NETLOGON not shared on the PDC, or is it just SYSVOL that is shared?

What is the value of the "SysvolReady" registry key on the PDC?

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\Sysvol\

both are NOT shared and SysvolReady on PDC is set at 1

Just to be on the safe side:

http:#35461317
..running the D2 burflag SRVADC1 has had no affect, re-running dcdiag produced these errors:

You did set the Burflags registry key on the DC called "SRVPDC"?

opps, apparently I need my eyes checked <rolls eyes>  will try that just as soon as i get back from lunch

so on PDC ...... I got the 13516 and I check net share for sysvol . no sysvol, no netlogon

When FRS has finished replicating SYSVOL content from an uptream partner, it will set the SysvolReady bit to 1. This notifies the netlogon service that SYSVOL is ready to serve and the netlogon service will share sysvol and netlogon.

In your case, something stops this from happening. Normally setting the Burflags to D2 solves any problems that interupt this process.

Could you verify that AD replication is ok, even though the dcdiag says it's ok. This will eliminated DNS and topology issues.

On "SRVPDC": repadmin /showrepl


Next I would run a FRSdiag on on the DC "SRVPDC" to see what state this partner is in.

You'll find it here: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=43CB658E-8553-4DE7-811A-562563EB5EBF&displaylang=en

Can you run this and put all logs generated in a zip archive and attach it?

Well just looking at the FRSDiag file seems that somehow an old server name got stuck in my sysvol replications and reading the MS recommended fix reminds me why I never got heavy into servers, now i'm kinda wishing I had

 SRVPDC.zip

It seems like SRVPDC has an incorrect value in the frsMemberReference object. Also you have some orphan SYSVOL replicas named "L1BO" (missing ServerReference).

KB 312862 is not a happy reading as it will kill the hope for most trying to fix FRS :)

Check the FRSDiag.txt log, open ADSIedit and check the nTFRSSubscriber object. The log describes what the value should be. (Current value and Suggested Value).


This none official site tells how to find the object in a more "human" understandable fashion.

Start at step 1, but the object you are looking for starts at step 12:

http://www.shantilal.net/technotes/1.html

yep your findings are the same thing I was thinking I saw also and will check the site and while i have you I saw the time your message posted and have to say WHAT THE DUCE!   I dont know when you sleep or even you if you do, you seem to be up at all hours but I do want to say THANKS for your assistance to this noobie in the server arena!

Anyway..... I shall return.........

I dont know when you sleep or even you if you do

What is sleeping?! ;)

I guess we are in different time zones :)

Maybe Im a little lost this early in the morning but going by the description given in the link my structure is a bit off and need some finger pointing.  The comments made in the link speak about the CN=NTFRS Subscriptions for the offended server being empty but my structure looks as follows;

Domain [SRVPDC.KSL1.LOCAL]
CN=Domain System Volume (SYSVOL share)  nTFRSSubscriber   CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=SRVPDC,OU=Domain Controllers,DC=KSL1,DC=LOCAL

If i hit edit on the aforementioned object and look for fRSMemberReference with the value of....
CN=LIBSRV,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=KSL1,DC=LOCAL

Question1
 Should I remove container "IASIdentity" or is this something you would just see in the PDC and not ADC
Question 2
I'm going to just edit the aforementioned fRSMemberReference attribute (as suggested in step 12) not make a new object to replace the existing.

Sorry, new territory so I want to be clear on this...

Thanks

What is sleeping?! ;)

I guess we are in different time zones :)

LOL  yeah, i concur on the what is sleeping, I'm a insomniac myself so can totally relate and even being in different time zones you seem to be up all the time, but I sure appreciate the guidance.

The link you saw was about missing NTFRS Subscriptions. That's not a problem you are experiencing. Just added it so you could see where to navigate.

See the attached image where to find it.

The value should be: CN=SRVPDC,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=KSL1,DC=LOCAL


frsMemberReference.jpg

Question1
 Should I remove container "IASIdentity" or is this something you would just see in the PDC and not ADC

I wouldn't do that.

Question 2
I'm going to just edit the aforementioned fRSMemberReference attribute (as suggested in step 12) not make a new object to replace the existing.

Just edit. Do not create any new objects.

well at least I'm thinking along the same path, just good for verification at this point

"tried" to modify the attribute string, when I apply, it errors out "The name reference is invalid"

I came across this - http://www.eggheadcafe.com/software/aspnet/30492248/help-changing-an-frsmemberreference-attribute.aspx

dont rename the value of the  "fRSMemberReference" Property of the
nTFRSSubscriber object

rename the following object:
CN=LTD-5Z1XQCCQSMH,CN=Domain System Volume (SYSVOL share),CN=File
Replication Service,CN=System,DC=JJHY,DC=LOCAL

to:
CN=WHATEVER-IS-CORRECT,CN=Domain System Volume (SYSVOL share),CN=File
Replication Service,CN=System,DC=JJHY,DC=LOCAL

the value of the "fRSMemberReference" Property of the nTFRSSubscriber object
will reflect the new value

If im reading it right, the object already has the correct name

So I back up a step to looking at the attributes actual NTFRS Subscriptions container and noted an attribute frsComputerReferenceBL that has the old LIBSRV naming  So I started looking and came across this

http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/fd1a2738-f0de-4171-875f-5b5df781a1bf

it sounds about identical to what has happened with these machines except I dont have a record of the 13562, being I lack at test environment, feedback is appriciated

Is the server reference object correct?

Domain
- DC=KSL1,DC=LOCAL
-- CN=System
--- CN=File Replication Service
----CN=Domain System Volume (SYSVOL share)
-----CN=SRVPDC

13562 is logged when you are missing objects or attributes. Not it a attribute in incorrect.

no SRVPDC is not contained in that location but I have found the L1BO and the LIBSRV along with my ADC units.

So I guess I need to add the new object CN=SRVPDC and remove the Object L1BO + LIBSRV, then go back to fix fRSMemberReference and correct it accordingly

grrr, thought I would just play it safe and Modify CN=LIBSRV but nope, owned by system.  Will keep reading

Are L1BO and LIBSRV computer object still present in ADUC? (reside Domain Controller OU)

It should look like this:

Domain
- DC=KSL1,DC=LOCAL
-- CN=System
--- CN=File Replication Service
----CN=Domain System Volume (SYSVOL share)
-----CN=SRVPDC
-----CN=SRVADC1
-----CN=SRVADC2

Also check for the computer object in AD Sites & Services (they should be empty though if they are present)

and Modify CN=LIBSRV but nope, owned by system

hmm.. I had no problem renaming this object in a lab.

Are L1BO and LIBSRV computer object still present in ADUC? (reside Domain Controller OU)

current structure looks as follows

Domain
- DC=KSL1,DC=LOCAL
-- CN=System
--- CN=File Replication Service
----CN=Domain System Volume (SYSVOL share)
-----CN=L1BO
-----CN=SRVADC1
-----CN=LIBSRV
-----CN=SRVADC2

Also check for the computer object in AD Sites & Services (they should be empty though if they are present)   Only PDC, ADC1 and ADC2 reside in ADSS

hmm.. I had no problem renaming this object in a lab.

Ok, I think I have been working this too long :(  I had been trying to rename object from "name" attrib, did not even think to 'just" rename object

structure now looks as follows

Domain
- DC=KSL1,DC=LOCAL
-- CN=System
--- CN=File Replication Service
----CN=Domain System Volume (SYSVOL share)
-----CN=L1BO
-----CN=SRVADC1
-----CN=SRVPDC
-----CN=SRVADC2

Since I did not see a I wouldn't do that. on my previous comment (will) remove the Object L1BO + LIBSRV, then go back to fix fRSMemberReference and correct it accordingly  will be how I proceed after lunch..... well remove L1BO at least

Finally showing progress
------------------------------------------------------------
FRSDiag v1.7 on 4/27/2011 12:21:58 PM
.\SRVPDC on 2011-04-27 at 12.21.58 PM
------------------------------------------------------------

Checking for errors/warnings in FRS Event Log .... passed
Checking for errors in Directory Service Event Log .... passed
Checking for minimum FRS version requirement ... passed
Checking for errors/warnings in ntfrsutl ds ... passed
Checking for Replica Set configuration triggers... passed
Checking for suspicious file Backlog size... passed
Checking Overall Disk Space and SYSVOL structure (note: integrity is not checked)...
      ERROR: Junction Point missing on "c:\windows\sysvol\sysvol"
 ......... failed 1
Checking for suspicious inlog entries ... passed
Checking for suspicious outlog entries ...
      ERROR: 57.25% (395 out of 690) of your outlog contains Security ACL events.
      See KB articles below for further information:
            279156 - The Effects of Setting the File System Policy on a Disk Drive or Folder
            284947 - Antivirus Programs May Modify Security Descriptors and Cause Excessive Replication of FRS Data in Sysvol and DFS
 ......... failed
Checking for appropriate staging area size ... passed
Checking for errors in debug logs ... passed
Checking NtFrs Service (and dependent services) state...
      ERROR : Cannot access SYSVOL share on SRVPDC
      ERROR : Cannot access NETLOGON share on SRVPDC
 ......... failed 2
Checking NtFrs related Registry Keys for possible problems...passed
Checking Repadmin Showreps for errors...passed


Final Result = failed with 4 error(s)

The fRSMemberReference is updated when you renamed the server object. I verified that in my lab. You should verify too.

ADSIedit is a very powerful tool, and you should be careful deleting stuffs. I say "I would not delete that", as *if* there happens any unpredictable things after you delete, it will be hard for me to help you recover over a forum :)

ERROR: Junction Point missing on "c:\windows\sysvol\sysvol"

Verify the junction points with linkd according to this KB. Recreate them if they are missing.

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

Just remember you should set the Burflags to D2 on SRVPDC when you have verified the JP.

The fRSMemberReference is updated when you renamed the server object. I verified that in my lab. You should verify too. Update -  verified

ADSIedit is a very powerful tool, and you should be careful deleting stuffs. I say "I would not delete that", as *if* there happens any unpredictable things after you delete, it will be hard for me to help you recover over a forum :)  AGREED~!  

This learning while "on fire" is not what I call an experience I wish to revisit anytime soon but none the less its been and apparently will continue (till all errors resolve)  to be a learning experience that I will keep in a PDF someplace for the future reference hoping to never need to open it again.

Did you verify the junctions points?

If you see the attached picture you will see the SYSVOL objects and where the references points (red arrows). So if you deleted and "NTFRS Member object", you should verify that the object the reference points to is not lingering.

FRS is complicated and if you have problems with orphan objects, missing references, you should consider if demoting/promoting the problem DC is a faster way to recover (assuming it's not a CA or is holding Exchange).

Picture reference: http://technet.microsoft.com/en-us/library/cc758169(WS.10).aspx


overview.jpg

Actually I got caught up in other items and had to leave early, but was reading through the MS KB last night and was noting that MS KB's are not always the best reference and not the first time I have come to realize this.

I reading the whole KB, I came across the summary that within the first steps it made mention of Moving the interior SYSVOL tree to a temporary location on the reference controller but we you get to the step by step there is no mention of it.

In the back of my head I'm thinking...... if you Move the interior SYSVOL tree on the reference machine you break your reference machine as you lose your links and your shares on the reference box.

Reading a MS KB is like reading a road map for China and if you make a wrong turn you end up in a wreck or you end up in Shanghai when you really wanted to be in Hong Kong this is why I try to make it a habit of with MS KB's to read, re-read, re-read again then go looking elsewhere because 2+2 don’t seem to add up and one really has to find another instructor that actually has lived through it.

Anyway.... was only able to do some reading last night before calling it a day, was going to remote in right now to check things but ADC1 is offline that I will need to get back online then I can get back to checking links and yes this FRS condition has been .....'Involved', but I’m also the type that likes to understand and figure out those 'involved’ process when they come up.

I will say I had been looking at the following http://www.pcreview.co.uk/forums/junction-point-missing-t1449224.html and thinking maybe this was last resort as I would assume I’d have to reassign all the roles and such.

No controller for time being is a CA or exchange unit, but looking at the diagram it gives me "some" better comprehension of the process involved.

OK time for me to get this offline ADC back online

well adc1 kind of bit it hard this am and had several areas messed up  I was able to pull some of the problems from a back up but being we have been going to all this "fun" with PDC I decided check all the main points and came across a lost link to windows\sysvol\staging areas\ksl1.local.

When just checking that out Linkd f:\windows\sysvol\staging areas\ksl1.local....... I got the following return  Cannot create a link at f:\windows\sysvol\staging

ADC1 is being decommissioned and ADC2 is to take its place, only that is holding me back is the migration never finished....... anyway just thought I would let you know all the fun i have had already this morning, going to check the other items now on PDC

ok so I have file replications

I had the scripts_delete and scripts_new along with the policy_delete/new happen across all controllers but also noted that from the pdc were i changed the names and set the D2 flag (only on PDC) that I also received back a polices_NTFRS_delete_NTFRS_xxxxx so were did I fail?

OK well now it all looks good, down to just one policy and scripts folder replicant but the size @ \SYSVOL on each controller are drastically different  PDC is reporting 118mb while ADC1 reports size at 17.2mb and ADC2 report 14mb  strangeness, guess i will do more reading after lunch

Is the staging area filled on PDC?

Is the NTFRS_Pre_Existing folder present on PDC? (this folder is created when you set the Burflags to D2)

YES, YES there is, it states to see event log but Im not seeing any errors in FRS    I gather these might have been from previous tries when PDC was broke

well i have been reading and i keep seeing a lot of comments to just delete the folder, after what I have gone though....... yeah im kind of gun shy now, will keep reading

The PreExisting folder is optional and can be deleted to free up space.

http://adfordummiez.com/?p=206

AWESOME  Wish MS was as straight forward  Thanks for the verification

well i got those folders cleared and the checked sizes again and saw some change but not enough so I figured there were hidden files and took appropriate steps and found em in the staging areas folder (guess why i did not see them first time through), went and did some more reading and found to junction folders need to be "empty" which would explain why i cant make the junction on ADC1, no sure how the PDC got the junctions but not going to look bad at a gift

came across https://www.experts-exchange.com/questions/26746300/Problems-with-Active-Directory-in-Windows-Server-2003.html    although the error codes I cant see I have seen....  reading through it sounds like a similar path that we have taken cept in my case server ADC2 is stable.

There was mention in that about turning off NTFRS and then using the good server and coping it to the other severs but sounds a like there as a bit of a chance for failure and being I have almost all my links......... yeah did not want to take the chance either

2nd thought I'm going to take back my comment on ADC 2 being stable as I have not ran a diag since this all started with a failed transfer of the file sever role and moving data files from ADC1, it would be nice if i could just demote ADC1 and take it out of the mix but not sure that would be wise for myself.

Look back over all this I dont think i have seen were i mentioned ADC2 is the replacement ADC1, need to look at my checklist again but think I had all roles of ADC1 transferred across and saved the file sever part for last to avoid interruptions, when i ran the file migration with one of the MS migration tools I noted that it did most of the work and then failed with the main data share which got me to checking various items on ADC1

well I found them on PDC and ADC1 have not checked ADC2 in depth as 2008 R2 seems to restrict access to looking at the files within KSL1.LOCAL even though I am under a domain and enterprise admin login which leads me to believe its a UAC thing and there is not an option to "run as administrator" like i have done with many other items on that new server OS (i know that does not apply to folder, just saying)........ looking at just the properties of Staging areas/KSL1.LOCAL there are 0 bytes and 0 files stated and the overall size of /SYSVOL is just 14mb unlike ADC1 and PDC

dont know why i did not think of it before, look at the pointer (\sysvol\staging) it is devoid of any files

good news, was having some network issues around here and in the course of solving I rebooted all servers and those files a happily gone now!

How about the junction points and the shares?

well start to feel like i see some light at in the tunnel and looking like i need to find dns related issues frsdiag-x-3.txt

Junction points and shares all seem to have repaired without my continued intervention, I know a reboot fixes a lot of things but did not expect this much to clear out, going to check them again here in a bit, have a meeting to attend on all this :-s

PDC produced the following output

C:\Program Files\Support Tools>linkd c:\windows\sysvol\sysvol\ksl1.local
Source  c:\windows\sysvol\sysvol\ksl1.local is linked to
C:\WINDOWS\SYSVOL\domain?

C:\Program Files\Support Tools>linkd c:\windows\sysvol\staging" "areas\ksl1.local
Source  c:\windows\sysvol\staging areas\ksl1.local is linked to
C:\WINDOWS\SYSVOL\staging\domain?

C:\Program Files\Support Tools>

ADC 1 produced the following output

C:\Program Files\Support Tools>linkd f:\windows\sysvol\sysvol\ksl1.local
Source  f:\windows\sysvol\sysvol\ksl1.local is linked to
f:\windows\sysvol\domain

C:\Program Files\Support Tools>linkd f:\windows\sysvol\staging" "areas\ksl1.local
Source  f:\windows\sysvol\staging areas\ksl1.local is linked to



C:\Program Files\Support Tools>


ADC 3 - well seems the linkd tool is missing in 2008 so i will have to load it from someone place and check things then

Is there a "?" at the end of the junction point output on the PDC? (it should not)

ADC1: Does it resolves to the Support tools folder??

To verify DNS:

dcdiag /test:dns /v > dcdiag.txt


This will test all records that is needed for a successful replication:

dnslint /ad /s <ip-address of a DNS server>


Access denied messages can be problems with the secure channel.

https://www.experts-exchange.com/questions/26810356/Rejoing-Primary-Domain-Controller-to-Domain.html

just woke up, yeah im not sure what is up with PDC and the ? for end junction point,

I found a GUI tool to let me scan for junction points and supposed make and kill them too but im more interested in the scan part, anyway running the scan shows me all the right junction points on all the DC's but going CLI I dont see the same things

No ADC1 does not resolve to the support tool it resolved just how copied....... staging areas resolved to apparently "nothing"

from reading in both cases it looks like i need to delete the  resolved to ? and "nothing" links and try again, not sure how well that is going to work when I dont know the end point.


My meeting yesterday was interesting on this subject, i was asked to send along a Thank You from our agency head..... at any rate this booby trap I stepped into that you have been assisting me with come from not only my predecessors but also the "organization IT authority"  (were just a tiny agency within a large organization) that ran into this similar problem about a year or so , there solution took about 30 or so minutes, they copied the SYSVOL from the working DC over to the bad then reset links and then left.......... well kind of, they did not want to send a physical person so they spoke with someone that had less knowledge than myself about computers and told them what to do.  granted were doing about the same thing but at least there is testing and showing and comprehension going on.

Agency head has vowed to never go without and IT person ever again (a commonplace thing here i guess)  I dont know if i should laugh or cry about the whole thing.

Anyway will get to looking at the DNS stuff

yeah have come to realize I walked into a bad situation from the start and when you told me many posts back that a copied sysvol should be avoided, it all came together when we had this meeting on how when and why things were as they were.

one way or another it will all get fixed, just a long an antagonizing process,  when I think I'm finally seeing daylight then come to find out it was just a hole in the clouds.  At least those concerned about this condition understood from the start I was not in any form or fashion a server expert and understand some of the challenges I have stepped into without that kind of background and have appreciated that they can still keep operational even with things being as they are.  I think they are a bit anxious about getting ADC 2 functional cause they have no faith in ADC1 which is an old Acer P3 server from around 2002 that has one drive split into 3 tiny partitions (12gb, 8gb, 8gb), personally I'm surprised it functions at all, This is the machine sysvol was "copied" too

I was told from someone i know that has migrated 20 or more severs that they have never had the challenges I'm seeing but wished me the best of luck and suggested i write a blog on the experience <rolls eyes>

I will see what i can do about the JP's in a few hours, I'm trying to remember its the weekend and gutting a room to rebuild/model for my kids.

Must have been something wrong with the staging areas\ksl1.local object,  kept getting told that could not create link or could not open folder, finally deleted the folder and made a new one and link finally created with no problem.

all links made and functional, will look at the dns next

I was doing some more reading and I think I have identified another "past" issue that may or is causing my access denied, in something I was reading someone mentioned the KDC service account had been deleted causing them similar issues, figured for the heck of it I would check AD for similar and I have found a user account tagged as the KDC SA that had been deactivated, lucky for me was placed in an inactive user container.

I'm going to move that account into my service accounts container and reactive it I syspect that I will need to run netdom resetpwd to make things final across all DC's running?  That I would need to send the netdom command from the PDC?  and at the /user: position I have seen many refereces to \administrator used but the KDCSA is not administrator so I would use the appropriate AD object name?

well seems i cant enable that cause its "built-in" and the administrator object has been in the inactive user container too so not real sure what KDC is using to authenticate across the domain  

seems i was looking down the wrong road as the built-in i guess is suppose to be disabled and I'm not finding anything glaringly obvious to me that something is pointing in the wrong way on DNS but since I have all the JP's verified after fixing I have yet more errors than before on items being denied access

have attached logs, will do some more reading ...... actually think i may hit the bookstore and see if i can find some books that are a little more comprehensible to me than the stuff I keep falling back to on MS and other sites that copy and paste the same work

 testing-fRS-Errors-and-Lint.txt

Can you run a new dcdiag?

dcdiag /v /e /c /f:dcdiag1.txt

Do you have any error IDs in the NTFRS event log?

Diag seems good,  have included the diag and my logs for FRS and Directory service  last errors I saw in FRS and DS were a few days and many reboots ago

 diag1.zip

Like you says, dcdiag looks flawless.

Are all SYSVOLs and NETLOGONs shared?

Try installing "sonar" to see FRS live: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=158cb0fb-fe09-477c-8148-25ae02cf15d8&displaylang=en

A little about usage: http://www.techrepublic.com/article/solutionbase-troubleshooting-the-file-replication-service-with-sonar/5160523

So I installed ultrasound last week on PDC and it shows green across the domain and controllers, does not mean I dont want to check with sonar although ultrasound reads as it may be more up to day with the times, at this point i want to check with any tools available.

So looking at the last log i sent here and looking at ultrasound everything looks great.......... well i was going to ask why the different diag sets looked so vastly different and just realized that the logs are stored in different places, was not aware of the debug folder within system root...... so i have been chasing my tail for hours  LOL  practice i did not need but oh well.  I think maybe I want to clear all those later so i can look at fresh output.

will have to see about the sonar later today maybe this evening, I have to go to another site 100 km away. Will check back once I get back.

THANKS!  

Since you already have Ultasound, you don't have to install Sonar.

Sonar is just a small exe file and you don't need a SQL (for historical data) like you do with UltraSound.

well  I thank you for all the help and looking over logs and hope to never have this issue again, but I have been documenting this stuff so will have a reference i guess.

floating through the bookstore, nothing really stood out for good comprehensive reading, if you should have any suggestions.....

Was you looking for "AD in genera"l or anything more spesific?

After what I went through over AD I think I might need something that covers that topic very well, but now that the world is moving too 2008 I think I better pick up some info on that too,  Server 2011 is out or coming out, I've not seen it as of yet but starting looking for books on that also.  

Anyway, I guess I'm going to re-prep for the file migration from ADC1 to ADC2 today, so will catch you later.