Backup dei dati di Exchange Server 2003 e i servizi copia shadow del volume

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

In questa pagina

Sommario

Per creare applicazioni che backup e ripristino di Microsoft Exchange Server 2003 Ŕ possibile utilizzare la funzionalitÓ di servizio Copia Shadow del volume in Microsoft Windows Server 2003. Il servizio di copia shadow (VSS) di Windows Volume fornisce un'infrastruttura che consente di programmi di gestione archiviazione di terze parti, programmi aziendali e provider hardware per cooperare creazione e gestione di copie shadow. Soluzioni basate su questa infrastruttura possono utilizzare le copie shadow (o copie con mirroring) per eseguire il backup e ripristinare uno o pi¨ database di Exchange Server 2003.

Il servizio Copia Shadow del volume coordina la comunicazione tra i richiedenti (le applicazioni di backup), il writer (applicazioni in servizi di Windows come Exchange Server 2003 e SQL Server 2000) e provider (sistema, componenti software o hardware che crea le copie shadow). Per utilizzare la funzionalitÓ servizio di copia shadow del volume per backup di Exchange Server 2003, Ŕ necessario che il programma di backup includere un richiedente di servizio Copia Shadow del volume grado di riconoscere Exchange Server 2003. PoichÚ il programma di backup viene fornito con Windows Server non dispone di nessun tali richiedente, Ŕ necessario che le organizzazioni utilizzare applicazioni di terze parti backup.

Per essere compatibile con Exchange Server 2003, le applicazioni di backup VSS basati devono procedere tre requisiti di base per garantire l'integritÓ e la recuperabilitÓ dei backup della copia replicata. Se questi requisiti non sono seguiti, Product Support Services (PSS) prenderÓ in considerazione la soluzione di backup per essere di fuori del framework VSS di Exchange e verrÓ non essere in grado di risolvere i problemi di backup e ripristino di problemi. I clienti devono verificare con fornitori backup che l'applicazione di backup soddisfi i requisiti di compatibile con Exchange indicati in questo articolo della Knowledge Base. Nella sezione "Informazioni" di questo articolo vengono presentati dettagli i requisiti di Exchange VSS.

Come con qualsiasi soluzione di terze parti, il fornitore dell'applicazione di backup Ŕ il provider di servizio di supporto relativi al backup e ripristino. PSS consentono di diagnosticare o analizzare i problemi relativi al database disponibili e il set di file registro delle transazioni. Tuttavia, Microsoft non risoluzione dei problemi o debug prodotti di terze parti. Assistenza PSS Ŕ limitato a informazioni su come meglio continuare a ripristinare il database disponibili e i file di registro delle transazioni.

Per ulteriori informazioni sulle modalitÓ soluzioni VSS in base supportate dal servizio supporto tecnico clienti Microsoft, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
841696Cenni preliminari le soluzioni software di archiviazione di terze parti Microsoft support policy

Informazioni

Nell'elenco seguente vengono descritti il backup di Exchange Server 2003 con processo del servizio Copia Shadow del volume:

  1. Un processo pianificato viene eseguito il programma backup (o agente).
  2. Il servizio Copia Shadow del volume richiedente nel programma di backup invia un comando al servizio Copia Shadow del volume da una copia shadow dei gruppi di archiviazione di Exchange Server 2003 selezionati.
  3. Servizio copia shadow del volume comunica con il server di Exchange 2003 scrittura per preparare un backup snapshot.
  4. Servizio copia shadow del volume comunica con il provider di archiviazione appropriato per creare una copia shadow del volume di archiviazione o i volumi di archiviazione che contengono il gruppo di archiviazione di Exchange Server 2003 o gruppi di archiviazione.
  5. Servizio copia shadow del volume rilascia per riprendere le normali operazioni di Exchange Server 2003.
  6. Il servizio Copia Shadow del volume richiedente verifica l'integritÓ del set di backup prima di informare Exchange il backup completato.
Ad esempio, quando una richiesta di copia shadow viene ricevuta da un programma backup di Exchange Server 2003 con servizio Copia Shadow del volume (un richiedente) di supporto, copia shadow del volume servizio comunica con il server di Exchange 2003 scrittura per prepararsi a questo punto lo snapshot, Exchange Server 2003 impedisce azioni amministrative per il gruppo di archiviazione, verifica le dipendenze di volume e sospende tutti scrivere le operazioni di database e i file log transazione consentendo l'accesso in sola lettura. Servizio copia shadow del volume comunica quindi con il provider di archiviazione appropriato per avviare il processo di copia shadow per i volumi del disco contenenti i dati di Exchange Server 2003. La copia shadow in genere richiede alcuni secondi che saranno quasi impercettibile tutte per l'utente finale. Quando la copia shadow Ŕ stata acquisita, servizio Copia Shadow del volume comunica con il writer di Exchange Server 2003 che Exchange consente di riprendere le operazioni normali. Programma di backup verifica lo stato della copia shadow prima per informare Exchange il backup completato. Alla fine di un esito positivo Exchange backup tronca i registri e registra il tempo dell'ultimo backup per il database o un database.

Per ulteriori informazioni sul backup di Exchange Server 2003 con i servizi copia shadow del volume, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
842066WebCast di TechNet: Copia shadow del volume per Exchange Server 2003

Di seguito sono elencati i requisiti di Exchange Server 2003 che le applicazioni di backup copia shadow devono seguire per garantire l'integritÓ e la recuperabilitÓ dei database di Exchange:

Nell'elenco riportato di seguito sono i registri eventi applicazioni specifici che identificano se i requisiti di Exchange sono in seguito. Le applicazioni di backup e il server Exchange possono accedere gli altri eventi associati al processo di backup e ripristino. Confermare che sono registrati i seguenti eventi durante il backup e ripristino fungerÓ dalla verifica della conformitÓ ai requisiti di Exchange VSS. Attualmente non Ŕ Nessun programma di certificazione per qualsiasi soluzione software di terze parti in esecuzione su Exchange. ConformitÓ garantisce l'integritÓ e recuperabilitÓ dei backup della copia shadow, ma non rende nessuna garanzia sui prestazioni o all'affidabilitÓ della soluzione di terze parti.
  1. Il backup dei file di checkpoint e il database di Exchange, log delle transazioni devono essere eseguiti esclusivamente tramite il writer di Exchange:

    I seguenti eventi dell'applicazione verranno registrati se il writer di Exchange viene inizializzato durante il backup della copia shadow.

    Tipo evento: informazioni
    Origine evento: ESE
    Categoria evento: ShadowCopy
    ID evento: 2005
    Data: 17/6/2004
    Ora: 11:40:41 AM
    Utente: N/d
    Computer: EXCHSERVER
    Descrizione: Copia shadow dell'archivio informazioni (2180) istanza 3 avvio. Questo sarÓ il tipo di backup ? ? * shadow di copia.

    * Dove ? tipo backup ? Ŕ il tipo di backup eseguito (completo, copia, incrementale o differenziale).

    Tipo evento: informazioni
    Origine evento: MSExchangeIS
    Categoria evento: Exchange VSS Writer
    ID evento: 9608
    Data: 17/6/2004
    Ora: 11:40:42 AM
    Utente: N/d
    Computer: EXCHSERVER
    Descrizione: Exchange VSS Snapshot preparazione per l'istantanea completata.

    Tipo evento: informazioni
    Origine evento: MSExchangeIS
    Categoria evento: Exchange VSS Writer
    ID evento: 9610
    Data: 17/6/2004
    Ora: 11:40:43 AM
    Utente: N/d
    Computer: EXCHSERVER
    Descrizione: Exchange VSS Snapshot ha bloccato i gruppi di archiviazione completata.

    Tipo evento: informazioni
    Origine evento: MSExchangeIS
    Categoria evento: Exchange VSS Writer
    ID evento: 9612
    Data: 17/6/2004
    Ora: 11:40:44 AM
    Utente: N/d
    Computer: EXCHSERVER
    Descrizione: Sblocco Exchange VSS Snapshot ha gruppi di da parte archiviazione completata.

  2. L'applicazione di backup deve convalidare l'integritÓ del set di backup copia shadow.

    Microsoft consiglia, ma non richiede, che ci˛ prima che l'applicazione di backup si comunica in Exchange che il backup Ŕ stata completata. La causa per questo consiglio Ŕ che Exchange esegue due operazioni importanti dopo un backup corretto:
    • Exchange aggiorna le intestazioni dei database di backup per riflettere l'ora ultimo backup riuscito
    • Exchange rimuove il server che non sono pi¨ necessari per eseguire il rollforward dall'ultimo backup corretto (? Elimina ?) registri delle transazioni.
    Se un'applicazione di backup pospone Verifica integritÓ fino a quando non dopo queste operazioni completate, quindi speciale necessario prestare attenzione per mantenere l'ultimo backup verificato insieme con copie di tutti i file di registro richiesti da tale backup. Sebbene il backup potrebbe sono giÓ stato segnalato come esito positivo a Exchange, il backup deve essere non essere recuperavano finchÚ non viene effettivamente l'applicazione di backup completata verifica dell'integritÓ.

    Fare riferimento a "Come per eseguire verifica di integritÓ per i backup VSS" sezione di questo articolo per informazioni dettagliate sul come eseguire i controlli di integritÓ e come determinare quale database e i file di registro delle transazioni deve essere salvato fino al completamento verifica dell'integritÓ.
  3. Ripristina al percorso originale ** deve essere eseguita esclusivamente con il writer di Exchange

    Exchange writer registrerÓ seguenti eventi nel registro eventi applicazioni nel registro durante un processo di ripristino copia shadow.

    Tipo evento: informazioni
    Origine evento: MSExchangeIS
    Categoria evento: Exchange VSS Writer
    ID evento: 9620
    Data: 17/6/2004
    Ora: 1:49:59 PM
    Utente: N/d
    Computer: EXCHSERVER
    Descrizione: Exchange VSS Snapshot ha elaborato pre-ripristino correttamente eventi

    Tipo evento: informazioni
    Origine evento: MSExchangeIS
    Categoria evento: Exchange VSS Writer
    ID evento: 9618
    Data: 17/6/2004
    Ora: 1:59:46 PM
    Utente: N/d
    Computer: EXCHSERVER
    Descrizione: Exchange VSS Snapshot ha elaborato post-ripristino correttamente eventi

** "Posizione originale" significa che un computer di Exchange con lo stesso nome di server e lo stesso percorso file del computer di Exchange in cui Ŕ stato eseguito il backup VSS.

Ripristini in posizioni alternative non Ŕ possibile ottenere tramite il writer di Exchange di Exchange Server 2003 SP1. Applicazioni di backup VSS basati possono scegliere di fornire manuale o altri metodi per ripristinare una posizione alternativa copie shadow dei database di Exchange a livello di programmazione.

Come eseguire la verifica dell'integritÓ per i backup VSS

Se utilizzando il flusso di API di backup di Exchange Ŕ dotato di un database, ogni pagina nel database viene letto a sua volta, e l'integritÓ del checksum di ogni pagina viene verificata durante il processo di backup. L'integritÓ del checksum dei file di registro delle transazioni viene inoltre verificata prima il backup.

Durante un backup VSS, non ha alcuna possibilitÓ per Exchange per leggere ogni file di database nel suo complesso e per verificare l'integritÓ del checksum. Di conseguenza, Ŕ necessario verificare l'integritÓ delle transazioni e database del file di registro dall'applicazione di backup. A tale scopo eseguire Eseutil, come descritto alla fine di questo documento.

Se si non checksum-verificano i backup VSS, Ŕ possibile che una pagina danneggiata pu˛ rimanere non rilevata nel database e infine diventano presente in tutti i backup esistenti. L'unico modo per ripristinare questa circostanza Ŕ riparare il database. Ripristino del database richiederÓ ampio tempi di inattivitÓ e conseguenza almeno una perdita di dati (almeno la perdita dei dati che era nelle pagine danneggiate).

Tuttavia, se l'ultimo backup VSS Ŕ stata verificata per contenere tutte le pagine buona, Ŕ possibile eliminare pagine danneggiate dal database ripristino verificato e in sequenza, avanti con i log delle transazioni creati dopo il backup. I tempi di inattivitÓ necessari per eseguire questa operazione sarÓ generalmente molto pi¨ breve per un ripristino del database e questo metodo di ripristino Ŕ in possibile di correggere i problemi di database con zero perdita di dati.

Di conseguenza, non Ŕ necessario considerare un backup VSS per essere utile fino a quando non tutti i file sono stati verificati di checksum.

╚ necessario seguono le due regole sotto per Verifica integritÓ backup:
  • Per i file di database: ╚ necessario mantenere sempre una copia integritÓ verificata i file di database disponibili. Un backup di integritÓ verificata Ŕ uno in quale pagina Ŕ stata completata verifica del checksum nel file del database contenuti nel set di backup.
Un database di backup recente non ha ancora superato la verifica del checksum non pu˛ essere considerato un backup valido. ╚ necessario annullare un precedente backup verifica non fino a quando non Ŕ stata verificata l'integritÓ del backup corrente.
  • Per i file di registro delle transazioni: transazione tutti i log necessari per ripristinare l'ultimo backup del database di integritÓ verificata necessario anche eseguire il backup di file e anche verificare l'integritÓ a livello di checksum.
Questi registri delle transazioni includono minimo dell'intervallo inclusivo dei file di registro elencato nel campo Log Required nell'intestazione di ogni database di verificato l'ultimo backup di. Se i file di registro non sono disponibili, il database non sarÓ installabile dopo il ripristino.

importante Questo requisito si applica all'ultimo backup integritÓ verificata, non di backup eseguita pi¨ di recente. Fino a quando il backup pi¨ recente ha superato la verifica del checksum, non viene considerato come un backup valido.

Facoltativamente, Ŕ inoltre potrebbe conservare i registri aggiuntivi necessari per ripristinare completamente del database dopo il ripristino di un backup di database. Questi sono tutti i file di registro delle transazioni in sequenza continua a partire dal pi¨ basso registro necessaria fino al log delle transazioni creato pi¨ di recente che sono stati eliminati dal server di Exchange. Di seguito vengono fornite esempi dettagliati e le spiegazioni ci˛ significa.

Conservazione dei registri delle transazioni oltre quelli elencati nel Registro di intervalli richiesto sono facoltativo, nel senso che ci˛ pertanto non Ŕ strettamente necessario per correttamente ripristinare e installare una copia di backup di database. Tuttavia, se non si mantengono tutti questi registri, quindi il ripristino da backup causerÓ perdita tutte le modifiche nel database di oltre il punto di backup. Si consiglia di non solo salvaguardare registri delle transazioni necessari per ripristinare e installare una copia di backup di database, ma tutti anche i successivi registri delle transazioni necessari per eseguire il rollforward del database fino senza perdita di dati.

Determinare quali file di registro delle transazioni sono necessari

Se un database di Exchange viene eseguito il backup mentre Ŕ in linea, file di log almeno una delle transazioni verrÓ eseguito sempre il backup con esso. Questo Ŕ anche se Ŕ possibile utilizzare il backup di flusso API o l'API di backup VSS.

Dopo il ripristino di un backup, informazioni in linea la transazione log devono essere applicati al database ("ripetuti") prima il database sarÓ installabile nuovamente. Campo Log Required del ogni intestazione di database registra i numeri di sequenza (generazione) dell'intervallo di file di registro delle transazioni deve essere riprodotti nel database.

Se il campo Log Required legge 0-0, questo significa che il database Ŕ installabile senza dover riprodurre i dati di registro delle transazioni aggiuntivi. L'unico caso in cui sarÓ il valore di registro obbligatorio di 0-0 Ŕ una volta importato un database in uno stato di chiusura normale. Durante l'esecuzione di un database, il campo Log Required registra sempre l'intervallo di log delle transazioni che non sono ancora stati applicati al database. Questo intervallo viene aggiornato continuamente.

Un database di backup in linea avrÓ sempre un intervallo di registro obbligatorio diverso da zero e il backup di questi registri devono essere eseguiti con il database. Se, dopo il ripristino, i registri non sono disponibili, Ŕ possibile che il database non Ŕ installabile. (╚ possibile ripristinare il database se Impossibile trovare i registri necessari, ma non esiste alcuna garanzia che ripristino avrÓ esito positivo, e ripristino conseguenza quasi sempre un livello di perdita di dati, anche se solo i dati in cui la parentesi mancante si connette.)

Se si utilizza il flusso di API di backup o l'API di backup VSS all'interno di Exchange VSS writer di Exchange, quindi necessari file di registro necessari per installare un database verranno eseguito il backup automaticamente con il database. Se Ŕ riprodurre solo i file di registro obbligatorio, verrÓ creato nel database ripristinato fino al punto nel tempo in cui il backup completato. Se si desidera eseguire il rollforward passato diretta di database che fanno riferimento, Ŕ inoltre necessario riprodurre i file di registro generati dopo che Ŕ stato eseguito il backup.

Per ripristinare completamente del database da qualsiasi particolare backup, Ŕ necessario conservare tutti i file registro in sequenza continua a partire dal Registro minimo dell'intervallo di registro necessario backup il file di log generato pi¨ di recente in gruppo di archiviazione del database. Se qualsiasi log in questa serie Ŕ mancante o danneggiato, sarÓ solo possibile eseguire il rollforward fino al punto dell'ultimo log buona prima del file manca o danneggiato.

Di conseguenza, se si desidera ripristinare da backup senza perdita di dati, Ŕ essenziale che mantenere una buona copie di tutti i file di registro delle transazioni Avanti si passa da ultimo backup di database appropriata in fase di verifica.

Eliminazione di log delle transazioni

Se i registri delle transazioni non vengono rimosse da un server di Exchange, continueranno ad accumulare fino a quando completare tutto lo spazio disponibile sul disco. Di conseguenza, flusso e backup VSS API supportano "eliminazione" dei file di registro delle transazioni dopo il completamento di un backup normale o incrementale. File di registro meno recenti rispetto a quelli necessari per ripristinare il backup pi¨ recente vengono automaticamente eliminati dal server dopo che il backup di Exchange i segnali di applicazioni di backup completata.

Con l'API di flusso, verifica del checksum del database viene eseguita durante il processo di backup. Nel momento in che completa di una copia di backup, l'intero database e i file necessari registro sono stati verificati per l'integritÓ fisica. Con l'API VSS, verifica del checksum non pu˛ essere eseguita come parte del processo di backup effettivo. Il fornitore Ŕ in deve di verificare l'integritÓ fisica del database in modo indipendente del processo di backup. Questo pu˛ avvenire con Eseutil prima o dopo la segnalazione di Exchange che il backup Ŕ stata completata.

Se verifica del checksum viene eseguita prima di completamento del backup e viene rilevato un problema nel set di backup, quindi Exchange pu˛ essere informati che il backup non Ŕ riuscito. In questo modo si impedirÓ Exchange da un file di registro eliminazione dal server.

Se la verifica del checksum Ŕ posticipata fino a quando non dopo la segnalazione di completamento del backup, Exchange eliminerÓ vecchi file di registro dal server. Alcuni di questi file registro potrebbe essere stato necessario per il rollforward da un precedente backup valido. Se non sono giÓ state copie di questi registri, quindi non sarÓ possibile eseguire il rollforward completamente.

Pertanto Microsoft consiglia, ma non Ŕ necessario, verifica del checksum eseguire su una copia di backup VSS prima che l'applicazione di backup segnala il completamento di backup di Exchange. Se la verifica del checksum Ŕ posticipata fino a quando non dopo che il backup Ŕ giÓ stata completata, quindi l'applicazione di backup deve assicurarsi che le copie vengano apportate di tutti i file registro delle transazioni che sono stati eliminati dal server, a meno che non rollforward completamente non Ŕ importante.

Nella maggior parte dei casi, tutti i registri delle transazioni necessari per ripristinare una copia di backup VSS saranno disponibile nel set di file registro salvato con il backup precedente con quelli salvati con il backup corrente. Tuttavia, i clienti devono verificare che ci˛ avviene quando si considera un fornitore specifico.

Ripristino dei backup non verificati

Potrebbero verificarsi casi in cui un problema grave che richiede il ripristino si verifica prima del completamento verifica del checksum su un backup recente. In questi casi, si consiglia ripristinare un precedente backup verificato e di ripristinare tale backup avanti anzichÚ componente in un backup non verificato.

Tuttavia, Ŕ necessario service level Agreement Ŕ necessario ripristinare i dati pi¨ rapidamente rispetto possono essere eseguite dal precedente copia di backup. In questi casi, l'utente ripristino di backup non verificato pu˛ essere un'opzione migliore, purchÚ mantenere comunque verificata una precedente, backup e di tutti i file registro necessari per eseguire il rollforward completamente da esso. Se si soddisfa questi requisiti, quindi sarÓ ancora possibile eseguire il rollforward da un backup noto valido nel caso dell'ultimo backup viene rilevato come non valido.

Come verificare la coerenza dello snapshot

Richiedente VSS Ŕ necessario verificare la coerenza dello snapshot eseguendo Eseutil.exe con i file di database e di log utilizzando le opzioni appropriate, come nella tabella seguente. Richiedente VSS deve verificare che tutti i uscita ERRORLEVELs restituiti siano non negativo. Per visualizzare il valore ERRORLEVEL nella riga di comando, Ŕ necessario digitare echo % errorlevel % Eseutil.exe termine dell'esecuzione. Un negativo ERRORLEVEL significa che i file danneggiati. Prima di richiedente VSS chiama BackupComplete , richiedente VSS necessario assicurarsi che lo stato di backup del componente nel documento dei componenti di backup corrisponde il risultato della verifica di coerenza. Lo stato del componente di backup deve essere FALSE se viene rilevato un errore e deve essere TRUE se non viene trovato alcun danneggiamento. Verifica della coerenza di snapshot Ŕ un requisito obbligatorio per la soluzione a essere supportate dal team di Exchange.

Nella tabella seguente vengono illustrati la combinazione di controlli di integritÓ per ogni tipo di backup.
Riduci questa tabellaEspandi questa tabella
tipo di file \ tipo backup backup completo copia di backup backup incrementale backup differenziale
file edb "eseutil /k /i ?"eseutil /k /i"NDND
log "eseutil /k" *"eseutil /k" *"eseutil /k" **"eseutil /k" **
.stmNDNDNDND
.chkNDNDNDND

Natura snap-in dei backup VSS, JET non riceve l'opportunitÓ di touch tutte le pagine per eseguire i controlli di coerenza necessarie. Di conseguenza, spetta del richiedente VSS per garantire la coerenza dello snapshot.

* Tutti i file di registro con numero di generazione di file di registro o uguale a quella del file di registro del checkpoint sono necessari per ripristinare un database di snapshot. Se esiste il corrente file di registro (Enn.log) inoltre Ŕ necessario per il ripristino del database. Se uno dei file di registro necessari non viene superato la verifica della coerenza, Ŕ necessario richiedente assicurarsi di che lo stato del componente backup Ŕ impostato su FALSE prima di chiamata BackupComplete . Per determinare il file di log del checkpoint, eseguire eseutil.exe il file del checkpoint di snapshot e analizzare l'output per "checkpoint:", ad esempio, "c:\eseutil.exe /mk E01.chk" viene illustrato quanto segue:
Checkpoint:  (0x20,9D,187)
dove 0 x 20 Ŕ il numero di generazione di log del file di log del checkpoint.

In questo esempio, qualsiasi log file, inclusi E0100020.log e sopra, deve essere non danneggiata per ripristinare il database di snapshot, anche se il database Ŕ giÓ trascorsa la verifica della coerenza fisica.

** Tutti i file di registro in un incrementale o differenziale set di backup sono necessari per il ripristino del database. Coerenza di una sequenza di intero log pu˛ essere controllato eseguendo eseutil con il prefisso del file di registro. Ad esempio, ? eseutil /k E01 ? eseguirÓ verifiche della coerenza su tutti i file del modulo E01xxxxx.log un determinato percorso.

ProprietÓ

Identificativo articolo: 822896 - Ultima modifica: lunedý 3 dicembre 2007 - Revisione: 7.6
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Editionáalle seguenti piattaforme
    • Microsoft Windows Server 2003, 64-Bit Datacenter Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Chiavi:á
kbmt kbtshoot KB822896 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: 822896
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