Powered by Foswiki, The Free and Open Source Wiki

You are here: Foswiki>KnowledgeBase Web>WindowsDomainsTroubleshootingExamples (28 Jun 2022, NickDemou)Edit Attach

Issue at Doculand Jan, Mars 2019

The error in the Logs (Event 4012, Error 9061)

Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share
----
The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 242 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.
To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.
Additional Information:
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 0EEB20A9-F80B-4141-9E39-04D91576BFBA
Replication Group Name: Domain System Volume
Replication Group ID: 4194E2B2-028F-4BB3-835C-1DCEA8F0A1D4
Member ID: 50D333C0-40B9-445B-BB3E-8D58F9302FB3

What I did

Executed this on both DCs to raise the threshold from 60 days to 300 and thus allow replication to continue:wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=300
After 2 days reset it to default with: wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60

ISSUE Jan 2018

What I did

Followed "Seize the FSMO roles"
Followed "Removing A Domain Controller Server Manually"
Followed "Metadata cleanup (the easy way)"
Executed the "netdom tests"
Executed the "repadmin tests"
Executed "dcdiag test" NOTE THAT I HAVE A FAILURE ON DFSR

todo

on all DCs: either disable NICs that are not used or Just un-check the "Register this connection's address in DNS" checkbox (e.g. if it's used for ISCSI )
on all DCs: IF SOMETHING GOES WRONG AND for troubleshooting reasons only point them to one and the same DNS Server , then run ipconfig /registerdns then restart the netlogon service
on all DCs: Make sure that these services are running: Server, Workstation, NETLOGON
You should only configure a NTP Server only at the DC that has the PDC role, other DCs, member servers and clients should not use NTP.
run dcdiag and look for any line that displays "failed test"
I found out the Both my DCs are Global Catalog server — should they? I think it is because a few good sysadmins at spiceworks are saying it's good for some use cases with huge domains and non of them says it's bad in any case.

Seize the FSMO roles

If you're curious see "What are the FSMO Roles". TLDR: there are 5 FSMO roles and each one must be assigned to at least one D.C.: 1. Schema master, 2. Domain naming master, 3. RID master, 4. PDC emulator, 5. Infrastructure master. For completence I must note that there's also the option for any and all DCs to also keep a Global Catalog (GC). It's not an FSMO role because more than one DCs can keep the GC of the same domain.

If you demote a DC that has any of the FSMO roles it will pass it to another DC (this is called a transfer of the role ). If you fail to demote it you must seize(take by force) the role.
For single domain forests all FSMO roles are installed in the first domain controller.
When you are carrying out a planned move, it is called transferring the role.

It is extremely important to remember two things:

It's OK for a DC hosting a role to go down for a short time.
If either the Schema Master, Domain Naming Master, or RID Master role is seized from a domain controller, that domain controller must never be allowed to come back online.

Log on to the domain controller that you are assigning FSMO roles to.

type "ntdsutil" at the command line. The prompt will then change to reflect the current level of the menu. In this case, at the "ntdsutil" prompt, you would type "roles." The command prompt will then change to FSMO Maintenance.
Type roles
Type connections
Type connect to server <servername>

servername is the name of the domain controller that you want to assign the FSMO role to.

At the server connections prompt, type q, and then press ENTER.
For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press ENTER
Type seize <role>

where role is the role that you want to seize.

At the fsmo maintenance prompt, type q, and then press ENTER
Type q, and then press ENTER to quit the Ntdsutil utility.

Do not put the Infrastructure master role on the same domain controller as the Global Catalog (GC) server. If the Infrastructure master runs on a global catalog server it stops updating object information. (The GC contains a searchable, partial representation of every object in every domain in a multidomain forest -- Read More)

https://blogs.technet.microsoft.com/canitpro/2016/02/17/step-by-step-removing-a-domain-controller-server-manually/
What about the Global Catalog? Is any server a global catalog?

Removing A Domain Controller Server Manually

(from https://blogs.technet.microsoft.com/canitpro/2016/02/17/step-by-step-removing-a-domain-controller-server-manually/)

Log in to DC server as Domain/Enterprise administrator and navigate to Server Manager > Tools > Active Directory Users and Computers

Expand the Domain > Domain Controllers

Right click on the DC server that need to be removed manually and click delete

In next dialog box, click yes to confirm

In next dialog box, select This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO) and click Delete

If the domain controller is global catalog server, in next window click yes to continue with deletion

If the domain controller holds any FSMO roles in next window, click ok to move them to the domain controller which is available

Step 2: Cleaning up the DC server instance from the Active Directory Sites and Services

Go to Server manager > Tools > Active Directory Sites and Services

Expand the Sites and go to the server which need to remove

Right click and click Delete

In next window click yes to confirm

https://chinnychukwudozie.com/2014/01/27/using-ntdsutil-metada-cleanup-to-remove-a-failedoffline-domain-controller-object/

Metadata cleanup (the eazy way)

(based on https://chinnychukwudozie.com/2014/01/27/using-ntdsutil-metada-cleanup-to-remove-a-failedoffline-domain-controller-object/)

ntdsutil
metadata cleanup
connections
connect to server pdcsrv
quit
select operation target

(Entering this mode, will enable me select the sites, domains and servers I intend to work with.)

Metadata cleanup (the hard way)

Overview of things to do:

seize the FSMO role on the healthy DC
transfer all other AD services like DNS/GC/DHCP etc on it.
Remove/clean the crashed DC objects & its references from AD to inform that this DC is no more.

A few notes about the metadata cleanup

Metadata cleanup is process which is required to remove the failed DC from the domain which can’t be demoted gracefully. Does metadata cleanup removes all the entry from AD? the answer is NO, it doesn’t remove all the records from AD & from few places manual cleaning of those objects are required. Why? There are different aging/scavenging configurations defined on DNS to remove entries when they become stale. When a host record is removed, its actually not removed but its Dnstombstoned attribute is set to true for later point of deletion using again/scavenging configured interval, so the records still exists in AD.

The places required to look after either using normal demotion or force demotion of a DC are below.

-Each & every sub folder inside _msdcs folder in DNS
-Name server tab in DNS
-Host records in DNS
-Server object under NTDS setting in AD sites & services.

Note: Once you perform the metadata cleanup of DC, don’t immediately reuse the same Hostname/IP of failed DC to configure it back to a new DC, because you have to allow changes to be replicated to all other domain controllers in the forest by allowing & waiting for at least one replication cycle to complete. But if you got few DC’s & good bandwidth, you can force the replication using repadmin /syncall /Aped

TESTS

netdom tests

PS > netdom query /domain:doculand dc
List of domain controllers with accounts in the domain:
PDCSRV
DC2

PS > netdom query /domain:doculand pdc
Primary domain controller for the domain:
PDCSRV

PS > netdom query /domain:doculand fsmo
Schema master pdcsrv.doculand.local
Domain naming master pdcsrv.doculand.local
PDC pdcsrv.doculand.local
RID pool manager pdcsrv.doculand.local
Infrastructure master pdcsrv.doculand.local
The command completed successfully.

repadmin tests

PS > repadmin /replsum
Replication Summary Start Time: 2018-01-30 01:01:11

Source DSA largest delta fails/total %% error
DC2 04m:04s 0 / 5 0
PDCSRV 04m:20s 0 / 5 0

Destination DSA largest delta fails/total %% error
DC2 04m:20s 0 / 5 0
PDCSRV 04m:04s 0 / 5 0

PS > repadmin /showreps
Default-First-Site-Name\PDCSRV
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: ac3968d7-7e1b-4483-92e8-899b6e2449aa
DSA invocationID: 4cc1cb82-2f89-478c-abe8-fd5cc3890683

INBOUND NEIGHBORS

DC= doculand,DC=local