Warning dcgetdcname pdc required call failed error 1355

Warning dcgetdcname pdc required call failed error 1355

Am hoping someone can help.

On 1 of my 2008 R2 DCs (AV2) I’m seeing multiple errors for enterprise tests from DCDIAG (please see output below). The errors are mainly 1355 and they sound quite serious («A Primary Domain Controller could not be located», «The server holding the PDC role is down.»).

In Event Viewer on my AV2 server I’m also seeing errors 1202 (Active Directory Web Services) and 8016 (related to my Sophos anti-virus management console).

These issues seemed to have cropped up after installing a bunch of Microsoft updates.

Thanks in advance for any feedback.

C:Usersadmin1.mydomain>netdom query fsmo
Schema master FS1.mydomain.com
Domain naming master FS1.mydomain.com
PDC FS1.mydomain.com
RID pool manager FS1.mydomain.com
Infrastructure master FS1.mydomain.com
The command completed successfully.

C:Usersadmin1.mydomain>
C:Usersadmin1.mydomain>
C:Usersadmin1.mydomain>dcdiag

Directory Server Diagnosis

Performing initial setup:
Trying to find home server.
Home Server = AV2
* Identified AD Forest.
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-NameAV2
Starting test: Connectivity
. AV2 passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-NameAV2
Starting test: Advertising
Warning: AV2 is not advertising as a time server.
. AV2 failed test Advertising
Starting test: FrsEvent
. AV2 passed test FrsEvent
Starting test: DFSREvent
. AV2 passed test DFSREvent
Starting test: SysVolCheck
. AV2 passed test SysVolCheck
Starting test: KccEvent
. AV2 passed test KccEvent
Starting test: KnowsOfRoleHolders
. AV2 passed test KnowsOfRoleHolders
Starting test: MachineAccount
. AV2 passed test MachineAccount
Starting test: NCSecDesc
Error NT AUTHORITYENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=DomainDnsZones,DC=mydomain,DC=com
Error NT AUTHORITYENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=ForestDnsZones,DC=mydomain,DC=com
. AV2 failed test NCSecDesc
Starting test: NetLogons
. AV2 passed test NetLogons
Starting test: ObjectsReplicated
. AV2 passed test ObjectsReplicated
Starting test: Replications
. AV2 passed test Replications
Starting test: RidManager
. AV2 passed test RidManager
Starting test: Services
. AV2 passed test Services
Starting test: SystemLog
An error event occurred. EventID: 0xC0001B6F
Time Generated: 12/09/2013 16:54:59
Event String:
The Sophos Management Service service terminated with the following error:
An error event occurred. EventID: 0xC0001B6F
Time Generated: 12/09/2013 17:05:01
Event String:
The Sophos Management Service service terminated with the following error:
A warning event occurred. EventID: 0x0000000B
Time Generated: 12/09/2013 17:19:31
Event String:
Custom dynamic link libraries are being loaded for every application. The system adminis
trator should review the list of libraries to ensure they are related to trusted applications.
A warning event occurred. EventID: 0x8000001D
Time Generated: 12/09/2013 17:19:44
Event String:
The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart ca
rd logons, or the KDC certificate could not be verified. Smart card logon may not function correctly
if this problem is not resolved. To correct this problem, either verify the existing KDC certificat
e using certutil.exe or enroll for a new KDC certificate.
A warning event occurred. EventID: 0x00000C18
Time Generated: 12/09/2013 17:19:52
Event String: The primary Domain Controller for this domain could not be located.
A warning event occurred. EventID: 0x00002724
Time Generated: 12/09/2013 17:20:01
Event String:
This computer has at least one dynamically assigned IPv6 address.For reliable DHCPv6 ser
ver operation, you should use only static IPv6 addresses.
An error event occurred. EventID: 0xC0001B6F
Time Generated: 12/09/2013 17:20:07
Event String:
The Sophos Management Service service terminated with the following error:
A warning event occurred. EventID: 0x00000012
Time Generated: 12/09/2013 17:19:23
Event String:
The Remote Desktop license server «AV2» has not been activated and therefore will only i
ssue temporary licenses. To issue permanent licenses, the Remote Desktop license server must be acti
vated.
A warning event occurred. EventID: 0x00000081
Time Generated: 12/09/2013 17:19:40
Event String:
NtpClient was unable to set a domain peer to use as a time source because of discovery e
rror. NtpClient will try again in 3473457 minutes and double the reattempt interval thereafter. The
error was: The entry is not found. (0x800706E1)
A warning event occurred. EventID: 0x00000081
Time Generated: 12/09/2013 17:19:57
Event String:
NtpClient was unable to set a domain peer to use as a time source because of discovery e
rror. NtpClient will try again in 3473457 minutes and double the reattempt interval thereafter. The
error was: The entry is not found. (0x800706E1)
A warning event occurred. EventID: 0x000727AA
Time Generated: 12/09/2013 17:21:25
Event String:
The WinRM service failed to create the following SPNs: WSMAN/AV2.mydomain.com; WSMAN/AV2.

An error event occurred. EventID: 0xC0001B6F
Time Generated: 12/09/2013 17:29:06
Event String:
The Sophos Management Service service terminated with the following error:
An error event occurred. EventID: 0xC000271A
Time Generated: 12/09/2013 17:29:36
Event String:
The server <2c5339f1-b8d3-4d40-9245-e68e0f8c6380>did not register with DCOM within the
required timeout.
An error event occurred. EventID: 0xC0001B6F
Time Generated: 12/09/2013 17:29:57
Event String:
The Sophos Management Service service terminated with the following error:
. AV2 failed test SystemLog
Starting test: VerifyReferences
. AV2 passed test VerifyReferences

Running partition tests on : DomainDnsZones
Starting test: CheckSDRefDom
. DomainDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
. DomainDnsZones passed test CrossRefValidation

Running partition tests on : ForestDnsZones
Starting test: CheckSDRefDom
. ForestDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
. ForestDnsZones passed test CrossRefValidation

Running partition tests on : Schema
Starting test: CheckSDRefDom
. Schema passed test CheckSDRefDom
Starting test: CrossRefValidation
. Schema passed test CrossRefValidation

Running partition tests on : Configuration
Starting test: CheckSDRefDom
. Configuration passed test CheckSDRefDom
Starting test: CrossRefValidation
. Configuration passed test CrossRefValidation

Running partition tests on : mydomain
Starting test: CheckSDRefDom
. mydomain passed test CheckSDRefDom
Starting test: CrossRefValidation
. mydomain passed test CrossRefValidation

Источник

Warning dcgetdcname pdc required call failed error 1355

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Just demoted old PDC and added and promoted new PDC. Dcdiag passed all tests before promoting. Have not raised functional level to 2008 yet.

I believe I scrubbed the old PDC from DNS though I have seen it show up in some queries (can’t remember which).

Dcdiag on the PDC still has no errors.

Other DCs all have this error:

Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355
A Primary Domain Controller could not be located.
The server holding the PDC role is down.

On all DCs netdom query fsmo list the PDC for all roles.

On all DCs nltest /dclist:domain.com lists the correct DC as the PDC.

The PDC seems to be the authoritative time server.

In DFS Management, when I try to list the namespaces I receive the following error:

\domain.comnamespace: The namespace cannot be queried. The specified domain either does not exist or could not be contacted.

Replication groups do populate.

I need help troubleshooting. Thanks

Answers

I think you forgot to delete the entry of OLD dc from DNS from following locations.

Manual Steps

Dnsmgmt.msc [Dns Management]
A.Expand the forward lookup zones_msdcs folder
i. Make sure only the actual domain controllers are listed, delete wrong Alias recordsremove wrong name server records
ii. Select the container [forward lookup zones_msdcs.domain.comdc_sites_sitename_tcp] > delete incorrect _ldap and _kerberos records are listed.
iii. Select the container [forward lookup zones_msdcs.domain.comdc_tcp] and delete incorrect _ldap and _kerberos records
iv. Expand the [forward lookup zones_msdcs.domain.comdomainsguid_tcp] and delete incorrect _ldap entries
v. Select [forward lookup zones_msdcs.domain.comgc] – delete incorrect HostA records
vi. Expand the [forward lookup zones_msdcs.domain.comgc_sitessitename_tcp] – delete incorrect _ldap entries
vii.Select the [forward lookup zones_msdcs.domain.comgc_tcp] – delete incorrect _ldap entries
viii. Select the [forward lookup zones_msdcs.domain.compdc_tcp] – delete incorrect _ldap entries

B.Expand the forward lookup zonesdomain.com folder
i.Delete Host(A) records of dc’s which are non-existant.
ii.Correct the NameServer (NS) records
iii. Follow steps similar to ’ A ii ‘ >> ‘ A viii’

· Dssite.msc [Sites and Services]
A.Expand the [SitesSitenameServers] – delete incorrect server’s
B.Delete incorrect subnet configurations [SitesSubnets]
C.Delete incorrect site links [SitesIP]

· Make sure the domain controllers are pointing to the correct dns servers in tcpip settings.
· Force replication – ‘repadmin /syncall’

It is FIXED. Thanks to Jedi and Purvesh. I tried ipconfig /flushdns and ipconfig /registerdns w/ netlogon restart I could not get the PDC record in DNS. Simple problem on the NIC. register DNS was unchecked! Not sure WHY it was unchecked but I checked it on and ran commands again. Low and behold, I have a PDC record.

Thanks for you help; it triggered the idea.

Did you transfer the PDC role to the new DC before you demoted it? What server in your environment contains your PDC role? Did you also transfer the NTP server settings before you demoted it? (assuming it was providing that service)The link below walks you through how to transfer the roles.

I transferred the PDC role to a new server then demoted the existing PDC.

The new server contains the PDC.

I did transfer the time server (NTP) to the new server and it seems to be working. w32tm /query /status on other DCs shows the time source as the PDC.

I already transferred FSMO roles to the new PDC. On all DCs netdom query fsmo lists the PDC for all roles.

How can I troubleshoot this? If there is a DNS problem I don’t know how to find it.

In the DNS server settings are your forwarders setup correctly? NIC DNS setting setup correctly (In the NIC did you put the PDC as the primary)?

As far as I can tell the forwarders are fine. We are not having any trouble resolving names; just resolving the PDC. Is there something specific I should look at?

The NIC’s primary DNS is the server itself (PDC) and the secondary is another DC.

Thanks for your help. What next?

Can you move the PDC role to another GC and see if the issue goes away?

On the DC that is the PDC right now, is the name and IP on the server correct in the DNS server properties and AD?

On the DNS server manager, right click the servername and go to properties. On the interface tab, is the right IP stated? On your forward lookup zone in the properties go to the name server tab, is the DC name in there?

NIC settings for the PDC make sure the other DC is the primary not itself. Make sure on all DC settings that the very last DNS IP listed is 127.0.0.1 this means it points to itself.

Please run the below commands and upload the output of the text file to one drive. share the URL or link here.

dnslint.exe /ad /s Ipaddress of DC

dcdiag /v /c /d /e /s:contoso.com >> DCDIAG.txt

repadmin /replsum /errorsonly >> REPADMINERROR.txt

repadmin /showrepl >> SHOWREPL.txt

Thanks for uploading let me have look and let you know once i get anything from output.

I take back my statement that the PDC is the authoritative time server. The DCs were using NTP instead of Nt5DS.

I would prefer to not move the PDC again for fear it will muddle things up even more. ?

DNS server properties and AD are correct.

The DNS interface tab shows it is listening on the correct IP.

I do not have a properties options on my forward lookup zone folder The DC is listed as a named server and is the server named in the start of authority. However, I ran the dnslint command as requested by Purvesh and noticed this:

Additional authoritative (NS) records from server:
Site1-PDC.contoso.com Unknown
Site4-DC.contoso.com Unknown
Site2-DC.contoso.com Unknown
Site3-DC.contoso.com Unknown

The NIC settings have the PDC as preferred and another DC as alternate. 127.0.0.1 is last. Other sites point the DC points to itself as preferred and the PDC as alternate. There seems to be multiple opinions on this. We have always set our DNS addresses this way and until we changed the PDC it worked fine. I will give it a try though. Thanks for the input.

Please note a change to my scenario that I updated above:

I take back my statement that the PDC is the authoritative time server. The DCs were using NTP instead of Nt5DS.

did you remove the old PDC from the name server list?

Delete the object out of sites and services and ADUC?

NS records are created from items stated in the name server list, did you clean up your name server list?

In ADUC -> system folder -> File replication Service -> Domain System Voume are all DC’s in your environment listed correctly?

Did you restart the DNS Client service (this will flush the DNS cache)? Did you run the command «NBTSTAT /RR» (If you have WINS this will release and refresh the records)

I scrubbed the old PDC from DNS (except Host A & PTR Records). However, I can not be certain I didn’t miss something or something is missing.

I removed it from the DC list for the site and from the domain controller folder in ADUC.

I removed it from the SOA and NS records.

In ADUC FRS the current DCs are listed. The old PDC is not.

I ran ipconfig /flushdns on all DCs. I went ahead and restarted the DNS client service on all DCs and ran the nbtstat command.

Still have the same problems.

Thanks for your continued help.

Can you published the output of following command from problem DC & one from working DC.

IPCONFIG /ALL

I think you forgot to delete the entry of OLD dc from DNS from following locations.

Manual Steps

Dnsmgmt.msc [Dns Management]
A.Expand the forward lookup zones_msdcs folder
i. Make sure only the actual domain controllers are listed, delete wrong Alias recordsremove wrong name server records
ii. Select the container [forward lookup zones_msdcs.domain.comdc_sites_sitename_tcp] > delete incorrect _ldap and _kerberos records are listed.
iii. Select the container [forward lookup zones_msdcs.domain.comdc_tcp] and delete incorrect _ldap and _kerberos records
iv. Expand the [forward lookup zones_msdcs.domain.comdomainsguid_tcp] and delete incorrect _ldap entries
v. Select [forward lookup zones_msdcs.domain.comgc] – delete incorrect HostA records
vi. Expand the [forward lookup zones_msdcs.domain.comgc_sitessitename_tcp] – delete incorrect _ldap entries
vii.Select the [forward lookup zones_msdcs.domain.comgc_tcp] – delete incorrect _ldap entries
viii. Select the [forward lookup zones_msdcs.domain.compdc_tcp] – delete incorrect _ldap entries

B.Expand the forward lookup zonesdomain.com folder
i.Delete Host(A) records of dc’s which are non-existant.
ii.Correct the NameServer (NS) records
iii. Follow steps similar to ’ A ii ‘ >> ‘ A viii’

· Dssite.msc [Sites and Services]
A.Expand the [SitesSitenameServers] – delete incorrect server’s
B.Delete incorrect subnet configurations [SitesSubnets]
C.Delete incorrect site links [SitesIP]

· Make sure the domain controllers are pointing to the correct dns servers in tcpip settings.
· Force replication – ‘repadmin /syncall’

Note that I switched the DNS order on the PDC per Jedi. Still getting the same error.

PDC is the only working DC (no PDC_REQUIRED error and DFS namespaces display). PDC is listed first than one of the DCs.

Windows IP Configuration

Host Name . . . . . . . . . . . . : Site1-PDC
Primary Dns Suffix . . . . . . . : contoso.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : contoso.com

Ethernet adapter Site1-PDC:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Dri
ver
Physical Address. . . . . . . . . : 44-A8-42-1D-E7-80
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::59ff:f83f:4d3d:daa4%19(Preferred)
IPv4 Address. . . . . . . . . . . : 10.0.2.12(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.2.10
DHCPv6 IAID . . . . . . . . . . . : 423929922
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-3B-18-C4-44-A8-42-1D-E7-81

DNS Servers . . . . . . . . . . . : 100.100.100.8
10.0.2.12
127.0.0.1
NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter 6TO4 Adapter:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft 6to4 Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2002:c064:240c::c064:240c(Preferred)
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 587202560
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-3B-18-C4-44-A8-42-1D-E7-81

DNS Servers . . . . . . . . . . . : 100.100.100.8
10.0.2.12
127.0.0.1
NetBIOS over Tcpip. . . . . . . . : Disabled

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

——————————————-
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

Windows IP Configuration

Host Name . . . . . . . . . . . . : Site3-DC
Primary Dns Suffix . . . . . . . : contoso.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : contoso.com

Ethernet adapter Site3-DC:

Connection-specific DNS Suffix . : contoso.com
Description . . . . . . . . . . . : BASP Virtual Adapter
Physical Address. . . . . . . . . : 14-FE-B5-CA-91-83
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::984f:584f:b628:aaf1%18(Preferred)
IPv4 Address. . . . . . . . . . . : 100.100.100.8(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 100.100.100.254
DHCPv6 IAID . . . . . . . . . . . : 638910133
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-76-7C-57-14-FE-B5-CA-91-83

DNS Servers . . . . . . . . . . . : 100.100.100.8
10.0.2.12
NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.contoso.com:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : contoso.com
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Reusable Microsoft 6To4 Adapter:

Источник

Что вы знаете об отпуске? Отпуск — это круто! Кто-то едет окучивать грядки, кто-то пляжи. Но однозначно, самая плохая мысль, которая может придти в голову — работать в отпуске. Если вы, сидя на пляже, пытаетесь проверить рабочую почту, участвуете в конференциях, раздаете какие-то указания, проверяете работу сотрудников, то вам, скорее всего надо к доктору. Это не отпуск, это мука.
Я провел отпуск правильно. Выключил телефон, благо компания Билайн позаботилась о том, чтобы у меня не было никакой связи в том месте, где я находился, не заходил в интернет, и полностью посвятил себя простому деревенскому быту. А вот вернувшись в Северную Пальмиру, я обнаружил приличное количество писем от одного веселого заказчика, которого я на самом деле обожаю, ибо он обеспечивает меня не просто работой, а постоянными симуляторами геморроя. В общем и целом, задачка была опять из разряда: “Шеф, усе пропало!”. Основная задача была связана с восстановлением организации Exchange практически с нуля, но внезапно выплыл некий side project, в виде мертвой службы ADDS в домене, который обслуживает инфраструктуру (гипервизоры и все, что с ними связано).

Что же произошло?
Умер сервер с ролью контроллера домена вместе с дисками, на которых находился его VHD. Умер от слова совсем, и восстановлению не подлежит. Слово “бэкап” произносить в данном контексте неуместно, т.к. парни не просто смелые, а отважные. И резервных копий нет и, похоже, никогда и не было. Но есть же второй контроллер домена! Круто!
Правда есть один нюанс: ни один инструмент управления службой ADDS не смог подключиться к ней со словами “The domain can’t exist or can’t be contacted”. Т.е. домен вроде как есть, но в то же время его вроде как и нет.
Куда нужно сходить первым делом, если есть какие-то проблемы с доступом к Active Directory? Ведущие собаководы утверждают, что первым делом надо смотреть в Domain Name System, т.к. “99% проблем с AD это проблемы с DNS!” (городская легенда).
Но там все оказалось вполне себе неплохо. Поудалял записи от старого контроллера (некоторые, типа А удаляются простым Delete, некоторые, типа NS надо удалять на вкладке Name Servers соответствующих зон). Привел в порядок, одним словом. Результат? Нулевой.
Смотрим дальше… При запуске DCDIAG получаем ошибку 1355, причем у меня их было несколько (GC_SERVER_REQUIRED, PDC_REQUIRED и еще всякие разные, в общем все сводилось к такому вот шаблону текста: DcGetDcName(PDC_REQUIRED) call failed, error 1355). По моему скромному разумению все это указывает на проблемы с механизмом Domain Controller Locator.
Вначале меня посетила мысль о том, что роли FSMO остались на стром контроллере, но это не совсем укладывалось в текущую картину, т.к. роли FSMO особо на DC Locator не влияют. Вернее влияют, но не в контексте обычной аутентификации. Проверив расположение ролей с помощью NTDSUTIL, я обнаружил отсутствие информации о старом контроллере. Т.е. метаданные из базы кто-то вычистил до меня (на самом деле, заказчик мне привел экспертное заключение каких-то абстрактных специалистов, что домену пришла труба, и никаких вариантов восстановления просто нет, кроме как создать новый домен, и “перезавести машины в него”. Видимо это и были авторы удаления метаданных).
Что было еще более интересным, так это отсутствие shared folders, которые мы привыкли видеть на любом контроллере домена: SYSVOL и NETLOGON. По сути эти каталоги представляют собой хранилище политик домена (SYSVOL) и логон-скриптов (NETLOGON).
Соответственно, физически они расположены (при дефолтной инсталляции) в C:Windowssysvol<Имя домена>sysvol (SYSVOL Shared Folder) и C:Windowssysvol<Имя домена>sysvolscripts (NETLOGON Shared Folder). Создание этих shared folders вручную ни к какому результату не приводит: ни контроллер от этого работать не начнет, ни сами настройки не сохранятся (при первой же перезагрузке эти shared folders исчезают).
Лезем в Event Viewer. В логе службы ADDS все на первый взгляд ровно. Как и на второй. Интересности обнаруживаются в логе службы репликации распределенной файловой системы (Applications and Services LogsDFS Replication). Там я нашел довольно интересное событие DFSR Error 4612, которое говорит о том, что каталог SYSVOL на данном контроллере был инициализирован и ожидает начальной репликации от умершего контроллера. И, что самое забавное, данный контроллер до завершения процесса репликации не будет работать. Прямо так в логе и пишется. Т.е. по идее, создание роли контроллера домена было не завершено до конца с самого начала, и он никогда не функционировал, как контроллер. Тупо стоял и молотил воздух.
Как же его завести, если того самого контроллера, с которого он ожидает начальной репликации, не существует? Тут на помощь нам приходит процедура авторитативного восстановления SYSVOL. Почему авторитативного? Потому что других “авторитетов” в сети, кроме этого единственного контроллера нет. Не на кого положиться, и ему придется принимать решение самому. Для этого, правда, он должен быть держателем роли PDC Emulator. Захват роли процедура не сложная, с учетом неработоспособности соврменных инструментов управления (консоли и модуль Active Directory в PowerShell), придется работать по старинке. Так как же произвести процедуру авторитативного восстановления SYSVOL при неработающем редакторе ADSIedit? Использовать вместо этого LDP.exe.
Итак, что же было сделано:
1. Остановлена служба репликации:
net stop DFSR или Stop-Service DFSR
2. Далее мне нужно изменить значение двух аттрибутов сервиса SYSVOL Subscription контроллера домена, объект которого можно найти по LDAP-пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
msDFSR-Enabled=FALSE (говорит о том, что репликации нет, дефолтное значение TRUE)
msDFSR-Options=1 (говорит о том, что наш контроллер обладает авторитативным экземпляром, т.е. истинным и верным, дефолтное значение 0)
Проблема была в том, что ADSIedit при попытке подключения к любому из контекстов AD, говорил, что домена не существует, либо он недоступен.
Меня спасла утилита LDP.exe, которая позволяет напрямую подключиться к экземпляру NTDS.dit (вру, конечно, т.к. подключение происходит по LDAP-протоколу на порт 389).
2а. Запускаем LDP.exe, жмем Connection — Bind (Ctrl+B) и цепляемся прямо к контроллеру домена, на котором мы ее и запустили в контексте текущего пользователя (прав-то, надеюсь, достаточно? Нужны права группы Domain Adminы). По сути просто жмем ОК.
2б. Дальше нам нужно подключиться к Default Naming Context, для чего жмем View — Tree (Ctrl+T) и в BaseDN выбираем корень домена в LDAP формате: DC=domain,DC=com).
2в. Ищем объект службы SYSVOL Subscription, последовательно раскрывая ветки дерева. Напоминаю, объект находится по пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>.
2г. Выделяем объект, и в контекстном меню (умное слово, на самом деле это меню правой кнопки мыши :)) выбираем Modify (Ctrl+M).
2д. В области Edit Entry, в поле Attribute вводим msDFSR-Enabled, в поле Values вводим FALSE. Выбираем Operation = Replace, жмем кнопку Enter, видим, что операция появилась в Entry List. Вводим данные для второго аттрибута (Attribute = msDFSR-Options, Values = 1, так же жмем Enter, и проверяем наличие в Entry List), и вот после этого жмем кнопку Run. И получаем ошибку 0x2098 Insufficient access rights Лечится просто: запустите LDP.exe от имени администратора (RunAs Administrator), UAC на серверах все-таки зло… В итоге должно получиться сообщение, что вызов ldap_modify_s изменил 2 аттрибута объекта службы SYSVOL Subscription.
2е. Не 3акрываем LDP.exe, она нам еще понадобится.
3. Запускаем службу репликации распределенной файловой системы:
net start DFSR или Start-Service DFSR
NOTE: Перед запуском этой команды рекомендуют очистить каталоги
%WINDIR%SYSVOL<Имя домена>sysvolPolicies
%WINDIR%SYSVOL<Имя домена>sysvolScripts
чтобы не получить кучу неработающих политик. Но у меня там было чисто, т.к. контроллер даже не выполнил начальной репликации.
4. В журнале службы (Applications and Services LogsDFS Replication) сразу же получаем событие от DFSR EventID 4114, которое говорит о том, что репликация каталога SYSVOL отключена.
5. Меняем значение msDFSR-Enabled обратно в TRUE (шаги 2а — 2д, обратите внимание, что меняем значение только одного аттрибута, msDFSR-Options не трогаем)
6. Запускаем репликацию (из командной строки, запущенной с повышением привилегий, иначе опять получите сообщение о недостатке прав):
repadmin /syncall /AdP
7. Запускаем dfsrdiag /ADPoll (если получаете сообщение, что команда не распознана, установите DFS Management Tools, они в FeaturesRemote server Administration ToolsRole Administration ToolsFile Services Tools или Add-WindowsFeature RSAT-DFS-Mgmt-Con)
8. В журнале DFS Replication должно появиться событие DFSR EventID 4602, говорящее о том, что процесс авторитативного восстановления запущен.
На этом все. Перезагружаем сервер и пробуем запустить, например, ADUC. Но тут меня ждал Его Величество Облом. Не работает.
Дело оказалось в том, что каталог SYSVOL был, но политик в нем не было. А их должно быть минимум две: Default Domain Policy c GUID {31B2F340-016D-11D2-945F-00C04FB984F9} и Default Domain Controller Policy c GUID {6AC1786C-016F-11D2-945F-00C04FB984F9}.
Восстановить их можно с помощью утилиты DCGPOFIX, которая воссоздает политики, используя для этого политики, которые хранятся в базе AD (CN=Policies,CN=System,DC=Domain,DC=ru). Один нюанс, даже два:
1. Все изменения, которые вы делали в этих двух политиках, придется делать заново, т.к. большинство настроек хранятся в GPT как раз в каталоге SYSVOLPolicies, а у нас там ничего нет.
2. Сертификат для EFS, если он используется в Default Domain Policy так же не пересоздается. придется все делать вручную. И дай Бог, чтобы у вас не было включено шифрование EFS на уровне политик…
Собственно после выполнения этой последней процедуры, контроллер ожил и заработал.
Выводы и уроки:
1. Развертывание дополнительного контроллера домена — не просто NNF (Next-Next-Finish), хотя казалось бы, чего там сложного, но данный случай показывает, что не проконтролировав процесс начальной репликации, в итоге администратор получил тыкву, практически бесполезную единицу.
2. Резервное копирование — это не для трусов, оно для умных. Наличие простой копии System State могло сильно упростить жизнь.
3. Ну и если вы встряли в подобное, не стоит сразу делать выводов космического масштаба и… ну вы поняли Есть городская легенда, что службу ADDS можно спасти при наличии всего лишь файла NTDS.dit. Так что never give up. Пишите мне, в конце концов, придумаем что-нибудь