Report password utenti AD

 Una delle cose a cui spesso e' necessario mettere mano con AD e' il discorso delle password.

Molto spesso sono impostate per non scadere mai, o potrebbe essere necessario farle scadere.

Il primo passo per prendere delle decisioni in merito e' un report sulle password. Io ho usato questi 2  script:

ES1:

Tutti gli utenti di AD

Get-ADUser -filter {Enabled -eq $True} –Properties DisplayName,msDS-UserPasswordExpiryTimeComputed,BadLogonCount,LastBadPasswordAttempt,LastLogonDate,PasswordExpired,PasswordLastSet,PasswordNeverExpires | Select-Object -Property "Displayname",DistinguishedName,@{Name="ExpiryDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}},BadLogonCount,LastBadPasswordAttempt,LastLogonDate,PasswordExpired,PasswordLastSet,PasswordNeverExpires | export-csv C:\Script\AD\ReportUserPassword\PwdUsersAll.csv

ES2:

Solo con password che non scadono

Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties DisplayName,msDS-UserPasswordExpiryTimeComputed,BadLogonCount,LastBadPasswordAttempt,LastLogonDate,PasswordExpired,PasswordLastSet,PasswordNeverExpires | Select-Object -Property "Displayname",DistinguishedName,@{Name="ExpiryDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}},BadLogonCount,LastBadPasswordAttempt,LastLogonDate,PasswordExpired,PasswordLastSet,PasswordNeverExpires | export-csv C:\Script\AD\ReportUserPassword\PwdUsersNEFalse.csv

A questo punto avete qualche informazione in piu per fare un'analisi e prendere delle decisioni.

Ricordate che obbligare gli utenti a cambiare password rappresenta potenzialmente del lavoro in piu, ma e' uno dei passaggi necessari per migliorare la sicurezza.

E possibile verificare la scadenza della password di un singolo utente di dominio in modo molto piu semplice:

net user c.ogura /domain

Vengono restituiti molti dati utili, anche sulle password 

Sulle impostazioni delle password e' importante impostare una scadenza (90/180 gg.), possibilmente dei criteri di complessiva, ed almeno una lunghezza minima, e magari un minimo di password ricordate in modo che non vengano usate a rotazione sempre le stesse. E' anche molto importante impostare un lockout automatico degli account. Questo non ci espone ad attacchi brute force. In pratica e' consigliabile bloccare un account per un periodo di tempo, anche breve, se un utente sbaglia la password per un certo numero di volte. 

In active directory le impostazioni per le password sono definite nella default domain policy, nel seguente percorso:

Computer configuration/Policies/Windows settings/Security settings/Account policies

Password policies

Account lockout policies 

Sarebbe inoltre molto utile monitorare l'event viewer per tentativi di accesso falliti ripetuti all'indirizzo di un utente. (ES: event viewer/security log/4625). Provate a controllare questo evento su un server RDP pubblicato senza VPN :). 

REFERENCE

https://social.technet.microsoft.com/wiki/contents/articles/12037.active-directory-get-aduser-default-and-extended-properties.aspx

https://www.pcwdld.com/password-expiration-date-ad-user#wbounce-modal

https://www.alitajran.com/create-active-directory-users-from-csv-with-powershell/

GPO - Filtri WMI per pc DESKTOP e PORTATILI

 Ciao a tutti,

sto preparando alcune GPO che vorrei applicare solo ai portatili in azienda (e a dir la verità neppure a tutti!!!).

Il mio primo scoglio e' proprio come distinguere un desktop da un portatile.

Per fare questo ho pensato di usare i WMI filtering, tramite cui è possibile recuperare alcune informazioni sul computer

Facendo riferimento a questa pagina:

https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-computersystem

Ho identificato due proprietà che mi possono essere utili:

PCSystemType e PCSystemTypeEx

La seconda e' disponibile solo da Windows 8.1 e Windows 2012 R2 in poi.

Quindi se:

PCSystemType=1 o 3 si tratta di PC Desktop (a dir la verita non so in quale categoria ricadano le workstation mobili!)

PCSystemType=2 si tratta di laptop

Sotto riporto un estratto dal sito su queste 2 proprieta

PCSystemType

Type of the computer in use, such as laptop, desktop, or Tablet.

Unspecified (0)

Desktop (1)

Mobile (2)

Workstation (3)

Enterprise Server (4)

SOHO Server (5) Small Office and Home Office (SOHO) Server

Appliance PC (6)

Performance Server (7)

Maximum (8)

PCSystemTypeEx

Type of the computer in use, such as laptop, desktop, or Tablet.

Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 and Windows Vista not supported.

This property is not supported before Windows 8.1 and Windows Server 2012 R2.

Unspecified (0)

Desktop (1)

Mobile (2)

Workstation (3)

Enterprise Server (4)

SOHO Server (5)

Appliance PC (6)

Performance Server (7)

Slate (8)

Maximum (9)

Adesso devo definire la query per decidere la classe

DESKTOP

Namespace: root\CIMv2

Select * from Win32_ComputerSystem WHERE (PCSystemType = 1) or (PCSystemType = 3)

LAPTOP

Namespace: root\CIMv2

Select * from Win32_ComputerSystem WHERE (PCSystemType = 2)

Adesso devo aprire GPMC ed andare in WMI Filter e scegliere NEW.

Namespace: root\CIMv2

Description: PC DESKTOP

Query: Select * from Win32_ComputerSystem WHERE (PCSystemType = 1) or (PCSystemType = 3)

Fare lo stesso, modificando la query, per i portatili.

Direi che abbiamo finito.

NOTE

Inizialmente avevo pensato di usare questa query: Select * from Win32_Battery WHERE (BatteryStatus <> 0), ma il risultato sarebbe stato che un desktop con attaccato un UPS sarebbe passato per un portatile. :)

APPENDICE

WIN32-SYSTEMENCLOSURE

A dir la verita ci sarebbe anche un'altra proprieta che sarebbe utile allo scopo, ma per semplicita' ho preferito usare quella precedente.

Ad ogni modo va considerata come alternativa.

https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-systemenclosure

ChassisTypes

This value comes from the Type member of the System Enclosure or Chassis structure in the SMBIOS information.

Other (1)

Unknown (2)

Desktop (3)

Low Profile Desktop (4)

Pizza Box (5)

Mini Tower (6)

Tower (7)

Portable (8)

Laptop (9)

Notebook (10)

Hand Held (11)

Docking Station (12)

All in One (13)

Sub Notebook (14)

Space-Saving (15)

Lunch Box (16)

Main System Chassis (17)

Expansion Chassis (18)

SubChassis (19)

Bus Expansion Chassis (20)

Peripheral Chassis (21)

Storage Chassis (22)

Rack Mount Chassis (23)

Sealed-Case PC (24)

Tablet (30)

Convertible (31)

Detachable (32)

QUERY x LAPTOP

Namespace: root\CIMv2

Query:  select * from Win32_SystemEnclosure where ChassisTypes = "{8}" or ChassisTypes = "{9}" or ChassisTypes = "{10}" or ChassisTypes = "{11}" or ChassisTypes = "{12}" or ChassisTypes = "{14}" or ChassisTypes = "{18}" or ChassisTypes = "{21}"

WMI

WMI e' l'acronimo di Windows management instrumentation.

Cosa puo fare?

WMI (Windows Management Instrumentation) è un insieme di interfacce che permettono di interagire con le informazioni di sistema, interrogarle e modificarle.

Nel nostro caso abbiamo bisogno di trovare quella particolare classe che contiene la proprieta che consente di capire se il pc in questione e' un desktop oppure un portatile.

E' possibile interrogare WMI tramite powershell. Un tool grafico che ho utilizzato e' WmiExplorer.

Il problema e' che non sempre le proprieta sono chiare ed occorre fare qualche ricerca per trovare cio di cui abbiamo bisogno

NOTE

wmic, tool di interrogazione WMI e stato rimpiazzato da Get-WmiObject (powershell)

Get-WmiObject e' stato rimpiazzato, dalla versione 3.0 di powershell da Get-CimInstance

ESEMPI POWERSHELL

Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object -Property *

Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object -Property pcsystemtype

REFERENCE

https://www.linkedin.com/pulse/wmi-filtering-gpos-philip-cumiskey

https://social.technet.microsoft.com/Forums/en-US/8f802a56-a66e-495f-9e6f-48bfca341343/gpo-wmi-filter-for-laptops?forum=winserverGP

https://docs.microsoft.com/it-it/windows/win32/cimwin32prov/win32-operatingsystem

https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-systemenclosure

https://docs.microsoft.com/it-it/windows/win32/cimwin32prov/win32-computersystem

https://docs.microsoft.com/en-us/dotnet/api/microsoft.powershell.commands.pcsystemtype?view=powershellsdk-1.1.0

https://docs.microsoft.com/it-it/powershell/scripting/samples/collecting-information-about-computers?view=powershell-7.1

https://powershell.one/wmi/root/cimv2/win32_computersystem

https://docs.microsoft.com/it-it/dotnet/framework/wcf/diagnostics/wmi/

http://www.dotnethell.it/articles/WMI.aspx

https://github.com/vinaypamnani/wmie2/releases

GPO - group policy permission

 Sistemazione permessi GPO

Sto effettuando la migrazione di un dominio da Windows Server 2008R2 a Windows Server 2019. Ho aggiunto quindi il nuovo domain controller 2019 ed effettuato le verifiche del caso.

Tutto funziona correttamente tranne un problema che ho notato dalla console di gestione delle policy. Infatti se la apro (GPMC.MSC), selezione il dominio, e nella destra, tra i tab in alto scelgo STATUS e premo “DETECT NOW”, vengono trovati degli errori si sync.

Solitamente accade per i DC da Windows Server 2012 in poi.

Nel mio caso ha problemi la replica con Windows Server 2019. 

Si tratta di un problema di permessi. Non sono corrette le ACL di una o più policy (nel mio caso quasi tutte).

Ogni ACL (lista dei permessi e’ formata da un insieme di ACE

ACL = Access control list. Elenco dei permessi. Un file dove administrator ed user hanno permessi di lettura rappresenta una ACL

ACE = Access control entry. L’insieme delle ACE crea una ACL. L’utente pippo che può accedere ad un file/oggetto in sola lettura rappresenta un’ACE. 

Ad ogni modo si tratta di un problema noto. Il problema nasce dal fatto che Windows Server 2008R2 e precedenti mettevano più ACE per uno stesso utente (parlando di GPO). Verificando i permessi sulle GPO si nota che DOMAIN ADMINS appare più volte. Questo si può verificare anche per altri utenti (Enterprise admins, SYSTEM ecc. ecc.) 

La parte subdola del problema e’ che questa fatto si evidenzia solo usando ICACLS, tool a riga di comando per la gestione dei permessi. Da GUI sembra tutto normale. 

Prima di fare qualsiasi modifica vi consiglio di fare un backup delle GPO, tramite gpmc.msc.

Selezionare “Group policy objects” – tasto DX e scegliere “Backup ALL” 

Per risolvere occorre togliere le ACE duplicate e forzare una replica. Dopodiché occorre gestire e creare le nuove policy solo da Windows Server 2012 e superiori. 

Per sistemare occorre accedere al server 2008, aprire un command prompt ed andare nel percorso locale delle GPO (ES: C:\Windows\SYSVOL\domain\Policies). 

Utilizzare i seguenti comandi: 

icacls "{GPO UID}"

Fate attenzione e verificate i permessi degli utenti che andrete a toccare. 

icacls "{GPO UID}" /remove:g "<localdomain>\Domain Admins"

icacls "{GPO UID}" /grant "<localdomain>\Domain Admins":(OI)(CI)(F)

repadmin /syncall

repadmin /syncall /AdePq 

ESEMPIO

icacls {F8D0D4C5-EAFB-44C2-8AF5-9A93B1BFB639}

mostra i permessi della GPO 

icacls {F8D0D4C5-EAFB-44C2-8AF5-9A93B1BFB639} /remove:g "<localdomain>\Domain Admins"

toglie tutte le ACE relative a DOMAIN ADMINS

icacls {01C13992-5EC3-4C95-8F85-1D73AEEB657D} /grant "<localdomain>\Domain Admins":(OI)(CI)(F)

aggiunge la ACE relativa a DOMAIN ADMINS, una sola volta! 

p.s. icacls * > c:\temp\GPO_ACL_2008r2.txt crea un file di report di tutti i permessi, utile soprattutto se ci sono molte policy 

Dopodiché posso verificare nuovamente la ACL per vedere che non ci siano entry duplicate per altri utenti.

Come dicevo sopra, mi sono trovato entry duplicate anche per ENTERPRISE ADMINS e SYSTEM.

Alla fine, dopo aver verificato le ACL posso forzare una sincronizzazione usando i seguenti comandi. 

repadmin /syncall

repadmin /syncall /AdePq 

Lasciare passare un pochino da uno all’altro e verificate da GPMC sul nuovo server se il problema si e’ risolto verificando con GPMC dal server dove si e’ verificato l’errore di allineamento. 

Altri comandi utili per verificare lo stato di replica sono:

repadmin /replsummary

repadmin /showrepl 

Ma nel mio caso non hanno mai dato esito negativo nonostante questo problema sulle GPO. 

NOTA

Per creare le nuove policy usando solo il nuovo DC occorre selezionarlo dalla console gpmc.msc.
Aprire la console, selezionare il dominio, tasto dx e dal menu scegliere:
"CAMBIA CONTROLLER DI DOMINIO" 
Da qui procedere alla scelta del controller di dominio da utilizzare.

REFERENCE

https://social.technet.microsoft.com/Forums/ie/en-US/f16b0af1-8772-4f96-a9ac-fac47943e8e9/sysvol-permissions-for-one-or-more-gpo-are-not-in-sync?forum=ws2016

https://social.technet.microsoft.com/Forums/ie/en-US/1a5db5cb-f194-40b5-8545-37ccbac300e1/windows-server-2012-gpos-wont-sync?forum=winserverGP

https://ss64.com/nt/icacls.html

Verifica scadenza password

 Ciao,

per verificare quando scade la password di un utente in AD e quando e' stata impostata l'ultima volta.

Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties "DisplayName", passwordlastset, Passwordneverexpires, "msDS-UserPasswordExpiryTimeComputed" | Select-Object -Property "Displayname", passwordlastset, Passwordneverexpires, @{Name="ExpiryDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}

REFERENCE:

https://activedirectorypro.com/how-to-get-ad-users-password-expiration-date/

Replica GPO

 Durante l'aggiunta di un nuovo domain controller in AD ho riscontrato uno strano errore con la replica delle GPO, nonostante event viewer, dcdiag, replmon non segnalassero errori.

Dalla console delle GPO due policy non erano replicate. Altre policy che, solo dopo, mi sono reso conto di aver creato dal nuovo DC, invece funzionavano senza problemi.

L'errore era il seguente:

the sysvol permission for one or more GPOs on this domain controller are not in sync with the permissions for the GPOs on the baseline domain controller

ed era visibile da gpmc.msc

selezionare il dominio e premere detect now in basso a dx per verificare eventuali errori.

Controllando i permessi delle cartelle da explorer non emerge nulla di strano.

Verificando le ACL delle con icacls, invece...

ES:

icacls C:\Windows\SYSVOL_DFSR\sysvol\nomedominio.local\Policies\{95B665A7-ABBC-4519-B9D7-529100908048}

si nota che l'account domain admin e' ripetuto 2 volte

NOMEDOMINIO\Domain Admins:(OI)(CI)(F)

NOMEDOMINIO\Enterprise Admins:(OI)(CI)(F)

NOMEDOMINIO\Domain Admins:(OI)(CI)(F)

CREATOR OWNER:(OI)(CI)(IO)(F)

NT AUTHORITY\SYSTEM:(OI)(CI)(F)

NT AUTHORITY\Authenticated Users:(OI)(CI)(RX)

NT AUTHORITY\CONTROLLER DI DOMINIO ORGANIZZAZIONE:(OI)(CI)(RX)

per risolvere e' sufficiente togliere e riaggiungere l'account domain admin, forzare la replica ed andare a verificare nuovamente in gpmc.msc.

icacls "{GPO UID}"  /remove:g "DOMINIO\Domain Admins"

icacls "{GPO UID}"  /grant "DOMINIO\Domain Admins":(OI)(CI)(F)

repadmin /syncall

repadmin /syncall /AdePq

Da ora in poi create le policy sul domain controller piu recente per verificare che l'errore si ripresenti. Da Windows server 2012 ci sono delle patch che risolvono il problema, ma non su 2008/2008R2

REFERENCE

https://social.technet.microsoft.com/Forums/en-US/f16b0af1-8772-4f96-a9ac-fac47943e8e9/sysvol-permissions-for-one-or-more-gpo-are-not-in-sync?forum=ws2016

DHCP Dynamic update

Quando il DHCP aggiorna i record DNS, come lo fa? Impersondo quale utente e con che permessi? 

E possibile utilizzare un utente dedicato per gli aggiornamenti dinamici fatti sul DNS da parte del DHCP.

L'utente non deve avere requisiti particolari, anzi basta che sia un utente "standard".

E' un'operazione che conviene effettuare soprattutto se il dhcp server e' anche un domain controller, per motivi di sicurezza.

Se non e' impostato un account dedicato per gli aggiornamenti dinamici del DHCP, quello utilizzato e' l'account macchina del DC, con i relativi permessi.

Cio significa che puo modificare anche record che non dovrebbe!!!

IMPOSTAZIONE

Creare un utente ad hoc. Niente di speciale. Ricordarsi di non far scadere mail la pwd e non permettere all'utente stesso di cambiarla.

Segnatevi questi dati, per favore. Non facciamo come gli utenti che si cambiano la password e poi ti chiamano per resettarla!

Aprire la console del DHCP

DHCP - nome server - IPv4

tasto dx su IPv4, properties

Tab Advanced

Press Credentials

Inserire le credenziali di un utente

p.s. usare nome di dominio NETBIOS

REFERENCE

https://blogs.msmvps.com/acefekay/2016/08/13/dynamic-dns-updates-how-to-get-it-to-work-with-dhcp-scavenging-static-entries-their-timestamps-the-dnsupdateproxy-group-and-dhcp-name-protection/

https://www.serverbrain.org/implementing-2003-network/how-to-configure-dns-dynamic-update-credentials-1.html

GLOBALNAMES Zone in AD

CREARE GLOBALNAME Zone in AD

Visto che ormai i server WINS sono caduti in disuso, e quindi tutta la risoluzione nomi e' affidata soprattutto al DNS, può essere utile creare in AD la zona GlobalNames ed attivarla.

Lo scopo di questa zona e' quello di risolvere i nomi "single label", senza suffisso dns, per intenderci.

il DNS risolverebbe il nome server01.dominio.local

La globalnames zone risolverebbe il nome server01.

La vera utilità della zona emerge in realtà con più nomi di dominio, e con i clienti che devono effettuare la ricerca tra più nomi (suffissi) di dominio.

Ad ogni modo non stiamo parlando di un rimpiazzo dei WINS e NETBIOS, dal punto di vista tecnico. Questi servizi/protocolli sono completamente differenti.

La gestione della GLOBALNAMES ZONE zona va fatta in modo completamente manuale. Vanno aggiunti alla zona solo record CNAME (alias). Non supporta gli aggiornamenti dinamici.

Si tratta di una funzione in più, che secondo me può essere utile (e che io uso molto).

L'attivazione va fatta singolarmente per ogni server server DNS/DC.

COME ATTIVARLA

I passaggi per attivarla sono molto semplici.

 - Creare una zona primaria integrata in AD e chiamarla d GlobalNames. E' inutile attivare i dynamic updates, tanto non li supporta!

 - Abilitare per il server la GlobalNames zone.

Set-DnsServerGlobalNamesZone –ComputerName servername –Enable $true (PS)

   oppure

Dnscmd ServerName /config /Enableglobalnamessupport 1 (OLD STYLE)

 - Aggiungere gli alias.

REFERENCE:

http://thefrozengeek.blogspot.com/2018/02/configuring-and-managing-globalnames.html

https://petri.com/using-globalnames-zone-window-server-2008

Exchange Microsoft365 ibrido - Creazione nuovo utente

Nei giorni scorsi mi e' capitato di creare un nuovo utente ed una nuova casella di posta in un ambiente ibrido Exchange/Microsoft365.
Anche se inizialmente sembrava essere andato tutto bene, dopo poco si sono manifestati alcuni problemi.
L'utente nuovo non appariva nella GAL e non riusciva a spedire agli indirizzi on-prem (per fortuna pochi indirizzi).
Analizzando meglio la situazione mi sono reso conto che questo utente esisteva in AD, ma non appariva tra i remote mailbox users in exchange.
Questo rappresentava il nocciolo della questione, ovvero esisteva un utente AD, senza attributi exchange, a cui corrispondeva una casella/utente Office365.
Tutto nasce dal processo che ho seguito per creare l'utente.
In AD ho creato il nuovo utente. Ho sincronizzato AD con AzureAD. Quando e' apparso l'utente anche nella console di amministrazione di Microsoft 365, gli ho assegnato una licenza creando cosi' la mailbox. Ho saltato a pie' pari tutta la parte Exchange on-prem.
Il risultato finale e' stato questo.
La prox volta che creero un nuovo utente, provvedero a crearlo prima on-prem, e quindi ad effettuare un remote-move.
Ma adesso e' necessario sistemare le cose.

Il processo e' abbastanza semplice (basta saperlo!!!). Occorre:
 - recuperare l'ExchangeGUID della casella di posta remota
 - abilitare l'utente AD come mailbox remote user (a seguito di questa operazione l'utente deve apparire nella console di Exchange)
 - associare l'ExchangeGUID al nuovo utente Exchange
 - sincronizzare AD con Azure AD

PASSAGGIO 1
recuperare l'exchange guid della mailbox su Microsoft 365:

get-mailbox -identity p.pippo@disneylanda.it|fl ExchangeGuid

ExchangeGuid : a09ff8fb-26f7-4d81-9425-0c967acfadcd

PASSAGGIO 2
Abilitare l'utente AD come remote mailbox user
Occorre solo abilitare l'utente in Exchange, poiche in AD gia esiste.

Enable-RemoteMailbox p.pippo -RemoteRoutingAddress p.pippo@disneylanda.mail.onmicrosoft.com

A questo punto l'utente deve apparire nell'elnco dei contatti nella GUI di Exchange

PASSAGGIO 3
Associare il corretto ExchangeGUID (recuperato nel passaggio 1) al nuovo utente

Set-RemoteMailbox p.pippo -ExchangeGUID a09ff8fb-26f7-4d81-9425-0c967acfadcd

a09ff8fb-26f7-4d81-9425-0c967acfadcd

PASSAGGIO 4
sincronizzazione AD con AzureAD

Start-ADSyncSyncCycle -PolicyType Delta

adesso potete verificare se funziona la spedizione ad indirizzi on-prem e se l'utente appare nella GAL, quando fate una ricerca.



REFERENCE
https://www.msb365.blog/?p=866

MIGRAZIONE DA FRS a DFSR

Se vi portate dietro dei domini molto vecchi, magari partiti da Windows Server 2000 o 2003, prima o poi, aggiornando i domain controller vi troverete nella situazione di dover aggiornare il meccanismo di replica della SYSVOL da FRS a DFSR. Grazie alla sysvol sono replicati nel dominio script di logon e GPO. Il servizio responsabile della replica della sysvol tra domain controller era il file replication service. Da Windows server 2008 (R2?!?) il servizio di replica e' stato sostituito dal DFSR (distribuited file system), decisamente piu efficiente. Creando un nuovo dominio, a partire partendo da un server 2008 il servizio di replica di SYSVOL si appoggiava nativamente su DFS, mentre se il vostro dominio e' nato su versioni precedenti di windows e nel tempo e' stato portato avanti ed aggiornato avra mantenuto DFSR. Oggi la cosa non e' piu possibile. Da Windows Server 2016 in poi, oltre ai soliti discorsi di adprep, sarete costretti ad aggiornare FRS a DFSR.

Come al solito l'idea e' quella di partire con il piede giusto. Prima di iniziare la procedura verificate tutti i log degli eventi  FRS, DFRS, AD
Eseguite un DCDIAG: dcdiag /e /v /c /fix /f:c:\dcdiag.txt
Forzate una replica tra domain controller:
repadmin /syncall /force /aped
Verificate di non essere troppo indietro con gli aggiornamenti. Mi e' capitato di trovare 2008 R2 neppure aggiornati all'SP1.

Il processo e' molto semplice e si svolge in varie fasi. Una volta avviate le potremo ritenere concluse dopo che tutti i domain controller si sono sincronizzati. E' possibile verificarne l'esito tramite event viewer (replica DFS/DFSR). Solo dopo la conferma tramite eventi viewer vi consiglio di procedere alla successiva. In pratica e' una questione di pazienza

Le fasi sono le seguenti:
0 – Start State
1 – Prepared State
2 – Redirected State
3 – Eliminated State

Sono tutte reversibili tranne l'ultima.
tramite il comando dfsrmig /GetGlobalState e' possibile monitorarne l'avanzamento

dfsrmig /SetGlobalState 1
dfsrmig /GetGlobalState
L'evento da controllare: 8014 - DFSR
Non procedete prima di vedere questo evento su tutti i DC - E' possibile il rollback

dfsrmig /SetGlobalState 2
dfsrmig /GetGlobalState
L'evento da controllare: 8017 - DFSR
Non procedete prima di vedere questo evento su tutti i DC - E' possibile il rollback

dfsrmig /SetGlobalState 3
dfsrmig /GetGlobalState
L'evento da controllare: 8019 - DFSR

Al termine di tutto il servizio File replication service verra definitivamente stoppato e disabilitato.
Verificate che gli share netlogon e sysvol siano presenti e visibili.
Provate ad aggiungere un client al dominio, eventualmente.

E se si verificano problemi? E' un problema. Ho incontrato problemi la prima volta che ho affrontato il processo e sono stato costretto ad effettuare un rollback.
In primo luogo, per i rollback vale la stessa regola dell'avvio del processo:
va fatto in modo sequenziale, cioe' non si puo passare dalla fase 2 alla fase 0
e' necessario aspettare che il processo sia ultimato prima di procedere oltre

Il punto e' che se siete costretti ad un rollback vuol dire che qualcosa non ha funzionato. Anche il rollback potrebbe dare qualche noia. Ad esempio a me erano sparite netlogon e sysvol. Se questo dovesse succedere, molto probabilmente i client avranno problemi di accesso al dominio, e vi potreste trovare un po pressati. Vista la situazione ho deciso di aspettare e rifare a ritroso i vari passaggi, fino al dfsrmig /SetGlobalState 0. Dopodiche ho riavviato il servizio NETLOGON/Accesso di rete e le share, dopo poco sono riapparse e tutto a ripreso a funzionare bene.

Ho cercato di analizzare le cause del problema, ma alla ho deciso di puntare sugli aggiornamenti, visto che la macchina era molto indietro. Ricordate la macchina senza SP1 di cui ho parlato all'inizio? :)

REFERENCE

https://www.silviodibenedetto.com/active-directory-migrate-frs-to-dfsr/

http://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distributed-file-system-replication/

https://judeperera.wordpress.com/2019/03/19/sysvol-migration-from-frs-to-dfsr-step-by-step/

Active directory Recycle bin

Una cosa che credo sia molto utile di AD e' il recycle bin, che non e' abilitato di default.

Come funziona il cestino e come abilitarlo.
Per abilitare il cestino occorre usare la "Active directory administrative center" console.
Nella colonna di destra, dopo aver selezionato il dominio apparira la voce "enable recycle bin". Cliccare e confermare. Al termine della propagazione a tutti i domain controller vederete apparire la nuova OU "deleted objects", ovvero il cestino di active directory. Accedendo alla ou e' possibile vedere gli oggetti cancellati e ripristinarli. Tutto qui :)