exchange_it

Annuncio di Analizzatore connettività Microsoft 1.0 e Analizzatore connettività remota Microsoft 2.1

OfficeLocalization — Thu, 09 May 2013 06:25:47 GMT

Articolo originale pubblicato martedì 12 marzo 2013

Già a novembre 2012 avevamo annunciato il client Analizzatore connettività Microsoft Beta. Da allora abbiamo lavorato intensamente per migliorare le opzioni di testing disponibili con tale client. Ecco cosa vi offriamo con la versione 1.0:

Strumento Analizzatore connettività Microsoft 1.0

Siamo lieti di annunciare la versione 1.0 di Analizzatore connettività Microsoft. Tale strumento è complementare al sito Web Analizzatore connettività remota Microsoft e consente ad amministratori e utenti finali di eseguire la diagnostica della connettività per cinque sintomi di connettività comuni direttamente dal rispettivo computer locale. Gli utenti possono testare la loro connettività e salvare i relativi risultati in un formato HTML riconoscibile dagli amministratori che visualizzano i risultati nel sito Web Analizzatore connettività remota.

Installate lo strumento Analizzatore connettività Microsoft 1.0 dall'indirizzo Web seguente: https://testconnectivity.microsoft.com/?tabid=client

Guardate il video introduttivo:

Lo strumento Analizzatore connettività Microsoft offre cinque test relativi ad altrettanti sintomi:

"Non posso accedere con Office Outlook" (I can't log on with Office Outlook). Questo test equivale al test "Outlook Anywhere (RPC su HTTP)" di Analizzatore connettività remota di Exchange. È disponibile un'opzione per eseguire il test SSO fornito nella pagina dei parametri.
"Non posso inviare o ricevere e-mail sul mio dispositivo mobile" (I can't send or receive email on my mobile device). Questo test equivale al test di Analizzatore connettività remota di Exchange per Exchange ActiveSync.
***Nuovo test di Analizzatore connettività Microsoft*** "Non posso accedere a Lync sul mio dispositivo mobile o all'app Lync Windows Store" (I can't log on to Lync on my mobile device or the Lync Windows Store app). Questo test consente di ricercare i record DNS (Domain Name Server) relativi al dominio locale per verificare che siano configurati correttamente per supportare i client di Mobile Lync. Consente inoltre di connettersi al servizio Web di individuazione automatica e verificare che l'autenticazione, il certificato e il servizio Web per dispositivi mobili siano impostati in modo adeguato.
***Nuovo test di Analizzatore connettività Microsoft*** "Non posso inviare o ricevere posta elettronica da Outlook (solo Office 365)" (I can't send or receive email from Outlook (Office 365 only)). Questo test consente di verificare il flusso di posta SMTP in ingresso e in uscita e inoltre include verifiche di convalida DNS per i clienti di Office 365.
***Nuovo test di Analizzatore connettività Microsoft*** "Non posso visualizzare le informazioni sulla disponibilità di un altro utente" (I can't view the free/busy information of another user). Questo test consente di verificare che una cassetta postale di Office 365 possa accedere alle informazioni sulla disponibilità di una cassetta postale locale e viceversa. A ogni esecuzione del test viene verificata una sola direzione.

Strumento Microsoft Lync Connectivity Analyzer. Nella pagina del client si noterà inoltre lo strumento Lync Connectivity Analyzer. Stiamo lavorando per consentire un utilizzo combinato di Analizzatore connettività Microsoft e MLCA nel prossimo futuro, ma nel frattempo desideravamo rendere disponibili entrambi questi fantastici strumenti per i clienti fin d'ora allo scopo di migliorare le nostre opzioni di diagnostica client. Per ulteriori informazioni su MLCA, fare clic QUI.

Commenti e suggerimenti. Inviate qualsiasi commento e suggerimento all'alias MCA Feedback. Saremo felici di sapere cosa pensate di questo strumento e se sarà utile per la risoluzione dei problemi relativi agli scenari di connettività. Non esitate inoltre a segnalarci eventuali test aggiuntivi che vorreste fossero aggiunti in futuro.

Analizzatore connettività remota Microsoft 2.1

Siamo lieti di annunciare la versione 2.1 del sito Web Analizzatore connettività remota Microsoft. Questo strumento consente ad amministratori e utenti finali di eseguire la diagnostica della connettività per i nostri server in modo da verificare problemi comuni relativi a Exchange, Lync e Office 365. Abbiamo aggiunto nuovi test DNS di Office 365, migliorato i test esistenti e ottimizzato l'esperienza di utilizzo del sito nel suo complesso.

Per controllare la disponibilità di aggiornamenti per il sito Web, visitate la pagina Web all'indirizzo seguente: https://testconnectivity.microsoft.com

Ecco le principali modifiche apportate nella versione 2.1 di Analizzatore connettività remota:

Versione 2.1 (marzo 2013)

È stato aggiunto il supporto per 60 lingue localizzate.
È stata aggiornata la versione dello strumento Analizzatore connettività Microsoft 1.0 scaricabile per la risoluzione dei problemi di connettività dal computer locale.
È stato aggiunto lo strumento Microsoft Lync Connectivity Analyzer scaricabile per la risoluzione dei problemi di Lync dal computer locale.
È stata aggiunta una sezione di test generici di Office 365.
È stato aggiunto il test di connettività DNS di Exchange per Office 365.

Buon divertimento.

Grazie.

Brian Feck per conto dell'intero team di Analizzatore connettività Microsoft/Analizzatore connettività remota
Seguite il team su Twitter - @ExRCA

Questo è un post di blog localizzato. L'articolo originale è disponibile in Announcing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1.

Ora disponibili le istruzioni su hosting e multi-tenancy per Exchange Server 2013

OfficeLocalization — Thu, 09 May 2013 06:25:45 GMT

Articolo originale pubblicato giovedì 21 febbraio 2013

Siamo lieti di poter annunciare il tanto richiesto documento di istruzioni sull'hosting e la multi-tenancy per Exchange Server 2013 (Hosting and Multi-Tenancy Guidance for Exchange Server 2013), scaricabile facendo clic qui.

Come i lettori più attenti osserveranno, è molto simile al documento di istruzioni per Exchange Server 2010 e non perché ci siamo limitati a ricercare, copiare e sostituire il contenuto già esistente, ma perché la strategia decisa per Exchange 2010 è valida anche per Exchange 2013. In altri termini, sarà sufficiente utilizzare gli strumenti, i cmdlet e le interfacce incorporati per configurare una soluzione e in nessun caso sarà necessario intervenire direttamente sugli oggetti in Active Directory per ottenere la configurazione desiderata.

Altrettanto vero è inoltre il concetto che non tutte le funzionalità si comporteranno come auspicato in una configurazione multi-tenant. Suggerimenti messaggio ad esempio funzionerà esattamente come funziona in una distribuzione locale standard e questo in genere può causare l'esposizione di dati indesiderati tra i tenant. Nel documento vengono poste in evidenza le funzionalità che potrebbero non avere il comportamento sperato se si configura Exchange per la multi-tenancy e vengono forniti consigli per la configurazione o la disabilitazione, quando necessaria.

Alla base dell'importante elemento di segmentazione directory della soluzione si trova la funzionalità Criteri rubrica. Con il recente annuncio di un agente di trasporto, creato per sfruttare Criteri rubrica, ci auguriamo che la soluzione 2013 risulti persino più facile da sviluppare e gestire.

Per la versione 2013 sono state apportate alcune modifiche significative, pertanto vi invitiamo a leggere per intero il documento di istruzioni prima di pianificare e creare la soluzione e di farvi riferimento in caso di problemi.

Come per Exchange 2010, disponiamo di soluzioni partner realizzate seguendo le linee guida riportate nel documento e le soluzioni attualmente convalidate sono inoltre elencate nel sito. Tale elenco è destinato a estendersi, perciò controllatelo con regolarità per trovare la soluzione desiderata oppure contattate il fornitore e chiedetegli per quando è prevista la relativa convalida.

Abbiamo in programma di pubblicare le istruzioni aggiornate sulla scalabilità per Exchange 2013 configurato per la multi-tenancy o l'hosting, pertanto aggiorneremo il sito delle soluzioni non appena tale documento sarà disponibile.

Speriamo che questo documento vi sia utile e aspettiamo con ansia i vostri commenti e suggerimenti.

Greg Taylor
Principal Program Manager Lead
Exchange Customer Experience

Questo è un post di blog localizzato. L'articolo originale è disponibile in Hosting and Multi-Tenancy Guidance for Exchange Server 2013 Now Available.

Misterioso ciclo di posta nel server Trasporto Edge: verificare i limiti di dimensione

OfficeLocalization — Thu, 09 May 2013 06:25:00 GMT

Articolo originale pubblicato venerdì 29 marzo 2013

Sono un addetto all'assistenza nell'ambito del Servizio Supporto Tecnico Clienti. Stavo lavorando con un cliente che aveva segnalato come errore un ciclo di posta per un dominio specifico come contoso.com. Era possibile osservare questo errore solo con messaggi di posta elettronica di grandi dimensioni. Questa situazione è veramente misteriosa finché non si comprende che il ciclo di posta dipende dalla restrizione relativa alla dimensione configurata nel connettore di invio. Ho pensato che tale episodio fosse sufficientemente curioso da condividerlo con voi.

Comprensione della configurazione e della causa principale del problema

Ho pensato inizialmente che l'errore dipendesse dal fatto che il server perimetrale (Edge) fosse configurato per l'utilizzo di un server DNS esterno, ovvero di un server DNS che risolve gli host esterni. Quando il server Trasporto Edge è configurato per l'utilizzo di un server DNS esterno, in genere risolve il nome del dominio come indirizzi IP pubblici (che di solito puntano al server stesso, al firewall esterno o al provider del servizio) anziché come server Trasporto Hub del sito di Active Directory, dando luogo a un ciclo di posta.

Riproducendo il problema, ho scoperto che il server Trasporto Edge non era configurato per l'utilizzo di un server DNS esterno. L'ambiente che ho allestito per riprodurre il problema era simile a quello illustrato nel diagramma riportato di seguito.

Ecco cosa accade in questo scenario: quando il server Trasporto Edge riceve un messaggio di posta elettronica di 20 MB da un mittente Internet, lo accetta. Tale server dispone di due connettori per cui viene trovata una corrispondenza con lo spazio degli indirizzi, uno per lo spazio degli indirizzi da contoso.com al sito di Active Directory e uno per lo spazio degli indirizzi *. Quando viene presa la decisione relativa al routing in base a tutti i connettori disponibili, quello che va da Edge a Hub non viene considerato a causa della restrizione relativa alla dimensione, ovvero del limite di 10 MB. La corrispondenza migliore è rappresentata dal connettore * che va da Edge a Internet e che prevede 30 MB come limite di dimensione per i messaggi. Rivedere l'algoritmo di selezione dei connettori illustrato in Informazioni sul routing dei messaggi.

Risultato finale: il messaggio viene reinstradato a Internet, generando un ciclo tra Internet e il server perimetrale (Edge).

A seconda del fatto che il connettore di invio verso Internet sia configurato per l'utilizzo di DNS o di uno smart host per recapitare la posta in uscita, si riceverà uno dei rapporti di mancato recapito riportati di seguito.

In caso di utilizzo di DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; i record DNS per questo dominio sono configurati in un ciclo ## (#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##)

In caso di utilizzo di uno smart host:

5.4.6 smtp;554 5.4.6 Superato conteggio hop - possibile ciclo di posta> #SMTP# (5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#)

Soluzione

Questo comportamento è da progettazione e può essere facilmente corretto modificando il limite di dimensione dei messaggi nel connettore. In base alle proprie necessità, è possibile scegliere una delle opzioni seguenti:

Impostare il parametro MaxMessageSize nel Connettore di ricezione (che riceve la posta in ingresso da Internet) su 10MB, in modo che i messaggi provenienti da Internet abbiano come limite 10 MB.
Impostare il parametro MaxMessageSize nel Connettore di invio dal server perimetrale (Edge) all'hub su 30MB, in modo che sia possibile ricevere messaggi da 30 MB da mittenti esterni.

Mistero risolto! Grazie ad Arindam Thokder e Scott Landry, che mi hanno aiutato a preparare questo post per il blog.

Suresh Kumar (XCON)

Questo è un post di blog localizzato. L'articolo originale è disponibile in Mysterious mail loop on Edge Transport server: Check your size limits!.

Aumento del limite di destinatari a 10.000 per Office 365 e Exchange Online

OfficeLocalization — Thu, 31 Jan 2013 11:44:47 GMT

Articolo originale pubblicato giovedì 27 dicembre 2012

In risposta ai suggerimenti dei nostri clienti, abbiamo aumentato il limite di destinatari per Office 365 Enterprise (E1, E2, E3, E4, K1 e K2), per professionisti e piccole imprese (P1) e piani Government (G1, G2, G3 e G4) per consentire agli utenti di inviare e-mail fino a 10.000 destinatari al giorno. Questi nuovi limiti si applicano inoltre ai piani individuali di Exchange Online (Chioschi, Piano 1 e Piano 2). In precedenza, il limite massimo per gli utenti di questi piani era pari a 1.500 destinatari al giorno.

Il limite di destinatari ha lo scopo di evitare che gli utenti inviino grandi quantità di e-mail commerciali non richieste, anche note con il nome spam. Questi limiti fanno in modo che il nostro servizio online non divenga una fonte di spam, e in tal modo viene protetto anche il flusso di e-mail dei clienti. I miglioramenti apportati nei data center ci hanno consentito di aumentare questo limite, offrendo lo stesso livello di protezione.

Questi limiti si applicano sia ai messaggi di posta elettronica inviati all'interno dell'organizzazione, sia a quelli inviati all'esterno. Per evitare di superare il limite massimo di destinatari è quelo di usare gruppi di distribizione quando si inviano messaggi a molti destinatari. I gruppi di distribuzione memorizzati nella rubrica condivisa, infatti, contano come un solo destinatario nel conteggio del limite. Per maggiori informazioni, vedere Strategie di supporto alla posta elettronica in blocco. I clienti di Office 365 che hanno bisogno di inviare messaggi di posta elettronica commerciali in blocco, ad esempio newsletter, devono continuare a servirsi di fornitori esterni specializzati in questo servizio.

Per maggiori informazioni sul limite di destinatari, vedere Limiti per numero di destinatari giornalieri e posta elettronica in blocco. Abbiamo apportato questa modifica grazie ai vostri suggerimenti. Grazie per il vostro supporto, e continuate a condividere con noi le vostre opinioni.

Steve Chew

Questo è un post di blog localizzato. L'articolo originale è disponibile in Recipient Rate Limit Increase to 10K for Office 365 and Exchange Online

Le numerose novità dell'Analizzatore connettività remota di Microsoft

OfficeLocalization — Thu, 31 Jan 2013 11:44:00 GMT

Articolo originale pubblicato martedì 20 novembre 2012

Avete mai ricevuto una chiamata da una persona che conoscete, e il cui client Outlook ha problemi a connettersi al server della posta elettronica? Non sarebbe utile avere uno strumento a disposizione che faccia eseguire passo passo un test di connettività, così che voi possiate analizzare i risultati?

O forse siete amministratori e usate l'Analizzatore connettività remota da anni per verificare la configurazione della posta elettronica, ma vorreste avere uno strumento che vi consenta di eseguire gli stessi test dall'interno dell'organizzazione, e che disponga degli stessi dettagli diagnostici del sito Web dell'Analizzatore connettività remota.

Abbiamo ricevuto molte richieste di questo tipo, e così il nostro team ha sviluppato uno strumento utile in questi casi. In questo articolo vi presento l'Analizzatore connettività di Microsoft (beta), una versione portatile del sito Web Analizzatore connettività remota. Ecco un breve video di 49 secondi che illustra l'Analizzatore connettività di Microsoft.

Questo strumento include gli stessi test presenti nel sito Web, ma con un'interfaccia leggermente semplificata, che potete condividere con gli utenti, la famiglia, o anche il vicino di casa.

Abbiamo inoltre suddiviso i risultati in due visualizzazioni: una visualizzazione semplificata in cui sono mostrati i risultati chiave, così che anche le mamme possono capirli, e una visualizzazione più complessa che mostra i risultati dettagliati, fatta apposta per gli amministratori (sì, proprio per voi).

I dettagli completi per gli amministratori sono visualizzati in "Review all the tests we ran" (Visualizza tutti i test eseguiti):

Potete inoltre chiedere agli utenti di salvare i risultati dettagliati e inviarli a voi. Questi risultati sono salvati in un file HTML visualizzabile nel browser.

Prerequisiti dell'Analizzatore connettività di Microsoft

Lo strumento supporta i seguenti sistemi operativi: Windows 7 a 64bit, Windows 7, Windows Server 2008+
Microsoft .NET Framework 4.5 è obbligatorio.
Requisiti per i browser:

L'installazione è supportata da tutti i browser attuali. Tuttavia…

Se utilizzate Google Chrome, dovete installare ClickOnce per Google Chrome

Se utilizzate FireFox, dovete installare Microsoft .Net Framework Assistant per FireFox.

Le note complete sulla versione si trovano qui.

E questo non è ancora tutto: abbiamo in programma di aggiungere altri test.

Analogamente alla prima versione del sito Web, la prima versione dell'Analizzatore connettività di Microsoft è sempre un "work in progress".

Grazie a uno strumento in locale presso l'utente finale, siamo in grado di ampliare i test in modo da includere alcuni problemi comuni a tutti i tipi di connettività. Questa prima versione dello strumento è solo l'inizio.

Ma non finisce qui.

Oltre a creare un nuovo strumento, abbiamo utilizzato l'Analizzatore connettività remota di Lync e unito i due strumenti. Noterete che la parola “Exchange” è scomparsa dal nome, e al sito Web si accede ora dall'indirizzo http://testconnectivity.microsoft.com. Avete capito bene: i test di Lync e Exchange sono disponibili nello stesso sito Web!

Ecco alcuni dei test:

Il Test di connettività remoto del servizio Web di individuazione automatica Lync Mobile testa la connettività remota al servizio Web di individuazione automatica Lync Mobile
Il Test di Microsoft Office Communications Server testa la connettività remota a Microsoft Office Communications Server, rileva automaticamente l'Access Edge e la porta per la connessione, OPPURE consente di specificare un server Access Edge specifico.
Il Test di connettività remoto Lync Server testa la connettività remota a Lync Server, rileva automaticamente l'Access Edge e la porta per la connessione, OPPURE consente di specificare un server Access Edge specifico.

Non finisce qui.

Quest'anno ci siamo impegnati molto: nella scheda Office 365 noterete due nuovi test, il Test DNS di Office 365 Lync e il test Disponibilità.

Il Test DNS di Office 365 Lync controllerà le impostazioni del nome di dominio esterno per l'utente di dominio personalizzato in Office 365.

Grazie al team di distribuzione dei servizi Office 365, il sito Web dell'Analizzatore connettività remota ospita ora il test Disponibilità Office, che verifica che una casella postale di Office 365 sia in grado di accedere alle informazioni sulla disponibilità di una casella locale, e viceversa. Il test comprende:

una verifica per confermare che l'offset del server ibrido non sia superiore a cinque minuti, poiché genererebbe errori durante la richiesta di token di delega dal Gateway federato Microsoft.
una verifica per confermare che la connettività in ingresso al server ibrido non necessiti di pre-autenticazione del firewall, e che quindi il firewall consenta l'autenticazione pass-through.
una verifica per confermare che il server ibrido soddisfa i requisiti minimi della versione di Exchange Server (Exchange Server 2010 SP1).
una query sulla disponibilità rispetto al servizio Disponibilità di destinazione.
Collegamenti a guide sulla Procedura guidata di configurazione ibrida, una delle fonti principali di configurazioni errate delle distribuzioni ibride

Grazie per aver letto fino alla fine. Spero abbiate apprezzato gli aggiornamenti, e di ricevere presto le vostre opinioni,

Nicole Allen
Per conto del team RCA (Analizzatore connettività remota)

Questo è un post di blog localizzato. L'articolo originale è disponibile in What’s new with Microsoft Remote Connectivity Analyzer? A lot!

Windows Management Framework 3.0 su Exchange 2007 e Exchange 2010

OfficeLocalization — Thu, 31 Jan 2013 11:43:40 GMT

Articolo originale pubblicato sabato 15 dicembre 2012

Di recente Windows Update ha iniziato a offrire Windows Management Framework 3.0 come aggiornamento facoltativo, che comprende tutte le forme di distribuzione degli aggiornamenti, quali Microsoft Update, WSUS, System Center Configuration Manager e altri meccanismi. L'informazione importante, qui, è che Windows Management Framework 3.0 include PowerShell 3.0.

Windows Management Framework 3.0 è distribuito come KB2506146 e KB2506143 (a seconda della versione del server che si esegue, Windows Server 2008 SP2 o Windows Server 2008 R2 SP1).

Quali sono gli effetti per gli utenti?

Windows Management Framework 3.0 (e nello specifico PowerShell 3.0) non è ancora supportato da nessuna versione di Exchange ad eccezione di Exchange Server 2013, che lo richiede. Se si installa Windows Management Framework 3.0 su un server che esegue Exchange 2007 o Exchange 2010, si andrà incontro a problemi, ad esempio la mancata installazione degli aggiornamenti cumulativi di Exchange o l'errata esecuzione di Exchange Management Shell.

Abbiamo riscontrato che l'installazione degli aggiornamenti cumulativi di Exchange non avviene in presenza dei seguenti sintomi:

Se un aggiornamento cumulativo è eseguito attraverso Microsoft Update, l'installazione potrebbe restituire il codice di errore 80070643
Se un aggiornamento cumulativo è eseguito da un download, comparirà l'errore L'installazione è stata interrotta in modo anomalo a causa di un errore.
In entrambi i casi è possibile che venga registrato l'ID evento 1024 nel registro eventi delle applicazioni con codice errore “1603”. Ad esempio, se si prova ad installare l'aggiornamento cumulativo 5 per Exchange 2010 SP2, potrebbe essere visualizzata la seguente descrizione nell'ID evento 1024:
Prodotto: Microsoft Exchange Server - Impossibile installare aggiornamento 'Aggiornamento cumulativo 5-v2 per Exchange Server 2010 Service Pack 2 (KB2785908) 14.2.328.10'. Codice errore 1603. Windows Installer può creare registri per aiutare a risolvere i problemi di installazione dei pacchetti software. Nel collegamento seguente sono presenti istruzioni per abilitare la registrazione: http://go.microsoft.com/fwlink/?LinkId=23127

Al momento suggeriamo di non distribuire Windows Management Framework 3.0 su server che eseguono Exchange 2007 o Exchange 2010, o su postazioni su cui sono installati gli strumenti di gestione di Exchange per una delle due versioni. Se l'aggiornamento è già stato distribuito, è necessario rimuoverlo. Una volta rimosso l'aggiornamento, le funzionalità saranno ripristinate.

Ben Winzenz

17/12/2012: aggiunti dettagli sull'ID evento 1024.

Questo è un post di blog localizzato. L'articolo originale è disponibile in Windows Management Framework 3.0 on Exchange 2007 and Exchange 2010

Exchange Server 2013 disponibile al pubblico

OfficeLocalization — Thu, 31 Jan 2013 11:43:00 GMT

Articolo originale pubblicato martedì 4 dicembre 2012

Lo scorso ottobre avevamo annunciato l'uscita della versione RTM (Release to Manufacturing) di Exchange Server 2013. Da allora ci siamo impegnati per il rilascio della nuova versione di Exchange ai nostri clienti aziendali attraverso canali di distribuzione multipli.

Oggi abbiamo raggiunto un altro importante traguardo: il team di Exchange e lieto di annunciare la disponibilità al pubblico di Exchange Server 2013. Potete scaricare il programma da TechNet e valutarlo per 180 giorni. Potete inoltre iscrivervi a Office 365 Preview per ottenere l'esperienza di Exchange più attuale nel cloud, in pochissimi minuti.

Coloro che vogliono distribuire Exchange Server 2013 in progetti nuovi o in ambienti di test per valutare le nuove caratteristiche e testarlo con le applicazioni line-of-business, possono farlo subito. Se si esegue un ambiente Exchange 2010 o 2007 è necessario disporre di Exchange Server 2010 SP3 o 2007 per l'aggiornamento. Sappiamo che siete ansioni di vedere una nuova versione, e per questo stiamo lavorando sodo agli ultimi ritocchi di Exchange 2010 SP3, che dovrebbe uscire nel primo trimestre del 2013.

Se non lo avete già fatto, vi consigliamo di scoprire tutte le informazioni su Exchange Server 2013 consultando la documentazione di TechNet o partecipando a un evento di formazione Ignite. È una buona idea valutare i prerequisiti e i requisiti di sistema in questo momento, e acquisire famigliarità con l'architettura a blocchi semplificata di Exchange, per essere avvantaggiati in termini di dimensioni, pianificazione e acquisto dell'hardware.

Sin dall'annuncio della versione RTM, il team EHLO ha aggiunto molto contenuto tecnico sul nuovo Exchange:

Offline Address Book in Exchange Server 2013 di Bhalchandra Atre
Managing Federated Sharing with the EAC di Elber Ren e Robert Mazzoli
Offline Access in Outlook Web App for the New Exchange di Sara Manning
Public Folders in the New Office di Alfons Staerk e Nikhil Aggarwal
Publishing Exchange Server 2013 using TMG di Greg Taylor
Lessons from the Datacenter: Managed Availability di Ross Smith IV e Greg Thiel

Nei prossimi mesi continueremo a pubblicare articoli su Exchange in EHLO. Grazie ancora per il vostro continuo supporto, e continuate a inviarci i vostri suggerimenti.

Team di Exchange

Questo è un post di blog localizzato. L'articolo originale è disponibile in Exchange Server 2013 Reaches General Availability

Risoluzione dei problemi di replica delle cartelle pubbliche

OfficeLocalization — Thu, 31 Jan 2013 11:42:07 GMT

Articolo originale pubblicato martedì 13 novembre 2012

Di recente abbiamo pubblicato degli esempi per la risoluzione dei problemi di replica delle cartelle pubbliche in Microsoft Exchange 2003. È possibile accedere alla risoluzione dei problemi in due modi diversi. Potete fare clic qui per accedervi direttamente. Alternativamente, il collegamento potrebbe trovarsi anche in diversi articoli relativi alla replica delle cartelle pubbliche, come il seguente: http://support.microsoft.com/KB/842273.

Vi chiederete senza dubbio perché abbiamo creato uno strumento di risoluzione dei problemi per Exchange 2003 ora che la fase principale del supporto è terminata. Lo abbiamo fatto per diversi motivi. Per prima cosa, molti dei clienti di Exchange stanno ancora effettuando il passaggio da Exchange 2003, e vogliamo offrire loro il massimo supporto nella transizione a versioni più recenti del prodotto. Questo è il migliore tipo di aiuto che possiamo offrire, dal momento che il supporto telefonico non è più disponibile. In secondo luogo, la maggior parte delle problematiche relative alle cartelle pubbliche per Exchange Server 2003 sono state identificate, e ciò vale a dire che la creazione di uno strumento di risoluzione dei problemi non modifica il materiale in maniera significativa. E per finire, dal momento che il meccanismo di replica delle cartelle pubbliche è rimasto lo stesso per un po' di tempo (fino a Exchange 2013), abbiamo pensato fosse una buona idea iniziare da Exchange 2003 e creare un modello che possiamo aggiornare facilmente per le versioni future.

L'organizzazione del supporto si sta impegnando per includere nello strumento di risoluzione dei problemi anche la versione 2007/2010.

Questi esempi rappresentano una guida alla risoluzione dei problemi di replica, come illustrato nei vari post di blog scritti da Bill Long, qui, qui e qui. Il loro scopo non è quello di sostituire i dati che vi aiutano a comprendere il processo di replica, ma soltanto di offrirvi i passaggi necessari a individuare eventuali problemi di replica.

Voglio ringraziare tutte le persone che mi hanno aiutato, tra cui:

Supporto di Exchange:

Nick Basile
Rob Whaley
Bill Long
Charlotte Raymundo
Will Duff
Nino Bilic

Team documentazione / contenuto:

Bobbie DeFault
Geoffrey Crisp (Entirenet)
Jerry Sitser (Entiernet)
Jarrett Renshaw
Star Li (Wicresoft)
Chen Jiang
Victor Zhang (Wicresoft)

Saluti,

Charlotte Raymundo
Messaging Knowledge Engineer

Questo è un post di blog localizzato. L'articolo originale è disponibile in Public Folder replication troubleshooter

Gestione della Rubrica offline in Exchange Server 2013

OfficeLocalization — Thu, 31 Jan 2013 11:42:00 GMT

Articolo originale pubblicato martedì 15 gennaio 2013

Nell'articolo postato nel blog del team di Exchange OAB in Exchange Server 2013 (Rubrica offline in Exchange Server 2013) viene presentata la nuova generazione della Rubrica offline e l'architettura di distribuzione in Exchange Server 2013. Consultate brevemente l'articolo per scoprire di cosa tratta o, se l'avete già letto, per ripassare i concetti chiave.

La gestione e l'amministrazione della Rubrica offline in Exchange 2013 è diversa a causa dei cambiamenti nell'architettura. Inoltre, la nuova Interfaccia di amministrazione di Exchange attualmente non possiede opzioni per la gestione della Rubrica offline. Ciò significa che, almeno per ora, dovrete utilizzare Exchange Management Shell per tutte le attività correlate alla Rubrica offline.

Questo articolo vi guiderà attraverso le attività eseguite più frequentemente nell'amministrazione della Rubrica offline e illustra un paio di situazioni verosimili che vi possono aiutare a comprendere meglio queste attività.

Nota: se vi trovate in un ambiente con dominio Active Directory multi-foresta, assicuratevi che nella sessione Shell sia abilitato il parametro ViewEntireForest, altrimenti alcuni dei comandi menzionati nell'articolo potrebbero non generare risultati.

Comando per l'abilitazione del parametro ViewEntireForest:

Set-ADServerSettings -ViewEntireForest $true

Creare una nuova Rubrica offline

La creazione di una nuova Rubrica offline in Exchange 2013 non si serve più del parametro -Server. Per creare una nuova Rubrica offline dovete specificare soltanto gli elenchi di indirizzi che saranno necessari.

L'esempio seguente crea una Rubrica offline per l'elenco di indirizzi chiamato “Global Address List FAB”

New-OfflineAddressBook -Name OAB-FAB -AddressLists "Global Address List FAB"

Identificare il server (o i server) di generazione della Rubrica offline

Alle cassette postali di arbitrato in Exchange Server 2013 sono assegnate alcune “capacità permanenti” che determinano lo scopo e la funzione della cassetta.

Una cassetta postale di arbitrato con capacità permanente “OrganizationCapabilityOABGen” ha responsabilità in merito alla creazione della Rubrica offline. Nell'articolo faremo riferimento a questa cassetta postale come "Cassetta postale dell'organizzazione".

Il server Cassette postali di Exchange Server 2013 che ospita la Cassetta postale dell'organizzazione genererà tutte le Rubriche offline definite nell'ambiente.

In ambienti non DAG potete usare il comando seguente per identificare i server di generazione della Rubrica offline:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,servername

Negli ambienti DAG, l'identificazione del server o dei server di generazione della Rubrica offline è una procedura a due fasi.

Fase 1: identificazione del database delle cassette postali che ospita la cassetta postale dell'organizzazione con capacità di generazione della Rubrica offline.

Potete usare il seguente comando per ottenere un elenco delle cassette postali di arbitrato con capacità permanenti di generazione della Rubrica offline, e dei database nei quali sono ospitate:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,database

Fase 1: identificazione del server Cassette postali in cui è installato il database che ospita la cassetta postale dell'organizzazione

Potete usare il comando seguente per identificare una copia attiva del database Cassette postali:

Get-MailboxDatabaseCopyStatus db1

Il server in cui lo stato del database è “installato” rappresenta il server corrente di generazione della Rubrica offline.

Modifica del server di generazione della Rubrica offline

Sono disponibili due modalità per modificare il server di generazione della Rubrica offline.

Spostamento della cassetta postale

Spostare la cassetta postale dell'organizzazione in un database delle cassette postali progettato per rappresentare il server di generazione della Rubrica offline.

Esempio:

DB1 è un database a copia singola presente sul server Exch1, che ospita la cassetta postale dell'organizzazione. DB2 è un database delle cassette postali presente su Exch2.

Il comando seguente consente di spostare la cassetta postale dell'organizzazione su DB2 e rendere Exch2 il server di generazione della Rubrica offline.

Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2

Questo metodo è più adatto per ambienti in cui è presente una sola copia del database delle cassette postali che ospita la cassetta postale dell'organizzazione.

Attivazione del database delle cassette postali su un server diverso

Questo metodo è più adatto per ambienti in cui sono presenti più copie del database delle cassette postali che ospita la cassetta postale dell'organizzazione.

Esempio:

DB1 ospita la cassetta postale dell'organizzazione e le copie sono presenti sui server Exch1 e Exch2. DB1 è correntemente attivo su Exch1.

Il comando seguente consente di attivare DB1 su Exch2 e renderlo così il server di generazione della Rubrica offline:

Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2

Nota: prima di modificare il server di generazione della Rubrica offline, consultate le linee guida illustrate nella sezione “Collocazione della cassetta postale dell'organizzazione,” in seguito.

Creazione di una nuova cassetta postale dell'organizzazione

Gli amministratori possono creare cassette postali dell'organizzazione aggiuntive per fornire la tolleranza dell'errore o per servire utenti in distribuzioni di Exchange geograficamente disperse.

La creazione di una nuova cassetta postale dell'organizzazione è una procedura a due fasi:

Fase 1: creazione di una nuova cassetta postale di arbitrato

New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle”

Fase 2: abilitazione della funzionalità di generazione della Rubrica offline

Set-Mailbox -Arbitration oabs -OABGen $true

Nota: prima di creare cassette postali dell'organizzazione aggiuntive, consultate le linee guida illustrate nella sezione “Collocazione della cassetta postale dell'organizzazione,” in seguito.

Modifica della pianificazione di generazione della Rubrica offline

Nelle versioni fino a Exchange Server 2010 la generazione della Rubrica offline si basa su una “pianificazione” impostata sulle proprietà della Rubrica offline. Nelle proprietà delle Rubriche offline di Exchange 2013 potreste vedere una pianificazione, ma la generazione della Rubrica offline in Exchange Server 2013 non avviene secondo una “Pianificazione” definita sulle proprietà della Rubrica offline:

Al contrario, la generazione della Rubrica offline in Exchange Server 2013 avviene secondo le proprietà OABGeneratorWorkCycle e OABGeneratorWorkCycleCheckpoint configurate presso il server della cassetta postale.

Esempio:

I valori nella schermata precedente indicano che la Rubrica offline è generata quotidianamente.

Quale server della cassetta postale ha elaborato la richiesta di download della Rubrica offline?

Il ruolo CAS di Exchange Server 2013 inoltra la richiesta di download della Rubrica offline a un ruolo del server Cassette postali appropriato. Il ruolo CAS mantiene una registrazione di ciascuna richiesta gestita all'interno di un file di registro, che sarà salvato nella cartella %ExchangeInstallPath%\Logging\HttpProxy\OAB\

Questi file di registro sono utilissimi per stabilire quale server delle cassette postali è stato scelto da CAS per elaborare la richiesta.

Alcune informazioni importanti contenute nel file di registro:

Campo	Descrizione
UrlStem	Utile per identificare la Rubrica offline che viene scaricata, e per stabilire se il download è di tipo completo o incrementale
AuthenticatedUser	Nome dell'utente che richiede la Rubrica offline
AnchorMailbox	DN della cassetta postale dell'organizzazione identificata come la più vicina per rispondere alla richiesta di Rubrica offline
ServerHostName	Nome del server CAS che gestisce la richiesta
HttpStatus	Codice di stato dell'azione Proxy
ProxyAction	Azione eseguita dal server CAS per la richiesta. Per le Rubriche offline di Exchange 2013 è molto spesso "Proxy"
TargetServer	Nome del server Cassette postali al quale è stata inoltrata la richiesta

Per una migliore leggibilità, è possibile importare il file di registro in Excel.

Esempio:

Generazione forzata della Rubrica offline

Esistono due metodi per forzare l'inizio immediato della generazione della Rubrica offline di Exchange Server 2013.

Metodo 1: Update-OfflineAddresBook

Questo comando forza la generazione di una Rubrica offline chiamata "Default Offline Address Book" (Rubrica offline predefinita) in tutte le cassette postali dell'organizzazione.

Update-OfflineAddressBook "default offline address book"

Nota: questo comando avvia una richiesta RPC a ciascun server Cassette postali che ospita una cassetta postale dell'organizzazione attiva.

Metodo 2: riavvio del servizio Assistenti cassette postali.

Il servizio Assistenti cassette postali sul ruolo Cassette postali è responsabile per la creazione delle Rubriche offline. Il riavvio di questo servizio genera tutte le Rubriche offline definite nell'ambiente all'interno di un server Cassette postali specifico, a condizione che ospiti una cassetta postale dell'organizzazione attiva.

Collocazione della cassetta postale dell'organizzazione

Il ruolo CAS di Exchange Server 2013 inoltra la richiesta di download della Rubrica offline al ruolo del server Cassette postali più vicino che ospita una cassetta postale dell'organizzazione attiva. Può inoltrare la richiesta secondo un meccanismo round robin qualora rilevasse più cassette postali dell'organizzazione attive nello stesso sito di AD. In questi casi, potrebbero avvenire frequenti download completi della Rubrica offline.

L'orientamento attuale è quindi quello di pianificare la collocazione di una cassetta postale in modo tale che vi sia una sola cassetta postale dell'organizzazione attiva in un sito di AD. Ciò si applica alla creazione di una nuova cassetta postale dell'organizzazione e alla creazione di copie del database delle cassette postali che ospita una cassetta postale dell'organizzazione.

Scenari

Nei seguenti scenari sono illustrate situazioni verosimili che spiegano più in dettaglio i metodi di gestione della Rubrica offline.

Scenario 1: creazione di una nuova cassetta postale dell'organizzazione

Contoso ha ruoli CAS e Cassette postali di Exchange Server 2013 distribuiti negli uffici di Dallas e Seattle. John, l'Amministratore Exchange di Contoso, analizza i file di registro del proxy HTTP sui server CAS e nota che la richiesta di download della Rubrica offline di Seattle passa ai server di Dallas. Analizzando più in dettaglio, John scopre che a Dallas c'è una sola cassetta postale dell'organizzazione, e perciò le richieste di download della Rubrica offline da parte di tutti gli utenti passano al server di Dallas.

Decide quindi di creare una nuova cassetta postale dell'organizzazione a Seattle, con i seguenti comandi:

Fase 1: creazione di una nuova cassetta postale di arbitrato

New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle”

Fase 2: abilitazione della funzionalità di generazione della Rubrica offline per la cassetta postale di arbitrato

Set-Mailbox -Arbitration oabs -OABGen $true

Scenario 2: personalizzazione della pianificazione di generazione della Rubrica offline

Ben lavora come Amministratore delle distribuzioni di Exchange 2013 presso Tail Spin Toys. La pianificazione predefinita di generazione della Rubrica offline non è ideale per loro, poiché vogliono generare una Rubrica offline ogni quattro ore circa.

Ben si servirà quindi del comando seguente per modificare le proprietà dei server Cassette postali che ospitano la cassetta postale dell'organizzazione.

Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00

Dopo un paio di giorni, John analizza l'ID evento 17002 del registro dell'applicazione, e verifica che sia generata una Rubrica offline ogni 4 ore.

Mi auguro che questo post vi possa essere utile. Comunicateci i vostri suggerimenti e le vostre opinioni!

Bhalchandra Atre

Questo è un post di blog localizzato. L'articolo originale è disponibile in Managing OAB in Exchange Server 2013

I dispositivi iOS6 assumono erroneamente la proprietà delle riunioni

OfficeLocalization — Wed, 05 Dec 2012 08:55:26 GMT

Articolo originale pubblicato mercoledì 24 ottobre 2012

Uno dei grandi vantaggi derivanti dall'utilizzo di una delle distribuzioni di Exchange più vaste al mondo è dato dal fatto che in Microsoft possiamo osservare in prima persona tutto quanto i nostri clienti devono affrontare ogni giorno. Con il recente rilascio di iOS6, abbiamo riscontrato un aumento significativo delle chiamate al supporto tecnico in cui vengono segnalati problemi relativi a riunioni in cui cambia il proprietario (fenomeno denominato a volte "assunzione del controllo di una riunione"). La maggior parte dei casi segnalati finora è relativa a utenti con delegati che prima aprono una convocazione a una riunione in Outlook e quindi agiscono sulla stessa riunione in iOS.

I problemi relativi alle riunioni riscontrati da alcune organizzazioni si verificano principalmente con dispositivi di terzeparti (un elenco è disponibile qui). Purtroppo con il recente aggiornamento di iOS si è accentuato uno di questi problemi. Desideravamo segnalarvelo e informarvi inoltre che ne abbiamo discusso con Apple. Stiamo anche cercando di mettere a punto sistemi per applicare una protezione avanzata all'infrastruttura di Exchange e proteggere i server e i servizi da client con prestazioni non ottimali.

Nel frattempo possiamo suggerirvi alcune soluzioni per ovviare a questi problemi:

Richiedete agli utenti di non eseguire azioni sui calendari in iOS. Questo problema non si verifica se gli utenti non eseguono azioni sugli elementi di calendario, ad esempio accettazione, eliminazione o modifica di riunioni.
Definite per gli utenti di iOS l'utilizzo del protocollo POP3/IMAP4. Un'altra opzione consiste nello spostare gli utenti alle connessioni POP/IMAP. In questo modo verranno rimosse le funzionalità del calendario e dei contatti, ma gli utenti potranno comunque continuare a utilizzare la posta elettronica (anche se è possibile che la posta elettronica passi dalla modalità di Push alla modalità di Pull quando si utilizzano questi protocolli).
Passate a client di terzeparti/OWA. Il passaggio degli utenti che hanno riscontrato questi problemi a un altro client di posta elettronica che non causa questo tipo di problemi nell'organizzazione può rappresentare una soluzione. Sono disponibili molte altre opzioni client (OWA è solo una di queste naturalmente). Negli archivi di applicazioni mobili è possibile scegliere tra numerosi client. Non consigliamo un client in particolare.
Bloccate i delegati. Molti dei problemi che stiamo riscontrando coinvolgono i delegati. Un amministratore può intraprendere un'azione meno drastica e utilizzare l'elenco dei dispositivi o degli utenti consentiti/bloccati/in quarantena per bloccare solo gli utenti delegati o che dispongono di un delegato e ridurre al minimo le conseguenze di questo problema.
Bloccate i dispositivi iOS 6. Exchange Server include l'elenco dei dispositivi o degli utenti consentiti/bloccati/in quarantena che consente agli amministratori di bloccare qualsiasi dispositivo o utente.
Indicate agli utenti di non eseguire l'aggiornamento a iOS 6 né di effettuare il downgrade dei dispositivi. Questa soluzione può funzionare come correzione temporanea finché Apple non fornisce una correzione, ma molti utenti potrebbero aver già preso la decisione di eseguire l'aggiornamento.
Attendete. Non disponiamo di informazioni sulla tempistica con cui Apple fornirà una correzione, ma se i tempi fossero brevi, questa potrebbe essere la soluzione più semplice. Contattate Apple per richiedere informazioni su eventuali correzioni o sulla tempistica con cui saranno disponibili.
Il nostro team di supporto ha pubblicato inoltre un articolo della Knowledge Base su questo problema disponibile qui. Questo post verrà aggiornato quando verrà fornita una correzione o quando disporremo di ulteriori informazioni.

Adam Glick
Sr. Technical Product Manager

Questo è un post di blog localizzato. L'articolo originale è disponibile in iOS6 devices erroneously take ownership of meetings.