prestazioni e procedure consigliate per la migrazione della posta elettronica di Microsoft 365 e Office 365

Esistono molti percorsi per eseguire la migrazione dei dati di posta elettronica per un'organizzazione ospitata in locale a Microsoft 365 o Office 365. Quando si pianifica una migrazione a Microsoft 365 o Office 365, una chiara comprensione del processo e della velocità di migrazione dei dati aiuta gli amministratori a pianificare meglio.

Panoramica della migrazione della posta elettronica a Microsoft 365 o Office 365

Microsoft 365 o Office 365 supporta diversi metodi per eseguire la migrazione dei dati di posta elettronica, calendario e contatto dall'ambiente di messaggistica esistente a Microsoft 365 o Office 365 come descritto in Come eseguire la migrazione di più account di posta elettronica a Microsoft 365 o Office 365.

Per domande relative alla rete e alle prestazioni in Microsoft 365 o Office 365, vedere Pianificazione della rete e ottimizzazione delle prestazioni per Microsoft 365 o Office 365.

Metodi di migrazione più frequenti

Metodo di migrazione	Descrizione	Risorse
Migrazione IMAP (Internet Message Access Protocol)	È possibile usare l'interfaccia di amministrazione di Exchange o Exchange Online PowerShell per eseguire la migrazione del contenuto delle cassette postali degli utenti da un sistema di messaggistica IMAP alle cassette postali di Microsoft 365 o Office 365. Ciò include la migrazione delle cassette postali da altri servizi di posta elettronica ospitati, ad esempio Gmail o Yahoo Mail. Si noti che Exchange Online offre ora un processo altamente specializzato in Modern EAC per la migrazione dei messaggi di posta elettronica da un'organizzazione esistente di distribuzione Gmail/G Suite/Google WorkSpace (GWS) a Exchange Online.	Eseguire la migrazione delle cassette postali IMAP a Microsoft 365 o Office 365
Migrazione completa	Usare la migrazione completa per eseguire la migrazione di tutte le cassette postali locali a Microsoft 365 o Office 365 in pochi giorni. Usare la migrazione completa se si prevede di spostare l'intera organizzazione di posta elettronica in Microsoft 365 o Office 365 e gestire gli account utente in Microsoft 365 o Office 365. È possibile eseguire la migrazione di un massimo di 2.000 cassette postali dall'organizzazione di Exchange locale a Microsoft 365 o Office 365 usando una migrazione completa. Il numero consigliato di cassette postali, tuttavia, è 150. È probabile che le prestazioni diminuiscano con numeri superiori. Viene eseguita la migrazione anche dei contatti di posta e dei gruppi di distribuzione dell'organizzazione di Exchange locale.	Migrazione completa a Microsoft 365 o Office 365
Migrazione a fasi	Usare la migrazione a fasi se si prevede di eseguire la migrazione finale di tutte le cassette postali dell'organizzazione a Microsoft 365 o Office 365, nel tempo. Usando una migrazione a fasi, si esegue la migrazione di batch di cassette postali locali a Microsoft 365 o Office 365 nel corso di alcune settimane o mesi.	Informazioni su una migrazione temporanea della posta elettronica a Microsoft 365 o Office 365
Distribuzione ibrida	La distribuzione ibrida offre alle organizzazioni la possibilità di estendere al cloud l'esperienza ricca di funzionalità e il controllo amministrativo che hanno con l'organizzazione exchange locale esistente. Una distribuzione ibrida offre l'aspetto semplice di una singola organizzazione di Exchange tra un'organizzazione di Exchange locale e Exchange Online in Microsoft 365 o Office 365. Inoltre, una distribuzione ibrida può fungere da passaggio intermedio per passare completamente a un'organizzazione di Microsoft 365 o Office 365.	Microsoft 365 e Office 365 Mail Migration Advisor Distribuzioni ibride di Exchange Server Mail Migration Advisor Exchange Deployment Assistant per Exchange locale 2013/2016/2019 distribuzioni ibride di Exchange Server 2013 Configurazione ibrida completa o minima.
Migrazione di terze parti	Ci sono molti strumenti disponibili da terzi. Usano protocolli e approcci distintivi per eseguire migrazioni di posta elettronica da piattaforme di posta elettronica come GWS, GoDaddy, Yahoo, IBM Lotus Notes e Novell GroupWise.	Di seguito sono elencati alcuni strumenti di migrazione di terze parti e partner che forniscono assistenza per migrazioni di Exchange da piattaforme di terze parti: Albero / binarioQuest / QuadroTech: Binary Tree e QuadroTech fanno ora parte di Quest. Quest è un provider di software di coesistenza e migrazione di messaggistica multipiattaforma, con prodotti per l'analisi, la coesistenza e la migrazione tra più piattaforme per Exchange Online. Le soluzioni Quest sincronizzano cassette postali, cartelle pubbliche e informazioni sul calendario mantenendo la coesistenza durante la migrazione. BitTitan: offre una soluzione automatizzata per le migrazioni a Microsoft 365 o Office 365 da un'ampia gamma di piattaforme. CodeTwo: provider di soluzioni di migrazione di Microsoft 365 e Office 365 per migrazioni di dati sicure e automatizzate a Microsoft 365 (Office 365) da Exchange On-Prem, server IMAP e tra tenant di Microsoft 365. Transvault: provider di soluzioni di migrazione di Cloud Office a Microsoft 365 da Exchange e Note. Transvault supporta decine di origini per la migrazione e offre prodotti che offrono qualsiasi dimensione di progetto, complesse migrazioni degli archivi di posta elettronica e gestione PST. Le soluzioni di migrazione aziendali sono sicure, conformi, efficienti e incentrate sull'utente e possono essere eseguite sia in locale che nel cloud. SkyKick: provider di soluzioni di migrazione automatizzata per passare da più tipi di origine a Microsoft 365 o Office 365. Gli strumenti di migrazione completi aiutano i partner nelle fasi di vendita, pianificazione, migrazione, gestione e operazioni in sede del progetto di migrazione. BCC: aiutare le aziende sostenendo la strategia di migrazione della collaborazione. Il miglior fornitore di strumenti di migrazione basati sulla piattaforma Domino, per la migrazione a Microsoft Exchange, Microsoft 365 e Office 365.

Prestazioni per i metodi di migrazione

Le sezioni seguenti confrontano i carichi di lavoro di migrazione delle cassette postali e i risultati delle prestazioni osservati per i diversi metodi di migrazione per la migrazione di cassette postali e dati delle cassette postali a Microsoft 365 o Office 365. Questi risultati si basano sui test interni e sulle migrazioni effettive dei clienti a Microsoft 365 o Office 365.

Importante

A causa delle differenze nel modo in cui vengono eseguite le migrazioni e quando vengono eseguite, la velocità effettiva della migrazione può variare.

Carichi di lavoro di migrazione dei clienti

Nella tabella seguente vengono descritti i diversi carichi di lavoro coinvolti in una migrazione tipica e le sfide e le opzioni per ognuno di essi.

Carico di lavoro	Note
Onboarding (migrazione a Microsoft 365 o Office 365)	Microsoft offre funzionalità e strumenti di migrazione dei dati che i clienti possono usare per eseguire la migrazione dei dati da Exchange Server locale (tramite Cutover/Staged/Hybrid) o da Gmail/S Suite/GWS alias Google Work Space (tramite EAC, PowerShell) o da altre origini IMAP (PowerShell, Gmail tramite IMAP) o migrazioni tra tenant a Exchange Online in Microsoft 365 o Office 365.
Multi-Geo	Le aziende multinazionali con uffici in tutto il mondo hanno spesso la necessità di archiviare i dati dei dipendenti inattivi in aree specifiche, per soddisfare i requisiti di residenza dei dati. Multi-Geo consente a una singola organizzazione di Microsoft 365 o Office 365 di estendersi in più aree geografiche (aree geografiche) di Microsoft 365 o Office 365 data center, che consente di archiviare i dati di Exchange, inattivi, per utente, nelle aree geografiche selezionate. Per altri dettagli, vedere Ottenere controlli della posizione dei dati globali di livello aziendale con Multi-Geo.
Crittografia	Crittografia del servizio con chiave del cliente è una funzionalità che consente a un cliente di effettuare il provisioning e gestire le chiavi radice usate per crittografare i dati inattivi a livello di applicazione in Microsoft 365 o Office 365. Per la prima volta che una cassetta postale viene crittografata, è necessario uno spostamento della cassetta postale. Per altre informazioni, vedere Crittografia del servizio con la chiave del cliente Microsoft Purview.
GoLocal	Microsoft continua ad aprire nuovi data center in nuove aree geografiche o aree geografiche. I clienti esistenti, quando idonei, possono richiedere di spostare i dati dei clienti dal data center originale in una nuova area geografica. Il periodo in cui è possibile effettuare questa richiesta è in genere di uno o due anni, a seconda della domanda complessiva per il servizio. Si noti che questo periodo durante il quale è possibile richiedere lo spostamento dei dati dei clienti diventa più breve una volta che un data center (DC) per i nuovi lanci geografici (a quel punto si hanno circa tre o sei mesi per richiedere uno spostamento). I dettagli sono disponibili in Spostamento dei dati di base in nuove aree geografiche dei data center di Microsoft 365.

Quando viene eseguita la migrazione delle cassette postali all'interno dei data center di Microsoft 365, ogni spostamento delle cassette postali o lo spostamento in blocco delle cassette postali richiede tempo per il completamento dell'operazione. Esistono diversi fattori, ad esempio l'attività del servizio Microsoft 365, che possono influire esattamente sulla quantità di tempo. Il servizio è progettato per limitare i carichi di lavoro discrezionali come gli spostamenti delle cassette postali, per garantire che il servizio venga eseguito in modo ottimale per tutti gli utenti. È comunque possibile prevedere l'elaborazione degli spostamenti delle cassette postali, a seconda della disponibilità discrezionale delle risorse del servizio. Altre informazioni sulla limitazione delle risorse sono disponibili in questo post di blog.

Stime della durata per la migrazione delle cassette postali in Exchange Online

Per pianificare la migrazione, le tabelle seguenti presentano linee guida su quando prevedere il completamento delle migrazioni in blocco delle cassette postali o delle singole migrazioni. Queste stime si basano su un'analisi dei dati delle migrazioni precedenti dei clienti. Poiché ogni ambiente è univoco, la velocità di migrazione esatta può variare.

Durata della migrazione delle cassette postali in base ai profili delle dimensioni delle cassette postali:

• GoLocal/Multi-Geo/Crittografia in Exchange Online

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  GoLocal/Multi-Geo/Encryption	0 - 10	1	1
  GoLocal/Multi-Geo/Encryption	10 - 50	2	6
  GoLocal/Multi-Geo/Encryption	50 - 100	4	11
  GoLocal/Multi-Geo/Encryption	100 - 200	6	14
  GoLocal/Multi-Geo/Encryption	> 200	Non supportato	Non supportato

• Onboarding in Exchange Online da exchange server locali (cutover/staged/hybrid)

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Onboarding da locale	0 - 10	1	3
  Onboarding da locale	10 - 50	2	6
  Onboarding da locale	50 - 100	4	13
  Onboarding da locale	100 - 200	10	31
  Onboarding da locale	> 200	Non supportato	Non supportato

• Migrazione tra tenant a Exchange Online (usare la soluzione microsoft di prima parte o usare soluzioni di terze parti).

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Tenant incrociato	0 - 10	1	1
  Tenant incrociato	10 - 50	1	2
  Tenant incrociato	50 - 100	2	5
  Tenant incrociato	100 - 200	3	6
  Tenant incrociato	> 200	Non supportato	Non supportato

• Onboarding specializzato per Exchange Online da Gmail/G Suite/GWS (EAC, PowerShell)

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Onboarding gmail specializzato	0 - 10	1	2
  Onboarding gmail specializzato	10 - 50	1	8
  Onboarding gmail specializzato	50 - 100	3	12
  Onboarding gmail specializzato	100 - 200	5	19
  Onboarding gmail specializzato	> 200	Non supportato	Non supportato

• Onboarding in Exchange Online da origini IMAP (altre origini IMAP, PowerShell, Gmail tramite IMAP)

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Onboarding IMAP generico	0 - 10	1	1
  Onboarding IMAP generico	10 - 50	1	2
  Onboarding IMAP generico	50 - 100	1	8
  Onboarding IMAP generico	100 - 200	3	29
  Onboarding IMAP generico	> 200	Non supportato	Non supportato

• Onboarding in Exchange Online tramite importazione PST

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Importazione PST	0 - 10	1	1
  Importazione PST	10 - 50	1	3
  Importazione PST	50 - 100	2	5
  Importazione PST	100 - 200	3	6
  Importazione PST	> 200	Non supportato	Non supportato

Nota

Il completamento di alcune cassette postali outlier richiederebbe più tempo in base al profilo della cassetta postale. Inoltre, se un tenant ha in media cassette postali di dimensioni maggiori, questo può contribuire anche alla durata estesa della migrazione.

Fattori relativi alle prestazioni di migrazione

La migrazione delle cassette postali/Email ha diversi fattori comuni che influiscono sulle prestazioni della migrazione.

Fattori comuni legati alle prestazioni della migrazione

La tabella seguente contiene un elenco dei fattori comuni che influiscono sulle prestazioni della migrazione. Altri dettagli sono riportati nelle sezioni che descrivono i singoli metodi di migrazione.

Fattore	Descrizione	Esempio
origine dati	Il dispositivo o il servizio che ospita i dati di cui eseguire la migrazione. Alle origini dati potrebbero applicarsi diverse limitazioni, a causa di specifiche hardware, carico di lavoro degli utenti finali e attività di manutenzione del back-end.	Gmail limita la quantità di dati che è possibile estrarre in uno specifico periodo di tempo.
Tipo e densità dei dati	Considerando la natura particolare del business dei clienti, il tipo e la combinazione degli elementi contenuti nelle cassette postali sono estremamente variabili.	La migrazione di un'unica cassetta postale di 4 GB con 400 elementi, ognuno con circa 10 magabyte (MB) di allegati, viene eseguita più velocemente di quella di una cassetta di 4 GB con 100.000 elementi più piccoli.
Server di migrazione	In molte soluzioni di migrazione si usa una workstation o un server specifico, di tipo "jump box", per completare la procedura.	I clienti usano spesso una macchina virtuale a basse prestazioni per ospitare il servizio MRSProxy per le distribuzioni ibride o per le migrazioni non ibride di PC client.
Motore di migrazione	Il motore di migrazione dei dati responsabile del pull dei dati dal server di origine converte i dati, se necessario. Il motore trasmette quindi i dati in rete e inserisce i dati nella cassetta postale di Microsoft 365 o Office 365. Cassetta postale.	Il servizio MRSProxy prevede funzionalità e limitazioni specifiche.
Appliance di rete locali	Le prestazioni di rete end-to-end (dall'origine dati ai server di accesso client Exchange Online) influiscono sulle prestazioni di migrazione.	Configurazione e specifiche del firewall nell'organizzazione locale.
Servizio Microsoft 365 o Office 365	Microsoft 365 e Office 365 dispongono di funzionalità e supporto predefiniti per gestire il carico di lavoro di migrazione.	I criteri di limitazione degli utenti includono impostazioni predefinite e limitano la velocità massima complessiva di trasferimento dei dati.

Fattori legati alle prestazioni della rete

In questa sezione vengono descritte le procedure consigliate per migliorare le prestazioni di rete durante la migrazione. La discussione è generica, perché l'impatto maggiore sulle prestazioni di rete durante la migrazione riguarda l'hardware di terze parti e i provider di servizi Internet (ISP).

Usare Exchange Analyzer per ottenere una conoscenza più approfondita della connettività di rete con Microsoft 365 o Office 365. Per eseguire i test di Exchange Analyzer in supporto tecnico Microsoft e Recovery Assistant, passare a Diagnostica > avanzata Exchange Online > Controllare Exchange Online connettività > di rete Sì. Per altre informazioni su supporto tecnico Microsoft e Recovery Assistant, vedere supporto tecnico Microsoft e Recovery Assistant.

Fattore	Descrizione	Procedure consigliate
Capacità della rete	La quantità di tempo necessaria per eseguire la migrazione delle cassette postali a Microsoft 365 o Office 365 è determinata dalla capacità disponibile e massima della rete.	Identificare la capacità di rete disponibile e determinare quella massima di caricamento. Contattare l'ISP per verificare la larghezza di banda assegnata e ottenere informazioni sulle restrizioni, ad esempio la quantità totale di dati che è possibile trasferire in uno specifico periodo di tempo. Usare gli strumenti per valutare la capacità di rete effettiva. Assicurarsi di testare il flusso end-to-end dei dati dalle origini dati locali ai server gateway dei data center Microsoft. Identificare altri carichi imposti alla rete, ad esempio le utilità di backup e la manutenzione pianificata, che possono influire sulla capacità della rete.
Stabilità della rete	Una rete veloce non sempre implica migrazioni veloci. Se la rete non è stabile, il trasferimento dei dati richiede più tempo a causa della correzione degli errori. In base al tipo di migrazione, la correzione degli errori può influire in modo significativo sulle prestazioni.	I problemi dell'hardware e dei driver di rete spesso causano problemi di stabilità. Collaborare con i fornitori dell'hardware per ottenere informazioni accurate sui dispositivi di rete e applicare le versioni più recenti dei driver e gli aggiornamenti software consigliati.
Ritardi della rete	Le funzionalità di rilevamento delle intrusioni configurate in un firewall di rete spesso causano ritardi significativi e possono influire sulle prestazioni della migrazione. La migrazione dei dati alle cassette postali di Microsoft 365 o Office 365 si basa sulla connessione Internet. I ritardi di Internet influiscono sulle prestazioni complessive della migrazione. Inoltre, gli utenti della stessa società potrebbero avere cassette postali sul cloud che risiedono in data center ubicati in aree geografiche diverse. Le prestazioni della migrazione possono variare in base all'ISP del cliente.	Valutare i ritardi di rete in tutti i potenziali data center Microsoft per garantire che il risultato sia coerente. Ciò consente anche di garantire un'esperienza coerente per gli utenti finali. Collaborare con l'ISP per risolvere i problemi relativi a Internet. Aggiungere gli indirizzi IP per i server del data center Microsoft all'elenco di indirizzi consentiti o ignorare tutto il traffico correlato alla migrazione dal firewall di rete. Per altre informazioni sugli intervalli IP di Microsoft 365 o Office 365, vedere Url e intervalli di indirizzi IP di Microsoft 365 e Office 365.

Per un'analisi più approfondita delle migrazioni all'interno dell'ambiente, vedere l'analisi delle prestazioni della migrazione delle cassette postali. Il post include uno script per analizzare le richieste di spostamento.

Limitazione di Microsoft 365 e Office 365

Microsoft 365 e Office 365 usano vari meccanismi di limitazione per garantire la sicurezza e la disponibilità del servizio. I tre tipi seguenti di limitazione possono influire sulle prestazioni della migrazione:

• Limitazione utente
• Limitazione del servizio di migrazione
• Limitazione basata sull'integrità delle risorse

Nota

I tre tipi di Microsoft 365 e Office 365 limitazione non influiscono su tutti i metodi di migrazione.

Limitazione delle richieste degli utenti di Microsoft 365 e Office 365

La limitazione degli utenti influisce sulla maggior parte degli strumenti di migrazione di terze parti e sul metodo di migrazione con caricamento del client. Questi metodi di migrazione usano protocolli di accesso client, ad esempio RPC (Remote Procedure Call) tramite protocollo HTTP, per eseguire la migrazione dei dati delle cassette postali a Microsoft 365 o Office 365 cassette postali. Si tratta di strumenti usati per eseguire la migrazione dei dati da piattaforme come IBM Lotus Domino e Novell GroupWise.

La limitazione delle richieste degli utenti è il metodo di limitazione più restrittivo in Microsoft 365 e Office 365. Poiché viene configurata per funzionare rispetto a un singolo utente finale, ogni utilizzo a livello di applicazione supererà facilmente i criteri di limitazione, rallentando la migrazione dei dati.

Limitazione delle richieste del servizio di migrazione di Microsoft 365 e Office 365

La limitazione del servizio di migrazione influisce su tutti gli strumenti di migrazione di Microsoft 365 o Office 365. La limitazione del servizio di migrazione gestisce la concorrenza della migrazione e l'allocazione delle risorse del servizio per microsoft 365 o soluzioni di migrazione Office 365.

La limitazione del servizio di migrazione influisce sulle migrazioni eseguite con i metodi seguenti:

• Migrazione IMAP
• Migrazione completa di Exchange
• Migrazione a fasi di Exchange
• Migrazioni ibride (spostamenti basati sul servizio MRSProxy in ambienti ibridi)

Importante

I metodi di migrazione indicati in precedenza non sono interessati dalla limitazione delle richieste degli utenti.

Un esempio di limitazione del servizio di migrazione consiste nel controllare il numero di cassette postali trasferite simultaneamente durante le migrazioni semplici di Exchange e le migrazioni IMAP. Il valore predefinito è 20. Ciò significa che viene eseguita la migrazione di un massimo di 20 cassette postali di tutti i batch di migrazione in qualsiasi momento. È possibile aumentare il numero di migrazioni simultanee delle cassette postali per un batch di migrazione nell'interfaccia di amministrazione di Exchange o in Windows PowerShell. Per altre informazioni su come ottimizzare questa impostazione, vedere Gestire i batch di migrazione in Microsoft 365 o Office 365.

Limitazione basata sull'integrità delle risorse di Microsoft 365 o Office 365

Tutti i metodi di migrazione sono soggetti alla governance della limitazione di disponibilità. La limitazione delle richieste del servizio Microsoft 365 o Office 365, tuttavia, non influisce sulle migrazioni di Microsoft 365 o Office 365 tanto quanto gli altri tipi di limitazione descritti in precedenza.

La limitazione basata sull'integrità delle risorse rappresenta il metodo di limitazione meno aggressivo. Si verifica quando c'è un problema di disponibilità del servizio che potrebbe influire sugli utenti finali e su operazioni strategiche.

Prima che le prestazioni del servizio peggiorino al punto da influire negativamente sulle prestazioni degli utenti finali, la migrazione ibrida verrà bloccata finché le prestazioni non vengono ripristinate e il servizio non torna a un livello inferiore alla soglia di limitazione.

Di seguito viene illustrato ciò che i clienti vedranno in merito alle durate di stallo usando il Get-MoveRequestStatistics - <> -IncludeReport cmdlet:

$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632

$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00

CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00

Soluzione e pratica:

Se si verifica una situazione analoga, attendere che le risorse di Microsoft 365 o Office 365 diventino disponibili.

Fattori relativi alle prestazioni e procedure consigliate per le migrazioni di distribuzione non ibride

Questa sezione descrive i fattori che influiscono sulle migrazioni IMAP, complete o a fasi. Identifica inoltre le procedure consigliate per migliorare le prestazioni.

Fattore 1: origine dati per migrazioni di distribuzione non ibride

Nella tabella seguente viene descritto l'impatto sulla migrazione prodotto dai server di origine nell'organizzazione di posta elettronica corrente e le procedure consigliate per ridurre tale impatto.

Elenco di controllo	Descrizione	Procedure consigliate
Prestazioni del sistema	L'estrazione dei dati è un'attività intensiva. Il sistema di origine deve avere risorse sufficienti, ad esempio tempo della CPU e memoria, per offrire prestazioni ottimali della migrazione. Durante la migrazione, il sistema di origine si avvicina spesso alla piena capacità in termini del normale carico di lavoro degli utenti finali. Se le risorse di sistema sono inadeguate, il carico di lavoro aggiuntivo risultante dalla migrazione può influire sugli utenti finali.	Monitorare le prestazioni del sistema durante un test di migrazione pilota. Se il sistema è occupato, è consigliabile evitare una pianificazione aggressiva della migrazione per il sistema specifico, perché si potrebbero verificare problemi di lentezza della migrazione e di disponibilità del servizio. Se possibile, migliorare le prestazioni del sistema di origine aggiungendo risorse hardware e ridurre il carico sul sistema spostando attività e utenti in altri servizi non coinvolti nella migrazione. Per altre informazioni, vedere: Server Health and Performance of Exchange Server (2007, 2010, 2013, 2016, 2019) Nota: Exchange Server 2007 e 2010 non sono più supportati attivamente. La fine del supporto per Exchange 2013 Server è pianificata per aprile 2023. Exchange Server 2016 e 2019 sono in supporto esteso fino a ottobre 2025. Per altri dettagli, vedere la matrice di supporto Exchange Server. Quando si esegue la migrazione da un'organizzazione locale di Exchange che comprende più server delle cassette postali, è consigliabile creare un elenco degli utenti della migrazione equamente distribuiti tra più server. In base alle prestazioni dei singoli server, l'elenco può essere ulteriormente perfezionato per ottimizzare la velocità effettiva. Ad esempio, se il server A ha il 50% in più di disponibilità di risorse rispetto al server B, è ragionevole avere il 50% in più di utenti dal server A nello stesso batch di migrazione. Procedure analoghe possono essere applicate ad altri sistemi di origine. Eseguire le migrazioni quando i server hanno la massima disponibilità di risorse, ad esempio fuori orario oppure nei weekend o durante le festività.
Attività di back-end	Altre attività di back-end in esecuzione durante la migrazione. Poiché è consigliabile eseguire la migrazione dopo l'orario di ufficio, è comune che le migrazioni vengano in conflitto con le attività di manutenzione (ad esempio il backup dei dati) eseguite nei server locali.	Valutare altre attività di sistema che potrebbero essere eseguite durante la migrazione. È consigliabile eseguire la migrazione dei dati quando non sono in esecuzione altre attività a elevato utilizzo di risorse. Nota: per i clienti che usano Exchange locale, le attività back-end comuni sono le soluzioni di backup e la manutenzione dell'archivio exchange (2013, 2016, 2019).
Criteri di limitazione	È prassi comune proteggere i sistemi di posta elettronica con criteri di limitazione che impostano un limite specifico sulla velocità e la quantità di dati che possono essere estratti dal sistema durante un determinato periodo di tempo.	Verificare i criteri di limitazione distribuiti per il sistema di posta elettronica. Ad esempio, Google Mail limita la quantità di dati che possono essere estratti in un determinato periodo. In base alla versione, Exchange include criteri che limitano l'accesso IMAP al server della posta locale (usato dalle migrazioni IMAP) e l'accesso al protocollo RPC su HTTP (usato dalle migrazioni complete di Exchange e dalle migrazioni a fasi di Exchange). Per controllare le impostazioni di limitazione, eseguire il cmdlet Get-ThrottlingPolicy . Per altre informazioni sulla limitazione delle richieste, vedere: (2007, 2010, 2013, 2016, 2019). Per altre informazioni sulla limitazione IMAP, vedere Eseguire la migrazione delle cassette postali IMAP a Microsoft 365 o Office 365.

Fattore 2: Server di migrazione per migrazioni di distribuzione non ibride

Le migrazioni IMAP, complete e a fasi sono metodi di migrazione con pull dei dati avviati sul cloud, quindi non è necessario avere un server dedicato. Gli host del protocollo con connessione Internet (IMAP o RPC su protocollo HTTP), tuttavia, funzionano come server di migrazione per la migrazione di cassette postali e dati delle cassette postali a Microsoft 365 o Office 365. Pertanto, i fattori di prestazioni della migrazione e le procedure consigliate, descritte nella sezione precedente sul server di origine dati per l'organizzazione di posta elettronica corrente, si applicano anche ai server perimetrali Internet. Per le organizzazioni di Exchange 2007, Exchange Server 2010 e Exchange 2013, il server Accesso client funge da server di migrazione.

Per altre informazioni, vedere:

• Exchange Server 2007: Monitoraggio dei server accesso client

• Exchange Server 2010: contatori del server Accesso client

• Exchange Server 2013: Gestione del carico di lavoro di Exchange

• Exchange Server 2016: Gestione del carico di lavoro degli utenti in Exchange Server

• Exchange Server 2019: Gestione del carico di lavoro degli utenti in Exchange Server

Fattore 3: motore di migrazione per migrazioni di distribuzione non ibride

Le migrazioni di Exchange IMAP, cutover e a fasi vengono eseguite usando il dashboard migrazione nell'interfaccia di amministrazione di Exchange. Questo è soggetto alla limitazione del servizio di migrazione di Microsoft 365 o Office 365.

Soluzione e pratica:

I clienti ora possono specificare la simultaneità delle migrazioni, ad esempio il numero di cassette postali da trasferire simultaneamente, usando Windows PowerShell. Il valore predefinito è 20 cassette postali. Dopo aver creato un batch di migrazione, è possibile usare il cmdlet di Windows PowerShell seguente per aumentare questo valore fino a un massimo di 100.

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

Per altre informazioni, vedere Gestire i batch di migrazione in Microsoft 365 o Office 365.

Nota

Se l'origine dati non dispone di risorse sufficienti per gestire tutte le connessioni, è consigliabile evitare una concorrenza elevata. Iniziare con un valore ridotto, ad esempio 10. Aumentare questo numero monitorando le prestazioni dell'origine dati per evitare problemi di accesso per gli utenti finali.

Fattore 4: Rete per migrazioni di distribuzione non ibride

Test di verifica:

In base al metodo di migrazione, è possibile provare i test di verifica seguenti:

• Migrazioni IMAP: prepopolare una cassetta postale di origine con dati di esempio. Quindi da Internet (all'esterno della rete locale), connettersi alla cassetta postale di origine usando un client di posta elettronica IMAP standard, ad esempio Microsoft Outlook, e quindi misurare le prestazioni di rete determinando il tempo necessario per scaricare tutti i dati dalla cassetta postale di origine. La velocità effettiva deve essere simile a quella che i clienti possono ottenere usando lo strumento di migrazione IMAP in Microsoft 365 o Office 365, dato che non esistono altri vincoli.

• Migrazioni di Exchange a fasi e cutover: prepopolare una cassetta postale di origine con dati di esempio. Quindi, da Internet (all'esterno della rete locale), connettersi alla cassetta postale di origine con Outlook usando RPC tramite protocollo HTTP. Assicurarsi di connettersi usando la modalità memorizzata nella cache. Misurare le prestazioni di rete controllando quanto tempo richiede la sincronizzazione di tutti i dati della cassetta postale di origine. La velocità effettiva deve essere simile a quella che i clienti possono ottenere usando i semplici strumenti di migrazione di Exchange in Microsoft 365 o Office 365, dato che non esistono altri vincoli.

Durante una migrazione IMAP, completa o a fasi di Exchange si potrebbe verificare un sovraccarico. La velocità effettiva, tuttavia, dovrebbe essere simile a quella dei risultati di questi test di verifica.

Fattore 5: Servizio Microsoft 365 e Office 365 per migrazioni di distribuzione non ibride

Microsoft 365 o Office 365 limitazione basata sull'integrità delle risorse influisce sulle migrazioni usando gli strumenti di migrazione nativi di Microsoft 365 o Office 365 semplici. Vedere la sezione relativa alla limitazione basata sull'integrità delle risorse di Microsoft 365 o Office 365.

Spostare le richieste in Microsoft 365 o Office 365

Per informazioni generali sul recupero di informazioni sullo stato per le richieste di spostamento, vedere Visualizzare le proprietà delle richieste di spostamento:

• Move-Mailbox

• [Get-MoveRequestStatistics]] (/powershell/module/exchange/get-moverequeststatistics)

Nel servizio Microsoft 365 o Office 365 la coda di migrazione e le risorse del servizio allocate per le migrazioni vengono condivise tra i tenant e influiscono sulla gestione delle richieste di spostamento in ogni fase del processo di spostamento.

Esistono due tipi di richieste di spostamento in Microsoft 365 e Office 365:

• Onboarding delle richieste di spostamento: le migrazioni dei nuovi clienti vengono considerate come richieste di spostamento di onboarding. Queste richieste hanno una priorità standard.

• Richieste interne di "spostamento" del data center: si tratta di richieste di spostamento delle cassette postali avviate dai team operativi del data center. Queste richieste hanno una priorità più bassa, perché l'esperienza degli utenti finali non ne risente qualora vengano ritardate.

Impatto e ritardi potenziali per le richieste di spostamento con stato "Accodato" e "In corso"

• Richieste di spostamento in coda: questo stato specifica che lo spostamento è stato accodato e che è in attesa che il servizio di replica delle cassette postali di Exchange lo selezioni. Per le richieste di spostamento di Exchange 2003, gli utenti possono comunque accedere alle loro cassette postali in questa fase.

  Due fattori influiscono sulla richiesta che verrà gestita dal servizio di replica delle cassette postali:

  • Priorità: le richieste di spostamento in coda con priorità più alta vengono prelevate prima delle richieste di spostamento con priorità inferiore. In questo modo ci si assicura che le richieste di spostamento delle migrazioni dei clienti vengano sempre elaborate prima di quelle interne al data center.

  • Posizione nella coda: se le richieste di spostamento hanno la stessa priorità, prima la richiesta entra nella coda, prima verrà prelevata dal servizio di replica delle cassette postali. Poiché potrebbero esserci più clienti che eseguono le migrazioni delle cassette postali contemporaneamente, è normale che le nuove richieste di spostamento rimangano nella coda prima di essere elaborate.

Spesso il tempo di attesa nella coda prima che le richieste di cassette postali vengano elaborate non viene considerato durante la pianificazione della migrazione. Il risultato è che ai clienti non viene assegnato un tempo sufficiente per completare tutte le migrazioni pianificate.

• Richieste di spostamento in corso: questo stato specifica che lo spostamento è ancora in corso. Se si tratta di uno spostamento di cassette postali online, l'utente avrà comunque la possibilità di accedervi.

Quando la richiesta di spostamento delle cassette postali ha lo stato "in corso", la priorità non ha più importanza e le nuove richieste di spostamento verranno elaborate solo dopo il completamento di quelle attualmente in corso, anche se la nuova richiesta ha una priorità più alta.

Procedure consigliate

Pianificazione: come accennato in precedenza, poiché gli utenti di Exchange 2003 perdono l'accesso durante una migrazione ibrida, i clienti di Exchange 2003 sono in genere più preoccupati quando pianificare le migrazioni e quanto tempo impiegano.

Quando si pianifica il numero di cassette postali di cui eseguire la migrazione durante uno specifico periodo di tempo, considerare quanto segue:

• Includere la quantità di tempo in cui la richiesta di spostamento sarà in attesa nella coda. Per calcolarlo, usare la formula seguente:

  (numero totale di cassette postali di cui eseguire la migrazione) = ((tempo totale) - (tempo medio coda)) * (velocità effettiva della migrazione)

  dove la velocità effettiva della migrazione equivale al numero totale di cassette postali che è possibile spostare ogni ora.

Si supponga ad esempio di avere una finestra temporale di sei ore per eseguire la migrazione delle cassette postali. Se il tempo medio della coda è di un'ora e si dispone di una velocità effettiva di migrazione di 100 cassette postali all'ora, è possibile eseguire la migrazione di 500 cassette postali nell'intervallo di tempo di sei ore: 500 = (6 - 1) * 100.

• Avviare la migrazione prima di quanto inizialmente pianificato per tenere conto del tempo in coda. Quando le cassette postali sono in coda, gli utenti di Exchange 2003 possono comunque accedere alle loro cassette postali.

Determinare il tempo di coda: il tempo di coda cambia sempre perché Microsoft non gestisce le pianificazioni della migrazione dei clienti.

Per determinare il potenziale tempo in coda, è possibile provare a pianificare uno spostamento di test diverse ore prima dell'avvio della migrazione effettiva. Quindi, in base alla quantità di tempo osservata durante il quale la richiesta rimane in coda, è possibile stimare in modo più accurato quando iniziare la migrazione e quante cassette postali è possibile spostare in uno specifico periodo.

Ad esempio, se una migrazione di test è stata completata quattro ore prima dell'inizio di una migrazione pianificata. Il cliente determina che il tempo trascorso in coda per la migrazione di prova è stato di circa un'ora. Quindi, il cliente deve prendere in considerazione l'avvio della migrazione un'ora prima di quanto originariamente previsto per assicurarsi che ci sia abbastanza tempo per completare tutte le migrazioni.

Strumenti di terze parti per le migrazioni di Microsoft 365 o Office 365

Gli strumenti di terze parti vengono usati principalmente negli scenari di migrazione che non coinvolgono Exchange, ad esempio quelli di Gmail/G Suite/GWS (Google Workspace), IBM Lotus, Domino e Novell GroupWise. Questa sezione riguarda principalmente i protocolli di migrazione usati da strumenti di terze parti, piuttosto che i prodotti e gli strumenti specifici. La tabella seguente fornisce un elenco di fattori applicabili agli strumenti di terze parti per gli scenari di migrazione di Microsoft 365 o Office 365.

Importante

Per problemi di coerenza o integrità dei dati dopo aver eseguito una migrazione usando strumenti di terze parti, contattare il fornitore che ha fornito lo strumento per il supporto.

Fattore 1: origine dati per le migrazioni di strumenti di terze parti

Elenco di controllo	Descrizione	Procedure consigliate
Prestazioni del sistema	L'estrazione dei dati è un'attività intensiva. Il sistema di origine deve avere risorse sufficienti, ad esempio tempo della CPU e memoria, per offrire prestazioni ottimali della migrazione. Durante la migrazione, il sistema di origine si avvicina spesso alla piena capacità in termini del normale carico di lavoro degli utenti finali. Se le risorse di sistema sono inadeguate, il carico di lavoro aggiuntivo risultante dalla migrazione può influire sugli utenti finali.	Monitorare le prestazioni del sistema durante un test di migrazione pilota. Se il sistema è occupato, è consigliabile evitare una pianificazione aggressiva della migrazione per il sistema specifico, perché si potrebbero verificare problemi di lentezza della migrazione e di disponibilità del servizio. Se possibile, migliorare le prestazioni del sistema di origine aggiungendo risorse hardware e ridurre il carico sul sistema spostando attività e utenti in altri servizi non coinvolti nella migrazione. Per altre informazioni, vedere: Integrità e prestazioni del server di Exchange Server (2007, 2010, 2013, 2016, 2019). Nota: Exchange Server 2007 e 2010 non sono più supportati attivamente. La fine del supporto per Exchange 2013 Server è pianificata per aprile 2023. Exchange Server 2016 e 2019 sono in supporto esteso fino a ottobre 2025. Per altri dettagli, vedere la matrice di supporto Exchange Server. Quando si esegue la migrazione da un'organizzazione locale di Exchange che comprende più server delle cassette postali, è consigliabile creare un elenco degli utenti della migrazione equamente distribuiti tra più server. In base alle prestazioni dei singoli server, l'elenco può essere ulteriormente perfezionato per massimizzare la velocità effettiva. Se ad esempio il server A ha il 50% di disponibilità di risorse in più rispetto al server B, è ragionevole avere il 50% di utenti in più del server A nello stesso batch di migrazione. Procedure analoghe possono essere applicate ad altri sistemi di origine. Eseguire le migrazioni quando i server hanno la massima disponibilità di risorse, ad esempio fuori orario oppure nei weekend o durante le festività.
Attività di back-end	Altre attività di back-end solitamente eseguite durante la migrazione. Poiché le procedure consigliate prevedono di eseguire la migrazione dopo l'orario di lavoro, non è raro che le migrazioni entrino in conflitto con altre attività di manutenzione eseguite nei server locali, come il backup dei dati.	Valutare altre attività di sistema che potrebbero essere eseguite durante la migrazione. È consigliabile eseguire la migrazione dei dati quando non sono in esecuzione altre attività a elevato utilizzo di risorse. Nota: per i clienti che usano Exchange locale, le attività back-end comuni sono le soluzioni di backup e la manutenzione dell'archivio exchange (2013, 2016, 2019).
Criteri di limitazione	È pratica comune proteggere i sistemi di posta elettronica con criteri di limitazione che impostano un limite specifico sulla velocità e sulla quantità di dati che è possibile estrarre dal sistema entro un determinato periodo di tempo e usando uno specifico metodo di migrazione.	Verificare i criteri di limitazione distribuiti per il sistema di posta elettronica. Ad esempio, Google Mail limita la quantità di dati che possono essere estratti in un determinato periodo. In base alla versione, Exchange include criteri che limitano l'accesso IMAP al server della posta locale (usato dalle migrazioni IMAP) e l'accesso al protocollo RPC su HTTP (usato dalle migrazioni complete di Exchange e dalle migrazioni a fasi di Exchange). Per controllare le impostazioni di limitazione, eseguire il cmdlet Get-ThrottlingPolicy . Per altre informazioni sulla limitazione delle richieste, vedere: (2007, 2010, 2013, 2016, 2019). Per altre informazioni sulla limitazione IMAP, vedere Eseguire la migrazione delle cassette postali IMAP a Microsoft 365 o Office 365.

Fattore 2: Server di migrazione per migrazioni di strumenti di terze parti

La maggior parte degli strumenti di terze parti per le migrazioni di Microsoft 365 o Office 365 sono avviati dal client e inviano dati a Microsoft 365 o Office 365. Questi strumenti richiedono in genere un server di migrazione. A questi server di migrazione si applicano fattori come le prestazioni di sistema, le attività di back-end e i criteri di limitazione dei server di origine.

Nota

Alcune soluzioni di migrazione di terze parti sono ospitate su Internet come servizi basati sul cloud e non richiedono un server di migrazione locale.

Soluzione e pratica:

Per migliorare le prestazioni della migrazione quando si usa un server di migrazione, applicare le stesse procedure consigliate descritte nella sezione Factor 1: Origine dati per le migrazioni di strumenti di terze parti .

Fattore 3: Motore di migrazione per le migrazioni di strumenti di terze parti

Per gli strumenti di migrazione di terze parti, i protocolli più diffusi sono Servizi Web Exchange e RPC su HTTP.

Servizi Web Exchange:

Servizi Web Exchange è il protocollo consigliato da usare per la migrazione a Microsoft 365 o Office 365 perché supporta batch di dati di grandi dimensioni e offre una migliore limitazione orientata ai servizi. In Microsoft 365 o Office 365, se usate in modalità di rappresentazione, le migrazioni che usano Servizi Web Exchange non utilizzano la quantità preventivata dell'utente di Microsoft 365 o Office 365 risorse di Servizi Web Exchange, utilizzando invece una copia delle risorse preventivate:

• Tutte le chiamate che rappresentano Servizi Web Exchange effettuate dallo stesso account di amministratore vengono calcolate separatamente rispetto al budget applicato a tale account.

• Per ogni sessione di rappresentazione, viene creata una copia shadow del budget effettivo dell'utente. Tutte le migrazioni di questa specifica sezione consumeranno questa copia shadow.

• La limitazione in rappresentazione è isolata per ogni sessione di migrazione degli utenti.

• I criteri di limitazione dei servizi Web Exchange possono essere modificati temporaneamente nel tenant (per una durata di 30, 60 o 90 giorni) per consentire il completamento della migrazione. È possibile richiederlo nella sezione Della Guida del interfaccia di amministrazione di Microsoft 365.

Procedure consigliate:

• Le prestazioni della migrazione per gli utenti che usano strumenti di terze parti basati sulla rappresentazione di EWA competono con le migrazioni basate su Servizi Web Exchange e con l'utilizzo delle risorse da parte di altri tenant. Pertanto, le prestazioni della migrazione possono variare.

• Se possibile, usare strumenti di migrazione di terze parti basati sulla rappresentazione di Servizi Web Exchange, perché in genere sono più veloci ed efficienti rispetto all'uso di protocolli come RPC su HTTP.

Protocollo RPC su HTTP:

Le soluzioni di migrazione tradizionali usano il protocollo RPC su HTTP. Questo metodo è completamente basato su un modello di accesso client, ad esempio quello di Outlook, e la scalabilità e le prestazioni sono limitate perché il servizio Microsoft 365 o Office 365 limita l'accesso presupponendo che l'utilizzo sia da parte di un utente anziché da un'applicazione.

Procedure consigliate:

• Per gli strumenti di migrazione che usano RPC tramite protocollo HTTP, è una procedura comune aumentare la velocità effettiva della migrazione aggiungendo più server di migrazione e usando più account utente amministrativi di Microsoft 365 o Office 365. Questa pratica può ottenere il parallelismo dell'inserimento dei dati e ottenere una velocità effettiva dei dati più elevata perché ogni utente amministratore è soggetto alla limitazione di Microsoft 365 e Office 365 utente. Molti clienti aziendali segnalano di aver dovuto configurare più di 40 server di migrazione per ottenere una velocità effettiva di 20-30 GB/ora.

• Nella fase di sviluppo degli strumenti di migrazione, è fondamentale valutare il numero di operazioni RPC necessarie per eseguire la migrazione di un messaggio. A questo scopo, sono stati raccolti i log acquisiti da Microsoft 365 o Office 365 servizi per due soluzioni di migrazione di terze parti (sviluppate da società di terze parti) usate dai clienti per eseguire la migrazione delle cassette postali a Microsoft 365 o Office 365. Abbiamo confrontato le due soluzioni di migrazione sviluppate da altre aziende. Per ogni soluzione, abbiamo confrontato la migrazione di due cassette postali e il relativo caricamento in un file PST di Outlook. Ecco i risultati.

Metodo	Dimensione cassetta postale	Numero di elementi	Tempo di migrazione	Transazioni RPC totali	Latenza media client (ms)	AvgCasRPCProcessingTime (ms)
Soluzione A (cassetta postale 1)	376,9 MB	4.115	4:24:33	132.040	48.4395	18.0807
Soluzione A (cassetta postale 2)	249,3 MB	12.779	10:50:50	423.188	44.1678	4.8444
Soluzione B (cassetta postale 1)	618,1 MB	4.322	1:54:58	12.196	37.2931	8.3441
Soluzione B (cassetta postale 2)	56,7 MB	2.748	0:47:08	5,806	42.1930	7.4439
Outlook	201,9 MB	3.297	0:29:47	15.775	36.9987	5.6447

Nota

I tempi di elaborazione del client e del servizio sono simili, ma la soluzione A richiede molte più operazioni RPC per eseguire la migrazione dei dati. Poiché ogni operazione usa il tempo di latenza client e il tempo di elaborazione del server, la soluzione A è molto più lenta per eseguire la migrazione della stessa quantità di dati rispetto alla soluzione B e a Outlook.

Fattore 4: Rete per le migrazioni di strumenti di terze parti

Procedura consigliata:

Per le soluzioni di migrazione di terze parti che usano il protocollo RPC su HTTP, ecco un metodo valido per misurare le potenziali prestazioni di migrazione:

1. Dal server di migrazione connettersi alla cassetta postale di Microsoft 365 o Office 365 con Outlook tramite RPC tramite protocollo HTTP. Assicurarsi di non connettersi usando la modalità cache.

2. Importare un file pst di grandi dimensioni con dati di esempio nella cassetta postale di Microsoft 365 o Office 365.

3. Misurare le prestazioni della migrazione calcolando il tempo richiesto per caricare il file PST. La velocità effettiva della migrazione dovrebbe essere simile a quella che i clienti possono ottenere con uno strumento di migrazione di terze parti che usa il protocollo RPC su HTTP, purché non siano presenti altri vincoli. Durante una migrazione effettiva si verifica un sovraccarico, quindi la velocità potrebbe essere leggermente diversa.

Fattore 5: Servizio Microsoft 365 e Office 365

Microsoft 365 e Office 365 limitazione basata sull'integrità delle risorse influisce sulle migrazioni che usano strumenti di migrazione di terze parti. Per altri dettagli, vedere Microsoft 365 e Office 365 limitazione basata sull'integrità delle risorse.