域内部分机器无法访问Sysvol中PowerShell脚本，疑与DC复制相关

Hey there, let’s work through this DC replication and logon script access issue—this is a super common pain point with SYSVOL, so let’s break it down systematically to get to the root cause.

1. Verify SYSVOL Replication Health Between Your DCs #

Since your script lives in SYSVOL, replication failures between domaincontroller1 and domaincontroller2 are the most likely culprit for inconsistent access. Here’s how to check:

• On both DCs, run repadmin /replsum in an elevated Command Prompt. Look for any replication errors specifically tied to the SYSVOL partition (it’ll show up under File Replication Service/DFS Replication sections).
• If your domain uses DFSR (the modern SYSVOL replication method), run dfsrdiag replicationstate /rgname:"Domain System Volume" to check if both DCs are active in the replication group and no members are stuck.
• Check the Event Viewer on both DCs: For DFSR, look in Applications and Services Logs > DFS Replication for errors like ID 5002 (replication stopped) or 5014 (connection issues). For older FRS setups, check File Replication Service logs for ID 13508 (replication pending) or 13509 (replication failed).

2. Validate SYSVOL Permissions & Script Access #

Even if replication works, permission misconfigurations can block access for some clients:

• Log into a problematic client with a domain user account (not local admin) and manually navigate to \\domain.local\sysvol\domain.local\scripts\Logon\yourscript.ps1. Note the exact error—Is it a permission denied or file not found message?
• Check NTFS permissions on the script and parent folders: On the DC hosting the original script, right-click the Logon folder > Properties > Security. Ensure Domain Users have Read & Execute permissions, and that these permissions are inherited down to the .ps1 file.
• Verify the sysvol share permissions: The share should default to giving Domain Users Read access. If this was modified, it could block client access.

3. Check Client-Side DC Locator & DNS #

Some clients might be connecting to a DC that hasn’t synced the script yet, or have DNS issues preventing them from finding the correct DC:

• On a problematic client, run nltest /dsgetdc:domain.local in Command Prompt. This shows which DC the client is currently using for domain services. If it’s domaincontroller2, confirm that this DC’s SYSVOL has the script (navigate to C:\Windows\SYSVOL\sysvol\domain.local\scripts\Logon on the DC to check).
• Ensure the client’s DNS settings point only to domain-controlled DNS servers—external DNS can cause incorrect DC resolution.
• Flush the client’s DNS cache and refresh its DC list: Run ipconfig /flushdns, then net stop netlogon && net start netlogon to reset the Netlogon service’s cached DC info.

4. Test PowerShell Execution Policy on Clients #

Sometimes the "cannot access file" error masks a PowerShell execution policy block:

• On a problematic client, open PowerShell as the domain user and run Get-ExecutionPolicy. If it’s set to Restricted, that will block all script execution (even if the file is accessible).
• Test by setting the policy to RemoteSigned for the current user: Run Set-ExecutionPolicy RemoteSigned -Scope CurrentUser (you’ll need to confirm the change). Try logging off and back on to see if the script runs.

Quick Fix: Force Manual Replication #

If you confirm replication is lagging, you can force an immediate sync:

• On domaincontroller1 (the DC where you added the script), run repadmin /syncall /APed to force sync all domain partitions to all other DCs.
• For DFSR, run dfsrdiag syncnow /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /member:domaincontroller2 to trigger an immediate sync to domaincontroller2.

内容的提问来源于stack exchange，提问作者turbonerd