Supporto Tecnico Enterprise : Exchange Team

Exchange 2007 – Generazione dell’Offline Address Book (OAB)

itentblg — Mon, 30 Nov 2009 00:00:00 GMT

Dopo l’ultimo caso ricevuto al GTSC relativo all’argomento ho deciso di buttare giù due righe per descrive a grandi linee come avviene la generazione, la distribuzione e la copia da parte dei client Outlook dell’ Offline Address Book (OAB).

Eviterò di soffermarmi su alcuni dettagli dato che il presente documento ha lo scopo di fornire una guida utile all’amministratore Exchange per comprendere meglio i vari passaggi del processo di generazione, copia, ed essere in grado eventualmente di effettuare del troubleshooting.

L’ Offline Address Book (OAB) viene generata una volta al giorno (di default alle h 05.00 del mattino) dal System Attendant tramite un processo chiamato OAB generation process (OABGen.dll).

Questo, dopo aver acquisito i dati dal GC prescelto, crea una copia compressa per le varie versioni di Offline Address Book (OAB Version 2, 3a, 4) che vengono copiate nella directory C:\Program Files\Microsoft\Exchange Server\ExchangeOAB del Generation Server (creata alla prima generazione Address List) e condivisa tramite il percorso UNC \\ExchangeServerName\ExchangeOAB\<GUID of OAB> .

Nota: avremo una sottodirectoy per ogni GUID relativa alle varie OAB generate contenente un set di file che dovranno poi essere acquisiti dai client.

A questo punto una notifica dell’ FDS (File Distribution Service), un nuovo componente di Exchange 2007 presente sui vari Client Access Server effettua la copia dell’ OAB dal Generation Server su di essi. Questa operazione avviene di default ogni 8h oppure in occasione dei seguenti eventi:

Viene creata una nuova OAB
Una OAB deve essere ripubblicata
Cambio dell’intervallo di polling
Cambio del path dove vengono generati file di cui sopra
Cambio del Generation server

A seguito di questa operazione potremo rilevare il seguente evento sul CAS:

Event Type: Information
Event Source: MSExchangeFDS
Event Category: FileReplication
Event ID: 1008
Date: 8/25/2006
Time: 6:05:41 PM
User: N/A
Computer: E12-CAS
Description: Process MSExchangeFDS.exe (PID=620). Offline Address Book data synchronization task has completed successfully. OAB name: "Test", Guid: 1fd83cb9-8887-4bbd-83f2-59c8a5ab29a4

Quando l’OAB viene creata per la prima volta il corrispondente oggetto addressBookContainer verrà creato nel seguente conteiner in Active Directory:

<CN=Offline Address Lists,CN=Address Lists Container, CN=Fourthcoffee, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Fourthcoffee,DC=com>

Non dimentichiamoci che l’OAB verrà pubblicata anche attraverso i public folder information store. I System Folders (per esssere esatti) veranno popolati, durante il processo di generazione, tramite messaggi con file in attach. Questo ovviamente avverrà solo se al momento dell’installazione di Exchange è stato

Al termine della prima generazione della stessa sarà necessario attendere il prossimo “online database maintenance” schedulato per il public folder database prima di poter accedere ai nuovi dati. Per verificare la periodicità del maintenance schedule è possibile utilizzare la cmdlet Get-PublicFolderDatabase. Non è possibile forzare l’ online database maintenance prima dell’orario schedulato a meno di non riavviare il servizio Microsoft Exchange Information Store all’interno della finestra temporale stabilita per l’ online database maintenance (il default è tra le 00.00 e le 04.00 di notte).

Nel caso in cui sia necessario effettuare del troubleshooting è possibile verificare e variare il livello dell’ event logging per la generazione dell’OAB attraverso questi due comandi:

Get-EventLogLevel: ci da informazioni circa l’ event logging level correntemente impostato (il default è Lowest)
Set-EventLogLevel: imposta l’ event logging level al livello desiderato [ Lowest | Low | Medium | High | Expert ]

In dettaglio, per l’OAB, sarà necessario usare la seguente cmdlet:

Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Expert

E’ possibile anche utilizzare il seguente comando per generare il log in modalità verbosa:

Set-EventLogLevel “MSExchangeSA\OAL Generator” –Level Expert –vb

Di solito se siamo a questo punto significa che stiamo verificando o riproducendo un problema con l’OAB. Possiamo per cui forzarne la generazione tramite EMC o attraverso la seguente cmdlet:

Update-OfflineAddressBook –Identity “Default Offline Address List”

Dopodiché sarà possibile visualizzare i log prodotti direttamente nell’Application log oppure, tramite la seguente cmdlet, sarà possibile ridirigere l’output su un file di testo:

Get-EventLog Application | Where {$_.Category -eq "OAL Generator"} > c:\oabevents.txt

Questo produrrà un log in un formato non intero (troncato). Per produrre un log completo degli eventi sarà necessario postporre | ft –Wrap alla fine del comando come nell’esempio seguente:

Get-EventLog Application | Where {$_.Category -eq "OAL Generator"} | ft -Wrap > c:\oabevents.txt

Nota: vi ricordo, alla fine delle operazioni di cui sopra, di riportare il livello dell’event log a Lowest.

Nella seconda parte di questo post tratterò della distribuzione dell’OAB dal punto di vista del client Outlook, delle modalità di download, lo schedule, versioni, file scaricati ecc.

Cristian Crifò
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange 2003 - Troubleshooting delle code e consegna dei messaggi

itentblg — Mon, 05 Oct 2009 02:00:00 GMT

Una delle richieste che ci viene fatta più spesso è il troubleshooting dei messaggi che non vengono consegnati ai destinatari.

Questa tipologia di problematiche ha 3 ambiti:

Il messaggio non arriva da internet verso la nostra infrastruttura
Il messaggio raggiunge la nostra infrastruttura ma non viene consegnato alla casella di posta
Il messaggio non esce dall’infrastruttura

Vediamo insieme come comportarci nei vari casi.

Il messaggio non arriva da internet verso la nostra infrastruttura

In questo caso il 90% dei problemi è dovuto a problemi di rete. Se non vedete le mail arrivare al vostro server di Front-end o al vostro Edge, controllate le seguenti cose:

Verificate con IntroDNS il vostro MX record “intoDNS: checks DNS and mail servers health http://www.intodns.com/”
Ottenuto il record mx (ogni tanto c’è qualche confusione su chi prende le email per chi :) ) si parte con i tests:

E’ necessario capire se il record punta direttamente alla vostra infrastruttura Exchange, o se c’è uno smarthost che prende le email per voi.

Digitate da Command Prompt:
telnet mx_record 25 [invio]
Dovreste ottenere il banner del server smtp che accetta la connessione
Inviate un’email di prova con la seguente sequenza di comandi:
helo test
mail from:utente@dominio.com
rcpt to:utente@dominio.com
data
subject:test email
test email

Se il server è il vostro Exchange, e vi viene restituito un codice di errore (e la descrizione di cosa succede non è chiara) cercate su http://support.microsoft.com il codice ottenuto.

Se il server non è il vostro Exchange, e vi viene restituito un codice di errore che non sia esplicativo, è necessario contattare il gestore del servizio, o il produttore dell’appliance (nel caso utilizzaste dei moduli hw\sw antispam)

Nel caso di un appliance o software\servizio di terze parti, si possono prendere 2 strade:

Collegarsi sull’appliance\server-servizio e verificare se ci sono dei diagnostic loggings che indicano in che stato è il messaggio
Verificare sui logs smtp del server di Front-end\Edge se ci sono delle sessioni smtp in ingresso dall’appliance\server-servizio (vedi http://blogs.technet.com/itasupport/archive/2008/10/10/smtp-analisi-del-protocol-logging.aspx per come abilitare\analizzare il log smtp) (per il server edge, è necessario abilitare il logging dalle proprietà del receive connector –> verbose logging)
L’apppliance deve in ogni caso comunicare con il server front-end\edge tramite una sessione SMTP, quindi si può provare a ripetere il tests della sessione telnet, questa volta dal server Exchange verso l’appliance\server-servizio e viceversa (ove possibile) per verificare eventuali problemi con apparati di rete.

Nel caso in cui il record MX sia il server Exchange:

Aprire l’Exchange System Manger e posizionarsi sul server –> Queue (Ex 2003) o il Queue Viewer (Ex 2007\2010). Se il messaggio è stato ricevuto, lo troveremo in una di queste code.
Se il messaggio non è presente nelle code, utilizzare il Message tracking per verificare se il messaggio è stato stato inviato ad un altro server o se sia stato generato un Non Delivery Report.
Utilizzate il log del protocollo SMTP per verificare la corretta sequenza di ricezione del messaggio.

Il messaggio raggiunge la nostra infrastruttura o è già nell’infrastuttura stessa ma non viene consegnato alla casella di posta

Dal punto precedente è necessario a quindi capire su quale server il messaggio è fermo. Una volta individuato il server con il message tracking, è necessario controllare le code di Exchange sul server incriminato per capire lo stato del messaggio:

Se il messaggio è pendente nella coda Awaiting Directory lookup

Indagare\verificare la connettività con l’infrastruttura Active Directory (connettività di rete verso i domain controller e global catalog (porte tcp 389 e 3268)
Verificare che i domain controllers e global catalogs non abbiamo problemi di performances

Aumentare il diagnostic logging del server per il componente Categorizer (proprietà del server –> diagnostic logging –> MsExchangeTransport Ex 2003 o Manager Diagnostic logging –> MsExchangeTransport –> categorizer Ex2007Sp2) a Maximum e verificare nell’application log eventuali avvisi\errori.

Se il messaggio è pendente nella coda Remote delivery

verificare la connettività di rete con il server\connettore riportato nel nome della coda (verificare anche la risoluzione nomi dns)

Se il messaggio è pendente nella coda Failed Message retry

il messaggio potrebbe essere corrotto o sono installati event sync di terze parti che possono interferire con la consegna del messaggio (antivirus o antispam). Provare a disabilitarli.

Se il messaggio non compare nelle code

Usare il message tracking per determinare a che punto del message flowing il messaggio è sparito. Se l’ultimo evento è la categorizzazione del messaggio, potrebbero essere coinvolti Event Sync di terze parti, come al punto precedente (gli Event Sync si agganciano alla fase di PostCategorize del messaggio).

From:Exchange Message Flow
http://technet.microsoft.com/en-us/library/bb123864(EXCHG.65).aspx

In generale in questo caso potete utilizzare i seguenti articoli per il troubleshooting delle code di Exchange:

Troubleshooting Mail Flow and SMTP
http://technet.microsoft.com/en-us/library/aa996805(EXCHG.65).aspx
Managing Queues
http://technet.microsoft.com/en-us/library/bb125022.aspx

E’ interessante notare che uno dei problemi che si presenta maggiormente è l’accodamento dei messaggi sul server di Back End, in particolare nelle code: Local Delivery e Awaiting directory lookup.

In questo caso ci sono 3 grandi famiglie di problematiche:

Performance del server: In particolare il systema dischi, in questo caso è necessario verificare i contatori logical discs –> average read\sec e average write\sec. Entrambi devono essere sotto i 0.02s
Antivirus: Se gli scanning threads sono pochi o i controlli vanno per le lunghe, si può generare il problema.Un dump del processo store.exe in genere rileva la problematica.
Varie: Qui si raccolgono alcuni problemi, anche relativi a Store event Syncs, che possono essere analizzati tramite la verifica di un dump del processo Store.exe

Performance del server

Per i problemi di performance utilizziamo il seguente articolo come base di partenza:

Troubleshooting Microsoft Exchange Server Performance
http://technet.microsoft.com/en-us/library/aa997270(EXCHG.65).aspx

Prendiamo ad esempio la parte relativa ai dischi. Vi riporto un esempio reale:

In questo caso vi era l’accodamento dei messaggi nella Local Delivery queue.

Come potete osservare il valore delle letture per buona parte dei dichi è scarso, in quanto è superiore ai 20ms(0.02s), mentre il valore delle scritture è assolutamente intollerabile da parte del sistema in quanto è praticamente sempre oltre gli 50ms(0.05s). Al superamento della soglia dei 20ms comincerete ad avere degli accodamenti sporadici di emails, a seconda del traffico e del message rate sperimentato.

Oltre i 50ms le code cominceranno a crescere fintanto che il problema sui dischi non sarà risolto. Considerate la vostra infrastruttura dischi come la colonna portante del vostro server Exchange. In questo caso la problematica era dovuta ad un alimentatore rotto sulla SAN!!!

Antivirus e varie

Se sospettate un problema con l’antivirus o uno Store Sync (la modalità di gestione dei sync, è sincrona (da non confondere sincrona con sync, in quanto la voce “sync” indica l’oggetto che si aggancia ad una funzione specifica e viene attivato solo nel caso specifico), ciò significa che nel processo vengono generati un certo numero di threads, detti Worker Threads che si occupano di eseguire la funzioni specifiche. La dll del sync object passerà la chiamata al worker thread libero e aspetterà la restituzione del controllo, prima di far continuare il processo padre.

Detto in temini semplici: se il processo dello store.exe ha 100 email da processare e l’antivirus ha 3 threads, ciò singnifica che verrano processate parallelamente 3 email per volta. Il primo thread che finisce, viene marcato come libero e può processare la mail successiva nella coda dello store.exe. Se per qualche ragione tutti e 3 i processi dell’antivirus si bloccano, da un dump in hang mode del processo store.exe, avrete un sacco di threads in questo stato:

ChildEBP RetAddr
4a7bf2d4 7c59a0a2 NTDLL!NtWaitForSingleObject+0xb
4a7bf2fc 7c57b40f KERNEL32!WaitForSingleObjectEx+0x71
4a7bf30c 00648dd6 KERNEL32!WaitForSingleObject+0xf
4a7bf394 00426a4f store!EcCheckVirusScanStamp+0x687 <---- in questo momento viene passato la chiamata all’antivirus e il thread di elaborazione della mail resta in attesa del completamento.

4a7bf3c4 00415d4d store!OMSG::EcCheckVirusScanStatus+0x130

Se vi ritrovate con un centinaio di thread in questo stato, allora il problema è esattamente li! :)

Nel caso di Syncs che non siano l’antivirus, nello stack trovere, nei primi frames di molti threads il riferimento alle funzioni chiamate. (ps. un analisi di questo tipo prevede di verificare lo stato del processo ad alcuni minuti di distanza, non è sufficiente una sola cattura del dump dump di processo in hang mode).

Il messaggio non esce dall’infrastruttura

In questo caso è necessario verificare dove il messaggio si blocca e avere ben presente l’infrastruttura di routing configurata (send connectors e smtp connectors).

Prima cosa verificare sempre se i messaggi raggiungo il server che fà da bridgehead per i connettori, e testare la connettività verso quel server (telnet alla porta 25).

Se il messaggio è fermo sul bridgehead server, verificare il log del protocollo smtp per eventuali errori, provare a fare a fare un telnet verso lo smart host configurato sul connettore smtp, o verso il record mx di un dominio esterno (se utilizzate la risoluzione dns).

Utilizzate un tool di cattura del traffico di rete (network monitor o equivalente) se sospettate problemi con device di rete:

Microsoft Network Monitor 3.3
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f

Fare una cattura utilizzando il filtro “.protocol.smtp” se volete verificare la sessione smtp

Verificate sempre se la problematica è simmetrica (ovvero otre a non uscire, la posta non entra).

Verificate con il message tracking, in quale parte della delivery il messaggio si blocca (per esempio advanced queue o mta transfer).

Riepilogo

La guida presentata vuole essere semplicemente uno scheletro generico che può essere utilizzato per indirizzare il troubleshoting della problematica. Le modalità di approccio al problema possono essere varie e dipendono molto dall’esperienza passata di chi esegue il troubleshooting.

Francesco Poli
Support Escalation Engineer
Microsoft Enterprise Exchange Support

Exchange 2007 – Supportabilità in base Sistema Operativo e Active Directory

itentblg — Mon, 21 Sep 2009 02:00:00 GMT

Dopo l’uscita del Service Pack 2 di Exchange Server 2007, è stato rilasciato il seguente articolo relativo alla supportabilità del prodotto:

Exchange Server Supportability Matrix: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee338574.aspx

L'articolo fa riferimento a diverse configurazioni riguardo a: Active Directory, Sistema Operativo, Clients, .Net Framework, etc.

Questo post ha l'intento di evidenziare alcune informazioni importanti:

Exchange Server 2003 non è supportato in ambiente dove il "domain/forest functional level" di Active Directory è stato alzato oltre il livello Windows Server 2003.
Comunque, Exchange Server 2003 SP2 può essere installato in ambiente dove vi siano Windows Server 2008 Active Directory Servers.
Exchange Server 2007 RTM non è supportato su Windows Server 2008 R2.
Exchange Server 2007 SP1 RU9 e SP2 sono supportati su Windows Server 2008 R2.
Exchange 2007 SP1 RU9 e SP2 sono supportati in ambienti dove il "domain/forest functional level" di Active Directory è stato alzato al livello Windows Server 2008 R2.
Exchange 2007 SP2 è supportato con PowerShell 2.0

Sistemi Operativi supportati

Operating System Platform	Exchange 2007 SP2	Exchange 2007 SP1	Exchange 2007 RTM	Exchange 2003 SP2	Exchange 2000 SP3
Windows 2000 SP4	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows XP Professional SP2	X*	X*	X*	X**	X**
Windows XP Professional SP3	X*	X*	X*	X**	X**
Windows Vista RTM	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X***	NOT SUPPORTED
Windows Vista SP1	X*	X*	NOT SUPPORTED	X***	NOT SUPPORTED
Windows Vista SP2	X*	X*		X***	NOT SUPPORTED
Windows Server 2003 SP2	X	X	X	X	NOT SUPPORTED
Windows Server 2003 R2 SP2	X	X	X	X	NOT SUPPORTED
Windows Server 2008	X	X	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 SP2	X	X	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

* Solo per Exchange Management Tools

** Solo per Exchange 2000/2003 System Manager

*** Solo con Exchange 2003 System Manager per Windows Vista

Active Directory Server e Ambiente supportati

Operating System Environment	Exchange 2007 SP2	Exchange 2007 SP1	Exchange 2007 RTM	Exchange 2003 SP2	Exchange 2000 SP3
Windows 2000 Server SP4 Active Directory Servers	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows Server 2003 SP1 Active Directory Servers	X	X	X	X	X
Windows Server 2003 SP2 Active Directory Servers	X	X	X	X	X
Windows Server 2008 Active Directory Servers	X	X	X	X	NOT SUPPORTED
Windows Server 2008 SP2 Active Directory Servers	X	X	X	X	NOT SUPPORTED
Windows Server 2008 R2 Active Directory Servers	X	X*	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 Read Only Active Directory Servers	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 R2 Read Only Active Directory Servers	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

Active Directory Environment	Exchange 2007 SP2	Exchange 2007 SP1	Exchange 2007 RTM	Exchange 2003 SP2	Exchange 2000 SP3
Windows 2000 Mixed Domain Functional Level	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows 2000 Native Functional Level	X	X	X	X	X
Windows Server 2003 Interim Domain Functional Level	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows Server 2003 Domain Functional Level	X	X	X	X	X
Windows Server 2008 Domain Functional Level	X	X	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 R2 Domain Functional Level	X	X*	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows 2000 Forest Functional Level	X	X	X	X	X
Windows Server 2003 Interim Forest Functional Level	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows Server 2003 Forest Functional Level	X	X	X	X	X
Windows Server 2008 Forest Functional Level	X	X	X	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 R2 Forest Functional Level	X	X*	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

* Necessario installare RU9 per Exchange Server 2007 SP1 disponibile al seguente indirizzo:
Description of Update Rollup 9 for Exchange Server 2007 Service Pack 1: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221166.aspx

Paulo Canuto
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange 2007 – Rilasciato il Service Pack 2

itentblg — Tue, 25 Aug 2009 02:00:00 GMT

È appena uscito il Service Pack 2 di Exchange Server 2007.

In questo articolo, intendo evidenziare alcune nuove funzionalità e considerazioni riguardo l’installazione o aggiornamento del Service Pack 2.

Installazione di Exchange Server 2010

Se Exchange Server 2007 (RTM o SP1) è già istallato e si vuole aggiornare ad Exchange Server 2010, o aggiungere un nuovo Exchange server 2010 nella infrastruttura, bisogna prima aggiornare Exchange Server 2007 alla SP2

Installazione di Exchange Server 2007 SP2

Per effettuare l’installazione di Exchange Server 2007 SP2, bisogna avere installato Windows Installer 4.5:
Windows Installer 4.5
http://www.microsoft.com/downloads/details.aspx?FamilyID=5a58b56f-60b6-4412-95b9-54d056d6f9f4&displaylang=en
Non è supportato installare Exchange Server 2007 SP2 su un server con Windows Server 2003 e dopo fare l’aggiornamento ad un Windows Server 2008 oppure, aggiornare il sistema operativo da Windows Server 2003 a Windows Server 2008 e successivamente aggiornare Exchange Server 2007 a SP2.
Per installare Exchange Server 2007 SP2 su un sistema operativo Windows Server 2008, bisogna prima installare il sistema operativo (senza Exchange) e dopo installare Exchange Server 2007 SP2.
Non è possibile disinstallare Service Pack 2. Per fare ciò, occorre disinstallare Exchange server e successivamente installare una versione precedente.
Nel caso in cui ci siano software di terze parti installati sul server, è necessario fermare tutti i servizi delle terze parti, prima di proseguire con l’installazione di Exchange Server 2007 SP2.

Aggiornamento a Exchange Server 2007 SP2

Tutti i ruoli del Exchange Server 2007 vengono aggiornati durante il processo di aggiornamento al Exchange Server 2007 SP2. Non è possibile aggiornare solo alcuni ruoli.
Il ruolo Mailbox, deve essere aggiornato per ultimo, ovvero, si devono aggiornare tutti gli altri ruoli prima e l’ordine consigliata è:
1. Client Access Server
2. Unified Messaging Servers
3. Hub Transport Servers
4. Edge Transport Servers
5. Mailbox Servers
Inoltre, è consigliato aggiornare i Client Access Server dall'esterno verso l’interno ovvero, configurare prima quelli accessibili da Internet seguiti di quelli interni, senza collegamento internet.
Nel caso in cui la versione di Exchange Server 2007 sia RTM e Microsoft Forefront Security for Exchange Server (FF) sia installato sul server, dobbiamo tenere in considerazione che:
1. La versione originale (RTM) di Forefront Security for Exchange Server è incompatibile con la versione di Exchange Server 2007 SP2. Bisogna o aggiornare Forefront Security for Exchange Server oppure rimuoverlo prima di aggiornare al Service Pack 2 di Exchange Server 2007
2. Se la versione di Forefront Security for Exchange Server è la più aggiornata, bisogna stoppare tutti i servizi di Forefront Security for Exchange Server prima della installazione del Service Pack 2 di Exchange Server 2007

Nuove caratteristiche

VSS Backup
Con la Service Pack 2 di Exchange Server 2007, abbiamo un VSS (Volume Shadow Copy Service ) plug-in per Windows Server Backup per il backup di Exchange. Il plug-in esiste in forma di un file denominato WSBExchange.exe e viene automaticamente installato su tutti i Mailbox server.
Bisogna installare la feature “Windows Server Backup” di Windows Server 2008

Durante il processo di Backup, non si evidenziano differenze con o senza SP2 comunque, durante il processo di Restore, abbiamo la possibilità di selezionare l’applicazione desiderata (in questo caso Exchange) come si può visualizzare nelle seguenti schermate:

Prima del Service Pack 2 del Exchange Server 2007:

Dopo aver istallato Service Pack 2 del Exchange Server 2007:

Using Windows Server Backup to Back Up and Restore Exchange Data: Exchange 2007 Help
http://technet.microsoft.com /en-us/library/ee221172.aspx

How to Perform a Backup of Exchange Using Windows Server Backup: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221177.aspx

How to Restore a Backup of Exchange Using Windows Server Backup: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221167.aspx
Auditing
Una delle funzionalità abbastanza richiesta dagli amministratori di Sistemi di posta, è l’auditing. Con la SP2, ci sono nuovi eventi e log che aiuteranno gli amministratori a monitorare i server Exchange. Avendo un luogo specifico dove accedere ai log di auditing, questa funzionalità è stata veramente agevolata.

L’auditing viene implementato al livello del processo Microsoft Exchange Store.exe visto che è tramite questo processo che si accede alle mail nelle mailbox.

Dopo aver configurato il livello di logging, bisogna riavviare il servizio Microsoft Exchange Information Store

Se il sistema operativo è il Windows Server 2008, il file evtx si trova sotto la cartella “\Exchange Server\Logs\AuditLogs” e si può accedere tramite Event Viewer, sotto “Applications and Services Logs\Exchange Auditings”

Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 2: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221156.aspx

Validazione automatica del’Active Directory Schema
L’aggiornamento e validazione automatica dello schema del Active Directory, consente futuri aggiornamenti di installarsi dinamicamente e di anche prevedere potenziali conflitti sempre che una nuova proprietà venga aggiunta allo schema di Active Directory.

Understanding Dynamic Schema Updates and Validation in Exchange 2007 SP2: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221169.aspx
Configurazione della Quota dei Public Folder
La gestione/configurazione delle quota dei Public Folder è stata migliorata, potenziando il cmdlet con ulteriori parametri.

Set-PublicFolder
- IssueWarnigQuota – SP2
  - Questo parametro ci consente di configurare il valore per cui, un messaggio è inviato al owner della PublicFloder informando che il public folder è quasi al massimo delle sue capacità .
- ProhibitPostQuota –SP2
  - Superando questa quota, un messaggio è inviato al’utente che invia un post alla Public Folder, informando che la public folder è al massimo della sua capacità. Da questo momento in poi, gli utenti non sono in grado di inviare più messaggi al public folder
- I seguenti due parametri sono stati rimossi nella SP2
  - PostStorageQuota
  - StorageQuota
Diagnostic Logging
Dal Exchange Server 2007 Service Pack 2, abbiamo la possibilità di abilitare il diagnostic logging dalla console di Exchange, Exchange Management Console (ESM). Per questo proposito, basterà cliccare con il tasto destro del mouse sopra il server e troviamo la voce: “Manage Diagnostic Logging Properties”

Selezionando questa opzione, abbiamo la seguente finestra di configurazione:

Informazioni addizionali

E’ disponibile un documento con l’elenco dettagliato delle novità introdotte nel Service Pack 2:

What's New in Exchange Server 2007 SP2: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221150.aspx

Il pacchetto di installazione è disponibile al seguente indirizzo:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a

Paulo Canuto
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange 2010 – Rilasciata la RELEASE CANDIDATE

itentblg — Wed, 19 Aug 2009 02:00:00 GMT

La Release Candidate di Exchange 2010 è stata rilasciata ieri al pubblico dal sito download Microsoft:

Microsoft Exchange Server 2010 Release Candidate

Brief Description

Microsoft Exchange Server 2010 helps you achieve new levels of reliability and performance by delivering features that help to simplify your administration, protect your communications, and delight your customers by meeting their demands for greater business mobility.
http://www.microsoft.com/downloads/details.aspx?FamilyID=c6d27da1-ba2c-4570-a491-c0d7b39ede8b&displaylang=en

Il rilascio della Release Candidate significa che il prodotto ha raggiunto un livello di stabilità tale per cui la build è considerata il punto di partenza per la successiva versione definitiva RTM.

Tutte le build successive saranno delle minor version, senza grossi cambiamenti in termini di funzionalità del prodotto e d’interfacce di gestione.

Attualmente, è disponibile solamente la versione in lingua Inglese.

Francesco Poli
Support Escalation Engineer
Microsoft Enterprise Exchange Support

OCS 2007 - Problema di integrazione con Outlook: Impossibile recuperare le informazioni del calendario

itentblg — Mon, 17 Aug 2009 02:00:00 GMT

Come sappiamo Office Communicator è altamente integrato con Outlook ed Exchange mettendo a disposizione una serie di feature come la presence, la conversation histroy, la missed-call history, ecc

Il Communicator ottiene inoltre da Outlook e/o da Exchange una serie di informazioni, tra cui quelle relative all’ Out of Office e al calendario, per poter aggiornare conseguentemente la presenza dell’utente. Le informazioni vengono ottenute sia via MAPI che tramite i Web Services di Exchange.

Una spiegazione di come funziona questo meccanismo è data sul blog ufficiale del team che si occupa dello sviluppo del Communicator:
Office Communicator Team Blog : Communicator and Exchange – Special considerations for deploying Communicator in an Exchange environment

PROBLEMA

Per un nuovo utente era stato preparato un nuovo account ed una macchina di lavoro che prevedeva Outlook 2003 e Office Communicator 2007; nell’infrastruttura il server era un Exchange 2003 EE.

All’avvio del Communicator, successivo all’avvio di Outlook, è stato notato il seguente messaggio di errore:

che sulla versione in lingua Inglese corrisponde a:

“Cannot retrieve your Outlook calendar information. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.”

Un messaggio di errore del Communicator che indicava l’impossibilità di scaricare le informazioni del calendario e che persisteva durante l’utilizzo del Communicator.

ANALISI

Come abbiamo detto sopra, il Communicator scarica le informazioni del calendario da Exchange, per i client Outlook 2007 con Exchange 2007 tramite gli Exchange Web Services oppure via MAPI.

Il tempo di polling del Communicator è modificabile via policy:

MapiPollInterval	Frequency of loading calendar data from MAPI.
WebServicePollInterval	Frequency of loading calendar data from the Web services provider.

Se l’utente non sta’ però pubblicando queste informazioni il Communicator non potrà aggiornare lo stato a sua volta, abbiamo quindi per prima cosa controllato se fossero state cambiate le impostazioni di default di Outlook:

Abbiamo poi verificato sul client Communicator che le impostazioni nel Personal Information Manager fossero settate su Outlook (in Tools -> Options):

Siccome risultava tutto configurato correttamente abbiamo abilitato i log del Communicator, da Tools –> Options -> General –> Logging

Dopo aver flaggato la voce: “Turn on logging in Communicator” e nessessario uscire e ri-loggarsi affinché le modifiche vengano accettate; verranno creati due file nella directory %userprofile%\Tracing: Communicator-uccapi-X.uccapilog e Communicator.etl.

Mentre il file .uccapilog è leggibile con Snooper, un tool del resource kit, ma anche semplicemente con il NotePad, il file ETL deve essere necessariamente mandato al supporto tecnico Microsoft per essere convertito in testo e interpretato.

La voce “Turn on Windows Event logging for Communicator” serve invece ad abilitare il Windows Event logging.

Maggiori informazioni sono reperibili sul blog ufficale di OCS: OCS Client Logging Capabilities (MOC)

Abbiamo quindi chiesto al cliente di abilitare i log, loggarsi nuovamente, aspettare che si riproducesse il problema e mandarci il file Communicator.etl.

Dal file etl risultava che il task incaricato del caricamento delle informazioni del calendario , restituiva il codice di errore 0x8004010F ovvero MAPI_E_NOT_FOUND.

SOLUZIONE

Abbiamo semplicemente inserito un evento nel calendario vuoto e l’errore è scomparso, non si tratta quindi di un vero problema, ma semplicemente del fatto che le informazioni non sono effettivamente presenti; il messaggio infatti non viene più riscontrato dopo che un appuntamento è stato creato almeno una volta.

Questo comportamento è presente solo con Outlook 2003 + Exchange 2003 di cui tra l’altro è ormai terminato il supporto mainstream:

come visto risolverlo è comunque molto semplice, in quanto al primo elemento inserito nel calendario l’errore lato Communicator sparice.

Rimando inoltre al seguente articolo di KB che descrive il motivo del possibile ritardo nell’aggiornare lo stato lato Communicator nella stessa configurazione: Communicator 2007 does not update the free/busy information as scheduled

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 - Presence unknown con utenti LCS 2005

itentblg — Mon, 10 Aug 2009 02:00:00 GMT

Nell’interazione tra Live Communications Server 2005 e Office Communications Server 2007 è capitato ad alcuni clienti di incappare in un problema legato alla “presence” degli utenti OCS; sostanzialmente gli utenti LCS2005 vedevano la presenza di quelli attestati su OCS sempre “Unknown” con relativo pallino color grigio.

Inoltre gli utenti LCS non riuscivano ad iniziare una sessione di IM con quelli OCS ma era possibile il contrario.

La prima cosa da fare per capire la causa di comportamenti simili è riprodurli abilitando i log sia sui client che sui server in modo da poter ricostruire ciascun passaggio.

Di seguito vediamo le azioni da svolgere.

Abilitazione Log

Su LCS 2005:
Trovate una descrizione su come abilitare i log in LCS 2005 SP1 nella Reference Guide da pag 37 in poi e reperibile qui:
Live Communications Server 2005 with SP1: All Technical Documents
Nel Tab logging abbiamo impostato il “Logging Level” a 4 per avere il maggior dettaglio possibile.
Su OCS 2007:
Con OCS è stato introdotto un tool di logging molto comodo: Replacement of Flat File Logging Functionality
Come descritto al link abbiamo abilitato il logging per il componente SIPStack.
Su MOC 2007:
Basta andare in ToolsàOptionsàGeneral e abilitare la voce “Turn on logging in Communicator”.
Le trace saranno disponibili nel folder %USERPROFILE%\Tracing con il nome: Communicator-uccapi-X.uccapilog
Per aprirlo è necessario il tool Snooper reperibile nel Resource Kit.
Su MOC 2005:
Si tratta di impostare le seguenti chiavi di registry:
HKCU\Software\Microsoft\Tracing\Communicator EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\LCAPI EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\LCIMSP EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\LCMSGSC EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\lcmedia_rtp EnableFileTracing=1

Le trace saranno disponibili nel folder %USERPROFILE%\Tracing
How to enable diagnostic logging for Office Communicator and for Windows Messenger

Riprodurre il problema

Per riprodurre abbiamo semplicemente eseguito il login su un MOC 2005 che aveva nella sua lista di contatti alcuni utenti 2007 e constatato dopo qualche minuto che la presenza risultava sempre sconosciuta.

Ricordatevi di disabilitare i log dopo il test se non vi serve mantenerli attivi per ulteriori test.

ANALISI

Per iniziare l’analisi è certamente essenziale avere ben chiaro l’ambiente del cliente, personalmente cerco sempre di farmi uno schema della parte di infrastruttura che mi interessa, con gli indirizzi IP, i nomi macchina e tutto quello che possa tornarmi utile ai fini dell’analisi.

A tal proposito se voleste raccogliere i dati di una macchina in particolare, potete utilizzare l’"MPS Report" che è parte del Microsoft Product Support's Reporting Tools:

http://www.microsoft.com/downloads/details.aspx?FamilyID=00ad0eac-720f-4441-9ef6-ea9f657b5c2f&DisplayLang=en

Il programma genera un file NomeMacchina_MPSReports.CAB salvato nella cartella: "C:\WINDOWS\MPSReports\PFE\Report\Cab" contenente numerosissime informazioni sullo stato del server e sulla relativa configurazione.

Dall’analisi dei dati raccolti avevamo notato il seguente errore:

$$begin_record

LogType: connection

Date: 2009/02/22 11:31:52

Severity: 1

Text: The connection matched by IP address had the wrong peer name

Peer-IP: 10.0.0.1:5061

Peer-Name: server_name.contoso.local

Transport: M-TLS

$$end_record

Effettivamente il mismatch c’era in quanto il “Peer Name” corrispondeva all’ FQDN del server fisico OCS, mentre l’indirizzo IP era quello del Pool.

Questo mismatch portava di conseguenza ad un 504 Server Time-Out alla richiesta di sottoscrizione iniziale:

$$begin_record

LogType: diagnostic

Date: 2009/02/22 11:31:52

Severity: information

Text: Response successfully routed

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 949157e5a19d4d8b91a5541ecb7f2e1

SIP-CSeq: 1 SUBSCRIBE

Peer: 191.168.1.122:4918

$$end_record

SOLUZIONE

In questo caso lato OCS avevamo una Enterprise Edition con un singolo Front End e senza bilanciatore Hardware: questo tipo di configurazione, supportata in OCS, era bloccata in LCS 2005 SP1 e un apposito controllo verificava che due FQDN non si risolvessero con lo stesso indirizzo IP.

Nella guida alla migrazione è riportato infatti quanto segue:

Supporting a Pool with a Single Enterprise Edition Server :

If you deploy Office Communications Server 2007 Enterprise pool with a single Enterprise Edition server without a load balancer, to support coexistence you must use a separate IP address for the Enterprise server and the Enterprise pool.

To do so, the following steps are required:

Add a second IP address on the Enterprise Edition server
Point the DNS record for the Enterprise pool to the second IP address

This requirement exists because Live Communications Server 2005 SP1 servers cannot successfully communicate if the Enterprise Edition server and the Enterprise pool have the same IP address.

After your deployment is moved completely to Office Communications Server, you can remove the new IP and use a single IP address for the pool (and the pools DNS record) and the Enterprise Edition server.

Per risolvere il problema abbiamo quindi aggiunto un secondo IP sulla macchina di Front End OCS e fatto puntare l’ FQDN del Pool a questo nuovo indirizzo, e una volta riavviati i servizi il problema è sparito.

Esiste un articolo di KB di riferimento per questa problematica ormai nota:
Presence information appears as "Presence Unknown" when Live Communications Server 2005 users view the presence information of Communications Server 2007 users

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS - Remote Connectivity Analyzer

itentblg — Mon, 03 Aug 2009 02:00:00 GMT

Sulla scia del successo ottenuto dall’Exchange Remote Connectivity Analyzer (creato da Shawn McGrath e Brad Hughes), Premal Gandhi, Matthew Fresoli e Jason Stine hanno scritto un tool complementare per OCS: Office Communications Server Remote Connectivity Analyzer.

Il tool è disponibile sul sito https://www.TestOcsConnectivity.com

Introduzione

L’Office Communications Server Remote Connectivity Analyzer è un sito dedicato agli Admin che vogliono testare l’accesso remoto alla loro infrastruttura OCS. Il sito simula l’accesso remoto di un client riportando l’esito del test e, nel caso di fallimento, fornisce i dettagli del problema e i suggerimenti necessari a risolverlo.

In questa fase il tool è in beta, al momento sono disponibili i seguenti test:

Office Communications Server Remote Connectivity
Office Communications Server Remote Connectivity con AutoDiscover

Caratteristiche future

Il tool nei prossimi mesi verrà integrato con:

Un maggior livello di informazioni diagnostiche;
Maggiori dettagli riguardanti il troubleshooting;
Ulteriori test e scenari.

Se avete feedback o suggerimenti al sito è presente il classico feedback link.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange Server - Verifica della rete con PortQry

itentblg — Tue, 16 Jun 2009 16:00:00 GMT

Dopo il mio post su NMCap vorrei continuare con la parte di troubleshooting relativa ai servizi di rete con PortQry e PortQryUI.

Scenari di utilizzo e Attivazione

Spesso, in configurazioni con i nostri server posti in DMZ, si ha la necessità di dover di verificare se il nostro firewall o switch L3 si stia comportando come noi ci aspetteremmo relativamente al filtraggio degli IP, porte, servizi, ecc. Per alcuni servizi questo può essere banale (es: un telnet alla porta 25 per valutare se SMTP risposte alle nostre richieste) mentre per altri la verifica può non essere altrettanto banale.

Caratteristiche di PortQry

Prendiamo ad esempio il caso del traffico RPC e dell’ EndPoint Mapper. Quando un client (MAPI ad esempio, oppure una console di amministrazione) inizia a dialogare col server di destinazione questo viene rediretto dall’ Endpoint Mapper, in ascolto sulla porta 135, su un'altra porta assegnata dinamicamente tra la 1024 e la 65535.

In casi come questo, dove può essere difficile verificare la disponibilità del servizio richiesto tramite l’utilizzo di un comune port scanner, PortQry (e PortQryUI) possono venirci in soccorso.

PortQry giunto alla versione 2.0, può essere scaricato gratuitamente dal Microsoft Download Center.

Mentre lo stesso tool adesso dotato di una interfaccia grafica è reperibile al seguente indirizzo: PortQryUI - User Interface for the PortQry Command Line Port Scanner

PortQry 2.0 supporta i seguenti session layer e application layer protocols:

Lightweight Directory Access Protocol (LDAP)
Remote Procedure Calls (RPC)
Domain Name System (DNS)
NetBIOS Name Service
Simple Network Management Protocol (SNMP)
Internet Security and Acceleration Server (ISA)
SQL Server 2000 Named Instances
Trivial File Transfer Protocol (TFTP)
Layer Two Tunneling Protocol (L2TP)

Analizzare traffico RPC

Cominciamo proprio con un esempio basato su RPC tramite il seguente comando:

portqry -n myserver -p udp -e 135

PortQry produrrà una query RPC, interpreterà la risposta ottenuta contenente tutti gli endpoint registrati con l’RPC endpoint mapper e verificherà la disponibilità delle varie porte restituite.

Ecco un esempio dell’output del comando:

Querying target system called:

ex2k3-01

Attempting to resolve name to IP address...

Name resolved to 192.168.1.81

querying...

UDP port 135 (epmap service): LISTENING or FILTERED

Using ephemeral source port

Querying Endpoint Mapper Database...

Server's response:

UUID: 3c4728c5-f0ab-448b-bda1-6ce01eb0a6d5 DHCP Client LRPC Endpoint

ncalrpc:[dhcpcsvc]

UUID: 3473dd4d-2e88-4006-9cba-22570909dd10 WinHttp Auto-Proxy Service

ncalrpc:[W32TIME_ALT]

UUID: 3473dd4d-2e88-4006-9cba-22570909dd10 WinHttp Auto-Proxy Service

ncacn_np:\\\\EX2K3-01[\\PIPE\\W32TIME_ALT]

UUID: 2f5f6521-cb55-1059-b446-00df0bce31db Unimodem LRPC Endpoint

ncacn_np:\\\\EX2K3-01[\\pipe\\tapsrv]

[..]

UUID: 9e8ee830-4459-11ce-979b-00aa005ffebe MS Exchange MTA 'Mta' Interface

ncacn_np:\\\\EX2K3-01[\\pipe\\9403671C54CE8F36]

[..]

UUID: a4f1db00-ca47-1067-b31e-00dd010662da Exchange Server STORE ADMIN Interface

ncacn_np:\\\\EX2K3-01[\\pipe\\D1A77AAA93FBC00C]

UUID: a4f1db00-ca47-1067-b31e-00dd010662da Exchange Server STORE ADMIN Interface

ncalrpc:[MSExchangeIS_LPC]

[..]

Total endpoints found: 154

==== End of RPC Endpoint Mapper query response ====

UDP port 135 is LISTENING

In questo modo possiamo determinare il corretto funzionamento della porta 135, i servizi registrati con l’RPC endpoint mapper database del server di destinazione, i vari Universal Unique IDentifier (UUID) per ogni servizio o programma e il rispettivo protocollo utilizzato.

Le possibili stati riportati da Portqry sono i seguenti:

Listening – Un processo è in ascolto sulla porta indicata e Portqry ha ottenuto una risposta
Not Listening – Nessun processo è in ascolto sulla porta indicata e Portqry ha ottenuto una risposta (ICMP) "Destination Unreachable - Port Unreachable" (porta UDP) oppure un acknowledgement packet (ACK) col Reset flag (RST) impostato ad 1 (Porta TCP).
Filtered - Portqry.exe non riceve nessuna risposta.

Esempi di altri protocolli

Altri esempi di sintassi sono i seguenti:

portqry -n 10.0.0.11 -p tcp -o 143,110,25 -l portqry.log

Effettua un test delle porte 143, 110 e 25 salvando il risultato nel rispettivo file di log.

portqry -n my_server -p udp -r 135:139 -l portqry.log

Come sopra a differenza del fatto che viene testato il range di porte 135-139.

Se non siete degli amanti della command-line, come anticipato all’inizio del post, adesso è disponibile la versione grafica di PortQry: PortQryUI.
Il funzionamento è pressoché identico con l’aggiunta di alcuni comodi set di test preconfigurati: Domain and Trusts, WEB Service, nonché il nostro amato Exchange.

Concludo questo veloce post con un paio di link utili riguardo quanto detto:

Cristian Crifò
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 R2 - Reperire le informazioni di configurazione

itentblg — Mon, 15 Jun 2009 02:00:00 GMT

Con Office Communicator 2007 R2 è possibile avere una schermata che riporta le informazioni di configurazione, in maniera del tutto simile a quella con cui si ottiene lo stato delle connessioni su Outlook 2007; basta tenere premuto il tasto CTRL e cliccare con il tasto destro del mouse sull’ icona del Communicator.

Comparirà una schermata simile a questa:

Per una dettagliata spiegazione di tutte le voci vi rimando all’articolo pubblicato nel blog ufficiale del team OCS.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 R2 - Il servizio Front End non si avvia dopo l’installazione della KB 967831

itentblg — Tue, 09 Jun 2009 02:00:00 GMT

La KB967831 dopo aver fermato i servizi OCS ed eseguito gli aggiornamenti, esegue il riavvio degli stessi compreso il Monitoring Agent (RtcQmsAgent).
Se quest’ultimo non è configurato, l’installazione fallisce e l’installer tenta un rollback degli aggiornamenti con conseguente fallimento del servizio di Front End.

Nei prerequisiti della KB è infatti riportato:

Tutti i servizi Office Communications Server devo essere avviati prima di provare ad installare l’aggiornamento. Dopo aver installato la fix, l’aggiornamento prova ad avviare i servizi Front-End di Microsoft Office Communications Server. Se il servizio Front-End di Microsoft Office Communications Server non può essere avviato, l’aggiornamento esegue un rollback. Verificare che i seguenti servizi siano avviati prima di installare l’aggiornamento:

Office Communication Server Front End Service - rtcsrv
Office Communication Server IM conferencing - rtcimmcu
Office Communication Server Telephony Conferencing - rtcacpmcu
Office Communication Server Monitoring Agent – rtcqms

Affinché il Monitoring Agent si avvii è necessario che l’ MSMQ (MS Messaging queue) sia presente sul server, per cui per risolvere il problema è sufficiente installare l’MSMQ e il MS Messaging Queue Server con i seguenti comandi:

ServerManagerCmd -i MSMQ-Services
ServerManagerCmd -i MSMQ-Server

Il seguente link Install and Configure Message Queuing (for Monitoring Server) riporta la procedura anche per Windows Server 2003.

Successivamente è necessario reinstallare la patch, che dovrebbe ora andare a buon fine.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 - Come verificare il contenuto dell’Address Book

itentblg — Mon, 08 Jun 2009 02:59:00 GMT

Durante il troubleshooting dei problemi legati all’Address Book, potrebbe essere comodo controllare il contenuto del file galcontacts.db.

L’“Offline Address Book” viene scaricato localmente da Office Communicator 2007 nella directory: %USERPROFILE%\AppData\Local\Microsoft\Communicator

Per poterlo convertire in un formato leggibile è sufficiente impostare la seguente chiave di registry:

[HKEY_CURRENT_USER\Software\Microsoft\Communicator]
"DumpContactsToCSVFile"=dword:00000001

Sul Communicator fate logout e poi nuovamente login: a questo punto basterà andare in Tools --> View Received Files per trovare l’address book in formato CSV.

Ricordatevi di togliere la chiave se volete usare View Received Files per i normali trasferimenti di file.

Nota: questo sistema non funziona sui client R2, un alternativa è l’utilizzo del tool abserver.exe da un prompt dei comandi.
Ad esempio:

abserver.exe -dumpfile “F-0bed.lsabs” c:\absdump.txt

fornendo in input un recente Full file (F-xxxx) che contenga quindi tutti i contatti.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange Server – Automatizzare la cattura del traffico di rete con NMCap

itentblg — Mon, 01 Jun 2009 02:00:00 GMT

In questi miei primi post, non strettamente legati al mondo Exchange, vorrei porre la vostra attenzione su alcuni tool di troubleshooting utilizzati per analizzare problematiche che impattano le funzionalità dei server Exchange. Iniziamo quindi con una utility che si è dimostrata spesso indispensabile: NMCap.

Scenari di utilizzo e Attivazione

Spesso capita di avere l’esigenza di effettuare delle catture di traffico di rete in attesa che un determinato problema si presenti nuovamente.

Nella maggior parte delle situazioni non è possibile collegarsi al server e lanciare Network Monitor, o in alternativa il vostro tool di cattura preferito, e lasciarlo semplicemente girare, magari col “circular logging” impostato.

Oltre al fatto d’essere una soluzione molto poco elegante la sessione RDP può andare in timeout, essere richiesta da un altro amministratore, vi ricordo il limite di due sessioni contemporanee insieme a quella “console”, o semplicemente un altro amministratore può avere la necessità di riavviare il server: fermando così la cattura fino a che questa non viene fatta ripartire nuovamente. Infine, col “circular logging” impostato, rischiamo di perdere i dati di nostro interesse se non agiamo velocemente per fermare la cattura.

Fino a qualche tempo fa, quando necessario, automatizzavo la cattura del traffico di rete con netta con qualche limitazione. Con il nuovo Network Monitor, giunto alla versione 3.3, sono state superate alcuni dei vincoli del suo predecessore e sono state introdotte alcune interessanti novità.

Tanto per citarne alcune tramite NMCap è possibile effettuare la cattura del traffico su tutte le interfacce, salvare grandi quantità di dati catturati effettuando lo “split” su più file. E’ possibile impostare un trigger per lo start e stop della cattura, oltre che per una determinata finestra temporale, anche per uno specifico evento (es: un ping inviato al server) e “last but not least” è ovviamente possibile utilizzare NMcap con i filtri creati attraverso la GUI di Network Monitor, fate attenzione ai doppi apici “”!

Per catture relative a sessioni molto lunghe è addirittura possibile arrivare a “scriptare” il tutto utilizzando in maniera continuativa NMcap (con o senza filtri) e comprimendo via via (sempre via command line) i file prodotti per spostarli poi su volumi “meno pregiati” del server. Volevo ricordare con l’occasione che NMCap, se utilizzato senza filtri, non causa un sostanziale decadimento delle performance del server.

Un’altra idea può essere quella di avviare NMCAp tramire un Alert di Performance Monitor oppure, tramite VBScript col verificarsi di uno specifico evento nel System Log o nell’Application Log (relativamente a questo pubblicherò a breve un post per dettagliare ulteriormente questi aspetti).

Esempi pratici

Dopo questa lunga introduzione passiamo a qualche esempio pratico relativo all’utilizzo ed alla sintassi del comando:

nmcap /network * /capture "(tcp.port == 25)" /file t.chn:100M /stopwhen /timeafter 120min /terminatewhen /keypress x

Nell’esempio di cui sopra NMcap catturerà il traffico relativo a tutte le interfacce (parametro “/network *”) indirizzato alla porta TCP 25 e si fermerà dopo 120 min oppure premendo il tasto “X”. Il comando concatena inoltre i dati catturati in N file t(1).chn e t(2).chn, ognuno di 100MB fino al termine previsto per la cattura (su questo punto vi consiglio di prestare particolare attenzione al esaurimento dello spazio disco a disposizione). Ricordo che per default, per fermare la cattura, è semplicemente necessario utilizzare Ctrl+C o Ctrl+Break. Procediamo con un passo indietro e un esempio più semplice:

nmcap /network * /capture /file test.cap

Il comando di cui sopra cattura il traffico su tutte le interfacce salvando i dati nel file test.cap (cattura circolare per un file con dimensione massima pari ai 20MB di default). Un altro esempio interessante può essere il seguente dove effluiamo la cattura di tutto il traffico escludendo la parte relativa al protocollo RDP (Terminal Services):

nmcap /network * /capture "!(tcp.port == 3389)" /file test.cap

Come anticipato nel primo script è possibile impostare la partenza e lo stop della cattura attraverso gli switch /startwhen e /stopwhen dopo un certo numero di minuti (ad esempio 30) col seguente switch: "/TimeAfter 30 mintues" oppure indicando un orario preciso con lo switch "/Time 10:30:00 am 9/10/2006" (attenzione perché il formato della data/ora dipende dai locale settings impostati) oppure, come ho accennato all’inizio del post, col verificarsi di un determinato evento come nell’esempio di cui sotto dove la cattura terminerà non appena NMCap rileverà i passaggio di un frame dal server locale all’ host con IP 10.20.30.41:

nmcap /network * /capture /file t.cap /stopwhen /frame (ipv4.address == ipconfig.localipv4address) AND (Ipv4.DestinationAddress == 10.20.30.41)

Come ho accennato prima è possibile concatenare i file di output della cattura specificando l’estensione ".chn” e la dimensione massima per ogni file (che consiglio di mantenere al di sotto di 100-200MB al fine di non ritrovarsi a gestire file di dimensioni troppo ampie). Per cui, utilizzando ad esempio lo switch "/file t.chn:1M" verranno creati dei file chiamati files t(1).chn, t(2).chn, ecc. ognuno con dimensione pari ad 1MB.

Relativamente alla salvaguardia dello spazio a disposizione sarà possibile indicare anche una condizione alternativa di stop della trace basata sulla percentuale di spazio libero su disco come nell’esempio di cui sotto dove, al raggiungimento del 5% di spazio libero residuo, la cattura terminerà automaticamente:

nmcap /network * /capture /file result.cap /MinDiskQuotaPercentage 5

Come avete potuto vedere le possibilità offerte sono veramente molte e credo saranno in grado di soddisfare tutte le vostre esigenze.

Altri esempi di utilizzo di NMCap potranno essere valutati digitando il comando con lo switch "/examples" mentre ulteriori informazioni su Network Monitor e il relativo download del tool sono disponibili ai seguenti indirizzi:

Buona cattura a tutti! :)

Cristian Crifò
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange 2010 – Disponibile la Beta: vediamo insieme i cambiamenti

itentblg — Thu, 16 Apr 2009 18:21:55 GMT

Il gruppo di supporto Exchange e lieto di annunciare che è disponibile la versione Beta di Exchange 2010.

Il download è disponibile nel sito ufficiale Microsoft per Exchange 2010

Il TechNet contiene la documentazione ufficiale per Exchange 2010 anche se è in fase di completamento.

Di seguito riporto le nuove funzionalità che sono state introdotte, nei prossimi giorni scenderemo nel dettaglio di ogni singola caratteristica.

Protezione delle Email con i servizi di Active Directory Right Management Services

Possibilità di utilizzo delle Transpor Rules per applicare le protezioni RMS condizionalmente.
Protezione continua degli allegati nei messaggi protetti con RMS.
Supporto per i templates di Active Directory RMS .
Templates RMS per la protezione delle mail inviate esternamente all’infrastruttura.
Protezione dei messaggi Vocali

Miglioramenti e aggiunte relative alle Transport Rules e Routing Functionalities

Segmentazione delle infrastruttua di Posta Elettronica = E’ possibile implementare una segmentazione dell’infrastruttura di emailing decidendo di mantenere parte del deployment dell’infrastruttura “in House” e utilizzare parte dei servizi On-Line di Exchange Hosted Services.
Disclaimer!!! = Sono state migliorate le funzionalità di aggiunta dei disclaimer, permettendo ora l’inserimento di Links, formattazioni HTML, Immagini e un interfaccia di integrazione con Active Directory
Transport Rules e integrazione con AD RMS = E’ stata aggiunta la possibilità di integrare la protezione AD RMS in automatico tramite delle Transport rules
Email, con “Moderazione” = E’ possibile implementare dei workflow di consegna per determinare dei processi di approvazione del contenuto delle email per decidere se un messaggio si possa essere consegnato al destinatario (questo è il genere di regole che piace agli uffici legali :) )
Ridondanza nella consegna = Il messaggio email viene mantenuto come copia di backup nell’Hub server fintato che il successivo Hub\smtp server non ne decreti la corretta ricezione. Nel caso in cui non venisse rilevata la corretta consegna, il messaggio verrebbe reinvitato.
Rimozione dei messaggi dal Transport Dumpster in base allo stato della copia dei log = Il messaggio verrà rimosso dal transport dumpster dell’Hub server, solamente nel momento in cui tutte le copie del mailbox database avranno ricevuto il messaggio.
Definizione di uno SLA per latenza nel transporto del messaggio = Il nuovo sistema di Transport permette di valutare lo SLA sulla latenza nelle tempistiche di consegna dei messaggi tra i vari Hops e per il tempo totale di consegna del messaggio, dalla partenza alla ricezione da parte del destinatario.
Miglioramenti nelle performance del database del Transport = Sono state notevolmente migliorate le performance del servizio di trasporto delle mail, riducendo, come nel caso dei server mailbox, il numero di IOPS necessari per il database del transport.

Nuove funzionalità e migliorie nella gestione dei permessi

E’ stato introdotto il nuovo modello di gestione basato sui ruoli che rimpiazza il vecchio modello di permessi precedentemente implementato.
In questo modo è possibile avere una segmentazione molto precisa e semplice di chi può fare cosa nell’infrastruttura Exchange.
Questo modello permette di implementare delle restrizioni di accesso anche ai comandi powershell che l’utente può eseguire, in base al ruolo che è stato assegnato.

Nuove funzionalità per l’Alta Disponibilità

Questa è una delle parti più interessanti (e non lo dico solo perché mi piace l’area di disaster recovey e alta affidabilità :) )

Nella versione 2007 di Exchange, sono state introdotte molte modalità di gestione della ridondanza per garantire l’alta affidabilità dei sistemi, in particolare abbiamo:

LCR: Local Continuos Replication: Implementa in locale, su un singolo server della copia di un database, in modo da garantire la protezione del database in caso di un problema sull’istanza fisica (es. si rompe il disco rigido)

SCC: Single Copy Cluster: Implementa il vecchio modello di cluster, in cui abbiamo una Storage Area Network condivisa tra più nodi di un cluster.

CCR: Cluster Continuos Replication: Implementa una modalità di replica dei database tramite un cluster geografico di tipo Majority Node Set e un servizio di replica gestito da Exchange, che permette la sincronizzazione dei database su 2 nodi fisici, senza avere uno storage condiviso.

SCR: StandBy Continuos Replication: Implementa una modalità (introdotta con la Sp1 di Exchange 2007) che permette di mantenere un infrastruttura simile a quella di produzione (intesa a livello di server Exchange, quindi server o cluster group) in StandBy tramite un meccanismo di replica simile a quello de CCR.

Database portabilty: a differenza delle versioni 5.5,2000 e 2003, dalla versione 2007 in avanti di Exchange non è più necessario che il database delle mailbox sia vincolato al server sul quale è stato creato, ma è possibile spostare i database tra i vari server, a seconda delle necessità

Vediamo ora cosa è cambiato con Exchange 2010!

Come avrete notato tutte le sigle dei vari sistemi replica, possono generare un po' di confusione, quindi… ABBIAMO ELIMINATO I CLUSTERS

In pratica è stato rivoluzionato completamente il modello di alta affidabilità, non esistono più le seguenti modalità: LCR,SCC,CCR e SCR, lo stesso concetto di Mailbox server clusterizzato non esiste più.

Exchange 2010 implementa una modalità di replica dei database che unisce le funzionalità del sistema CCR e SCR.

E’ stato implementato un modello denominato Continuos Availability (disponibilità continua) per cui ogni singolo database può essere replicato su ben 16 server diversi in modalità continua.

l failover è stato reso più granulare, quindi adesso abbiamo la possibilità di eseguire un Database Failover, invece del classico server failover che prevedeva lo spostamento di tutti i database di un server (il server failover sarà disponibile comunque dalla prossime release di Exchange 2010, in pratica sarà comunque un failover di tutti i database del server)

Le tempistiche di failover sono nettamente diminuite rispetto alle versioni precedenti, a prodotto finito si stima un tempo di failover di meno di 30 secondi, contro i circa 2 minuti attuali.

I backups possono essere fatti da una qualsiasi delle copie del database, oltre che dal nodo attivo.

Nei prossimi post approfondiremo gli aspetti tecnici dell’alta disponibilità.

Nuove funzionalità e miglioramenti nell’Information Store (lo “Store” per gli amici)

Storage Group: Non esiste più il concetto di storage group come gruppo logico per raggruppare i database, ma ogni database vive singolarmente.
I Mailbox database non sono più direttamente collegati ai server, ma sono considerati oggetti “stand alone”. Anche in Active Direcotry, l’oggetto mailbox database è stato spostato, nella struttura del configuration container, allo stesso livello del server.
Extensible Storage Engine (ESE) è stato modificato e aggiornato, introducendo delle modifiche che ne migliorano il comportamento in termini di performance e ne estendono le funzionalità per l’alta affidabilità e per la il Database Mobility.
La struttura dello Store è stata ristrutturata in modo da incrementarne le performance e rimuovendo delle strutture che ne appesantivano l’utilizzo.

Nuove funzionalità per la Compliance e Messaging Policy

Sono state implementate nuove interfacce per l’applicazione delle policy.
E’ stato implementato un sistema di tagging automatico per le policy di conservazione delle Email.
Aggiunte alcune funzionalità che permettono di eseguire delle ricerche in più Mailbox contemporaneamente con il supporto per l’Advanced Query Sintax
Nuove predicati e azioni per la creazione delle Transport Rule.

Nuove funzionalità di OWA (Outlook Web Access)

Utilizzo dei Favoriti nel pannello di Navigazione
Cartelle di ricerca
Filtri sui messaggi
Possibilità di impostare le categorie nelle liste di messaggi
Il Web Managent permette di impostare le configurazioni per OWA
Possibilità di visualizzare i calendari affiancati
Supporto Multi lingue per i clients
Possibilità di fare l’attach di un messaggio ad un nuovo messaggio ed inviarlo come allegato.
Nuove funzionalità e menù con il tasto destro del mouse.
Integrazione con Office Communicator, visualizzazione della presenza, chat e liste di contatti.
Possibilità di visualizzare una conversazione (ordinamento email)
Possibilità di inviare e ricevere SMS da OWA
Policy mailbox per OWA

Nuove funzionalità per l’Unified Messaging

Configurazione di regole per la risposta automatica (Auto Attendants Rule)
Aggiunto il supporto per altre lingue relativo all’Outlook Voice Access e per il Voice Mail Preview
Miglioramenti nella risoluzione dei nome del chiamante tramite l’identificativo del chiamante
Possibilità di farsi leggere le email da una voce automatica (Voice Mail Preview)
Notifica di un messaggio in attesa
Notifica di conversazioni perse o di chiamate vocali tramite SMS
Chiamate vocali protette
Ruoli di gestione dell’Unified Messaging predefiniti

Nuova Interfaccia di gestione Web

Integrazione con servizi telefonici quali SMS
Integrazione con il Voice messaging
Funzionalità di ricerca Mailbox
Possibilità di creazione e gestione delle liste di distribuzione
Regole Moderazione e approvazione per l’invio alle liste di distribuzione

Nuove funzionalità per la console di gestione (Exchange Managemet Console)

Integrazione con il programma Customer Experience Improvement Program (CEIP)
visualizzazione dello stato di funzionamento dell’Organizzazione Exchange
Collegamento con le Communities e con Risorse web
Possibilità di loggare i comandi eseguiti

Nuove funzionalità nella shell (Exchange Management Shell)

Powershell v2: L’utilizzo della versione 2 della powershell, permette di creare script di gestione molto elaborati.
Amministrazione remota: Grazie alla nuova shell sarà possibile collegarsi remotamente al server Exchange per eseguire i comandi senza necessità di essere loggati direttamente sul server.
Logging: Possibilità di loggare tramite Audit i comandi che vengono eseguiti e che comportano un cambiamento di configurazione degli oggetti collegati all’infrastruttura Exchange.

Questo è solo una veloce review delle modifiche che saranno introdotte da questa nuova versione di Exchange, nei prossimi giorni faremo dei post di approfondimento relativi ai vari componenti qui citati.

Francesco Poli
Senior Support Engineer
Microsoft Enterprise Exchange Support

Emergenza Abruzzo – la risposta di Microsoft

itentblg — Thu, 09 Apr 2009 14:00:00 GMT

Le notizie che si susseguono sulla tragedia che ha colpito l’Abruzzo lunedì scorso sono veramente sconvolgenti. Tutti i dipendenti ed i partner della nostra azienda sono vicini alle persone coinvolte. Microsoft Italia si è attivata in questi giorni con una serie di azioni di supporto materiale e tecnico che speriamo possano alleviare per quanto possibile i disagi e le difficoltà in cui versano le popolazioni toccate da questo drammatico evento.
Molte di queste iniziative sono e saranno oggetto di comunicazione direttamente alle Istituzioni coinvolte o destinatarie di questi contributi. Tra le azioni intraprese, segnaliamo a tutte le scuole, enti pubblici, piccole aziende e organizzazioni non profit del territorio che avessero necessità di supporto tecnico informatico sui nostri prodotti a più ampia diffusione, di rivolgersi al numero 02 70398398 e, indicando la provenienza dalle province colpite, le chiamate saranno dirottate ad un servizio gratuito appositamente attivato per loro.

Se vuoi partecipare attivamente per aiutare le popolazioni terremotate dell'Abruzzo, fai clic qui.

Grazie a tutti per il vostro aiuto.

Supporto Tecnico Enterprise