Come aggiornare i controller di dominio Windows 2000 a Windows Server 2003

Questo articolo illustra come aggiornare i controller di dominio di Microsoft Windows 2000 a Windows Server 2003 e come aggiungere nuovi controller di dominio di Windows Server 2003 ai domini di Windows 2000.

Si applica a: Windows Server 2012 R2
Numero KB originale: 325379

Riepilogo

Questo articolo illustra come aggiornare i controller di dominio di Microsoft Windows 2000 a Windows Server 2003 e come aggiungere nuovi controller di dominio di Windows Server 2003 ai domini di Windows 2000. Per altre informazioni su come aggiornare i controller di dominio a Windows Server 2008 o Windows Server 2008 R2, visitare il seguente sito Web Microsoft:

Aggiornare controller di dominio: supporto tecnico Microsoft avvio rapido per l'aggiunta di controller di dominio Windows Server 2008 o Windows Server 2008 R2 a domini esistenti

Inventario di domini e foreste

Prima di aggiornare i controller di dominio Windows 2000 a Windows Server 2003 o prima di aggiungere nuovi controller di dominio windows server 2003 a un dominio di Windows 2000, seguire questa procedura:

  1. Inventariare i client che accedono alle risorse nel dominio che ospitano i controller di dominio di Windows Server 2003 per garantire la compatibilità con la firma SMB:

    Ogni controller di dominio di Windows Server 2003 abilita l'accesso SMB ai criteri di sicurezza locali. Assicurarsi che tutti i client di rete che usano il protocollo SMB/CIFS per accedere a file condivisi e stampanti in domini che ospitano controller di dominio Windows Server 2003 possano essere configurati o aggiornati per supportare la firma SMB. In caso contrario, disabilitare temporaneamente la firma SMB fino a quando non è possibile installare gli aggiornamenti o finché i client non possono essere aggiornati ai sistemi operativi più recenti che supportano la firma SMB. Per informazioni su come disabilitare la firma SMB, vedere la sezione Per disabilitare la firma SMB alla fine di questo passaggio.

    Piani d'azione

    L'elenco seguente mostra i piani di azione per i client SMB più diffusi:

    • Microsoft Windows Server 2003, Microsoft Windows XP Professional, Microsoft Windows 2000 Server, Microsoft Windows 2000 Professional e Microsoft Windows 98

      Non è richiesta alcuna azione.

    • Microsoft Windows NT 4.0 Installa Service Pack 3 o versione successiva (è consigliabile usare Service Pack 6A) in tutti i computer basati su Windows NT 4.0 che accedono ai domini che contengono computer basati su Windows Server 2003. Disabilitare temporaneamente la firma SMB nei controller di dominio di Windows Server 2003. Per informazioni su come disabilitare la firma SMB, vedere la sezione Per disabilitare la firma SMB alla fine di questo passaggio.

    • Microsoft Windows 95

      Installare il client del servizio directory Windows 9 x nei computer basati su Windows 95 o disabilitare temporaneamente la firma SMB nei controller di dominio di Windows Server 2003. Il client del servizio directory Win9 x originale è disponibile nel CD-ROM di Windows 2000 Server. Tuttavia, tale componente aggiuntivo client è stato sostituito da un client del servizio directory Win9 x migliorato. Per informazioni su come disabilitare la firma SMB, vedere la sezione Per disabilitare la firma SMB alla fine di questo passaggio.

    • Client di rete Microsoft per i client MS-DOS e Microsoft LAN Manager

      Il client di rete Microsoft per MS-DOS e il client di rete Microsoft LAN Manager 2.x possono essere usati per fornire l'accesso alle risorse di rete oppure possono essere combinati con un disco floppy di avvio per copiare file del sistema operativo e altri file da una directory condivisa in un file server come parte di una routine di installazione software. Questi client non supportano la firma SMB. Usare un metodo di installazione alternativo o disabilitare la firma SMB. Per informazioni su come disabilitare la firma SMB, vedere la sezione Per disabilitare la firma SMB alla fine di questo passaggio.

    • Client Macintosh

      Alcuni client Macintosh non sono compatibili con la firma SMB e riceveranno il messaggio di errore seguente quando tentano di connettersi a una risorsa di rete:

      - Errore -36 I/O

      Installare il software aggiornato, se disponibile. In caso contrario, disabilitare la firma SMB nei controller di dominio di Windows Server 2003. Per informazioni su come disabilitare la firma SMB, vedere la sezione Per disabilitare la firma SMB alla fine di questo passaggio.

    • Altri client SMB di terze parti

      Alcuni client SMB di terze parti non supportano la firma SMB. Consultare il provider SMB per verificare se esiste una versione aggiornata. In caso contrario, disabilitare la firma SMB nei controller di dominio di Windows Server 2003.

    Per disabilitare la firma SMB

    Se non è possibile installare gli aggiornamenti software nei controller di dominio interessati che eseguono Windows 95, Windows NT 4.0 o altri client installati prima dell'introduzione di Windows Server 2003, disabilitare temporaneamente i requisiti di firma del servizio SMB in Criteri di gruppo fino a quando non è possibile distribuire software client aggiornato.

    È possibile disabilitare l'accesso al servizio SMB nel nodo seguente dei criteri controller di dominio predefiniti nell'unità organizzativa controller di dominio: Configurazione computer\Impostazioni di Windows\Impostazioni di sicurezza\Criteri locali\Opzioni di sicurezza\Microsoft Network Server:

    Firma digitale delle comunicazioni (sempre)

    Se i controller di dominio non si trovano nell'unità organizzativa del controller di dominio, è necessario collegare l'oggetto Criteri di gruppo (GPO) del controller di dominio predefinito a tutte le unità organizzative che ospitano controller di dominio Windows 2000 o Windows Server 2003. In alternativa, è possibile configurare l'accesso al servizio SMB in un oggetto Criteri di gruppo collegato a tali unità organizzative.

  2. Inventario dei controller di dominio presenti nel dominio e nella foresta:

    1. Assicurarsi che tutti i controller di dominio di Windows 2000 nella foresta abbiano installato tutti gli hotfix e i Service Pack appropriati.

      Microsoft consiglia a tutti i controller di dominio Windows 2000 di eseguire i sistemi operativi Windows 2000 Service Pack 4 (SP4) o versioni successive. Se non è possibile distribuire completamente Windows 2000 SP4 o versioni successive, tutti i controller di dominio Windows 2000 devono avere un file Ntdsa.dll la cui data e versione sono successive al 4 giugno 2001 e alla 5.0.2195.3673.

      Per impostazione predefinita, gli strumenti di amministrazione di Active Directory nei computer client Windows 2000 SP4, Windows XP e Windows Server 2003 usano la firma LDAP (Lightweight Directory Access Protocol). Se tali computer usano l'autenticazione NTLM (o si rientreranno) quando amministrano in remoto controller di dominio Windows 2000, la connessione non funzionerà. Per risolvere questo comportamento, nei controller di dominio amministrati in remoto deve essere installato almeno Windows 2000 SP3. In caso contrario, è consigliabile disattivare la firma LDAP nei client che eseguono gli strumenti di amministrazione.

      Gli scenari seguenti usano l'autenticazione NTLM:

      • Si amministrano i controller di dominio Windows 2000 che si trovano in una foresta esterna connessa da un trust NTLM (non Kerberos).
      • Gli snap-in di Microsoft Management Console (MMC) vengono concentrati su un controller di dominio specifico a cui fa riferimento il relativo indirizzo IP. Ad esempio, si fa clic su Start, si fa clic su Esegui e quindi si digita il comando seguente: dsa.msc /server=ipaddress

      Per determinare il sistema operativo e il livello di revisione del Service Pack dei controller di dominio Active Directory in un dominio di Active Directory, installare la versione di Windows Server 2003 di Repadmin.exe in un computer membro di Windows XP Professional o Windows Server 2003 nella foresta e quindi eseguire il comando seguente repadmin su un controller di dominio in ogni dominio della foresta:

      >repadmin /showattr <name of the domain controller that is in the target domain> ncobj:domain: /filter:"(&(objectCategory=computer)(primaryGroupID=516))" /subtree /atts:operatingSystem,operatingSystemVersion,operatingSystemServicePack
      
      DN: CN=NA-DC-01,organizational unit=Domain Controllers,DC=company,DC=com
       1> operatingSystem: Windows Server 2003
       1> operatingSystemVersion: 5.2 (3718)
      DN: CN=NA-DC-02,organizational unit=Domain Controllers,DC=company,DC=com
       1> operatingSystem: Windows 2000 Server
       1> operatingSystemVersion: 5.0 (2195)
       1> operatingSystemServicePack: Service Pack 1
      

      Nota

      Gli attributi del controller di dominio non tengono traccia dell'installazione dei singoli hotfix.

    2. Verificare la replica end-to-end di Active Directory in tutta la foresta.

      Verificare che ogni controller di dominio nella foresta aggiornata replica tutti i contesti di denominazione contenuti in locale con i partner in modo coerente con la pianificazione definita dai collegamenti al sito o dagli oggetti connessione. Usare la versione di Windows Server 2003 di Repadmin.exe in un computer membro basato su Windows XP o Windows Server 2003 nella foresta con gli argomenti seguenti: Tutti i controller di dominio nella foresta devono replicare Active Directory senza errori e i valori nella colonna "Delta più grande" dell'output repadmin non devono essere significativamente superiori alla frequenza di replica nei collegamenti di sito o negli oggetti di connessione corrispondenti usati da un determinato dominio di destinazione Controller.

      Risolvere tutti gli errori di replica tra controller di dominio che non sono riusciti a eseguire la replica in ingresso in meno del numero di giorni TSL (Tombstone Lifetime) (per impostazione predefinita, 60 giorni). Se la replica non può essere eseguita per funzionare, potrebbe essere necessario abbassare forzatamente i controller di dominio e rimuoverli dalla foresta usando il comando ntdsutil metadata cleanup e quindi alzare di livello nuovamente i controller di dominio nella foresta. È possibile usare un abbassamento di livello forzato per salvare sia l'installazione del sistema operativo che i programmi che si trovano in un controller di dominio orfano. Per altre informazioni su come rimuovere i controller di dominio di Windows 2000 orfani dal dominio, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente:

      216498 Come rimuovere i dati in Active Directory dopo un abbassamento di livello del controller di dominio non riuscito

      Eseguire questa azione solo come ultima risorsa per ripristinare l'installazione del sistema operativo e dei programmi installati. Si perderanno gli oggetti e gli attributi non replicati nei controller di dominio orfani, tra cui utenti, computer, relazioni di trust, password, gruppi e appartenenze a gruppi.

      Prestare attenzione quando si tenta di risolvere gli errori di replica nei controller di dominio che non hanno replicato le modifiche in ingresso per una particolare partizione di Active Directory per un numero di giorni maggiore di tombstonelifetime . In questo caso, è possibile rianimare gli oggetti eliminati in un controller di dominio, ma per i quali i partner di replica diretta o transitiva non hanno mai ricevuto l'eliminazione nei 60 giorni precedenti.

      Provare a rimuovere gli oggetti persistenti che risiedono nei controller di dominio che non hanno eseguito la replica in ingresso negli ultimi 60 giorni. In alternativa, è possibile abbassare di livello i controller di dominio che non hanno eseguito alcuna replica in ingresso in una determinata partizione nel numero di giorni di durata della rimozione definitiva e rimuovere i metadati rimanenti dalla foresta di Active Directory usando Ntdsutil e altre utilità. Per altre informazioni, contattare il provider di supporto tecnico o Microsoft PSS.

    3. Verificare che il contenuto della condivisione Sysvol sia coerente.

      Verificare che la parte relativa al file system dei criteri di gruppo sia coerente. È possibile usare Gpotool.exe di Resource Kit per determinare se esistono incoerenze nei criteri in un dominio. Usare Healthcheck dagli strumenti di supporto di Windows Server 2003 per determinare se i set di repliche di condivisione Sysvol funzionano correttamente in ogni dominio.

      Se il contenuto della condivisione Sysvol è incoerente, risolvere tutte le incoerenze.

    4. Usare Dcdiag.exe dagli strumenti di supporto per verificare che tutti i controller di dominio abbiano condivisioni Netlogon e Sysvol. A tale scopo, digitare il comando seguente al prompt dei comandi:

      DCDIAG.EXE /e /test:frssysvol
      
    5. Inventariare i ruoli delle operazioni.

      I master delle operazioni dello schema e dell'infrastruttura vengono usati per introdurre modifiche dello schema a livello di foresta e di dominio alla foresta e ai relativi domini apportate dall'utilità adprep di Windows Server 2003. Verificare che il controller di dominio che ospita il ruolo dello schema e il ruolo dell'infrastruttura per ogni dominio nella foresta si trovino in controller di dominio live e che ogni proprietario del ruolo abbia eseguito la replica in ingresso su tutte le partizioni dall'ultimo riavvio.

      Il DCDIAG /test:FSMOCHECK comando può essere usato per visualizzare i ruoli operativi a livello di foresta e a livello di dominio. I ruoli master operazioni che risiedono in controller di dominio inesistenti devono essere assegnati a un controller di dominio integro usando NTDSUTIL. I ruoli che risiedono nei controller di dominio non integri devono essere trasferiti, se possibile. In caso contrario, dovrebbero essere sequestrati. Il NETDOM QUERY FSMO comando non identifica i ruoli FSMO che risiedono nei controller di dominio eliminati.

      Verificare che l'oggetto abbia eseguito la replica in ingresso di Active Directory dall'ultimo avvio. La replica in ingresso può essere verificata usando il REPADMIN /SHOWREPS DCNAME comando , dove DCNAME è il nome del computer NetBIOS o il nome computer completo di un controller di dominio. Per altre informazioni sui master operazioni e sul relativo posizionamento, fare clic sui numeri degli articoli seguenti per visualizzare gli articoli della Microsoft Knowledge Base:

      197132 ruoli FSMO di Windows 2000 Active Directory

      223346 posizionamento e ottimizzazione FSMO nei controller di dominio Active Directory

    6. Revisione del log eventi

      Esaminare i log eventi in tutti i controller di dominio per individuare gli eventi problematici. I log eventi non devono contenere messaggi di evento gravi che indicano un problema con uno dei processi e dei componenti seguenti:

      connettività fisica
      connettività di rete
      registrazione del nome
      risoluzione dei nomi
      Autenticazione
      Criteri di gruppo
      criteri di sicurezza
      sottosistema disco
      Schema
      Topologia
      motore di replica

    7. Inventario dello spazio su disco

      Il volume che ospita il file di database di Active Directory, Ntds.dit, deve avere spazio libero pari almeno al 15-20% delle dimensioni del file Ntds.dit. Anche il volume che ospita il file di log di Active Directory deve avere spazio libero pari ad almeno il 15-20% delle dimensioni del file Ntds.dit. Per altre informazioni su come liberare spazio su disco aggiuntivo, vedere la sezione "Controller di dominio senza spazio sufficiente su disco" di questo articolo.

    8. Scavenging DNS (facoltativo)

      Abilitare lo scavenging DNS a intervalli di 7 giorni per tutti i server DNS nella foresta. Per ottenere risultati ottimali, eseguire questa operazione 61 o più giorni prima di aggiornare il sistema operativo. In questo modo, il daemon di scavenging DNS è sufficiente per raccogliere gli oggetti DNS obsoleti quando viene eseguita una deframmentazione offline nel file Ntds.dit.

    9. Disabilitare il servizio server DLT (facoltativo)

      Il servizio DLT Server è disabilitato nelle installazioni nuove e aggiornate dei controller di dominio di Windows Server 2003. Se non viene usato il rilevamento dei collegamenti distribuiti, è possibile disabilitare il servizio DLT Server nei controller di dominio Windows 2000 e iniziare a eliminare oggetti DLT da ogni dominio della foresta. Per altre informazioni, vedere la sezione "Consigli Microsoft per il rilevamento dei collegamenti distribuiti" dell'articolo seguente nella Microsoft Knowledge Base: 312403 Distributed Link Tracking nei controller di dominio basati su Windows

    10. Backup dello stato del sistema

      Eseguire un backup dello stato del sistema di almeno due controller di dominio in ogni dominio della foresta. È possibile usare il backup per ripristinare tutti i domini nella foresta se l'aggiornamento non funziona.

Microsoft Exchange 2000 nelle foreste di Windows 2000

Nota

Lo schema di Exchange 2000 definisce tre attributi inetOrgPerson con LDAPDisplayNames non conforme a Request for Comment (RFC): houseIdentifier, secretary e labeledURI.

Windows 2000 inetOrgPerson Kit e il comando di Windows Server 2003 adprep definiscono le versioni RFC-complaint degli stessi tre attributi con LDAPDisplayName identici alle versioni non conformi a RFC.

Quando il comando di Windows Server 2003 adprep /forestprep viene eseguito senza script correttivi in una foresta contenente le modifiche dello schema di Windows 2000 ed Exchange 2000, gli attributi LDAPDisplayNames per houseIdentifier, labeledURI e secretary vengono alterati. Un attributo diventa "mangled" se "Dup" o altri caratteri univoci vengono aggiunti all'inizio del nome dell'attributo in conflitto in modo che gli oggetti e gli attributi nella directory abbiano nomi univoci.

Le foreste di Active Directory non sono vulnerabili a LDAPDisplayNames mangled per questi attributi nei casi seguenti:

  • Se si esegue il comando di Windows Server 2003 adprep /forestprep in una foresta contenente lo schema di Windows 2000 prima di aggiungere lo schema di Exchange 2000.
  • Se si installa lo schema di Exchange 2000 nella foresta creata in cui un controller di dominio Windows Server 2003 è stato il primo controller di dominio nella foresta.
  • Se si aggiunge Windows 2000 inetOrgPerson Kit a una foresta contenente lo schema di Windows 2000, quindi si installano le modifiche dello schema di Exchange 2000 e quindi si esegue il comando di Windows Server 2003 adprep /forestprep .
  • Se si aggiunge lo schema di Exchange 2000 a una foresta windows 2000 esistente, eseguire Exchange 2003 /forestprep prima di eseguire il comando di Windows Server 2003 adprep /forestprep .

Gli attributi mangled si verificheranno in Windows 2000 nei casi seguenti:

  • Se si aggiungono le versioni di Exchange 2000 di labeledURI, houseIdentifier e gli attributi secretary a una foresta di Windows 2000 prima di installare Windows 2000 inetOrgPerson Kit.
  • Aggiungere le versioni di Exchange 2000 dell'uri etichettato, houseIdentifier e gli attributi secretary a una foresta di Windows 2000 prima di eseguire il comando di Windows Server 2003 adprep /forestprep senza prima eseguire gli script di pulizia. Di seguito sono seguenti i piani d'azione per ogni scenario:

Scenario 1: le modifiche allo schema di Exchange 2000 vengono aggiunte dopo l'esecuzione del comando adprep /forestprep di Windows Server 2003

Se le modifiche dello schema di Exchange 2000 verranno introdotte nella foresta di Windows 2000 dopo l'esecuzione del comando di Windows Server 2003 adprep /forestprep , non è necessaria alcuna pulizia. Passare alla sezione "Panoramica: Aggiornamento dei controller di dominio di Windows 2000 a Windows Server 2003".

Scenario 2: Le modifiche dello schema di Exchange 2000 verranno installate prima del comando adprep /forestprep di Windows Server 2003

Se sono già state installate modifiche allo schema di Exchange 2000 ma NON è stato eseguito il comando Windows Server 2003 adprep /forestprep , considerare il piano d'azione seguente:

  1. Accedere alla console del master operazioni dello schema usando un account membro del gruppo di sicurezza Schema Admins.

  2. Fare clic su Start, fare clic su Esegui, digitare notepad.exe nella casella Apri e quindi fare clic su OK.

  3. Copiare il testo seguente, incluso il trattino finale dopo "schemaUpdateNow: 1" nel Blocco note.

    dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
    changetype: Modifica
    replace:LDAPDisplayName
    LDAPDisplayName: msExchAssistantName
    -

    dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
    changetype: Modifica
    replace: LDAPDisplayName
    LDAPDisplayName: msExchLabeledURI
    -

    dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
    changetype: Modifica
    replace: LDAPDisplayName
    LDAPDisplayName: msExchHouseIdentifier
    -

    Dn:
    changetype: Modifica
    add: schemaUpdateNow
    schemaUpdateNow: 1
    -

  4. Verificare che non vi sia spazio alla fine di ogni riga.

  5. Scegliere Salva dal menu File. Nella finestra di dialogo Salva con nome attenersi alla seguente procedura:

    1. Nella casella Nome file digitare quanto segue: \%userprofile%\InetOrgPersonPrevent.ldf
    2. Nella casella Salva con nome fare clic su Tutti i file.
    3. Nella casella Codifica fare clic su Unicode.
    4. Fare clic su Salva.
    5. Chiudere il Blocco note.
  6. Eseguire lo script InetOrgPersonPrevent.ldf.

    1. Fare clic su Start, fare clic su Esegui, digitare cmd nella casella Apri e quindi fare clic su OK.

    2. Al prompt dei comandi digitare quanto segue e quindi premere INVIO: cd %userprofile%

    3. Digitare il comando seguente

    c:\documents and settings\%username%>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "domain name path for forest root domain"
    

    Note sulla sintassi:

    • DC=X è una costante con distinzione tra maiuscole e minuscole.
    • Il percorso del nome di dominio per il dominio radice deve essere racchiuso tra virgolette.

    Ad esempio, la sintassi del comando per una foresta di Active Directory il cui dominio radice della foresta è TAILSPINTOYS.COM :

    c:\documents and settings\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "dc=tailspintoys,dc=com"

    Nota

    Potrebbe essere necessario modificare la sottochiave del Registro di sistema Aggiornamento schema consentito se viene visualizzato il messaggio di errore seguente: L'aggiornamento dello schema non è consentito in questo controller di dominio perché la chiave del Registro di sistema non è impostata o il controller di dominio non è il proprietario del ruolo FSMO dello schema.

  7. Verificare che gli attributi LDAPDisplayNames per CN=ms-Exch-Assistant-Name, CN=ms-Exch-LabeledURI e CN=ms-Exch-House-Identifier nel contesto di denominazione dello schema vengano ora visualizzati come msExchAssistantName, msExchLabeledURI e msExchHouseIdentifier prima di eseguire i comandi di Windows Server 2003 adprep /forestprep .

  8. Passare alla sezione "Panoramica: Aggiornamento dei controller di dominio windows 2000 a Windows Server 2003" per eseguire i adprep /forestprep comandi e /domainprep .

Scenario 3: il comando forestprep di Windows Server 2003 è stato eseguito senza prima eseguire inetOrgPersonFix

Se si esegue il comando di Windows Server 2003 adprep /forestprep in una foresta di Windows 2000 che contiene le modifiche dello schema di Exchange 2000, gli attributi LDAPDisplayName per houseIdentifier, secretary e labeledURI verranno alterati. Per identificare i nomi intagliati, usare Ldp.exe per individuare gli attributi interessati:

  1. Installare Ldp.exe dalla cartella Support\Tools del supporto di Microsoft Windows 2000 o Windows Server 2003.

  2. Avviare Ldp.exe da un controller di dominio o da un computer membro nella foresta.

    1. Nel menu Connessione fare clic su Connetti, lasciare vuota la casella Server , digitare 389 nella casella Porta e quindi fare clic su OK.
    2. Scegliere Associa dal menu Connessione, lasciare vuote tutte le caselle e quindi fare clic su OK.
  3. Registrare il percorso del nome distinto per l'attributo SchemaNamingContext. Ad esempio, per un controller di dominio nella foresta CORP.ADATUM.COM, il percorso del nome distinto potrebbe essere CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.

  4. Scegliere Cerca dal menu Sfoglia.

  5. Usare le impostazioni seguenti per configurare la finestra di dialogo Cerca :

    • DN di base: percorso del nome distinto per il contesto di denominazione dello schema identificato nel passaggio 3.
    • Filtro: (ldapdisplayname=dup*)
    • Ambito: sottoalbero
  6. Gli attributi Mangled houseIdentifier, secretary e labeledURI hanno attributi LDAPDisplayName simili al formato seguente:

    LDAPDisplayName: DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d;
    LDAPDisplayName: DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
    LDAPDisplayName: DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef

  7. Se LDAPDisplayNames per labeledURI, secretary e houseIdentifier sono stati alterati nel passaggio 6, eseguire lo script InetOrgPersonFix.ldf di Windows Server 2003 per il ripristino e quindi passare alla sezione "Aggiornamento dei controller di dominio windows 2000 con Winnt32.exe".

    1. Creare una cartella denominata %Systemdrive%\IOP ed estrarre il file InetOrgPersonFix.ldf in questa cartella.

    2. Al prompt dei comandi digitare cd %systemdrive%\iop.

    3. Estrarre il file InetOrgPersonFix.ldf dal file Support.cab che si trova nella cartella Support\Tools del supporto di installazione di Windows Server 2003.

    4. Dalla console del master operazioni dello schema caricare il file InetOrgPersonFix.ldf usando Ldifde.exe per correggere l'attributo LdapDisplayName degli attributi houseIdentifier, secretary e labeledURI. A tale scopo, digitare il comando seguente, dove <X> è una costante con distinzione tra maiuscole e minuscole e <il percorso dn per il dominio> radice della foresta è il percorso del nome di dominio per il dominio radice della foresta:

      C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X "domain name path for forest root domain"
      

      Note sulla sintassi:

      • DC=X è una costante con distinzione tra maiuscole e minuscole.
      • Il percorso del nome di dominio per il dominio radice della foresta deve essere racchiuso tra virgolette.
  8. Verificare che gli attributi houseIdentifier, secretary e labeledURI nel contesto di denominazione dello schema non siano "alterati" prima di installare Exchange 2000.

Panoramica: Aggiornamento dei controller di dominio di Windows 2000 a Windows Server 2003

Il comando di Windows Server 2003 adprep eseguito dalla cartella \I386 del supporto di Windows Server 2003 prepara una foresta di Windows 2000 e i relativi domini per l'aggiunta di controller di dominio Windows Server 2003. Il comando di Windows Server 2003 adprep /forestprep aggiunge le funzionalità seguenti:

  • Descrittori di sicurezza predefiniti migliorati per le classi di oggetti

  • Nuovi attributi utente e gruppo

  • Nuovi oggetti e attributi dello schema, ad esempio inetOrgPersonL'utilità adprep supporta due argomenti della riga di comando:

    • adprep /forestprep: esegue operazioni di aggiornamento della foresta.
    • dprep /domainprep: esegue operazioni di aggiornamento del dominio.

Il adprep /forestprep comando è un'operazione una tantum eseguita sul master dell'operazione dello schema (FSMO) della foresta. L'operazione forestprep deve essere completata e replicata nel master dell'infrastruttura di ogni dominio prima di poter essere eseguita adprep /domainprep in tale dominio.

Il adprep /domainprep comando è un'operazione una tantum eseguita nel controller di dominio master operazioni dell'infrastruttura di ogni dominio nella foresta che ospiterà controller di dominio Windows Server 2003 nuovi o aggiornati. Il adprep /domainprep comando verifica che le modifiche apportate da forestprep siano state replicate nella partizione di dominio e quindi apporta le proprie modifiche alla partizione di dominio e ai criteri di gruppo nella condivisione Sysvol.

Non è possibile eseguire una delle azioni seguenti a meno che le operazioni /forestprep e /domainprep non siano state completate e replicate in tutti i controller di dominio in tale dominio:

  • Aggiornare i controller di dominio Windows 2000 ai controller di dominio di Windows Server 2003 usando Winnt32.exe.

Nota

È possibile aggiornare i computer e i server membri di Windows 2000 ai computer membri di Windows Server 2003 quando si desidera. Alzare di livello i nuovi controller di dominio di Windows Server 2003 nel dominio usando Dcpromo.exe. Il dominio che ospita il master operazioni dello schema è l'unico dominio in cui è necessario eseguire sia adprep /forestprep che adprep /domainprep. In tutti gli altri domini è sufficiente eseguire adprep /domainprep.

I adprep /forestprep comandi e adprep /domainprep non aggiungono attributi al set di attributi parziali del catalogo globale o causano una sincronizzazione completa del catalogo globale. La versione RTM di adprep /domainprep causa una sincronizzazione completa della cartella \Policies nell'albero Sysvol. Anche se si esegue forestprep e domainprep più volte, le operazioni completate vengono eseguite una sola volta.

Dopo le modifiche apportate e adprep /forestprepadprep /domainprep la replica completa, è possibile aggiornare i controller di dominio di Windows 2000 a Windows Server 2003 eseguendo Winnt32.exe dalla cartella \I386 del supporto di Windows Server 2003. È anche possibile aggiungere nuovi controller di dominio di Windows Server 2003 al dominio usando Dcpromo.exe.

Aggiornamento della foresta con il comando adprep /forestprep

Per preparare una foresta e un dominio windows 2000 per accettare i controller di dominio di Windows Server 2003, seguire questa procedura prima in un ambiente lab, quindi in un ambiente di produzione:

  1. Assicurarsi di aver completato tutte le operazioni nella fase "Inventario foresta" con particolare attenzione agli elementi seguenti:

    1. Sono stati creati backup dello stato del sistema.
    2. Tutti i controller di dominio Windows 2000 nella foresta hanno installato tutti gli hotfix e i Service Pack appropriati.
    3. La replica end-to-end di Active Directory si verifica in tutta la foresta
    4. Frs replica correttamente i criteri del file system in ogni dominio.
  2. Accedere alla console del master operazioni dello schema con un account membro del gruppo di sicurezza Schema Admins.

  3. Verificare che lo schema FSMO abbia eseguito la replica in ingresso della partizione dello schema digitando quanto segue al prompt dei comandi di Windows NT: repadmin /showreps

    ( repadmin viene installato dalla cartella Support\Tools di Active Directory.

  4. La documentazione iniziale di Microsoft consiglia di isolare il master operazioni dello schema in una rete privata prima di eseguire adprep /forestprep. L'esperienza reale suggerisce che questo passaggio non è necessario e può causare il rifiuto delle modifiche dello schema da parte di un master delle operazioni dello schema quando viene riavviato in una rete privata.

  5. Eseguire adprep nel master operazioni dello schema. A tale scopo, fare clic su Start, fare clic su Esegui, digitare cmd e quindi fare clic su OK. Nel master operazioni dello schema digitare il comando seguente:

     X:\I386\adprep /forestprep
    

    dove X:\I386\ è il percorso del supporto di installazione di Windows Server 2003. Questo comando esegue l'aggiornamento dello schema a livello di foresta.

    Nota

    Gli eventi con ID evento 1153 registrati nel registro eventi del servizio directory, ad esempio l'esempio seguente, possono essere ignorati:

  6. Verificare che il adprep /forestprep comando sia stato eseguito correttamente nel master operazioni dello schema. A tale scopo, dalla console del master operazioni dello schema verificare gli elementi seguenti: - Comando adprep /forestprep completato senza errori. - L'oggetto CN=Windows2003Update viene scritto in CN=ForestUpdates,CN=Configuration,DC= forest_root_domain. Registrare il valore dell'attributo Revision. - (Facoltativo) Versione dello schema incrementata alla versione 30. A tale scopo, vedere l'attributo ObjectVersion in CN=Schema,CN=Configuration,DC= forest_root_domain. Se adprep /forestprep non viene eseguito, verificare gli elementi seguenti:

    • Il percorso completo per Adprep.exe che si trova nella cartella \I386 del supporto di installazione è stato specificato durante adprep l'esecuzione. A tale scopo, digitare il comando seguente:

      x:\i386\adprep /forestprep
      

      dove x è l'unità che ospita il supporto di installazione.

    • L'utente connesso che esegue adprep è membro del gruppo di sicurezza Schema Admins. Per verificarlo, usare il whoami /all comando .

    • Se adprep ancora non funziona, visualizzare il file Adprep.log nella cartella %systemroot%\System32\Debug\Adprep\Logs\Latest_log .

  7. Se la replica in uscita è stata disabilitata nel master operazioni dello schema nel passaggio 4, abilitare la replica in modo che le modifiche dello schema apportate da adprep /forestprep possano propagarsi. A tale scopo, seguire questa procedura:

    1. Fare clic su Start, fare clic su Esegui, digitare cmd e quindi fare clic su OK.
    2. Digitare quanto segue e quindi premere INVIO: repadmin /options -DISABLE_OUTBOUND_REPL
  8. Verificare che le adprep /forestprep modifiche siano state replicate in tutti i controller di dominio nella foresta. È utile monitorare gli attributi seguenti:

    1. Incremento della versione dello schema
    2. CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC= forest_root_domain o CN=Operations,CN=DomainUpdates,CN=System,DC= forest_root_domain e i GUID delle operazioni in cui sono stati replicati.
    3. Cercare nuove classi di schema, oggetti, attributi o altre modifiche aggiunte adprep /forestprep , ad esempio inetOrgPerson. Visualizzare i file Sch XX.ldf (dove XX è un numero compreso tra 14 e 30) nella cartella %systemroot%\System32 per determinare quali oggetti e attributi devono essere presenti. Ad esempio, inetOrgPerson è definito in Sch18.ldf.
  9. Cercare LDAPDisplayNames mangled. Se si trovano nomi mangled, passare allo scenario 3 dello stesso articolo.

  10. Accedere alla console del master operazioni dello schema con un account membro del gruppo di sicurezza Schema Admins della foresta che ospita il master operazioni dello schema.

Aggiornamento del dominio con il comando adprep /domainprep

Eseguire adprep /domainprep dopo la replica completa delle modifiche di /forestprep nel controller di dominio master dell'infrastruttura in ogni dominio che ospiterà i controller di dominio di Windows Server 2003. A tale scopo, seguire questa procedura:

  1. Identificare il controller di dominio master dell'infrastruttura nel dominio che si sta aggiornando e quindi accedere con un account membro del gruppo di sicurezza Domain Admins nel dominio che si sta aggiornando.

    Nota

    L'amministratore dell'organizzazione non può essere membro del gruppo di sicurezza Domain Admins nei domini figlio della foresta.

  2. Eseguire adprep /domainprep nel master infrastruttura. A tale scopo, fare clic su Start, fare clic su Esegui, digitare cmd e quindi nel master infrastruttura digitare il comando seguente: X:\I386\adprep /domainprep dove X:\I386\ è il percorso del supporto di installazione di Windows Server 2003. Questo comando esegue modifiche a livello di dominio nel dominio di destinazione.

    Nota

    Il adprep /domainprep comando modifica le autorizzazioni per i file nella condivisione Sysvol. Queste modifiche causano una sincronizzazione completa dei file in tale albero di directory.

  3. Verificare che domainprep sia stato completato correttamente. A tale scopo, verificare gli elementi seguenti:

    • Il adprep /domainprep comando è stato completato senza errori.
    • Il percorso CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn del dominio che si sta aggiornando esisteSe adprep /domainprep non viene eseguito, verificare gli elementi seguenti:
    • L'utente connesso che esegue adprep ha l'appartenenza al gruppo di sicurezza Domain Admins nel dominio da aggiornare. A tale scopo, usare il whoami /all comando .
    • Il percorso completo per Adprep.exe che si trova nella directory \I386 del supporto di installazione è stato specificato durante l'esecuzione adprepdi . A tale scopo, al prompt dei comandi digitare il comando seguente: x :\i386\adprep /forestprep dove x è l'unità che ospita il supporto di installazione.
    • Se adprep ancora non funziona, visualizzare il file Adprep.log nella cartella %systemroot%\System32\Debug\Adprep\Logs\ Latest_log .
  4. Verificare che le adprep /domainprep modifiche siano state replicate. A tale scopo, per i controller di dominio rimanenti nel dominio, verificare gli elementi seguenti: - Il percorso CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn del dominio che si sta aggiornando esiste e il valore dell'attributo Revision corrisponde al valore dello stesso attributo nel master infrastruttura del dominio. - (Facoltativo) Cercare gli oggetti, gli attributi o le modifiche adprep /domainprep dell'elenco di controllo di accesso aggiunte. Ripetere i passaggi da 1 a 4 nel master dell'infrastruttura dei domini rimanenti in blocco o quando si aggiungono o si aggiornano controller di dominio in tali domini a Windows Server 2003. È ora possibile alzare di livello i nuovi computer Windows Server 2003 nella foresta usando DCPROMO. In alternativa, è possibile aggiornare i controller di dominio di Windows 2000 esistenti a Windows Server 2003 usando WINNT32.EXE.

Aggiornamento di controller di dominio Windows 2000 tramite Winnt32.exe

Dopo che le modifiche apportate da /forestprep e /domainprep sono state completamente replicate e si è presa una decisione sull'interoperabilità della sicurezza con i client di versione precedente, è possibile aggiornare i controller di dominio windows 2000 a Windows Server 2003 e aggiungere nuovi controller di dominio di Windows Server 2003 al dominio.

I computer seguenti devono essere tra i primi controller di dominio che eseguono Windows Server 2003 nella foresta in ogni dominio:

  • Master dei nomi di dominio nella foresta in modo da poter creare partizioni del programma DNS predefinite.
  • Il controller di dominio primario del dominio radice della foresta in modo che le entità di sicurezza a livello aziendale aggiunte dalla forestprep di Windows Server 2003 diventino visibili nell'editor ACL.
  • Controller di dominio primario in ogni dominio non radice in modo da poter creare nuove entità di sicurezza di Windows 2003 specifiche del dominio. A tale scopo, usare WINNT32 per aggiornare i controller di dominio esistenti che ospitano il ruolo operativo desiderato. In alternativa, trasferire il ruolo a un controller di dominio Windows Server 2003 appena promosso. Seguire questa procedura per ogni controller di dominio Windows 2000 che si esegue l'aggiornamento a Windows Server 2003 con WINNT32 e per ogni computer membro o gruppo di lavoro di Windows Server 2003 promosso:
  1. Prima di usare WINNT32 per aggiornare i computer membri e i controller di dominio di Windows 2000, rimuovere Strumenti di amministrazione di Windows 2000. A tale scopo, usare lo strumento Installazione applicazioni in Pannello di controllo. (Solo aggiornamenti di Windows 2000).

  2. Installare eventuali file hotfix o altre correzioni che Microsoft o l'amministratore determinano è importante.

  3. Controllare ogni controller di dominio per eventuali problemi di aggiornamento. A tale scopo, eseguire il comando seguente dalla cartella \I386 del supporto di installazione: winnt32.exe /checkupgradeonly Risolvere eventuali problemi identificati dal controllo di compatibilità.

  4. Eseguire WINNT32.EXE dalla cartella \I386 del supporto di installazione e riavviare il controller di dominio aggiornato 2003.

  5. Abbassare le impostazioni di sicurezza per i client di versione precedente in base alle esigenze.

    Se i client Windows NT 4.0 non dispongono di client NT 4.0 SP6 o Windows 95 non hanno installato il client del servizio directory, disabilitare la firma del servizio SMB nei criteri Controller di dominio predefiniti nell'unità organizzativa Controller di dominio e quindi collegare questo criterio a tutte le unità organizzative che ospitano i controller di dominio. Configurazione computer\Impostazioni di Windows\Impostazioni di sicurezza\Criteri locali\Opzioni di sicurezza\Microsoft Network Server: Firma digitalmente le comunicazioni (sempre)

  6. Verificare l'integrità dell'aggiornamento usando i punti dati seguenti:

    • L'aggiornamento è stato completato correttamente.
    • Gli hotfix aggiunti all'installazione hanno sostituito correttamente i file binari originali.
    • La replica in ingresso e in uscita di Active Directory si verifica per tutti i contesti di denominazione contenuti nel controller di dominio.
    • Le condivisioni Netlogon e Sysvol esistono.
    • Il registro eventi indica che il controller di dominio e i relativi servizi sono integri.

    Nota

    Dopo l'aggiornamento è possibile ricevere il messaggio di evento seguente: è possibile ignorare questo messaggio di evento.

  7. Installare gli strumenti di amministrazione di Windows Server 2003 (solo aggiornamenti di Windows 2000 e controller non di dominio di Windows Server 2003). Adminpak.msi si trova nella cartella \I386 del CD-ROM di Windows Server 2003. Il supporto di Windows Server 2003 contiene strumenti di supporto aggiornati nel file Support\Tools\Suptools.msi. Assicurarsi di reinstallare questo file.

  8. Eseguire nuovi backup di almeno i primi due controller di dominio Windows 2000 aggiornati a Windows Server 2003 in ogni dominio della foresta. Individuare i backup dei computer Windows 2000 aggiornati a Windows Server 2003 nell'archiviazione bloccata in modo da non usarli accidentalmente per ripristinare un controller di dominio che ora esegue Windows Server 2003.

  9. (Facoltativo) Eseguire una deframmentazione offline del database di Active Directory nei controller di dominio aggiornati a Windows Server 2003 dopo il completamento dell'archivio a istanza singola (SIS) (solo aggiornamenti di Windows 2000).

    Il SIS esamina le autorizzazioni esistenti per gli oggetti archiviati in Active Directory e quindi applica un descrittore di sicurezza più efficiente su tali oggetti. Il SIS viene avviato automaticamente (identificato dall'evento 1953 nel registro eventi del servizio directory) quando i controller di dominio aggiornati avviano per la prima volta il sistema operativo Windows Server 2003. È possibile sfruttare l'archivio descrittore di sicurezza migliorato solo quando si registra un messaggio dell'evento ID evento 1966 nel registro eventi del servizio directory: questo messaggio di evento indica che l'operazione di archiviazione a istanza singola è stata completata e funge da coda all'amministratore per eseguire la deframmentazione offline di Ntds.dit usando NTDSUTIL.EXE.

    La deframmentazione offline può ridurre le dimensioni di un file Ntds.dit di Windows 2000 fino al 40%, migliorare le prestazioni di Active Directory e aggiornare le pagine nel database per un'archiviazione più efficiente degli attributi con valori di collegamento. Per altre informazioni su come deframmentare il database di Active Directory, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente:

    232122 Esecuzione della deframmentazione offline del database di Active Directory

  10. Esaminare il servizio server DLT. I controller di dominio di Windows Server 2003 disabilitano il servizio DLT Server nelle installazioni aggiornate e di aggiornamento. Se i client Windows 2000 o Windows XP nell'organizzazione usano il servizio DLT Server, usare Criteri di gruppo per abilitare il servizio DLT Server nei controller di dominio Windows Server 2003 nuovi o aggiornati. In caso contrario, eliminare in modo incrementale gli oggetti di rilevamento dei collegamenti distribuiti da Active Directory. Per altre informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo della Microsoft Knowledge Base:

    312403 rilevamento dei collegamenti distribuiti nei controller di dominio basati su Windows

    Se si eliminano in blocco migliaia di oggetti DLT o altri oggetti, è possibile bloccare la replica a causa della mancanza di un archivio versioni. Attendere tombstonelifetime numero di giorni (per impostazione predefinita, 60 giorni) dopo l'eliminazione dell'ultimo oggetto DLT e il completamento della Garbage Collection, quindi usare NTDSUTIL.EXE per eseguire una deframmentazione offline del file Ntds.dit.

  11. Configurare la struttura delle unità organizzative di procedure consigliate. Microsoft consiglia agli amministratori di distribuire attivamente la struttura delle unità organizzative consigliate in tutti i domini di Active Directory e, dopo aver aggiornato o distribuito i controller di dominio di Windows Server 2003 in modalità dominio Windows, reindirizzare i contenitori predefiniti usati dalle API di versione precedente per creare utenti, computer e gruppi in un contenitore di unità organizzative specificato dall'amministratore.

    Per altre informazioni sulla struttura delle unità organizzative di procedure consigliate, vedere la sezione "Creazione di una progettazione di unità organizzative" del white paper "Best Practice Active Directory Design for Managing Windows Networks". Per visualizzare il white paper, visitare il seguente sito Web Microsoft: https://technet.microsoft.com/library/bb727085.aspx Per altre informazioni sulla modifica del contenitore predefinito in cui si trovano utenti, computer e gruppi creati dalle API di versione precedente, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente:

    324949 Reindirizzamento dei contenitori di utenti e computer nei domini di Windows Server 2003

  12. Ripetere i passaggi da 1 a 10 come richiesto per ogni controller di dominio Windows Server 2003 nuovo o aggiornato nella foresta e passaggio 11 (struttura delle unità organizzative di procedure consigliate) per ogni dominio di Active Directory.

    In Riepilogo:

    • Aggiornare i controller di dominio Windows 2000 con WINNT32 (dal supporto di installazione slipstream, se usato)
    • Verificare che i file degli hotfix siano stati installati nei computer aggiornati
    • Installare gli hotfix necessari non contenuti nei supporti di installazione
    • Verificare l'integrità nei server nuovi o aggiornati (AD, FRS, Criteri e così via)
    • Attendere 24 ore dopo l'aggiornamento del sistema operativo e quindi defrag offline (facoltativo)
    • Se necessario, avviare il servizio DLT, altrimenti eliminare oggetti DLT usando q312403/q315229 dopo domainpreps a livello di foresta
    • Eseguire la deframmentazione offline per oltre 60 giorni (durata della rimozione definitiva e Garbage Collection # di giorni) dopo l'eliminazione di oggetti DLT

Aggiornamenti a secco in un ambiente lab

Prima di aggiornare i controller di dominio Windows a un dominio windows 2000 di produzione, convalidare e perfezionare il processo di aggiornamento nel lab. Se l'aggiornamento di un ambiente lab che rispecchia accuratamente la foresta di produzione funziona senza problemi, è possibile aspettarsi risultati simili negli ambienti di produzione. Per gli ambienti complessi, l'ambiente lab deve eseguire il mirroring dell'ambiente di produzione nelle aree seguenti:

  • Hardware: tipo di computer, dimensioni della memoria, posizionamento dei file di pagina, dimensioni del disco, prestazioni e configurazione raid, livelli di revisione del BIOS e del firmware
  • Software: versioni del sistema operativo client e server, applicazioni client e server, versioni del Service Pack, hotfix, modifiche dello schema, gruppi di sicurezza, appartenenze a gruppi, autorizzazioni, impostazioni dei criteri, tipo di numero di oggetti e posizione, interoperabilità della versione
  • Infrastruttura di rete: WINS, DHCP, velocità dei collegamenti, larghezza di banda disponibile
  • Caricamento: i simulatori di carico possono simulare le modifiche delle password, la creazione di oggetti, la replica di Active Directory, l'autenticazione di accesso e altri eventi. L'obiettivo non è riprodurre la scalabilità dell'ambiente di produzione. Gli obiettivi sono invece individuare i costi e la frequenza delle operazioni comuni e interpolarne gli effetti (query dei nomi, traffico di replica, larghezza di banda di rete e consumo del processore) nell'ambiente di produzione in base ai requisiti correnti e futuri.
  • Amministrazione: attività eseguite, strumenti usati, sistemi operativi usati
  • Operazione: capacità, interoperabilità
  • Spazio su disco: si noti la dimensione iniziale, massima e finale dei file di log del sistema operativo, Ntds.dit e Active Directory nei controller di dominio del catalogo globale e del catalogo non globale in ogni dominio dopo ognuna delle operazioni seguenti:
    1. adprep /forestprep
    2. adprep /domainprep
    3. Aggiornamento dei controller di dominio windows 2000 a Windows Server 2003
    4. Esecuzione della deframmentazione offline dopo gli aggiornamenti della versione

La comprensione del processo di aggiornamento e della complessità dell'ambiente combinata con un'osservazione dettagliata determina il ritmo e il grado di attenzione che si applicano all'aggiornamento degli ambienti di produzione. Gli ambienti con un numero ridotto di controller di dominio e oggetti Active Directory connessi tramite collegamenti WAN (Wide Area Network) a disponibilità elevata potrebbero essere aggiornati in poche ore. Potrebbe essere necessario prestare maggiore attenzione alle distribuzioni aziendali con centinaia di controller di dominio o centinaia di migliaia di oggetti Active Directory. In questi casi, è possibile eseguire l'aggiornamento nel corso di diverse settimane o mesi.

Usare gli aggiornamenti a esecuzione a secco nel lab per eseguire le attività seguenti:

  • Comprendere il funzionamento interno del processo di aggiornamento e i rischi associati.
  • Esporre potenziali aree problematiche per il processo di distribuzione nell'ambiente.
  • Testare e sviluppare piani di ripiego nel caso in cui l'aggiornamento non abbia esito positivo.
  • Definire il livello di dettaglio appropriato da applicare al processo di aggiornamento per il dominio di produzione.

Controller di dominio senza spazio su disco sufficiente

Nei controller di dominio con spazio su disco insufficiente, seguire questa procedura per liberare spazio su disco aggiuntivo nel volume che ospita i file Ntds.dit e Log:

  1. Eliminare i file inutilizzati, inclusi i file *.tmp o i file memorizzati nella cache usati dai browser Internet. A tale scopo, digitare i comandi seguenti (premere INVIO dopo ogni comando):

    cd /d drive\  
    del *.tmp /s  
    
  2. Eliminare tutti i file di dump dell'utente o della memoria. A tale scopo, digitare i comandi seguenti (premere INVIO dopo ogni comando):

    cd /d drive\  
    del *.dmp /s  
    
  3. Rimuovere o rilocare temporaneamente i file a cui è possibile accedere da altri server o reinstallare facilmente. I file che è possibile rimuovere e sostituire facilmente includono ADMINPAK, Strumenti di supporto e tutti i file nella cartella %systemroot%\System32\Dllcache.

  4. Eliminare i profili utente obsoleti o inutilizzati. A tale scopo, fare clic su Start, fare clic con il pulsante destro del mouse su Risorse del computer, scegliere Proprietà, fare clic sulla scheda Profili utente e quindi eliminare tutti i profili per gli account vecchi e inutilizzati. Non eliminare profili che potrebbero essere per gli account del servizio.

  5. Eliminare i simboli in %systemroot%\Symbols. A tale scopo, digitare il comando seguente: rd /s %systemroot%\symbols a seconda che i server dispongano di un set di simboli completo o di piccole dimensioni, è possibile che questo guadagni da 70 MB a 600 MB circa.

  6. Eseguire una deframmentazione offline. Una deframmentazione offline del file Ntds.dit può liberare spazio, ma richiede temporaneamente il doppio dello spazio del file DIT corrente. Eseguire la deframmentazione offline usando altri volumi locali, se disponibile. In alternativa, usare lo spazio in un server di rete connesso migliore per eseguire la deframmentazione offline. Se lo spazio su disco non è ancora sufficiente, eliminare in modo incrementale account utente, account computer, record DNS e oggetti DLT non necessari da Active Directory.

Nota

Active Directory non elimina gli oggetti dal database fino a quando non è trascorso il numero di giorni di rimozione definitiva (per impostazione predefinita, 60 giorni) e la Garbage Collection viene completata. Se si riduce tombstonelifetime a un valore inferiore alla replica end-to-end nella foresta, è possibile che si verifichino incoerenze in Active Directory.