Microsoft Exchange Server è la piattaforma di posta elettronica, calendario, contatti, pianificazione e collaborazione di Microsoft. Viene distribuito sul sistema operativo Windows Server (OS) per uso aziendale. Microsoft ha progettato Exchange Server per consentire agli utenti di accedere alla piattaforma di messaggistica da dispositivi mobili, desktop e sistemi basati sul Web. Le funzionalità di telefonia in Exchange Server supportano i messaggi vocali.
Gli utenti di Exchange collaborano tramite la condivisione di calendario e documenti. Le funzionalità di archiviazione e sicurezza della piattaforma consentono alle organizzazioni di archiviare i contenuti, eseguire ricerche ed eseguire attività di conformità. Exchange Server si è evoluto nel tempo, ed è ora un componente fondamentale di Office 365 come software as a service (SaaS) offerta nel cloud di Microsoft con Microsoft in qualità di fornitore di servizi.
Come funziona Exchange Server?
Exchange Server è un prodotto di collaborazione di classe enterprise che si concentra principalmente sull’invio, la ricezione e la memorizzazione di messaggi e-mail. Oltre a gestire il traffico di messaggistica, Exchange Server offre diverse altre funzionalità di collaborazione, come il calendario e una stretta integrazione con altre applicazioni di Microsoft Office.
Exchange Server è noto per le sue caratteristiche di alta disponibilità (HA) che garantiscono il servizio continuato in diversi scenari di interruzione. Ciò include percorsi di progettazione in grado di garantire il servizio durante errori di server singolo o interruzioni del data center.
Funzionalità di Exchange Server 2019
La versione 2019 offre un failover significativamente più veloce e affidabile tra i server. È stato progettato per migliorare le prestazioni complessive e sfruttare l’hardware di archiviazione più recente, inclusi dischi più grandi e unità a stato solido (SSD).
Ulteriori funzionalità di Exchange server 2019 includono i seguenti:
- fornisce il supporto per fino a 256 GB di memoria e 48 core della CPU;
- consente installazioni di Windows Server Core;
- consente l’accesso esterno al centro di amministrazione di Exchange (EAC) e Exchange Management Shell per essere bloccato in modo nativo;
- impiega dinamica della memoria allocazione della cache per ottimizzare l’utilizzo della memoria per i database attivi;
- impedisce di partecipanti per l’inoltro di inviti a riunioni;
- fornisce agli utenti finali con ulteriori opzioni Fuori sede;
- consente agli amministratori di cancellare incontri che sono stati organizzati da un utente che ha lasciato l’azienda;
- consente agli amministratori di assegnare autorizzazioni delegato; e
- consente di indirizzi e-mail che contengono caratteri non inglesi di essere indirizzati e consegnati in modo nativo.
Exchange Server 2019 logo Insieme a queste funzionalità aggiuntive in Exchange 2019, il ruolo Unified Messaging (UM) e tutte le funzionalità associate sono stati rimossi da Exchange 2019. Un settembre. 16, 2019, il blog sul sito del team di Exchange ha indicato che Microsoft avrebbe spinto il supporto esteso di Exchange Server 2010 da jan. 14, 2020, a Ott. 13, 2020, per dare ai clienti di Exchange Server 2010 più tempo per completare le loro migrazioni.
Gli amministratori che eseguono i carichi di lavoro di Exchange Server 2010 su Windows Server 2008 dovranno apportare modifiche a causa del Jan. 14, 2020, fine della vita per quel sistema operativo del server.
Requisiti Exchange Server 2019
Per installare Exchange è necessario soddisfare i seguenti requisiti 2019:
- Exchange 2019 può essere installato nelle foreste di Active Directory (AD) con i server Exchange 2016 e/o 2013 esistenti. Non è possibile installare versioni precedenti di Exchange nella stessa foresta di Exchange 2019.
- Tutti i controller di dominio (DCS) nella foresta AD devono eseguire Windows Server 2019 Standard o Datacenter, Windows Server 2016 Standard o Datacenter o Windows Server 2012 R2 Standard o Datacenter.
- Il livello della funzione AD forest deve essere Windows Server 2012 R2 o superiore.
- Il server hosting Exchange 2019 deve utilizzare un processore a 64 bit.
- Il server hosting Exchange 2019 dovrebbe avere tra 128 e 256 gigabyte (GB) di memoria ad accesso casuale (RAM).
- New Technology File System (NTFS) è richiesto su tutte le partizioni del disco contenenti la partizione di sistema, i binari di Exchange, i registri diagnostici e il database di trasporto. Resilient File System (ReFS) può essere utilizzato su partizioni contenenti database di cassette postali e log delle transazioni.
Exchange Server high availability
Exchange Server ha diverse caratteristiche importanti per mantenere la resilienza e HA. I componenti del server mailbox di Exchange si basano sui gruppi di disponibilità del database (DAG). I componenti del server di accesso client si basano sul bilanciamento del carico.
Gruppi di disponibilità del database
Il DAG è il sottosistema di scambio fondamentale per garantire HA. Il DAG è stato introdotto per la prima volta in Exchange 2010 ed è diventato rapidamente uno dei sottosistemi più importanti all’interno di Exchange.
Il DAG è un gruppo di fino a 16 server Exchange che copia automaticamente i database tra i membri per fornire ridondanza in caso di errore a livello di database o server. Qualsiasi server membro di un DAG può ospitare una copia di un database da qualsiasi altro server membro del DAG. Una volta che una copia di un database viene aggiunta a un altro server, tale copia viene automaticamente mantenuta aggiornata e pronta per essere attivata in qualsiasi momento.
Il DAG è basato sul Clustering di Windows e non sulla tecnologia specifica del team di Exchange stesso. Ciò può significare che, a volte, funzionalità e bug in Windows Server possono avere un impatto significativo su come funzioni Exchange.
Active Manager
Active Manager (AM) è il componente di Exchange responsabile della gestione degli eventi di failover all’interno di un ambiente Exchange. AM viene eseguito nel servizio di replica di Microsoft Exchange su tutti i server Exchange 2016. Quando un server Exchange viene unito a un DAG, su quel server vengono eseguiti due ruoli AM: Primary Active Manager (PAM) e Standby Active Manager (SAM).
Il server membro DAG proprietario della risorsa quorum cluster manterrà il ruolo PAM. Se il nodo DAG che contiene la risorsa quorum non riesce, il ruolo PAM si sposterà sul server che assume la proprietà della risorsa quorum.
Il SAM è responsabile di fornire informazioni agli altri componenti di Exchange che eseguono client AM su quale copia del database è attualmente attiva. Il SAM rileva quando un database fallisce e chiede al PAM di avviare l’evento di failover. Il SAM non è responsabile della selezione della copia del database attivata dopo un errore. Questo processo è chiamato best copy and server Selection (BCSS).
Best copy selection
Quando viene rilevato un errore di database, AM prende misure per recuperare dall’errore selezionando la migliore copia del database effettuato da attivare. Il processo BCSS va così:
- Un errore viene rilevato da AM o da Managed Availability. Questo processo può anche essere avviato da un amministratore che avvia una commutazione senza target.
- Il PAM avvia l’algoritmo interno BCSS.
- Il sottoprocesso Attempt copy last logs (ACLL) tenta di copiare tutti i file di registro mancanti dal server che ha ospitato l’ultima copia attiva del database.
- Al termine del processo ACLL, viene controllato un valore AutoDatabaseMountDial per i server che ospitano copie del database e viene confrontato con la lunghezza della coda di copia del database attivato. Se il numero di file di registro mancanti è minore o uguale al valore di AutoDatabaseMountDial, AM passa al passaggio cinque. In caso contrario, AM avvierà questo processo al secondo passaggio.
- Il PAM invia una richiesta di montaggio all’archivio informazioni. Se il database non viene montato, AM torna al passaggio due.
C’è qualche logica aggiuntiva in questo processo se l’evento di failover è innescato da un evento di monitoraggio. La logica aggiuntiva garantirà che il server che prende in consegna il database attivo sia in condizioni migliori rispetto al server da cui proviene.
Modalità quorum DAG
Un DAG è un’implementazione specifica di un cluster di Windows Server. I componenti di Exchange di DAG si basano sulla tecnologia Cluster di Windows Server sottostante per funzionare. Il concetto di quorum è essenziale per capire come implementare e gestire i DAG.
Quorum è l’idea che, in caso di fallimento di alcuni membri DAG, ci sono regole per governare quali risorse i membri rimanenti possono fornire. Questi set di regole quorum esistono per fornire un funzionamento coerente di un DAG e fungere da tie-break in situazioni in cui i nodi DAG perdono la comunicazione tra loro.
Quando un DAG ha un numero pari di nodi, utilizza il nodo & Modalità quorum di maggioranza condivisione file. In questa modalità, un server testimone esterno funge da tie-break. Quando si esegue in questa modalità, ogni membro del nodo DAG ottiene un singolo voto, ma il server witness fornisce a uno dei nodi DAG un voto aggiuntivo. I dati del quorum del cluster vengono memorizzati sul disco di sistema locale di ciascun membro, ma il server witness dispone di un file separato che punta a un membro DAG come copia più aggiornata dei dati del quorum del cluster DAG.
Quando un DAG ha un numero dispari di membri, utilizza la modalità quorum di maggioranza dei nodi. In questa modalità, ogni membro DAG ottiene un voto e il disco di sistema locale di ciascun membro viene utilizzato per memorizzare i dati del quorum del cluster.
È possibile assegnare manualmente specifici membri DAG con voti quorum ponderati. In questo modo non è raccomandato nella maggior parte dei casi e dovrebbe essere fatto solo dopo consultazione diretta con il supporto Microsoft.
Modalità di coordinamento attivazione Datacenter
La modalità DAC (Datacenter Activation Coordination) è una funzionalità dei DAG progettata per prevenire situazioni in cui un’interruzione causa la presenza di due copie di un database su due server diversi. La modalità DAC richiede un intervento manuale quando il server che ospita il database non può raggiungere la maggior parte dei server membri DAG.
Le best practice di Microsoft richiedono l’attivazione della modalità DAC su qualsiasi DAG con due o più membri e che utilizza la replica continua. Gli unici casi in cui la modalità DAC per un DAG non è raccomandata sarebbero se l’amministratore stesse utilizzando uno strumento di replica di terze parti.
Quando il DAC è attivo, vi è una comunicazione aggiuntiva tra i nodi DAG all’avvio che utilizzano il protocollo DAC (DACP). DACP è impostato su 0 all’avvio. Se il bit DACP rimane a 0, AM non tenterà di avviare alcun database su quel nodo. Il bit DACP può anche essere impostato su 1 se un altro membro DAG ha il suo bit DACP impostato su 1 o quando un nodo DAG può contattare tutti i server nella sua lista di appartenenza DAG.
La modalità DAC è utile quando un data center primario si guasta completamente e viene attivato un data center di backup. Quando l’alimentazione ritorna e i server arrivano prima che la connessione WAN (Wide Area Network) torni online, la modalità DAC impedisce che copie diverse degli stessi database finiscano attive in entrambi i data center.
Per un DAG con due nodi, la modalità DAC utilizza un confronto tra il tempo di avvio del server witness alternativo e il tempo in cui il bit DACP è stato impostato su 1 per determinare se può montare database. Se il bit DACP è stato impostato su 1 prima del tempo di avvio del server witness alternativo, il sistema presuppone che i due server siano stati riavviati contemporaneamente, probabilmente a causa di un’interruzione di corrente nel data center primario, e che il membro DAG non sia autorizzato a montare i database. Se il bit DACP è stato impostato su 1 dopo l’avvio del server witness alternativo, il sistema presuppone che sia sicuro montare i database.
DatabaseAvailabilityGroup cmdlets and split-brain conditions
Split brain è una situazione in cui due copie diverse dello stesso database diventano attive contemporaneamente in data center diversi. Quando ciò accade, le due diverse copie del database divergono, causando la potenziale perdita di dati utente quando le due copie diverse tentano di riconciliarsi.
Oltre a prevenire le condizioni di split-brain, la modalità DAC consente di avviare, arrestare e ripristinare i cmdlet di DatabaseAvailabilityGroup. Questi cmdlet vengono utilizzati per eseguire commutazioni manuali del data center. Quando la modalità DAC non è attiva, il processo di un data center manuale è complesso e coinvolge sia gli strumenti di Exchange che un gestore di cluster.
Immaginate una situazione in cui un ambiente Exchange è costituito da quattro server, ognuno con una copia dello stesso database. Due di questi server si trovano nel data center A e due nel data center B. Si verifica un errore di rete nel collegamento tra i due data center. Senza la modalità DAC abilitata, sarebbe possibile che i server di ogni data center pensassero di aver bisogno di attivare una copia del database.
La modalità DAC impedisce questo scenario split-brain richiedendo la maggioranza dei nodi prima che un database possa essere attivato. Maggioranza dei nodi significa che la maggior parte dei nodi nel cluster-o DAG in questo caso-deve essere online e raggiungibile affinché un nodo DAG possa attivare una copia del database. Se nel DAG è presente un numero pari di nodi, il file share witness funzionerà anche come membro votante per determinare la maggioranza del nodo.
Nel caso descritto sopra con un cluster a quattro nodi e due nodi in ciascun data center, solo i server Exchange nel data center con il file share witness sarebbero in grado di attivare i database. Ai nodi DAG dell’altro data center sarebbe impedito di attivare qualsiasi database finché non fossero in grado di contattare tutti i server elencati come membri del DAG.
Third-site witness
Una funzionalità aggiunta a Exchange nell’era 2013 era il supporto per un third-site witness, che ha il potere di portare tutte le risorse online senza l’intervento dell’amministratore. Quando ogni sito ha un percorso di rete indipendente per il terzo sito testimone, i nodi in un sito possono mantenere il quorum utilizzando il server testimone. L’aspetto negativo dell’utilizzo di un testimone di un terzo sito è che gli amministratori di Exchange devono prendere il tempo necessario per scavare e comprendere a fondo il loro comportamento di rete.
Bilanciamento del carico
Il bilanciamento del carico è un modo per gli amministratori di gestire il traffico di rete che finisce per essere diretto a ciascun server Exchange all’interno di una rete. Di solito, è auspicabile gestire la distribuzione delle connessioni client in entrata tra i server Exchange 2016 per due motivi:
- Per distribuire il carico di lavoro. Se qualcuno sta per andare alla briga di impostare e mantenere più server di Exchange, è una buona idea avere tutti quei server di Exchange fare un po ‘ di lavoro su base regolare.
- Per ridurre l’impatto di un guasto. Quando qualcosa va storto, è bello avere un sistema ridondante per assumere il carico di lavoro del sistema fallito.
Il bilanciamento del carico integra i DAG. Il compito di un DAG è: (1) assicurarsi che ci siano più copie di ogni casella di posta pronta per essere attivata e (2) accettare le richieste del client nel caso in cui la copia attiva non sia disponibile. Il bilanciamento del carico funziona più o meno allo stesso modo; il suo compito è assicurarsi che ci siano altri posti in cui inviare il traffico client se un posto non fosse disponibile.
Il bilanciamento del carico può estendersi tra due o più server Exchange in un singolo sito o può estendersi su più siti. Una distribuzione di Exchange PA (Preferred Architecture) includerebbe quattro server Exchange distribuiti su due siti di annunci separati. Le versioni attuali di Exchange supportano il bilanciamento del carico round-robin Layer 4, Layer 7 e Domain Name system (DNS).
Exchange Preferred Architecture
Exchange PA è la distribuzione di Exchange ideale, come previsto dal team Exchange di Microsoft. Il PA è sviluppato con costo totale di proprietà (TCO), HA, resilienza, ridondanza e recupero in mente. Il PA non è destinato ad essere utilizzato come modello di maturità; è stato progettato per essere utilizzato come ispirazione.
Client Exchange Server
Gli utenti Exchange accedono e interagiscono con i messaggi tramite un client di posta elettronica. Microsoft Outlook è il client più comune. Exchange Server 2016 supporta anche quanto segue:
- Outlook 2016
- Outlook 2013
- Outlook 2010 Service Pack 2 (SP2)
- Outlook per Mac di Office 365
- Outlook per Mac 2011
Outlook è disponibile anche come applicazione web-based, chiamato Outlook sul web — precedentemente Outlook Web App e comunemente abbreviato con OWA — per gli utenti di accedere e interagire con i messaggi da molti browser diversi. Outlook on the web consente agli utenti di collegare e condividere i documenti archiviati in OneDrive for Business in un server SharePoint locale. Ciò crea un modo più semplice e diretto per gli utenti finali di salvare e allegare file alle e-mail.
Pro e contro di Exchange Server
Mentre è facile parlare dei pro dell’utilizzo di Microsoft Exchange, può essere difficile identificare eventuali svantaggi, oltre ai costi di licenza. In questo momento, ci sono pochi competitors se non del tutto competitors veri concorrenti da scambiare.
Exchange on-premises-tutte le versioni contate insieme-probabilmente ha la più grande base di utenti attivi, ma Microsoft non pubblica pubblicamente numeri sul numero di utenti attivi in Exchange on-premises o Exchange Online. Outlook.com ora funziona su Exchange, quindi Exchange on-premises, Exchange Online e Outlook.com probabilmente hanno più utenti totali (business e personale) di Gmail (business e personale). Qualsiasi altra piattaforma di messaggistica concorrente dopo le offerte di Microsoft e Google ha basi di utenti aziendali relativamente piccole.
Dopo le piattaforme di messaggistica aziendale di Microsoft e Google, la soluzione più grande in termini di base di utenti installata è probabilmente Lotus Notes. I confronti tra Notes e Exchange sono difficili perché Notes non è principalmente una soluzione di messaggistica. Lotus Notes è una soluzione di database che include funzionalità di messaggistica. Inoltre, a partire dal 30 giugno 2019, IBM ha venduto la proprietà di Lotus Notes a HCL e non aggiornerà più quel prodotto.
Zimbra è la più grande soluzione di messaggistica basata su Linux. Sono disponibili soluzioni Zimbra basate su SCSI (SAS) on-premise e Serial-Attached. Ci sono versioni open source di Zimbra disponibili, che includono diverse opzioni di licenza.
Tutte le diverse soluzioni di messaggistica con diverse caratteristiche e si concentra rendono un confronto pro e contro dritto difficile. Di seguito sono riportati alcuni confronti pro e contro di alto livello. Questi elenchi non sono destinati ad essere definitivi.
Exchange on-premises vs. Exchange Online
La scelta più comune per le aziende alla ricerca di una soluzione di messaggistica sarà tra Exchange on-premises e Exchange Online.
| Exchange locale | |
| Pro | Contro |
|
gli Amministratori possono controllare la pianificazione di aggiornamento e la disponibilità |
riparazioni Hardware sono le responsabilità dell’amministratore |
|
Una volta tassa di concessione delle licenze |
Deve essere gestito a livello locale, on-site |
| Nessuno al di fuori dell’organizzazione ha accesso a un server o a dati | costi di Hardware e software devono essere ammortizzati |
| in Linea di Exchange | |
| Pro | Contro |
| Non c’è bisogno di manutenzione del sistema hardware e software | Inflessibile soluzione |
| licenza Mensile di spesa | Potenziale perdita di controllo dei propri dati |
| 99.9% uptime del contratto di servizio (SLA) | Potenzialmente più costoso |
| Potenzialmente richiede talmente semplice mantenere aggiornati i relativi software on-premise aggiornato | |
Exchange Online vs Gmail
| Exchange Online | |
| Pros | Con |
| Integration with other Office 365 applications | More expensive than Gmail |
| Hybrid integration with Exchange on-premises | |
| Gmail | |
| Pro | Cons |
| Less expensive than Exchange Online | Less complete suite of software |
| No hybrid options | |
| Nessuna integrazione AD | |
Microsoft Exchange Online
Microsoft offre Exchange come offerta SaaS denominata Exchange Online. È disponibile come servizio autonomo o come parte della suite Office 365. Gli utenti finali si connettono a Exchange Online tramite il client Outlook o Outlook sul web. Gli amministratori con autorizzazioni amministrative di Office 365 configurano e gestiscono il servizio. Microsoft offre Exchange come servizio ospitato per ridurre il lavoro amministrativo coinvolto nelle distribuzioni locali di Exchange.
Prezzi di Exchange Server
I prezzi di Exchange Server possono variare ampiamente in base a come viene acquistato e quale versione viene acquistata.
Exchange on-premise viene venduto su base server. Inoltre, è necessaria una licenza di accesso client (CAL) per ogni utente che accede a Exchange. Exchange Server deve essere installato su un server che esegue il sistema operativo Windows Server, che deve anche essere concesso in licenza con un modello CAL per server plus. Il server deve essere installato in una foresta di ANNUNCI con almeno un DC.
Exchange Server stesso è disponibile in due livelli di licenza: Standard ed impresa. I CALS di scambio vengono anche in Standard e Enterprise. Ogni utente deve disporre di una CAL standard di Windows Server e può avere una CAL Enterprise per funzionalità aggiuntive. Sia il CALs standard che Enterprise possono essere utilizzati con entrambe le versioni server.
Exchange Online viene venduto per utente al mese come offerta autonoma o come parte di un pacchetto Office 365. Ci sono due piani autonomi. Exchange Online Plan 1 4 4 per utente, al mese offers offre e-mail aziendali sicure e disponibili, con una cassetta postale da 50 GB per utente. Exchange Online Plan 2 8 8 per utente, al mese builds si basa sul Piano 1 e include archiviazione illimitata, segreteria telefonica ospitata e funzionalità DLP (Data Loss Prevention).
Cronologia di Exchange Server
Exchange Server è stato rilasciato per la prima volta in anteprima privata nel 1993. Nel 1996, la prima versione disponibile pubblicamente di Exchange Server è stato rilasciato come Exchange 4.0. Il numero di versione 4.0 nella prima versione di Exchange doveva significare che era l’aggiornamento da Microsoft Mail 3.5, ma questi erano due programmi drasticamente diversi. Exchange 4.0 ha utilizzato la X.protocollo 500 per i servizi di directory e la consegna della posta.
Nel 1997 è stato rilasciato Exchange 5.0. Questa è stata la prima versione di Exchange a presentare Simple Mail Transfer Protocol (SMTP) come Mail Server Delivery Protocol. SMTP ha reso Exchange 5.0 la prima versione in grado di comunicare con altre piattaforme di messaggistica su Internet. Exchange 5.0 ha anche introdotto OWA in Exchange 5.0 in un service pack post-release.
Exchange 5.5 è stato rilasciato meno di un anno dopo Exchange 5.0 ed è stata la prima versione di Exchange a venire nelle edizioni Standard ed Enterprise. Scambio 5.5 incluso anche l’introduzione di recupero per gli elementi eliminati e il supporto per Internet Message Access Protocol 4 (IMAP4) e Lightweight Directory Access Protocol (LDAP) v3 client.
Exchange Server 2000 è stato rilasciato due anni dopo in concomitanza con il rilascio di AD. Exchange 2000 includeva una funzione di messaggistica istantanea che è stata successivamente scorporata su Office Communications Server. Exchange Server 2000 non è stato ampiamente adottato.
Exchange Server 2003 è stato un enorme passo avanti per Exchange, sia in termini di funzionalità che di adozione. Exchange Server 2003 ha iniziato la tendenza di differenziare diversi server di Exchange per soddisfare diverse funzioni. Mentre lo stesso software è stato installato su tutti i server di Exchange, 2003 ha sostenuto l’idea di designare alcuni server come server front-end per ospitare le connessioni client. Exchange 2003 ha anche reso molto più semplici le migrazioni dalle versioni precedenti di Exchange consentendo la coesistenza dei server 2003 in organizzazioni che eseguivano ancora versioni precedenti.
Exchange Server 2007 era un’altra versione importante che includeva molte nuove funzionalità. Al momento del rilascio, Exchange 2007 non supportava le cartelle pubbliche, ma tale supporto veniva restituito con Service Pack 1 (SP1) dopo i reclami dei clienti. Exchange 2007 è stato il primo grande prodotto Microsoft ad abbracciare completamente PowerShell. Per la prima volta, tutte le funzionalità di Exchange erano disponibili come comandi PowerShell, anche se alcune funzionalità non avevano controlli di interfaccia utente grafica (GUI).
Exchange 2007 ha anche introdotto il concetto di ruoli Server Exchange completamente separati. Il 2007 includeva cinque diversi ruoli di Exchange Server con software separato installato sul server fisico. Quattro di questi ruoli potrebbero essere installati su un singolo server fisico se lo si desidera, ma ogni ruolo potrebbe essere installato anche sul proprio server fisico.
Exchange 2007 ha anche introdotto UM per fornire servizi di telefonia “dopo la risposta alla chiamata” e ha incluso più opzioni di database HA. Queste opzioni, che includevano diversi modi per creare un cluster di database, hanno finito per essere complicate e confuse da distribuire e mantenere.
Exchange 2010 era una versione minore di Exchange Server. Il principale cambiamento in Exchange Server 2010 è stata l’introduzione del DAG e la deprecazione delle complicate opzioni di clustering da Exchange 2007. Exchange 2010 ha incluso e migliorato la separazione dei ruoli del server da Exchange 2007 e ha migliorato le opzioni di bilanciamento del carico disponibili per una migliore disponibilità di accesso client. Office 365 è stato rilasciato per la prima volta durante l’intervallo di tempo di Exchange 2010 e Exchange 2010 ha incluso la prima funzionalità ibrida di Exchange tra Exchange on-premises e Exchange Online.
Scambio 2013 è stato rilasciato il ott. 11, 2012, insieme alle nuove versioni di SharePoint e Skype for Business. Questa versione ha significato l’intenzione di Microsoft di creare un’integrazione più stretta tra i tre prodotti Office Server e le loro versioni online di Office 365. Le cassette postali del sito sono state introdotte in Exchange 2013 e includevano funzionalità che consentivano l’accesso alle cassette postali di Exchange e al contenuto di SharePoint insieme.
Exchange 2013 ha incluso una modifica significativa alle cartelle pubbliche chiamate cartelle pubbliche moderne. Mentre la funzionalità di base delle cartelle pubbliche è rimasta la stessa, l’architettura dietro le quinte è stata modificata per includere le cartelle pubbliche negli stessi database delle cassette postali delle cassette postali degli utenti. Durante il ciclo di vita di Exchange 2013, i clienti Microsoft hanno iniziato a chiedersi se Microsoft avrebbe continuato a sviluppare nuove versioni di Exchange on-premises o avrebbe supportato solo Exchange Online. La speculazione si è verificata principalmente perché le nuove funzionalità di Exchange hanno iniziato a comparire prima in Exchange Online e poi lo avrebbero trasformato in versioni locali del software.
Exchange 2016 ha rimosso la possibilità di installare ruoli Server Exchange separati su server fisici separati, ad eccezione del ruolo di trasporto Edge.
Exchange Server 2019 includeva la possibilità di installare Exchange Server su Windows Server Core. Questa è stata la prima versione di Exchange che poteva essere eseguita e gestita con una GUI. Tutte le funzionalità UM sono state rimosse da Exchange 2019 in questa versione e sono state aggiunte nuove funzionalità per Exchange 2019.
Versioni di Exchange Server
Il seguente elenco mostra la progressione della versione di Exchange Server con la data di rilascio e la compilazione del software corrispondenti:
- Exchange Server 4.0 Standard Edition è stato rilasciato per la prima volta l ‘ 11 giugno 1996, come build 4.0.837.
- Exchange Server 5.0 è stato rilasciato per la prima volta il 23 maggio 1997, come build 5.0.1457.
- Exchange Server 5.5 è stato rilasciato per la prima volta febbraio. 3, 1998, come build 5.5.1960.
- Exchange 2000 Server è stato rilasciato per la prima volta novembre. 29, 2000, come build 6.0.4417.
- Exchange Server 2003 è stato rilasciato per la prima volta settembre. 28, 2003, come build 6.5.6944.
- Exchange Server 2007 è stato rilasciato per la prima volta l ‘ 8 marzo 2007, come build 8.0.685.25.
- Exchange Server 2010 è stato rilasciato per la prima volta novembre. 9, 2009, come build 14.00.0639.021.
- Exchange Server 2013 è stato rilasciato per la prima volta dicembre. 3, 2012, come costruire 15.00.0516.032.
- Exchange Server 2016 è stato rilasciato per la prima volta ottobre. 1, 2015, come costruire 15.01.0225.042.
- Exchange Server 2019 è stato rilasciato per la prima volta ottobre. 14, 2018, come costruire 15.2.221.12.