none
Consigli e pareri su procedure di Upgrade dominio Windows Server 2008 R2

    Domanda

  • Ciao a tutti.

    Devo analizzare , progettare e per ultimo compiere un upgrade di un dominio piuttosto corposo (centinaia di oggetti tra Clients e utenti e varie GP) , formato da due DC con objectVersion:47 (Windows Server 2008 R2).
    Pur trattandosi di una operazione fatta più volte con successo, data la complessità e delicatezza della realtà dove andrò ad operare, avrei piacere di condividere con voi alcuni aspetti piu che altro in via "teorica" modalità di approccio, analisi e implementazione delle operazioni.

    Gli aspetti anche al momento vorrei chiarirmi e che spero possiate autarmi sono :

    - L'inserimento di nuovi DC di versione superiore (2012?2016?), senza innalzare la funzionalità di dominio, che cosa provoca effettivamente ? Devo fare comunque una valutazione di Benefici/Rischi ? 

    - L'innalzamento eventuale della funzionalità (che se non sbaglio non dovrebbe essere reversibile) di che prerequisiti e accortezze necessità ? Quando è davvero necessaria o quando invece è da ritenersi  consigliabile o forse meglio rimandabile o addirittura pericolosa ? 

    - Posto che dopo aver aggiunto i nuovi DC (alzando o meno la funzionalità) i vecchi vadano dismessi, dopo aver spostato i vari ruoli, quale è la procedura piu corretta per avere la certezza che "nessuno" utilizzi i vecchi DC e che l'operazione di "demote" non provochi problemi ? 

    - DNS: un DC è sicuramente anche DNS . Per questo motivo , in fase di dismissione , quale procedura è preferibile adottare per utilizzare i nuovi DNS ?? cambiare ed utilizzare dei nuovi IP per i nuovi DNS di produzione (agendo sul DHCP) , oppure dare ai nuovi DC - DNS gli ip dei vecchi? Quale metodo è da preferirsi e considerarsi più sicuro ed efficiente? 

    Grazie infinite a tutti se avrete la pazienza di affrontare insieme questi aspetti  o se vorrete aggiungerne di nuovi.


    Hunternet

    venerdì 1 dicembre 2017 15:16

Risposte

  • Prima di eseguire una modifica di questo tipo è necessario verificare se ci sono applicazioni di terze parti che utilizzano Active Directory come database (es. autenticazione terze parti) e se le modifiche apportate allo schema sono supportate. Per quanto riguarda l'ambiente Microsoft, verificare la presenza di Exchange.

    - L'inserimento di nuovi DC di versione superiore (2012?2016?), senza innalzare la funzionalità di dominio, che cosa provoca effettivamente ? Devo fare comunque una valutazione di Benefici/Rischi?

    L'attività modifica la versione dello schema che di norma non provoca problemi (vedi nota introduttiva).

    - L'innalzamento eventuale della funzionalità (che se non sbaglio non dovrebbe essere reversibile) di che prerequisiti e accortezze necessità? Quando è davvero necessaria o quando invece è da ritenersi consigliabile o forse meglio rimandabile o addirittura pericolosa?

    Ogni nuovo sistema operativo include nuove funzionalità che spesso non sono utilizzate. La scelta se eseguire o meno l'attività passa attraverso la verifica dei benefici introdotti. Tra i vari benefici da tenere in considerazione ci sono quelli della sicurezza che sicuramente sono quelli che a priori verranno utilizzati. Questo punto è fondamentale per la dismissione dei domini 2003.

    - Posto che dopo aver aggiunto i nuovi DC (alzando o meno la funzionalità) i vecchi vadano dismessi, dopo aver spostato i vari ruoli, quale è la procedura più corretta per avere la certezza che "nessuno" utilizzi i vecchi DC e che l'operazione di "demote" non provochi problemi?

    Tutti i Server ed i Client non devono più puntare ai vecchi Domain Controller. Questo non significa che questi non possano essere utilizzati ma che non vengono automaticamente interrogati ed utilizzati per l'autenticazione. Inoltre, prima di eseguire il demote è necessario assicurarsi che le repliche siano state eseguite e completate correttamente.

    - DNS: un DC è sicuramente anche DNS . Per questo motivo, in fase di dismissione, quale procedura è preferibile adottare per utilizzare i nuovi DNS ?? cambiare ed utilizzare dei nuovi IP per i nuovi DNS di produzione (agendo sul DHCP) , oppure dare ai nuovi DC - DNS gli ip dei vecchi? Quale metodo è da preferirsi e considerarsi più sicuro ed efficiente?

    La risposta a questa domanda credo che vada inquadrata nella singola realtà. Sicuramente se si può operare a livello DHCP si evita di aggiungere ulteriore criticità.

    Giusto un paio di giorni fa ho scritto qualcosa sull'argomento. Spero possa esserti utile: Migrazione dominio Active Directory: Livelli di funzionalità e ruoli FSMO

    Saluti
    Nino


    www.testerlab.it

    sabato 2 dicembre 2017 09:54
    Moderatore
  • Ciao e come prima cosa grazie per questa risposta dettagliata e completa.

    Grazie anche e soprattutto per l'ottimo articolo che hai scritto (Windows Server 2003 migrazione a Windows Server 2012 - http://www.testerlab.it/2015/05/16/windows-server-2003-migrazione-a-windows-server-2012/ ) e che sta facendo esattamente al mio caso.

    Riguardo la pianificazione e verifica della “bontà” dell’attuale configurazione, i risultati sono abbastanza positivi ad esclusione di un errore riguardante il Dcdiag che Fallisce riguardo il NCSecDesc e che da questo articolo potrebbe anche essere non considerato se non vengono usati DC read only : https://support.microsoft.com/en-us/help/967482/dcdiag-fails-for-ncsecdesc-test-on-windows-2008-domain-controllers. ( Eventuamente aprirò una nuova domanda al riguardo .)

    Ci sono comunque alcuni aspetti generici molto “caldi” e che mi lasciano alcuni dubbi che però, data la loro importanza, vorrei riuscire a togliermi per lavorare in sicurezza :

    • Pur non essendo presente un server Exchange,  ci sono MOLTE applicazioni di terze parti che utilizzano Active Directory come database : decine di Server Lixux (Suse) che sono “joinati” al dominio e sui quali vengono utilizzati utenti del dominio stesso, integrazione con VMWare, tutta la parte di GSUITE, di Palo Alto, TrendMicro ed altro. Significa che per essere “tutelato” devo farmi fornire la “certificazione”  per ogni prodotto che fa autenticazione su AD ? E se nemmeno il Cliente stesso ha una “certezza” delle applicazioni utilizzanti AD? Esiste un qualche modo di “inventarirle” ?
    • Mettiamo il caso (che fortunatamente ho capito essere “remoto”) che l’operazione del semplice inserimento di un nuovo DC e quindi modifica dello schema,  provochi problemi a queste o altre realtà, quale è la possibilità di Roolback ? Non credo che la rimozione dal dominio del nuovo DC annulli le modifiche , confermi ? Nel tuo articolo fai riferimento a backup , backup ,backp (GIUSTAMENTE) ma anche in questa realtà ho scoperto che l’unico backup di queste VM è l’intera macchina che non saprei nemmeno se effettua un backup “consistente” di AD oppure no . Che altri tipi di backup mi consigli di fare prima di iniziare le operazioni ?
    • Ultima cosa ma non meno importante: per tua esperienza o per “documentazione” credi “opportuno” inserire direttamente un DC 2016, invece che un 2012 ? è supportato ? 

    Hunternet

    1) se i clients AD si limitano ad avere la corretta configurazione ip per poter contattare i dc, che i dc sia win2k8 o win2k16, non cambierà nulla.

    2) la semplice aggiunta di un server con s.o. superiore come domain controller in un dominio esistente non modifica lo schema di active directory. questo accade solo quando innalzi il functional level e poiuchè questa operazione è irreversibile farai l'innalzamento solo quando avrai solo dc di quel determinato functional level all'interno del dominio. fino a quando permangono dc di livello inferiore manterrai il functional level attuale e continuerà a funzionare tutto.

    3) è supportato sia aggiungere un dc win2k12 sia un dc win2k16 senza alcun problema.

    ciao


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    mercoledì 6 dicembre 2017 16:50
    Moderatore

Tutte le risposte

  • Prima di eseguire una modifica di questo tipo è necessario verificare se ci sono applicazioni di terze parti che utilizzano Active Directory come database (es. autenticazione terze parti) e se le modifiche apportate allo schema sono supportate. Per quanto riguarda l'ambiente Microsoft, verificare la presenza di Exchange.

    - L'inserimento di nuovi DC di versione superiore (2012?2016?), senza innalzare la funzionalità di dominio, che cosa provoca effettivamente ? Devo fare comunque una valutazione di Benefici/Rischi?

    L'attività modifica la versione dello schema che di norma non provoca problemi (vedi nota introduttiva).

    - L'innalzamento eventuale della funzionalità (che se non sbaglio non dovrebbe essere reversibile) di che prerequisiti e accortezze necessità? Quando è davvero necessaria o quando invece è da ritenersi consigliabile o forse meglio rimandabile o addirittura pericolosa?

    Ogni nuovo sistema operativo include nuove funzionalità che spesso non sono utilizzate. La scelta se eseguire o meno l'attività passa attraverso la verifica dei benefici introdotti. Tra i vari benefici da tenere in considerazione ci sono quelli della sicurezza che sicuramente sono quelli che a priori verranno utilizzati. Questo punto è fondamentale per la dismissione dei domini 2003.

    - Posto che dopo aver aggiunto i nuovi DC (alzando o meno la funzionalità) i vecchi vadano dismessi, dopo aver spostato i vari ruoli, quale è la procedura più corretta per avere la certezza che "nessuno" utilizzi i vecchi DC e che l'operazione di "demote" non provochi problemi?

    Tutti i Server ed i Client non devono più puntare ai vecchi Domain Controller. Questo non significa che questi non possano essere utilizzati ma che non vengono automaticamente interrogati ed utilizzati per l'autenticazione. Inoltre, prima di eseguire il demote è necessario assicurarsi che le repliche siano state eseguite e completate correttamente.

    - DNS: un DC è sicuramente anche DNS . Per questo motivo, in fase di dismissione, quale procedura è preferibile adottare per utilizzare i nuovi DNS ?? cambiare ed utilizzare dei nuovi IP per i nuovi DNS di produzione (agendo sul DHCP) , oppure dare ai nuovi DC - DNS gli ip dei vecchi? Quale metodo è da preferirsi e considerarsi più sicuro ed efficiente?

    La risposta a questa domanda credo che vada inquadrata nella singola realtà. Sicuramente se si può operare a livello DHCP si evita di aggiungere ulteriore criticità.

    Giusto un paio di giorni fa ho scritto qualcosa sull'argomento. Spero possa esserti utile: Migrazione dominio Active Directory: Livelli di funzionalità e ruoli FSMO

    Saluti
    Nino


    www.testerlab.it

    sabato 2 dicembre 2017 09:54
    Moderatore
  • Ciao e come prima cosa grazie per questa risposta dettagliata e completa.

    Grazie anche e soprattutto per l'ottimo articolo che hai scritto (Windows Server 2003 migrazione a Windows Server 2012 - http://www.testerlab.it/2015/05/16/windows-server-2003-migrazione-a-windows-server-2012/ ) e che sta facendo esattamente al mio caso.

    Riguardo la pianificazione e verifica della “bontà” dell’attuale configurazione, i risultati sono abbastanza positivi ad esclusione di un errore riguardante il Dcdiag che Fallisce riguardo il NCSecDesc e che da questo articolo potrebbe anche essere non considerato se non vengono usati DC read only : https://support.microsoft.com/en-us/help/967482/dcdiag-fails-for-ncsecdesc-test-on-windows-2008-domain-controllers. ( Eventuamente aprirò una nuova domanda al riguardo .)

    Ci sono comunque alcuni aspetti generici molto “caldi” e che mi lasciano alcuni dubbi che però, data la loro importanza, vorrei riuscire a togliermi per lavorare in sicurezza :

    • Pur non essendo presente un server Exchange,  ci sono MOLTE applicazioni di terze parti che utilizzano Active Directory come database : decine di Server Lixux (Suse) che sono “joinati” al dominio e sui quali vengono utilizzati utenti del dominio stesso, integrazione con VMWare, tutta la parte di GSUITE, di Palo Alto, TrendMicro ed altro. Significa che per essere “tutelato” devo farmi fornire la “certificazione”  per ogni prodotto che fa autenticazione su AD ? E se nemmeno il Cliente stesso ha una “certezza” delle applicazioni utilizzanti AD? Esiste un qualche modo di “inventarirle” ?
    • Mettiamo il caso (che fortunatamente ho capito essere “remoto”) che l’operazione del semplice inserimento di un nuovo DC e quindi modifica dello schema,  provochi problemi a queste o altre realtà, quale è la possibilità di Roolback ? Non credo che la rimozione dal dominio del nuovo DC annulli le modifiche , confermi ? Nel tuo articolo fai riferimento a backup , backup ,backp (GIUSTAMENTE) ma anche in questa realtà ho scoperto che l’unico backup di queste VM è l’intera macchina che non saprei nemmeno se effettua un backup “consistente” di AD oppure no . Che altri tipi di backup mi consigli di fare prima di iniziare le operazioni ?
    • Ultima cosa ma non meno importante: per tua esperienza o per “documentazione” credi “opportuno” inserire direttamente un DC 2016, invece che un 2012 ? è supportato ? 

    Hunternet

    lunedì 4 dicembre 2017 15:59
  • Ciao e come prima cosa grazie per questa risposta dettagliata e completa.

    Grazie anche e soprattutto per l'ottimo articolo che hai scritto (Windows Server 2003 migrazione a Windows Server 2012 - http://www.testerlab.it/2015/05/16/windows-server-2003-migrazione-a-windows-server-2012/ ) e che sta facendo esattamente al mio caso.

    Riguardo la pianificazione e verifica della “bontà” dell’attuale configurazione, i risultati sono abbastanza positivi ad esclusione di un errore riguardante il Dcdiag che Fallisce riguardo il NCSecDesc e che da questo articolo potrebbe anche essere non considerato se non vengono usati DC read only : https://support.microsoft.com/en-us/help/967482/dcdiag-fails-for-ncsecdesc-test-on-windows-2008-domain-controllers. ( Eventuamente aprirò una nuova domanda al riguardo .)

    Ci sono comunque alcuni aspetti generici molto “caldi” e che mi lasciano alcuni dubbi che però, data la loro importanza, vorrei riuscire a togliermi per lavorare in sicurezza :

    • Pur non essendo presente un server Exchange,  ci sono MOLTE applicazioni di terze parti che utilizzano Active Directory come database : decine di Server Lixux (Suse) che sono “joinati” al dominio e sui quali vengono utilizzati utenti del dominio stesso, integrazione con VMWare, tutta la parte di GSUITE, di Palo Alto, TrendMicro ed altro. Significa che per essere “tutelato” devo farmi fornire la “certificazione”  per ogni prodotto che fa autenticazione su AD ? E se nemmeno il Cliente stesso ha una “certezza” delle applicazioni utilizzanti AD? Esiste un qualche modo di “inventarirle” ?
    • Mettiamo il caso (che fortunatamente ho capito essere “remoto”) che l’operazione del semplice inserimento di un nuovo DC e quindi modifica dello schema,  provochi problemi a queste o altre realtà, quale è la possibilità di Roolback ? Non credo che la rimozione dal dominio del nuovo DC annulli le modifiche , confermi ? Nel tuo articolo fai riferimento a backup , backup ,backp (GIUSTAMENTE) ma anche in questa realtà ho scoperto che l’unico backup di queste VM è l’intera macchina che non saprei nemmeno se effettua un backup “consistente” di AD oppure no . Che altri tipi di backup mi consigli di fare prima di iniziare le operazioni ?
    • Ultima cosa ma non meno importante: per tua esperienza o per “documentazione” credi “opportuno” inserire direttamente un DC 2016, invece che un 2012 ? è supportato ? 

    Hunternet

    1) se i clients AD si limitano ad avere la corretta configurazione ip per poter contattare i dc, che i dc sia win2k8 o win2k16, non cambierà nulla.

    2) la semplice aggiunta di un server con s.o. superiore come domain controller in un dominio esistente non modifica lo schema di active directory. questo accade solo quando innalzi il functional level e poiuchè questa operazione è irreversibile farai l'innalzamento solo quando avrai solo dc di quel determinato functional level all'interno del dominio. fino a quando permangono dc di livello inferiore manterrai il functional level attuale e continuerà a funzionare tutto.

    3) è supportato sia aggiungere un dc win2k12 sia un dc win2k16 senza alcun problema.

    ciao


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    mercoledì 6 dicembre 2017 16:50
    Moderatore
  • Ci sono comunque alcuni aspetti generici molto “caldi” e che mi lasciano alcuni dubbi che però, data la loro importanza, vorrei riuscire a togliermi per lavorare in sicurezza
    Pur non essendo presente un server Exchange,  ci sono MOLTE applicazioni di terze parti che utilizzano Active Directory come database : decine di Server Lixux (Suse) che sono “joinati” al dominio e sui quali vengono utilizzati utenti del dominio stesso, integrazione con VMWare, tutta la parte di GSUITE, di Palo Alto, TrendMicro ed altro. Significa che per essere “tutelato” devo farmi fornire la “certificazione”  per ogni prodotto che fa autenticazione su AD ? E se nemmeno il Cliente stesso ha una “certezza” delle applicazioni utilizzanti AD? Esiste un qualche modo di “inventarirle”?
    La soluzione migliore è quella di avere un ambiente di test per poter eseguire in sicurezza la migrazione. Per quanto riguarda il login al dominio, i client non risentono delle modifiche, non è questo il livello di autenticazione che interessa. Se hai possibilità di sentire i fornitori per aver un loro via per la certificazione della release AD non è male.
    Mettiamo il caso (che fortunatamente ho capito essere “remoto”) che l’operazione del semplice inserimento di un nuovo DC e quindi modifica dello schema,  provochi problemi a queste o altre realtà, quale è la possibilità di Roolback? Non credo che la rimozione dal dominio del nuovo DC annulli le modifiche , confermi? Nel tuo articolo fai riferimento a backup , backup ,backup (GIUSTAMENTE) ma anche in questa realtà ho scoperto che l’unico backup di queste VM è l’intera macchina che non saprei nemmeno se effettua un backup “consistente” di AD oppure no . Che altri tipi di backup mi consigli di fare prima di iniziare le operazioni ?
    Windows Server 2008 R2 ha introdotto il roll-back AD non ricordo se è stato lasciato anche su 2012.
    Ultima cosa ma non meno importante: per tua esperienza o per “documentazione” credi “opportuno” inserire direttamente un DC 2016, invece che un 2012 ? è supportato
    Dal punto di vista tecnico la migrazione è possibile. Dal punto di vista dell'opportunità personalmente mi fermerei alla versione 2012 R2. Dal punto di vista della certificazione che tutto funziona torniamo al primo punto. Un'applicazione potrebbe funzionare con 2012 ma non con 2016 quindi, in qualche modo, sei legato a cosa è certificato.

    www.testerlab.it

    giovedì 7 dicembre 2017 09:53
    Moderatore