Offline Backup and Restoration Procedures for Exchange

Traduzione articoli Traduzione articoli
Identificativo articolo: 296788 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

In questo articolo vengono descritti metodi che è possibile utilizzare per ignorare l'applicazione di backup in linea programming interface (API) ed eseguire il backup manualmente e ripristinare database di archivio informazioni di Exchange. Se si dispone di più gruppi di archiviazione su un singolo server di Exchange, ogni gruppo di archiviazione deve essere considerata un'unità indipendente e indipendente per a scopo di backup non in linea e di ripristino.Per ulteriori informazioni sui backup non in linea e snapshot, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
296787XADM: Non in linea procedure di backup e ripristino per Exchange Server 4.0, 5.0 e 5.5

Informazioni

Prima di iniziare

Prima di eseguire un backup non in linea, assicurarsi di disporre le seguenti informazioni:
  • Consente di determinare o meno la registrazione circolare è abilitata per il gruppo di archiviazione. (Registrazione circolare è disattivata per impostazione predefinita in Exchange.) Per determinare se la registrazione circolare è abilitata, aprire le proprietà dell'oggetto storage_group nel gestore di sistema di Exchange e quindi visualizzare la pagina Generale . Per disattivare la registrazione circolare, fare clic per deselezionare la casella di controllo Circular Logging . Le modifiche apportate a registrazione circolare non vengono applicate fino all'interruzione di ogni database del gruppo di archiviazione.

    Non è necessario disattivare la registrazione circolare, eseguire il backup non in linea. Tuttavia, è necessario disattivare la registrazione circolare se si desidera riprodurre i registri delle transazioni in ripristinato backup non in linea.
  • Determinare i percorsi di percorso per il database di Exchange, di flusso, log delle transazioni e i file del checkpoint e il prefisso del file di registro del gruppo di archiviazione.

    Per individuare queste informazioni, aprire le proprietà dell'oggetto storage_group nel gestore di sistema di Exchange e quindi visualizzare la pagina Generale . Registrare i valori per le tre caselle seguenti:
    • prefisso file registro (E0n, in cui può essere E0n E00, E01, E02 o E03)
    • percorso del log delle transazioni (E0n*.log)
    • Posizione percorso di sistema (E0n.chk)
    I percorsi dei database sono elencati nelle proprietà database di ogni oggetto database_name. Registrare i valori per i due campi seguenti per ogni database nel gruppo di archiviazione:
    • database di Exchange (con estensione edb)
    • database di flusso di Exchange (con estensione stm)
Se Gestore di sistema non è disponibile, è possibile trovare tutte le precedenti informazioni leggendo direttamente gli attributi non elaborati da Active Directory con uno strumento come ADSIEDIT o LDIFDE. È possibile utilizzare il comando LDIFDE riportato di seguito per generare informazioni per tutti i server Exchange in un insieme di strutture di Active Directory.

Nota : il testo per questo comando è stata suddivisa per facilitarne la lettura.
LDIFDE -F EXPATHS.TXT -D "CN = CONFIGURATION, DC = configuration_container_domain, DC = top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH, MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME, MSEXCHESEPARAMCIRCULARLOG, MSEXCHSLVFILE,
MSEXCHEDBFILE - R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Di seguito è un esempio dell'output del comando precedente:
D:\Exchsrvr\Mdbdata>ldifde -f con -d "cn = configuration, dc = test, dc = com" -l msexch eseparamlogfilepath msexcheseparamsystempath, msexcheseparambasename, msexchesepar amcircularlog, msexchslvfile, msexchedbfile - r "(|(msexcheseparamlogfilepath=*) (ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) le=*)(msexcheseparamcircularlog=*)) di msexchedbfi"
Connessione a "dc1.child.test.com"
Accedere come utente corrente utilizzando SSPI
L'esportazione di directory in file con
Ricerca di voci in corso...

output troncato: >

.DN: CN = Primo gruppo di archiviazione, CN = InformationStore, CN = Exchange1, CN = Servers, CN = Primo gruppo amministrativo, CN = Administrative Groups, CN = organizzazione, CN = Microsoft Excha cambia, CN = Services, CN = Configuration, DC = test, DC = com
changetype: aggiungere
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: CN = Public Information Store (EXCHANGE1), CN = Primo gruppo di archiviazione, CN = Informati onStore, CN = Exchange1, CN = Servers, CN = Primo gruppo amministrativo, CN = Administrative Groups, CN = organizzazione, CN = Microsoft Exchange, CN = Services, CN = Configuration, DC = Tes t, DC = com
changetype: aggiungere
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.DN: CN = Private Information Store (EXCHANGE1), CN = Primo gruppo di archiviazione, CN = informazioni ionStore, CN = Exchange1, CN = Servers, CN = Primo gruppo amministrativo, CN = Administrative Groups, CN = organizzazione, CN = Microsoft Exchange, CN = Services, CN = Configuration, DC = Te st, DC = com
changetype: aggiungere
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Per riprodurre correttamente i registri delle transazioni, è necessario ripristinare file di database (edb e stm) negli stessi percorsi percorso da cui i file di backup. Ad esempio, se esegue il backup del file di database dalla cartella E:\Mdbdata e il file di database di flusso dalla cartella F:\Mdbdata, è necessario ripristinare i file E:\Mdbdata e F:\Mdbdata, rispettivamente. Questa limitazione si applica anche se si desidera ripristinare il database in un server completamente diverso (ad esempio, in una situazione di ripristino singola cassetta postale).

Se si modifica un percorso di database dopo l'ultimo backup, è possibile riprodurre solo parzialmente i registri delle transazioni ed è possibile ottenere una riproduzione parziale solo se si modifica il percorso alla posizione originale. Se ripristinare il percorso precedente, è possibile riprodurre i registri di backup per il punto in cui è stato modificato il percorso.

È possibile ripristinare il file di registro delle transazioni (E0n*.log) in un percorso diverso da quello originale backup. Questo è perché i registri delle transazioni registra i percorsi dei database che i registri delle transazioni sono collegati a, ma i database non registrano i percorsi dei registri delle transazioni. Durante la riproduzione, i registri "individuare" i database utilizzando le informazioni di percorso memorizzate nelle intestazioni di registro delle transazioni. (L'API di backup in linea compensa internamente le modifiche al percorso del database, e pertanto questa limitazione non si applica).

È non il backup o ripristinare il file di checkpoint (E0n.chk), ma è necessario conoscere la posizione corrente del file checkpoint poiché potrebbe essere necessario esaminarlo o eliminato durante il ripristino.

Come file di database di Exchange correlare a reciprocamente

I file edb e stm sono il repository finale per tutte le informazioni di database. Ai fini della maggior parte dei, gestisce la questi due file come se si tratta di un singolo file, backup e ripristinare questi file in parallelo. Questi file devono rimanere sincronizzati in ordine cronologico con un file edb sottoposti a backup in un giorno non corrisponde a un file di flusso che viene eseguito il backup su un altro giorno.

Un Exchange 2000 o un server di Exchange 2003 può supportare fino a quattro gruppi di archiviazione e ogni gruppo di archiviazione può supportare fino a cinque database. Un gruppo di archiviazione è un insieme di database che condividono un insieme comune di file di registro delle transazioni. Supportano un massimo di un gruppo di archiviazione, che supporta fino a due database (archivi di informazioni privati e pubblici) con Microsoft Exchange Server 5.5.

Quando vengono apportate modifiche al database, le modifiche vengono scritte prima il file di registro delle transazioni corrente, quindi per una cache in memoria. Non appena le modifiche sono presenti nella cache, tali modifiche diventano visibili per gli utenti. Pagine della cache vengono trasferite nel file di database quando risulta pratico effettuare questa operazione. Il checkpoint contrassegna il punto nella sequenza dei file di registro fino alla quale tutte le transazioni sono state svuotate fisicamente nel file di database. È normale per il checkpoint per il ritardo di tre o più file registro dietro il file di registro corrente.

Per evitare confusione sui file di registro appartengono a ogni gruppo di archiviazione, i registri di Exchange che appartengono a un gruppo di archiviazione specificato viene assegnato un prefisso di registro univoco, ovvero i primi tre caratteri del nome del file. I prefissi di registro valida per quattro gruppi di archiviazione sono supportati in un server di Exchange 2003 o Exchange 2000 sono E00, E01, E02 ed E03. In questo articolo, il prefisso di registro per un gruppo di archiviazione viene designato come E0n. Il file di registro corrente per un gruppo di archiviazione è sempre E0n.log.

I registri di transazione sono un uniforme 5 megabyte (MB) di dimensioni. Quando il file di registro corrente è pieno, viene rinominato con un numero esadecimale sequenza, chiamato il numero di generazione log, e viene generato un nuovo file di registro corrente. I file di registro vengono numerati come E0n00001.log, E0n00002.log e così via. In questo articolo, file di registro numerati vengono definiti genericamente come E0n xxxxx . log.

Se un database è stato arrestato in modo anomalo, i record del file (E0n.chk) di checkpoint del log delle transazioni da cui deve iniziare il ripristino riprodurre per ripristinare il database la coerenza. Questo processo è denominato "recupero". "Ripristino hardware", ovvero il processo di riproduzione da quale registro dei file dopo il ripristino di un backup in linea può essere differenza del ripristino software. Il più importante differenza tra un ripristino software e hardware è l'interpolazione dei dati del file di patch nel processo di riproduzione del file di registro durante il ripristino hardware.

Un file di database incoerente Exchange è un file che tutte le transazioni in sospeso non sono stati scritti per ancora. Durante il normale funzionamento, i file di database non sono coerenti causa di informazioni nella cache che non è ancora stati fisicamente scritti nel file. In generale, un file di database di Exchange può essere considerato coerenza solo dopo un arresto normale del servizio di database. Ciononostante, sempre è coerenza il database, come intero (considerato come somma delle informazioni dei registri delle transazioni e file di database), a meno che i file registro necessarie in modo anomalo vengono eliminati.

Backup di un database di Exchange non in linea

Per eseguire il backup di un database di Exchange in modalità non in linea:
  1. Disinstallare il database che si desidera eseguire il backup. Non è necessario disinstallare tutti i database nel gruppo di archiviazione, solo il database o database che si desidera eseguire il backup.
  2. Verificare che i file di database (file edb e stm) siano coerenti e corrispondenza a altra. A tale scopo, eseguire questo comando su ogni file:
    file del database eseutil /mh | trovare /i "DB firma"
    Nota : Exchange 2000 Service Pack 2 e versioni successive non segnalare lo stato del database come "Coerenti" o "Incoerenti", ma come "Chiusura normale" o "Chiusura anomala." Il significato di "Chiusura normale" è lo stesso "Coerenti" e il significato di "Chiusura anomala" corrisponde a quello "Incoerenti". Per Exchange 2000 Service Pack 2 o versione successiva, eseguire questo comando aggiuntivo per determinare lo stato di ogni database:
    eseutil /mh nome_database | trovare /i "Arresto"
    Di seguito è un esempio dell'output del comando precedente:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    Nell'esempio precedente, le firme di database sono gli stessi, che dimostra che i file con estensione edb e stm appartengano allo stesso insieme. (Le linee di firma devono corrispondere carattere per carattere nella loro interezza possa essere considerato una corrispondenza di firma).

    Non solo devono corrispondere le firme di DB, ma i file inoltre devono essere sincronizzate tra loro e coerente. Eseguire il comando seguente per ogni file:
    file del database eseutil /mh | trovare /i "uniforme"
    Di seguito è un esempio dell'output derivante dal comando precedente:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    Nell'esempio precedente, entrambe rapporto sui file "stato: coerente." Devono anche corrispondere i numeri esadecimali tra parentesi per ogni file (0x2CC7, 1F14, 1F7). Non è necessario che il timestamp ultimo coerente corrisponda. Questi file sono corrispondenza a altra e coerente.

    Se il file report "stato: incoerenti" o le posizioni ultimo coerente di registro non sono sincronizzate, il database non è stato disinstallato correttamente. Installare e quindi disinstallare di nuovo il database. Se i file ancora non corrispondono correttamente o non sono coerenti, contattare il servizio supporto tecnico clienti Microsoft (PSS) per ulteriori informazioni.
  3. Consente di copiare ogni file di database edb e il corrispondente file in database di flusso .stm in un percorso di backup.
  4. Montare il backup dei database.
  5. Se la registrazione circolare è attivata, è possibile ignorare questo passaggio. Se la registrazione circolare è disattivata e si desidera "rollforward" più avanti, è necessario eseguire il backup di tutti i log delle transazioni numerato del (E0n xxxxx file log). Non eseguire il backup del file E0n.log, Res1.log e Res2.log.

    È possibile backup file di registro numerati in qualsiasi momento appropriato, anche subito dopo la creazione, perché dopo che un file di registro è stato rinominato da E0n.log al log xxxxx E0n, Exchange non modifica nuovamente il file. Tuttavia, eliminazione dei backup di file registro solo in base alle istruzioni riportate nel passaggio 6.

    I backup del file di registro non dispone di una corrispondenza uno-a-uno con i backup dei database. Ogni backup del file di log è un collegamento in una catena di file di registro che potrebbero essere riproducibile con uno dei diversi backup di database diverso. È possibile rollforward da un backup di database specifico, purché si dispone di un flusso ininterrotta di registri che inizia con il registro elencato nella riga dell'intestazione del database "Ultimo coerente". In questo articolo, l'ultimo log coerente è detta "registro ancoraggio bassa".

    Se si fa riferimento all'esempio precedente, l'ultima voce di coerenza è (0x2CC7, 1F14, 1F7). I tre numeri designare un file di registro, una pagina in file di log e un offset di byte in tale pagina. Ciascun file registro contiene circa 10.000 pagine di 512 byte. L'offset di pagina consente una buona idea è come chiudere il file di registro per essere completo (il file di registro nell'esempio precedente è circa l'80 % completo, poiché è equivalente al decimale 7956 0x1F14,) ma è irrilevante per il ripristino. Ripristino inizia sempre all'inizio di un file di registro.

    In questo esempio, il file di log di ancoraggio basso è E0n02cc7.log.

    È possibile che non sempre visualizzati l'ultimo log coerente sul disco come un registro numerato, poiché l'ultimo log coerente ancora potrebbe essere denominato E0n.log. È possibile visualizzare la sequenza verrà assegnato il numero E0n.log infine esaminando l'intestazione del file registro, mentre il database è interrotto (accesso negato all'intestazione E0n.log mentre il database è in esecuzione).

    Per visualizzare il numero di generazione log interni, eseguire il comando riportato di seguito:
    eseutil /ml [file di registro] | trovare /i "lGeneration"
    Di seguito è un esempio dell'output del comando precedente:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    In molti casi, è più importante per assicurarsi che i backup del file di registro siano buona piuttosto che verificare che ogni backup del database sia buona. Infatti, ogni backup del database può ridondanza per le altre, ma la conservazione di ogni file di registro dopo che il backup dipende dalla recupero completo da qualsiasi backup del database.
  6. Se la registrazione circolare è attivata, ignorare questo passaggio. Esaminare l'intestazione del file checkpoint per determinare il file di registro numerati massimo che può essere rimossa in modo sicuro. Il checkpoint tiene traccia del minimo numerato file registro che è necessario per ripristino automatico se il database viene arrestato in modo anomalo. Per esaminare il file di checkpoint, eseguire il comando riportato di seguito:
    Eseutil /mk E0n.chk
    Di seguito è un esempio dell'output del comando precedente:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    La terza riga, la riga di checkpoint, contiene le informazioni rilevanti (il LastFullBackupCheckpoint voce viene utilizzato dal backup in linea e rimane tutti zero, se un backup in linea non viene mai eseguito a fronte del database). Il formato di posizione del Registro di checkpoint è come l'ultima voce coerenza nell'intestazione del database. In questo esempio, il checkpoint si trova in E0002cc7.log.

    Se la registrazione circolare è disattivata, i file di registro si accumulano fino a quando vengono manualmente eliminati o rimossi automaticamente dal processo di backup in linea. Se la registrazione circolare è attivata, non speciali di gestione di vecchi file di registro è necessaria, perché il servizio di database vengono automaticamente Elimina vecchi file di registro dopo il checkpoint passa attraverso di essi.

    Dopo il backup tutti i file registro numerati, è possibile recuperare spazio su disco da tutti i file registro numerato con la rimozione fino a, ma non incluso, il Registro di checkpoint.

    importante : non rimuovere il log del checkpoint.

    In questo esempio, è possibile rimuovere tutti i registri su E0002cc6.log.
  7. Questo passaggio è facoltativo. È possibile utilizzare l'utilità Esefile per verificare l'integrità a livello di pagina dei database copiati.

    Il file di Esefile.exe è disponibile nella cartella Support sul CD di Exchange Server 5.5 Service Pack 3, CD di installazione di Exchange 2000 Server o il CD di Exchange Server 2003. È inoltre possibile ottenere il file Esefile.exe dal servizio supporto tecnico clienti Microsoft. L'utilità di Esefile funziona per i file con estensione EDB da Exchange Server 5.0 e 5.5, Exchange 2000 ed Exchange 2003.

    Non è attualmente disponibile alcun metodo diverso da un backup in linea per verificare i checksum per ogni pagina di un file con estensione stm. Il file stm contiene dati non elaborati. Tutti gli indici e i puntatori organizzano che i dati sono nel file edb. Un problema nel file stm causa un client specifico perdita di dati, ma ciò non compromettere l'integrità di strutturali o logica del database come un intero.

    Per verificare i checksum di pagina per un database di Exchange, è necessario eseguire il comando di utilità Esefile riportato di seguito:
    Esefile /s database_name
    Di seguito è un esempio dell'output del comando precedente:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Pagine non inizializzate sono accettabili, ma in un database senza problemi, sono presenti checksum 0 e 0 numeri di pagina errati.

    Se un database non supera il controllo di integrità Esefile utilità, la soluzione migliore è ripristinare un backup precedente si è certi sia valida e per eseguire il rollforward del database. Per informazioni su come ripristinare o recuperare il database, se non è disponibile una copia di backup, consultare PSS.
  8. Questo passaggio è facoltativo. È possibile utilizzare il comando seguente per verificare l'integrità del backup dei file di registro:
    Eseutil /ml E0n
    Di seguito è un esempio dell'output del comando precedente:
    k:\backups>eseutil /ml E00
    							
    È necessario eseguire questo comando da una cartella che contiene il backup dei file di registro. È possibile eseguire questo comando per la cartella di registro corrente in esecuzione, ma se Eseutil tenta di leggere l'intestazione di E0n.log durante qualsiasi database del gruppo di archiviazione è in esecuzione, viene visualizzato un errore di-1032 (JET_errFileAccessDenied).

    Questo comando rileva un danneggiamento nei file di registro e si informa inoltre se un file di registro risulta manca all'interno di una sequenza o, in presenza di una mancata corrispondenza di firma tra i file di registro.

Ripristino di un backup non in linea di un database di Exchange

In questa sezione vengono descritti due metodi per ripristinare un backup non in linea:
  • Ripristino di "Punto nel tempo". Nessun file di registro vengono riprodotti nel database. Tutti i dati creati dopo il backup viene persa.
  • Ripristino "Rollforward". I file di registro sono stati creati dopo il backup vengono riprodotti nel database. Se tutti i file di registro sono disponibili, tutti i dati creati dopo il backup può essere salvati. Se è attivata la registrazione circolare, è necessario eseguire un ripristino "punto nel tempo" del backup non in linea non è possibile scegliere un ripristino "rollforward".
Il set di file che è possibile ripristinare è in necessario di soddisfare i seguenti criteri minimi:
  • Per punto nel tempo ripristini, tutti i database interrotto nel gruppo di archiviazione deve essere coerente ed è necessario un file di checkpoint valido. Non eliminare il file di checkpoint corrente o i file di registro esistenti.
  • Tutti i database nel gruppo di archiviazione deve essere arrestato e coerente per ripristini diretta di rollback, e dei file di registro creati dopo il momento in cui è stato eseguito il backup devono esistere tutti i (incluso il E0n.log corrente). Il file di checkpoint deve essere eliminato.
Se il set di file non soddisfa le condizioni precedenti, ripristino e la riproduzione non necessariamente riesca, ma è probabile che messaggio-1216 di errore (JET_errAttachedDatabaseMismatch) durante il ripristino software.

Gestione di un errore-1216

Recupero ulteriori misure di protezione causa in Exchange 2000 e versioni successive il-1216 errore di individuare il file di dati che sono stato modificati manualmente e determina che il ripristino in esecuzione con l'insieme corrente di dati potrebbe causare la perdita di in precedenza i dati esistenti.

Nelle versioni precedenti di Exchange, se il set di file non è completo, ma è valido per una corretta riproduzione, recupero Avvia senza ulteriore avviso all'amministratore. In Exchange 2000 e versioni successive, l'amministratore deve particolare eseguire l'override dell'errore-1216 utilizzando Eseutil.

Punto di ripristino di ora di un backup non in linea

Per eseguire un punto di ripristino di volta di un backup non in linea:
  1. Se il database che si desidera ripristinare attualmente è installato, disinstallato. Se qualsiasi altri database nel gruppo di archiviazione vengono disinstallati, dei tali database database e i file (con estensione edb e stm) di flusso ogni necessario coerente e corrispondenza. (Per verificare la coerenza e la corrispondente, vedere la sezione passaggio 2 in "Backing Up an Exchange Database Offline" di questo articolo.)

    Se tutti i database nel gruppo di archiviazione vengono disinstallati, tutti i database devono essere coerenti e un file di checkpoint valido deve essere presente anche. Un file di checkpoint valido è un file di checkpoint che è in uso all'ultima uno qualsiasi dei database nel gruppo di archiviazione sono stati in esecuzione, che dispone di un'intestazione contenente E0n.log come il checkpoint. Se qualsiasi database del gruppo di archiviazione è ancora installato, il file di checkpoint valido è il file di checkpoint viene attualmente utilizzato dal sistema. Se qualsiasi database nel gruppo di archiviazione è in esecuzione, sarà presente un checkpoint valido.

    Per verificare il file di checkpoint quando tutti i database vengono interrotti, eseguire i comandi seguenti:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Di seguito è un esempio dell'output dei comandi precedenti:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Nell'esempio precedente, il checkpoint è nel registro con il lGeneration di 0x2cc7, e00.log. Di conseguenza, il checkpoint può essere considerato valido.

    Se il checkpoint non è valido, si verificano un messaggio di errore-1216 (JET_errAttachedDatabaseMismatch) quando si tenta di installare qualsiasi database del gruppo di archiviazione. Questo problema può verificarsi anche nel se in cui tutti i database nel gruppo di archiviazione sono coerenti.
  2. Copiare il backup con estensione edb e stm flusso percorsi dei file e database appropriato. (Per trovare queste posizioni, vedere la sezione "Prima di iniziare" di questo articolo.) Verificare che i file ripristinati siano coerenti e corrispondenza.

    Nota : se copie dei file di database che si desidera ripristinare già esistono sul server, backup questi file prima di ripristinare il database, anche se i file esistenti non sono attivabili. Potrebbero essere ripristinabile, e potrebbe essere in grado di ai dati di recupero da essi utilizzando l'utilità Exmerge.
  3. Installare il database ripristinato. Il database stesso aggiunge alla fine del file E0n.log. Dopo il database di avvio, non è possibile riprodurre nessun file di registro esistente mai nel database. Database di cartelle pubbliche che contengono migliaia di cartelle nella gerarchia potrebbero richiedere parecchio tempo per l'avvio. Consente di almeno un minuto per ogni 1.000 cartelle nella gerarchia.

    Nelle versioni precedenti di Exchange Server, è in genere necessario eseguire il ISINTEG - patch comando dopo il ripristino di un backup non in linea di un database dell'archivio informazioni, per sincronizzare il database dell'archivio informazioni con la directory. Quando l'applicazione delle patch per un database di Exchange è necessario che l'applicazione di patch viene eseguita automaticamente dal sistema, a meno che il database non ripristinato in un altro server, gruppo di archiviazione, o oggetto di database logico o l'oggetto Active Directory per il database viene eliminato e ricreato in Active Directory. In questi casi, viene registrato il seguente messaggio di errore nel registro eventi applicazioni.
    Tipo evento: errore
    Origine evento: Archivio cassette postali MSExchangeIS
    Categoria evento: generale
    ID evento: 1087
    Data: 5/4/2001
    Ora: 8:33:42 PM
    Utente: N/d
    Computer: Exchange1
    Descrizione: La configurazione dell'archivio informazioni è stato ripristinato da un backup non in linea. In Gestore di sistema di Microsoft Exchange specificare che il database "First Storage Group\Private Information Store" può da ripristinare, in modo che possa essere corretto.
    Per risolvere il problema, è scegliere selezionare la casella di controllo database riscrivibile da un ripristino nel gestore di sistema di Exchange, nelle proprietà di database di oggetto di database.

Ripristinare ripristino avanti di un backup non in linea

Per la migliore possibilità di successo completa la riproduzione dei file di registro in un database ripristinato:
  • Conservare una copia di tutti i registri delle transazioni creati dopo l'ora del backup completo meno recente.
  • Non modificare un percorso di database senza apportare immediatamente in seguito un nuovo backup completo.
  • Non eseguire ESEUTIL /p o ESEUTIL /d senza eseguire immediatamente in seguito un nuovo backup completo.
  • Divieto di aggiungere o rimuovere un database in un gruppo di archiviazione senza apportare immediatamente un backup completo di tutti i database nel gruppo di archiviazione.
Per iniziare il processo di ripristino:
  1. Se il database che si desidera ripristinare è installato, disinstallare e quindi copiare i file database che si desidera ripristinare i percorsi appropriati sul server. Se copie dei file di database che si desidera ripristinare già esistono sul server, nuovamente queste copie di backup prima di ripristinare il database, anche se i file esistenti non sono attivabili. I file potrebbero essere ripristinabile ed è possibile utilizzare l'utilità ExMerge di recupero dati da essi.
  2. Disinstallare tutti i database nel gruppo di archiviazione e quindi eseguire il comando seguente in ogni database nel gruppo di archiviazione corrente e su ogni file di database ripristinato:
    eseutil /mh database_file_name | trovare /i "uniforme"
    Nota : Exchange 2000 Service Pack 2 e versioni successive non segnalare lo stato del database come "Coerenti" o "Incoerenti", ma come "Chiusura normale" o "Chiusura anomala." Il significato di "Chiusura normale" è lo stesso "Coerenti" e il significato di "Chiusura anomala" corrisponde a quello "Incoerenti". Per Exchange 2000 Service Pack 2 o versione successiva, eseguire questo comando aggiuntivo per determinare lo stato di ogni database:
    eseutil /mh nome_database | trovare /i "Arresto"
    Di seguito è un esempio dell'output del comando precedente:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    Questo comando ha tre scopi:
    • Per verificare che i file di database siano coerenti ogni.
    • Per verificare che i file edb e stm per ciascun database sono una coppia.
    • Per identificare i file registro ancoraggio minimo e massimo, i file registro e il cognome che sono necessari per ripristinare correttamente tutti i dati senza generare un errore-1216. Il valore minimo ultimo coerenza in tutti i database è il registro basso ancoraggio e il valore di coerenza ultimo più alto è il registro elevato di ancoraggio.
    Nell'esempio precedente, il file di log di ancoraggio basso è E0002ac8.log e il file di log di ancoraggio elevato è E0002cc7.log.
  3. Consente di verificare che la firma di registro che viene registrata in ciascuna intestazione di database sia la firma del registro basso ancoraggio. Eseguire i seguenti comandi:
    eseutil /mh database_name | trovare /i "Firma di registro"
    eseutil /ml low_anchor_log | trovare /i "Firma"
    Di seguito è un esempio dell'output del comando precedente:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Un file di registro potrebbe segnalare le firme diverse. Prima firma è sempre la firma del file di registro e le altre sono database che erano in esecuzione nel momento in cui è stato creato il file di registro. Nell'esempio precedente, le firme di registro che vengono registrate nel file di database sono uguali la firma di registro nel Registro di ancoraggio in basso.

    Se non si riesce a individuare il registro basso ancoraggio, è Impossibile riprodurre i registri in avanti in tale database. Se non è possibile trovare il file di registro basso ancoraggio, è Impossibile riprodurre qualsiasi file di registro in qualsiasi database. Esistono due metodi utilizzabili per gestire un registro basso ancoraggio mancante:
    • È possibile rimuovere tutti i file registro. Poiché i database sono tutte coerenti, è possibile avviare senza la presenza di eventuali file di registro, ma si perde qualsiasi possibilità al ripristino dei dati che non sia già nei file di database.
    • È possibile rimuovere i database con i valori coerenti ultimi più bassi, finché non sarà possibile costruire una serie di log continua da basso a elevato ancoraggi e quindi eseguire ripristino i database rimanenti. Quando si inserisce nuovamente i database rimossi nel gruppo di archiviazione, è Impossibile riprodurre dati aggiuntivi al loro interno.
  4. Verificare che i percorsi di percorso di database corrente siano gli stessi come erano al momento di apportate il backup.

    Sebbene sia possibile modificare il percorso del log delle transazioni o il lavoro percorso dopo aver apportato una copia di backup, è possibile eseguire solo riesecuzione del file di registro se i file di database sono nelle posizioni stesse in cui sono stati backup dal. Se non si conosce delle posizioni originali, è necessario eseguire il seguente comando:
    eseutil /ml "Last_Consistent"_log | trovare /i "database name or pattern"
    Di seguito è un esempio dell'output del comando precedente:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    Nota : se il registro basso ancoraggio è E0n00001.log, esso verrà non dispone di percorso informazioni nella relativa intestazione, perché l'intestazione per il primo log in una serie viene generato prima che il primo database mai è collegato il registro. In questo caso, è necessario visualizzare nell'intestazione del log successivo per visualizzare le informazioni di percorso del database. In rari casi, ciò potrebbe anche essere vero per i registri in un secondo momento oltre alla prima, perché un database è stato creato o collegato nel flusso di registro dopo il registro è stato creato.
  5. Raccogliere tutti i registri, di quanto Avanti possibile nella sequenza continua, il numero di ancoraggio bassa e copiare questi registri il percorso del log delle transazioni corrente. Non sovrascrivere i registri sono già presenti sul server senza il backup di questi registri per primo. Per effettuare questa operazione, è necessario ripristinare i file di registro da più di un tipo di supporto di backup.

    Nell'esempio precedente, l'ancoraggio basso è E0002ac8.log e l'ancoraggio elevato è E0002cc7.log. Quando si esaminano i registri disponibili, il registro numerato cifra più alta che è possibile trovare è in potrebbe essere di essere un numero inferiore rispetto al numero necessario (ad esempio, E0002cc6.log, anziché 2cc7). Ciò si verifica in genere perché il E0n.log non è stato compilato e rinominato il numero della sequenza. Per determinare se E0n.log è effettivamente il log di ancoraggio elevato, è necessario utilizzare il comando seguente per esaminare il valore lGeneration nell'intestazione del file registro:
    eseutil /ml E0n.log | trovare /i "lGeneration"
    Di seguito è un esempio dell'output del comando precedente:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Nota : per visualizzare l'intestazione di un file di registro con l'utilità Eseutil, utilizzare l'opzione /ml ; per visualizzare un'intestazione del file di database, utilizzare l'opzione /mh . Se si confondere i parametri, l'output dei comandi è errato.

    In genere, il registro elevato ancoraggio è anche il Registro di più alto disponibile, ma questo non è true se:
    • I file di registro sono stati distrutti in una situazione di emergenza.

      - oppure -
    • Si sta ripristinando tutti i database contemporaneamente in un gruppo di archiviazione.
    Nel primo caso, è probabile che si verifichino errori di-1216 durante il ripristino e nel secondo caso, è possibile riprodurre log file inoltrano, anche oltre il registro elevato di ancoraggio, purché continuano la sequenza lGeneration.
  6. Verificare che tutti i registri di condividere la stessa firma di registro e sono in sequenza continua. Eseguire il comando riportato di seguito:
    eseutil /ml E0n > nomefile.txt
    Di seguito è un esempio dell'output del comando precedente:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Questo comando Eseutil esegue tre operazioni: verifica di ciascun file di registro per danni, segnala eventuali gap nella sequenza dei file di registro e rileva la mancata corrispondenza di firma di registro.

    Tutte le firme di registro devono corrispondere tra tutti i file registro sono candidati di riproduzione. È necessario rimuovere tutti i registri che non dispongono di corrispondente firme prima di inizia la riproduzione.

    A questo punto, dopo aver rimosso i file che non hanno superato i test di verifica, il log delle transazioni solo i file nella cartella dei registri delle transazioni sono file che:
    • Sono in sequenza ininterrotta lGeneration, partire con il file di registro ancoraggio bassa e continuando fino a almeno il file registro ancoraggio ad alta e oltre che, se possibile.
    • Con corrispondenti di firme di registro.
  7. Se il registro elevato ancoraggio non è già denominato E0n.log, rinominarlo.
  8. Rimuovere il file E0n.chk dalla cartella percorso di sistema.

    In assenza di un file di checkpoint, Exchange Server si inizia a riprodurre i registri dal più basso numerato file di registro disponibile nella cartella dei registri delle transazioni: il registro basso ancoraggio. Se il file E0n.chk esiste, il server inizia riproduzione nel checkpoint registrato in questo file. Se E0n.chk punta oltre il registro basso ancoraggio, la riproduzione non riesce completamente per il set di file ripristinato. In molti casi, se si commette un errore con il file di checkpoint, è necessario avviare sul ripristino di file di database dal backup.
  9. Come un controllo finale prima di installare il gruppo di archiviazione, verificare che:
    • Tutti i file di database presenti nei relativi percorsi in esecuzione.
    • I file di registro solo nel percorso di registro delle transazioni in esecuzione sono file che iniziano dal registro basso ancoraggio e continuano almeno il registro elevato ancoraggio, con il più alto log disponibili denominato E0n.log.
    • Non esiste alcun file di E0n.chk nella cartella percorso di sistema.
    Dovrebbe essere in grado di installare il gruppo di archiviazione e di iniziare a riprodurre i registri delle transazioni con questo gruppo di file correttamente. Anche dopo aver al termine del ripristino e l'avvio del database, tutti i dati in tutti i file di registro può effettivamente essere recuperati causa dei problemi firma e il percorso DB che si verificano durante la riproduzione. La sezione "non Dealing con database firma e percorso corrisponde" di questo articolo fornisce informazioni aggiuntive su questi problemi.
  10. Se l'archivio informazioni non è già in esecuzione, avviarlo e quindi installare almeno un database nel gruppo di archiviazione. In questo modo recupero eseguire tutti i database nel gruppo di archiviazione.

    Nelle versioni precedenti di Exchange Server, è in genere necessario eseguire il ISINTEG - patch comando dopo il ripristino di un backup non in linea di un database dell'archivio informazioni, per sincronizzare il database con la directory. Quando l'applicazione delle patch per un database di Exchange è necessario che l'applicazione di patch viene eseguita automaticamente dal sistema, a meno che il database non ripristinato in un altro server, gruppo di archiviazione, o oggetto di database logico o l'oggetto Active Directory per il database viene eliminato e ricreato in Active Directory. In questi casi, viene registrato il seguente messaggio di errore nel registro eventi applicazioni.
    Tipo evento: errore
    Origine evento: Archivio cassette postali MSExchangeIS
    Categoria evento: generale
    ID evento: 1087
    Data: 5/4/2001
    Ora: 8:33:42 PM
    Utente: N/d
    Computer: Exchange1
    Descrizione: La configurazione dell'archivio informazioni è stato ripristinato da un backup non in linea. In Gestore di sistema di Microsoft Exchange specificare che il database "First Storage Group\Private Information Store" può da ripristinare, in modo che possa essere corretto.
    Per risolvere il problema, è scegliere selezionare la casella di controllo database riscrivibile da un ripristino nel gestore di sistema di Exchange, nelle proprietà di database di oggetto di database.
Controllare il registro eventi applicazioni nel Visualizzatore eventi Windows Microsoft eventuali errori o anomalie che potrebbero verificarsi quando si avvia il database. Per ciascun file registro è riprodotto viene visualizzato un evento 301. Controllare attentamente le errori e avvisi durante il processo di ripristino.

Gestione di database firma e il percorso non corrisponde

Database, quali i file di registro, con le proprie firme digitali. Ma, sebbene le firme di registro non si modificano dopo l'ora che viene creato il file E0n000001.log, le firme di database modificare ogni volta che viene modificata la topologia fisica del database, senza le modifiche analizzate attraverso i file di registro. Deframmentazione non in linea o di ripristino di un database con Eseutil modificata la firma di DB. Dopo un evento può essere collegato al database stesso flusso di registro come prima, ma il database non accetta la riproduzione di tutte le transazioni eseguite mentre il database la firma precedente. Una copia precedente del database non accetta la riproduzione di qualsiasi transazione di cui è stata eseguita dopo la modifica di firma del database.

Poiché le firme di database vengono reimpostate in questo modo, si consiglia eseguire il backup completo del database immediatamente dopo la deframmentazione non in linea o di ripristino di un database. Se si ripristina una copia del database con la firma precedente in un secondo momento, riproduzione ha esito positivo fino al punto di modifica della firma, ma si perderanno tutte le modifiche oltre tale punto.

I percorsi dei database vengono modificati all'interno di un flusso di registro, l'effetto è simile a quello di modificare le firme: riproduzione viene interrotta al momento della modifica. (L'API di backup in linea fornisce una funzionalità per riassociare i percorsi durante il ripristino; di conseguenza, l'API di backup in linea può di riprodurre i registri completamente, anche se un percorso è modificato poiché è stato eseguito il backup).

Come firma DB o DB problemi di percorso sono durante riproduzione, tali DB firma o percorso del database nel registro eventi dell'applicazione in linea con gli eventi di 301 riproduzione per ciascun file registro vengono visualizzati problemi. I file di registro oltre il punto del problema sembra di riprodurre correttamente, ma questo è solo perché non viene registrato più volte lo stesso avviso mancata corrispondenza. Come regola generale, la riproduzione in un particolare database viene troncata dal punto in cui viene rilevato il primo errore di firma o il percorso DB fa riferimento a tale database.

Proprietà

Identificativo articolo: 296788 - Ultima modifica: lunedì 3 dicembre 2007 - Revisione: 4.8
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Chiavi: 
kbmt kbproductlink kberrmsg kbhowto KB296788 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 296788
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com