when I check one of the dc with dcdiag the results are as follows :
Directory Server Diagnosis
Performing initial setup:
* Identified AD Forest.
Done gathering initial info.
Doing initial required tests
Testing server: Default-First-Site-NameAD4
Starting test: Connectivity
……………………. AD4 passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-NameAD4
Starting test: DNS
DNS Tests are running and not hung. Please wait a few minutes…
……………………. AD4 passed test DNS
Running partition tests on : ForestDnsZones
Running partition tests on : DomainDnsZones
Running partition tests on : Schema
Running partition tests on : Configuration
Running partition tests on : domain
Running enterprise tests on : domain.local
Starting test: DNS
Test results for domain controllers:
DC: AD4.domain.local
Domain: domain.local
TEST: Dynamic update (Dyn)
Warning: Failed to add the test record dcdiag-test-record in zone domain.local
TEST: Records registration (RReg)
Network Adapter [00000018] XenServer PV Network Device:
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._udp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kpasswd._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.Default-First-Site-Name._sites.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_ldap._tcp.gc._msdcs.domain.local
Warning:
Missing A record at DNS server 192.168.100.4:
gc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._udp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kpasswd._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.Default-First-Site-Name._sites.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_ldap._tcp.gc._msdcs.domain.local
Warning:
Missing A record at DNS server 192.168.100.14:
gc._msdcs.domain.local
Error: Record registrations cannot be found for all the network adapters
Summary of DNS test results:
Auth Basc Forw Del Dyn RReg Ext
_________________________________________________________________
Domain: domain.local
AD4 PASS PASS PASS PASS WARN FAIL n/a
……………………. domain.local failed test DNS
Содержание
- The dfs replication service encountered an error communicating with partner
- Answered by:
- Question
- The dfs replication service encountered an error communicating with partner
- Asked by:
- Question
- All replies
- The dfs replication service encountered an error communicating with partner
- Answered by:
- Question
- Answers
- All replies
The dfs replication service encountered an error communicating with partner
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
I have installed windows 2008 R2 x64 on two servers and deployed DFS-Replication. Error 5014, 5008,5002 keeps on coming after certain days and replication starts after it. I’m worried why these error are occuring. can anyone help?
EVENT 5014
The DFS Replication service is stopping communication with partner EKTW2K8FSRV2 for replication group Photos due to an error. The service will retry the connection periodically.
Additional Information:
Error: 1723 (The RPC server is too busy to complete this operation.)
Connection ID: 17ED06AD-C3FD-40E1-ABAB-73139A5C0097
Replication Group ID: E980F065-7465-4523-A899-293133BEFDAA
EVENT 5008The DFS Replication service failed to communicate with partner EKTW2K8FSRV2 for replication group Photos. This error can occur if the host is unreachable, or if the DFS Replication service is not running on the server.
Partner DNS Address: EKTW2K8FSRV2.snpl.net.np
Optional data if available:
Partner WINS Address: EKTW2K8FSRV2
Partner IP Address: 192.168.70.126
The service will retry the connection periodically.
Error: 1722 (The RPC server is unavailable.)
Connection ID: 17ED06AD-C3FD-40E1-ABAB-73139A5C0097
Replication Group ID: E980F065-7465-4523-A899-293133BEFDAA
EVENT 5002
The DFS Replication service encountered an error communicating with partner EKTW2K8FSRV2 for replication group Photos.
Partner DNS address: EKTW2K8FSRV2.snpl.net.np
Optional data if available:
Partner WINS Address: EKTW2K8FSRV2
Partner IP Address: 192.168.70.126
The service will retry the connection periodically.
Error: 1753 (There are no more endpoints available from the endpoint mapper.)
Connection ID: 17ED06AD-C3FD-40E1-ABAB-73139A5C0097
Replication Group ID: E980F065-7465-4523-A899-293133BEFDAA
EVENT 5004
The DFS Replication service successfully established an inbound connection with partner EKTW2K8FSRV2 for replication group Information.
Connection Address Used: EKTW2K8FSRV2.snpl.net.np
Connection ID: 455CB401-0DAF-4BA6-882C-8E0206C3A6A9
Replication Group ID: B4BA1C7A-378E-4DE0-8522-CB9BB9E0B192
Источник
The dfs replication service encountered an error communicating with partner
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Asked by:
Question
When check repadmin /replsum and netdom query fsmo via command line output :
The system cannot find the file specified.
The command failed to complete successfully.
When I check log in event viewer
The DFS Replication service encountered an error communicating with partner for replication group Domain System Volume.
When I test replicate now domain controller :
Mark the answer if it helps you.
I can’t access DCs
Mark the answer if it helps you.
Might want to check that the DNS is OK and is resolved (both Forward and Reverse).
Also check the health of the Domain Controller with the dcdiag commands.
Dcdiag: How to Check Domain Controller Health
You’ll also reach more DFS Replication experts in the dedicated forum over here:
Windows Server > File Services and Storage
Best regards,
Leon
Blog: https://thesystemcenterblog.com LinkedIn:
Mark the answer if it helps you.
Mark the answer if it helps you.
when I check one of the dc with dcdiag the results are as follows :
Directory Server Diagnosis
Performing initial setup:
* Identified AD Forest.
Done gathering initial info.
Doing initial required tests
Testing server: Default-First-Site-NameAD4
Starting test: Connectivity
. AD4 passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-NameAD4
Starting test: DNS
DNS Tests are running and not hung. Please wait a few minutes.
. AD4 passed test DNS
Running partition tests on : ForestDnsZones
Running partition tests on : DomainDnsZones
Running partition tests on : Schema
Running partition tests on : Configuration
Running partition tests on : domain
Running enterprise tests on : domain.local
Starting test: DNS
Test results for domain controllers:
DC: AD4.domain.local
Domain: domain.local
TEST: Dynamic update (Dyn)
Warning: Failed to add the test record dcdiag-test-record in zone domain.local
TEST: Records registration (RReg)
Network Adapter [00000018] XenServer PV Network Device:
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._udp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kpasswd._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_kerberos._tcp.Default-First-Site-Name._sites.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.4:
_ldap._tcp.gc._msdcs.domain.local
Warning:
Missing A record at DNS server 192.168.100.4:
gc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._udp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kpasswd._tcp.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_kerberos._tcp.Default-First-Site-Name._sites.domain.local
Warning:
Missing SRV record at DNS server 192.168.100.14:
_ldap._tcp.gc._msdcs.domain.local
Warning:
Missing A record at DNS server 192.168.100.14:
gc._msdcs.domain.local
Error: Record registrations cannot be found for all the network adapters
Источник
The dfs replication service encountered an error communicating with partner
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
I have 3 Windows 2012 R2 DC’s, they are fully patched and functioning as intended. A few days ago I migrated the FRS to DFS, all show in the «eliminated» state. however I now get the events listed below in my DCDiag, DNS, WINS, etc. are all correct. Replication goes through without any errors, any help/ insight would be appreciated.
Starting test: DFSREvent
The DFS Replication Event Log.
There are warning or error events within the last 24 hours after the
SYSVOL has been shared. Failing SYSVOL replication problems may cause
Group Policy problems.
A warning event occurred. EventID: 0x80001396
Time Generated: 08/29/2016 08:07:43
The DFS Replication service is stopping communication with partner DC-Name for replication group Domain System Volume due to an error. The service will retry the connection periodically.
Error: 1723 (The RPC server is too busy to complete this operation.)
Connection ID: 3FF762E2-3312-4A65-A7E2-6AC390B8AAA4
Replication Group ID: 7A73E152-50A8-4771-9520-12F22A15D334
A warning event occurred. EventID: 0x80001396
Time Generated: 08/29/2016 14:23:33
The DFS Replication service is stopping communication with partner DC-Name for replication group Domain System Volume due to an error. The service will retry the connection periodically.
Error: 1723 (The RPC server is too busy to complete this operation.)
Connection ID: AB877B94-36EA-4345-8413-5BAAB8165AA7
Replication Group ID: 7A73E152-50A8-4771-9520-12F22A15D334
An error event occurred. EventID: 0xC000138A
Time Generated: 08/29/2016 14:23:56
The DFS Replication service encountered an error communicating with partner DC-Name for replication group Domain System Volume.
Partner DNS address: DC-Name.
Optional data if available:
Partner WINS Address: DC-Name
Partner IP Address:
The service will retry the connection periodically.
Error: 1726 (The remote procedure call failed.)
Connection ID: AB877B94-36EA-4345-8413-5BAAB8165AA7
Replication Group ID: 7A73E152-50A8-4771-9520-12F22A15D334
A warning event occurred. EventID: 0x80001396
Time Generated: 08/29/2016 14:34:30
The DFS Replication service is stopping communication with partner DC-Name for replication group Domain System Volume due to an error. The service will retry the connection periodically.
Error: 1723 (The RPC server is too busy to complete this operation.)
Connection ID: 3FF762E2-3312-4A65-A7E2-6AC390B8AAA4
Replication Group ID: 7A73E152-50A8-4771-9520-12F22A15D334
An error event occurred. EventID: 0xC000138A
Time Generated: 08/29/2016 14:34:44
The DFS Replication service encountered an error communicating with partner DC-Name for replication group Domain System Volume.
Partner DNS address: DC-Name.
Optional data if available:
Partner WINS Address: DC-Name
Partner IP Address:
The service will retry the connection periodically.
Error: 1753 (There are no more endpoints available from the endpoint mapper.)
Connection ID: 3FF762E2-3312-4A65-A7E2-6AC390B8AAA4
Replication Group ID: 7A73E152-50A8-4771-9520-12F22A15D334.
Answers
Thanks for your post.
According to the research, the issue maybe occur because the DFS servers do not have the permission to read AD information on themselves or their partners.
1. Please open the ADSIedit.msc console to verify the «Authenticated Users» is set with the default READ permission on the following object:
a. The computer object of the DFS server.
b. The DFSR-LocalSettings object under the DFS server computer object.
2. After the permissions is set correct, please run «DFSRDIAG POLLAD» to pick up the changes.
Another possible reason is that FSRM is configured as some types of files are blocked from DFS replication. When the DFSR filters are not set to match FSRM screens by extension and the files exist on the server before screening, this can lead to degraded DFSR performance and the files will never replicate.
If possible, please remove file screening and reconfigure it to remove files by extension or set a comparable DFSR filter rule to prevent replication attempts.
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
I did some research but failed to find DFSR replication successful related event ID.
So what’s the current progress of your issue? After these changes, the same event listed in DCDIAG?
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
Thanks for your post.
According to the research, the issue maybe occur because the DFS servers do not have the permission to read AD information on themselves or their partners.
1. Please open the ADSIedit.msc console to verify the «Authenticated Users» is set with the default READ permission on the following object:
a. The computer object of the DFS server.
b. The DFSR-LocalSettings object under the DFS server computer object.
2. After the permissions is set correct, please run «DFSRDIAG POLLAD» to pick up the changes.
Another possible reason is that FSRM is configured as some types of files are blocked from DFS replication. When the DFSR filters are not set to match FSRM screens by extension and the files exist on the server before screening, this can lead to degraded DFSR performance and the files will never replicate.
If possible, please remove file screening and reconfigure it to remove files by extension or set a comparable DFSR filter rule to prevent replication attempts.
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
I went into ADSIEdit and verified that authenticated users have read right all the way down to the sysvol subscription. There are no file screen settings in place either.
My DFS Replication log generates event id 5014 followed by event id 5004. I created a diagnostic report and under the DFS Replication Propagation Report the test shows as incomplete (Status: pending 1 of 2 completed) and under the member section the replication status sits at arrival pending.
The DFS Replication Propagation report does not complete any of the tests.
I ran the command below and it succeed.
dfsrdiag pollad /member:
UAC is disabled on all DC’s
DCDIAG /c /v comes back with everything clean and working (except the DRSEvent test)
Should the authenticated users have read right assigned to all the keys?
Using portquery tool I have verified that port 135 is open and communicating between the DC’s.
The picture below shows what the TCP stack looks like on all DC NICS:
Below is the information taken from the debug log:
20160831 08:52:06.249 1804 CCTX 2390 VolumeIdTable::ProcessVolumes SVI Paths:
20160831 08:52:06.249 1804 CCTX 2392 VolumeIdTable::ProcessVolumes sviPath:\?Volume<455f7211-bbad-11e4-80b3-806e6f6e6963>System Volume Information
20160831 08:52:06.249 1804 CCTX 2392 VolumeIdTable::ProcessVolumes sviPath:\.C:System Volume Information
20160831 08:52:06.249 1804 CCTX 1374 VolumeIdTable::GetVolumeIdFromVolumeNotification Getting the volume guid for volume pathname:\?Volume<455f7216-bbad-11e4-80b3-806e6f6e6963> index:0
20160831 08:52:06.249 1804 CCTX 1407 [WARN] VolumeIdTable::GetVolumeIdFromVolumeNotification [CLUSTER] (Ignored) Couldn’t find the volume guid. guid:<455f7216-bbad-11e4-80b3-806e6f6e6963>
20160831 08:52:06.249 1804 VDSN 656 [WARN] VdsAdviseSink::InitializeCache (Ignored) Unable to retrieve volume’s GUID. Volume will not be added to the cache. This could be a CD ROM. Error:
+ [Error:9225(0x2409) VolumeIdTable::GetVolumeIdFromVolumeNotification context.cpp:1440 1804 C The volume was not found]
+ [Error:9225(0x2409) VolumeIdTable::GetVolumeIdFromVolumeNotification context.cpp:1437 1804 C The volume was not found]
20160831 08:52:06.249 1804 VDSN 520 VdsAdviseSink::InitializeCache Fetched:1, Pack#:2
20160831 08:52:06.249 1804 VDSN 581 VdsAdviseSink::InitializeCache Fetched:1, Volume#:1
20160831 08:52:06.342 1804 CCTX 1311 VolumeIdTable::GetVolumeIdFromVolumeNotification VDS service supplied number of paths for this notification: 1
20160831 08:52:06.342 1804 CCTX 1338 VolumeIdTable::GetVolumeIdFromVolumeNotification This node is capable of being clustered and we are doing retry number:0
20160831 08:52:06.342 1804 CLUS 4047 Cluster::ClusterUtil::GetOwnedOnlinePhysicalDisks [CLUSTER] Get locally owned online physical disk list
20160831 08:52:06.342 1804 CCTX 1686 VolumeIdTable::GetClusteredVolumes [CLUSTER] Cluster service is not installed or configured. Skipping clustered volume query.
20160831 08:52:06.342 1804 CCTX 1875 [WARN] VolumeIdTable::GetNonClusteredVolumes (Ignored) Unable to retrieve the volume’s serial number and filesystem name. Volume will not be added to the Volume Id Table. volPath:\?Volume<455f7216-bbad-11e4-80b3-806e6f6e6963> Error:[Error:21(0x15) Util::GetVolumeInformationW fsutil.cpp:306 1804 W The device is not ready.]
20160831 08:52:06.342 1804 CCTX 2374 VolumeIdTable::ProcessVolumes VolumeIdTable:
20160831 08:52:06.342 1804 CCTX 2380 VolumeIdTable::ProcessVolumes volId: <455f7211-bbad-11e4-80b3-806e6f6e6963>volPath:\?Volume <455f7211-bbad-11e4-80b3-806e6f6e6963>volPathIsMountPoint:false isClustered:false clusterDisk: serialNumber:3498427251
20160831 08:52:06.342 1804 CCTX 2380 VolumeIdTable::ProcessVolumes volId: <455f7212-bbad-11e4-80b3-806e6f6e6963>volPath:\.C: volPathIsMountPoint:false isClustered:false clusterDisk: serialNumber:2693168507
20160831 08:52:06.342 1804 CCTX 2390 VolumeIdTable::ProcessVolumes SVI Paths:
20160831 08:52:06.342 1804 CCTX 2392 VolumeIdTable::ProcessVolumes sviPath:\?Volume<455f7211-bbad-11e4-80b3-806e6f6e6963>System Volume Information
20160831 08:52:06.342 1804 CCTX 2392 VolumeIdTable::ProcessVolumes sviPath:\.C:System Volume Information
20160831 08:52:06.342 1804 CCTX 1374 VolumeIdTable::GetVolumeIdFromVolumeNotification Getting the volume guid for volume pathname:\?Volume<455f7211-bbad-11e4-80b3-806e6f6e6963> index:0
20160831 08:52:06.358 1804 VDSN 662 VdsAdviseSink::InitializeCache Insert in cache. VDS_OBJECT_ID: volId:\?Volume<455f7211-bbad-11e4-80b3-806e6f6e6963>
20160831 08:52:06.358 1804 VDSN 581 VdsAdviseSink::InitializeCache Fetched:1, Volume#:2
20160831 08:52:06.482 1804 CCTX 1311 VolumeIdTable::GetVolumeIdFromVolumeNotification VDS service supplied number of paths for this notification: 1
20160831 08:52:06.482 1804 CCTX 1338 VolumeIdTable::GetVolumeIdFromVolumeNotification This node is capable of being clustered and we are doing retry number:0
20160831 08:52:06.482 1804 CLUS 4047 Cluster::ClusterUtil::GetOwnedOnlinePhysicalDisks [CLUSTER] Get locally owned online physical disk list
20160831 08:52:06.482 1804 CCTX 1686 VolumeIdTable::GetClusteredVolumes [CLUSTER] Cluster service is not installed or configured. Skipping clustered volume query.
20160831 08:52:06.498 1804 CCTX 1875 [WARN] VolumeIdTable::GetNonClusteredVolumes (Ignored) Unable to retrieve the volume’s serial number and filesystem name. Volume will not be added to the Volume Id Table. volPath:\?Volume<455f7216-bbad-11e4-80b3-806e6f6e6963> Error:[Error:21(0x15) Util::GetVolumeInformationW fsutil.cpp:306 1804 W The device is not ready.]
20160831 08:52:06.498 1804 CCTX 2374 VolumeIdTable::ProcessVolumes VolumeIdTable:
20160831 08:52:06.498 1804 CCTX 2380 VolumeIdTable::ProcessVolumes volId: <455f7211-bbad-11e4-80b3-806e6f6e6963>volPath:\?Volume <455f7211-bbad-11e4-80b3-806e6f6e6963>volPathIsMountPoint:false isClustered:false clusterDisk: serialNumber:3498427251
20160831 08:52:06.498 1804 CCTX 2380 VolumeIdTable::ProcessVolumes volId: <455f7212-bbad-11e4-80b3-806e6f6e6963>volPath:\.C: volPathIsMountPoint:false isClustered:false clusterDisk: serialNumber:2693168507
20160831 08:52:06.498 1804 CCTX 2390 VolumeIdTable::ProcessVolumes SVI Paths:
20160831 08:52:06.498 1804 CCTX 2392 VolumeIdTable::ProcessVolumes sviPath:\?Volume<455f7211-bbad-11e4-80b3-806e6f6e6963>System Volume Information
20160831 08:52:06.498 1804 CCTX 2392 VolumeIdTable::ProcessVolumes sviPath:\.C:System Volume Information
20160831 08:52:06.498 1804 CCTX 1374 VolumeIdTable::GetVolumeIdFromVolumeNotification Getting the volume guid for volume pathname:\?Volume<455f7212-bbad-11e4-80b3-806e6f6e6963> index:0
20160831 08:52:06.498 1804 VDSN 662 VdsAdviseSink::InitializeCache Insert in cache. VDS_OBJECT_ID: <524bbcfd-52be-4981-80df-5c8ad4a3f757>volId:\.C:
20160831 08:52:06.498 1804 FREP 2561 FrsReplicator::Initialize Registering for the VDS Service SCM notification.
Источник
Поучительная история о том, как не надо удалять контроллеры из домена и как чинить упавшую репликацию между контроллерами.
Итак, смеркалось… Ко мне обратился коллега с просьбой помочь разобраться в странной, необъяснимой ™ проблеме: между DC выделенной инфраструктуры ВНЕЗАПНО не реплицируются шары Netlogon и Sysvol. При этом, разумеется, «никто ничего не трогал» (с), однако какое-то время назад из этого домена был удален контроллер OLDDC со всеми FSMO ролями, каковые роли, со слов коллеги, были перед этим корректно перенесены на один из оставшихся в строю контроллеров DC1 (все имена действующих героев серверов и доменов изменены на произвольные).
Путем беглого просмотра логов на одном из пострадавших контроллеров были довольно быстро выловлены три ключевые ошибки:
1058 - The processing of Group Policy failed.1014 - Name resolution for the name _ldap._tcp.DC1. timed out after none of the configured DNS servers responded.
9033 - The DFS Replication service is stopping communication with partner DC1 for replication group Domain System Volume due to an error. The service will retry the connection periodically.
Далее – наш любимый dcdiag, который в числе прочего мусора выдал крайне примечательную вещь:
TEST: Delegations (Del)
Delegation information for the zone: domain.ru.
Delegated domain name: _msdcs.domain.ru.
Error: DNS server: OLDDC.domain.ru.
IP:<Unavailable> [Missing glue A record]
[Error details: 9714 (Type: Win32 — Description: DNS name does not exist.)]
Все чудесатее и чудесатее. Чешем репу, открываем консоль DNS и проверяем NS записи в зоне _msdcs.domain.ru. Вроде все на месте и все указывают на боевые домен-контроллеры. А вот в зоне domain.ru для зоны-заглушки _msdcs.domain.ru как раз и обнаружилась NS запись с указанием старого OLDDC, причем она же – единственная.
Правим запись, делаем принудительную репликацию AD, рестартуем службу DFSR на контроллерах. В логах наблюдаем:
5004 - The DFS Replication service successfully established an inbound connection with partner DC1 for replication group Domain System Volume.
Все? Как бы не так: репликация по-прежнему не работает. Курим лог дальше. Обнаруживаем вот это:
4614 - The DFS Replication service initialized SYSVOL at local path C:WindowsSYSVOLdomain and is waiting to perform initial replication.
Initial replication, как несложно догадаться, так и не проходит. Мораль – надо восстанавливать хирургическими методами. Пробуем обойтись малой кровью, не трогая PDC: выполняем процедуру non-authoritative synchronization на подчиненном контроллере – не помогает. Тут уж иного выхода, кроме как authoritative synchronization, нет. Сам механизм пошагово описан в приведенной статье KB, повторять его не вижу смысла, однако хотел бы заострить внимание на некоторых моментах:
1. Перед началом процедуры крайне желательно сделать полный бэкап папки C:WindowsSYSVOLdomain (а в случае, если при установке DC дефолтные пути менялись – той папки, которая была прописана при установке роли ADDS).
2. Никаких изменений в GPO во время процедуры проводиться не должно.
3. После выполнения authoritative synchronization на основном DC, необходимо выполнить non-authoritative synchronization на всех подчиненных. При этом перед началом данной процедуры рекомендуется очистить на них папки C:WindowsSYSVOLdomainPolicies и C:WindowsSYSVOLdomainscripts, предварительно на всякий случай тоже забэкапив их.
4. Если на каком-то из DC не находится утилита dfsrdiag – ставим фичу DFS Management Tools из ветки Remote Server Administration Tools.
Если все сделано правильно, то в конце на каждом DC мы получим такое сообщение в логе:
4604 - The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:WindowsSYSVOLdomain.
А мораль сей басни такова: при удалении DC из домена, тем более при переносе с него ролей FSMO, будет далеко не лишним пройтись по консолям DNS и Sites and Services в поисках оставшихся от него «хвостов». В данном случае это не было сделано и могло бы привести к печальным последствиям, поскольку отсутствие репликации между контроллерами означает, в том числе, и рассинхронизацию GPO.
Healthy SYSVOL replication is key for every active directory infrastructure. when there is SYSVOL replication issues you may notice,
1. Users and systems are not applying their group policy settings properly.
2. New group policies not applying to certain users and systems.
3. Group policy object counts is different between domain controllers (inside SYSVOL folders)
4. Log on scripts are not processing correctly
Also, same time if you look in to event viewer you may able to find events such as,
|
Event Id |
Event Description |
|
2213 |
The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication. Recovery Steps 1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders. 2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command: wmic /namespace:\rootmicrosoftdfs path dfsrVolumeConfig where volumeGuid=”xxxxxxxx″ call ResumeReplication |
|
5002 |
The DFS Replication service encountered an error communicating with partner <FQDN> for replication group Domain System Volume. |
|
5008 |
The DFS Replication service failed to communicate with partner <FQDN> for replication group Home-Replication. This error can occur if the host is unreachable, or if the DFS Replication service is not running on the server. |
|
5014 |
The DFS Replication service is stopping communication with partner <FQDN> for replication group Domain System Volume due to an error. The service will retry the connection periodically. |
Some of these errors can be fixed with simple server reboot or running commands describe in the error ( ex – event 2213 description) but if its keep continuing we need to do Non-Authoritative or Authoritative SYSVOL restore.
Non-Authoritative Restore
If it’s only one or few domain controller (less than 50%) which have replication issues in a given time, we can issue a non-authoritative replication. In that scenario, system will replicate the SYSVOL from the PDC.
Authoritative Restore
If more than 50% of domain controllers have SYSVOL replication issues, it possible that entire SYSVOL got corrupted. In such scenario, we need to go for Authoritative Restore. In this process, first we need to restore SYSVOL from backup to PDC and then replicate over or force all the domain controllers to update their SYSVOL copy from the copy in PDC.
SYSVOL can replicate using FRS too. This is deprecated after windows server 2008, but if you migrated from older Active Directory environment you may still have FRS for SYSVOL replication. It also supports for Non-Authoritative and Authoritative restore but in this demo, I am going to talk only about SYSVOL with DFS replication.
Non-Authoritative DFS Replication
In order to perform a non-authoritative replication,
1) Backup the existing SYSVOL – This can be done by copying the SYSVOL folder from the domain controller which have DFS replication issues in to a secure location.
2) Log in to Domain Controller as Domain Admin/Enterprise Admin
3) Launch ADSIEDIT.MSC tool and connect to Default Naming Context
4) Brows to DC=domain,DC=local > OU=Domain Controllers > CN=(DC NAME) > CN=DFSR-LocalSettings > Domain System Volume > SYSVOL Subscription
5) Change value of attribute msDFSR-Enabled = FALSE
6) Force the AD replication using,
repadmin /syncall /AdP
7) Run following to install the DFS management tools using (unless this is already installed),
Add-WindowsFeature RSAT-DFS-Mgmt-Con
Run following command to update the DFRS global state,
dfsrdiag PollAD
9) Search for the event 4114 to confirm SYSVOL replication is disabled.
Get-EventLog -Log «DFS Replication» | where {$_.eventID -eq 4114} | fl
10) Change the attribute value back to msDFSR-Enabled=TRUE (step 5)
11) Force the AD replication as in step 6
12) Update DFRS global state running command in step 8
13) Search for events 4614 and 4604 to confirm successful non-authoritative synchronization.
All these commands should run from domain controllers set as non-authoritative.
Authoritative DFS Replication
In order to perform to initiate authoritative DFS Replication,
1) Log in to PDC FSMO role holder as Domain Administrator or Enterprise Administrator
2) Stop DFS Replication Service (This is recommended to do in all the Domain Controllers)
3) Launch ADSIEDIT.MSC tool and connect to Default Naming Context
4) Brows to DC=domain,DC=local > OU=Domain Controllers > CN=(DC NAME) > CN=DFSR-LocalSettings > Domain System Volume > SYSVOL Subscription
5) Update the given attributes values as following,
msDFSR-Enabled=FALSE
msDFSR-options=1
6) Modify following attribute on ALL other domain controller.
msDFSR-Enabled=FALSE
7) Force the AD replication using,
repadmin /syncall /AdP
Start DFS replication service in PDC
9) Search for the event 4114 to verify SYSVOL replication is disabled.
10) Change following value which were set on the step 5,
msDFSR-Enabled=TRUE
11) Force the AD replication using,
repadmin /syncall /AdP
12) Run following command to update the DFRS global state,
dfsrdiag PollAD
13) Search for the event 4602 and verify the successful SYSVOL replication.
14) Start DFS service on all other Domain Controllers
15) Search for the event 4114 to verify SYSVOL replication is disabled.
16) Change following value which were set on the step6. This need to be done on ALL domain controllers.
msDFSR-Enabled=TRUE
17) Run following command to update the DFRS global state,
dfsrdiag PollAD
18) Search for events 4614 and 4604 to confirm successful authoritative synchronization.
Please note you do not need to run Authoritative DFS Replication for every DFS replication issue. It should be the last option.
Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com
What a week; actually started over the weekend, with a DFSR database crash on a spoke server within my topology. This happened for a replication group that is 1.6TB in size, so the volume check takes quite a long time.
During this time, replication hung so I decided to restart the DFSR service on our hub server. Unfortunately, the restart failed, and the service was hung at “stopping”. So I killed the dfsrs.exe process, and then started the service.
At this point, it tried to repair the DFSR database, but failed so it went into “initial replication”. Initial replication on a 1.6 TB replication group is a thing straight from my nightmares. Compounding the problem is the fact that the hub server then crashed the next night (which I haven’t had time to look into yet) and basically had to restart the process.
That was 3 days ago, and after all this time, I’ve got initial replication finished but a backlog of 10,000 files going to 2 of the spoke servers. That backlog didn’t appear to be moving, and investigating the DFS Replication section of the Event Log revealed:
The DFS Replication service encountered an error communicating with partner SW3020 for replication group swg.cafilesjobs. The service will retry the connection periodically. Additional Information: Error: 9032 (The connection is shutting down)
The steps I took to fix this error:
- On the hub server, I deleted the individual connections from the hub to the spoke servers for this specific replication group
- From a domain controller in the hub site, I ran this to ensure those changes reached the branch sites sooner:
repadmin /syncall /e /A /P - Then I re-created the connections for each spoke and re-ran the repadmin command.
Following that, both servers showed this in the DFSR log:
The DFS Replication service failed to communicate with partner SW3020 for replication group swg.cafilesjobs. The partner did not recognize the connection or the replication group configuration. The service will retry the connection periodically. Additional Information: Error: 9026 (The connection is invalid)
So from each spoke server, I ran the following:
dfsrdiag pollad /v /member:hubserver.domain.com (Replication partner)
dfsrdiag pollad /v /member:hub_site_dc.domain.com (Domain Controller in hub site)
Shortly thereafter I saw this in the logs:
The DFS Replication service successfully established an inbound connection with partner SW3020 for replication group swg.cafilesjobs.
And now replication traffic is flowing properly. Now all I have to do is deal with the more than 500 conflict files this whole ordeal has generated.
I have 3 servers in this network:
ServerA — WS 2008
ServerB — WS 2008 R2
ServerC — WS 2012 R2
I was checking out the AD health today from Server C. I ran:
DCDIAG /C /E /V
Most everything came back fine except for it was showing some DFSR errors.
I looked in event viewer for DFS Replication and I see the following Errors/Warnings:
1) DFSR Event ID 5012 — DFS replication service failed to communicate with partner ServerA for replication group Domain System Volume. The partner did not recognize the connection or the replication group configuration.
Under Additional Information it shows Error: 9026 (The connection is invalid)
11 seconds after that error, it has another entry saying that the DFS replication service successfully established a inbound connection with partner ServerA for replication group Domain System Volume.
2) DFSR Event ID 5002 — The DFS Replication service encountered an error communicating with partner ServerA for replication group Domain System Volume.
Under Additional Information it shows Error: 9036 (Paused for backup or restore)
17 seconds after that error it has another entry saying that The DFS Replication service successfully established an inbound connection with partner ServerA for replication group Domain System Volume.
3) Warning DFSR Event ID 5014 — The DFS Replication service is stopping communication with partner ServerB for replication group Domain System Volume due to an error.
Under Additional Information it shows Error: 9036 (Paused for backup or restore)
4 seconds later it shows DFSR Event 5004 saying The DFS Replication service successfully established an inbound connection with partner ServerB for replication group Domain System Volume.
Any idea what is going on? It looks to my like replication is working as shortly after each error/warning there is an event saying communication has been established again. However, I would like to verify there is no bigger issue and eliminate these errors/warnings if possible.
They do seem to be occuring about the same time every day/night. Is this related to backup software I am using? I am using Veeam on ServerC as it is a VM and ServerA and ServerB are both physical servers.
On ServerB I do also see Error 5002 and that it is unable to communicate with ServerA. It has Error: 9036 (Paused for backup or restore) also.
Thanks as always for the help!