Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

Archivi per la categoria 'Exchange Server 2007' Categoria


Bloccare lo spam interno (dal proprio dominio di posta) in Exchange Server

Scritto da Ivan Salvade' il 7 ottobre 2013

Questo articolo si applica a : Exchange Server 2007, 2010, 2013

Capita spesso di ricevere mail di spam, dove l’indirizzo di posta del mittente rappresenta un’utenza vostra interna (es. Nomeutente@NomeVostroDominioDiPosta ) o addirittura rappresenta voi stessi (cioè ricevete spam da voi stessi!!!).

Questo capita perché gli spammer sono riusciti ad eseguire lo spoofing del vostro indirizzo di posta (o di quello di altre persone nella vostra azienda), inserendolo poi nelle intestazioni SMTP delle mail di tipo spam che essi lanciano.

Con i software antispam professionali, tipicamente, ci si difende agevolmente da questo tipo di spam.  Ma per chi vuole utilizzare esclusivamente i filtri antispam nativi (o altre impostazioni) di Exchange 2007/2010/2013, la difesa non è così immediata.

L’impostazione di default dei server Exchange è quella di ricevere qualunque mail proveniente dai cosiddetti “Domini Accettati” (”Accepted Domains”), inseriti nella configurazione del trasporto.  E il vostro dominio pubblico di posta è sicuramente configurato come ”Dominio Accettato”.  Inoltre, il Connettore di Ricezione che riceve mail da Internet è sicuramente configurato a non richiedere l’autenticazione ai mittenti delle mail (giustamente), altrimenti non si riceverebbero più mail dal mondo intero!

I Connettori di Ricezione di Exchange, però, hanno numerose altre autorizzazioni particolari, che si possono vedere e modificare solo con comandi di powershell.

Ecco un comando esemplificativo per visualizzare tutte le autorizzazioni assegnate ad un normale Connettore di Ricezione configurato per ricevere posta da Internet :

Get-ReceiveConnector “Nome Connettore” | Get-AdPermission | Ft User,AccessRights, ExtendedRights -Autosize

La particolare autorizzazione che ci interessa è la “MS-Exch-SMTP-Accept-Authoritative-Domain-Sender” assegnata all’identità speciale “Anonymous Logon”.  Questa autorizzazione permette a qualunque persona non autenticata (quindi anche agli spammer) di collegarsi al Connettore di Ricezione in oggetto, di dichiarare il vostro dominio di posta nell’intestazione SMTP “Mail From:”, e di essere comunque accettati.

Questa autorizzazione è assegnata ad un Connettore di Ricezione, quando esso è impostato a ricevere da Internet.

Ecco le autorizzazioni di “Anonymous Logon” su un connettore senza accesso anonimo :

rcv1.jpg   Fig 1 : se il connettore non ha l’accesso anonimo…

rcv2.jpg

Fig 2 :…. ecco quali sono le autorizzazioni di Anonymous Logon

Ecco invece come si presentano le autorizzazioni di “Anonymous Logon” su un connettore con l’accesso anonimo attivato :

rcv3.jpg   Fig. 3 : se il connettore ha l’accesso anonimo…

rcv4.jpg

Fig. 4 : …. ecco la presenza dell’autorizzazione “MS-Exh-SMTP-Accept-Authoritative-Domain-Sender”

Se un client di posta non autenticato tentasse ora di spedire mail insererendo un indirizzo di posta interno sia come mittente che come destinatario, gli esiti sarebbero questi (mail accettata!) :

rcv5.jpg

Fig. 5 : mail accettata

Il trucco per bloccare questo tipo di mail provenienti dall’esterno, sta nel rimuovere l’autorizzazione “ms-exch-smtp-accept-authoritative-domain-sender” ad “Anonymous Logon”.  Il comando per eseguire la rimozione è il seguente :

Get-ReceiveConnector “Nome Connettore” | Get-AdPermission -User “NT Authority\Accesso Anonimo” | Where {$_.ExtendedRights -Like “MS-Exch-SMTP-Accept-Authoritative-Domain-Sender”} | Remove-AdPermission

N.B. : nel precedente comando, l’identità speciale “Anonymous Logon” deve essere indicata esattamente come mostrato (cioè “NT Authority\Accesso Anonimo” se la lingua di installazione di Exchange è l’italiano, mentre deve essere indicata come “NT Authority\Anonymous Logon” se la lingua di installazione di Exchange è l’inglese.

Ecco l’esecuzione del comando :

rcv6.jpg

Fig. 6 : esecuzione del comando di rimozione dell’autorizzazione

Ed ecco ora il diverso comportamento per un client di posta non autenticato :

rcv7.jpg

Fig. 7 : mail rifiutata

Questa procedura riesce quindi a bloccare lo spam che utilizza indirizzi di posta interni “spoofati”.

Buon divertimento :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | 10 Commenti »

Conoscere i domain controller usati da Exchange

Scritto da Ivan Salvade' il 18 settembre 2013

E’ spesso utile conoscere i domain controller che un server Exchange sta utilizzando, in un certo momento.

Per esempio, durante una migrazione di Active Directory, durante la quale vengono installati nuovi domain controller, oppure vengono rimossi quelli vecchi, è utile sapere se Exchange ha già iniziato a contattare i domain controller nuovi.

Un comando di powershell utile a questo scopo è il seguente :

Get-ExchangeServer -Status | FL Name,Current*

Ecco l’esecuzione del comando in un ambiente con diversi server Exchange in esecuzione :

1.jpg      (Clicca sulla foto per ingrandire)

Il comando restituisce i domain controller utilizzati dai vari server Exchange.

Nella colonna “CurrentDomainControllers” sono riportati i domain controller utilizzati per eseguire le normali query LDAP a porta 389.

Nella colonna “CurrentGlobalCatalogs” sono riportati i domain controller con funzione di Global Catalog, utilizzati per eseguire query LDAP alla porta 3268.

Nella colonna “CurrentConfigDomainController” è riportato il domain controller scelto per eseguire letture e scritture sulla Configuration Partition di Active Directory : per esempio, la Configuration Partition di AD viene modificata in tutti i casi in cui si eseguono modifiche all’Organizzazione Exchange.

Ricordo che Exchange Server è in grado di gestire autonomamente il discovery dei domain controller, attraverso il proprio servizio DSAccess.  Quest’ultimo entra in esecuzione ogni 15 minuti circa, registrando nel log Applicazione gli eventi con codice 2080 contenenti l’elenco dei domain controllers trovati in rete.

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | Nessun commento »

Come compattare i files .pst di Outlook

Scritto da Ivan Salvade' il 26 novembre 2012

Ci sono persone che magari da anni utilizzano Outlook memorizzando la posta nel file .pst di default, o in files .pst personalizzati.  Con il passar del tempo, i files pst possono raggiungere dimensioni considerevoli, rendendo lunghe eventuali operazioni di copia, trasferimento o backup.

Non tutti sanno che gli Outlook di tutte le versioni permettono facilmente di compattare i files pst, ottenendo una riduzione di grandezza che spesso raggiunge o supera il 50% della dimensione originale.

Ecco come si può compattare un file pst utilizzando, per esempio, Outlook 2010.

Si accede alle proprietà dell’account di posta (Fig.1 ) :

pst1.jpg      Fig. 1

Si accede poi al Tab “File di Dati”, si seleziona il file PST che si desidera compattare, e si clicca su “Impostazioni” (Fig. 2) :

pst2.jpg      Fig. 2

Nelle proprietà del file di dati Outlook, si clicca “Compatta” (Fig. 3) :

pst3.jpg      Fig. 3

La compattazione può durare più o meno tempo, a seconda della grandezza del file pst (Fig. 4) :

 pst5.jpg      Fig. 4

Ecco, nel mio esempio, la grandezza del file Outlook.pst, prima (Fig. 5) e dopo (Fig. 6) la compattazione.  Come si vede, qui la differenza è di pochi Kb (il file dell’esempio era già stato compattato pochi giorni prima), ma in una situazione reale si potrebbero notare riduzioni di grandezza di oltre il 50%

pst4.jpg      Fig. 5

pst6.jpg      Fig. 6

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010, Exchange Server 2013 | 2 Commenti »

Nuova release degli ultimi Update Rollup per Exchange Server 2007 e 2010

Scritto da Ivan Salvade' il 9 ottobre 2012

A quasi 2 mesi dal rilascio del RU4 di Exchange 2010 SP2 , Microsoft ha dovuto rettificarlo oggi con il rilascio della sua versione 2.

Anche il RU7 per Exchange 2010 SP1 e il RU8 per Exchange 2007 SP3 sono stati nuovamente rilasciati nella loro seconda versione.

Il motivo è l’errata firma digitale di alcuni componenti degli Update Rollup : questa firma è stata eseguita con certificati aventi un EKU (Enhanced Key Usage) senza timestamp, o con un timestamp indicante una scadenza troppo vicina (per alcuni componenti la scadenza è addirittura fine novembre 2012).  Questo potrebbe portare a difficoltà nell’installare o disinstallare questi componenti.

Oltre ad Exchange 2007 e 2010, sono a rischio anche i sistemi operativi stessi, come riporta il Security Advisory di Microsoft che trovate a questo link :

http://technet.microsoft.com/en-us/security/advisory/2749655

Non è necessario disinstallare la versione originale dei Rollup prima di installare le loro re-release.

Il RU4-v2 per Exchange Server 2010 SP2 si trova al seguente link (attenzione alla lingua) :

http://www.microsoft.com/en-us/download/details.aspx?id=34956

Il RU7-v2 per Exchange Server 2010 SP1 si trova al seguente link (attenzione alla lingua) :

http://www.microsoft.com/en-us/download/details.aspx?id=34957

Il RU8-v2 per Exchange Server 2007 SP3 si trova al seguente link (attenzione alla lingua) :

http://www.microsoft.com/en-us/download/details.aspx?id=34959

  • Share/Bookmark

Pubblicato in Exchange Server 2007, Exchange Server 2010 | Nessun commento »

Lista ordinata delle dimensioni delle cassette postali in Exchange 2007/2010

Scritto da Ivan Salvade' il 17 novembre 2011

Nelle console grafiche di Exchange 2007 e 2010, nella sezione Mailbox posta nel gruppo “Recipient Configuration”, si vede la lista delle cassette postali, con diverse informazioni su di loro.  Purtroppo mancano alcune “colonne” piuttosto importanti, come per esempio una colonna “Size” che mostra la grandezza delle cassette postali, o una colonna “Last Logon Time” per osservare l’ultimo accesso effettuato alla cassetta postale.

Bisogna ricorrere a comandi Powershell per ottenere un output di questo tipo.  Anzi, utilizzando i comandi, i formattatori e la redirezione su file, possiamo ottenere report (anche cartacei) veramente validi.

Indico subito qua sotto un esempio di comando che genera un report contenente le seguenti informazioni :

  • nome dell’utente
  • grandezza della cassetta postale (scelta come variabile di ordinamento, dalla più grande alla più piccola)
  • grandezza dei cestini (posta eliminata)
  • numero di mail presenti in cassetta postale
  • data e ora dell’ultimo logon

Get-Mailbox -Database “nome_db” | Get-MailboxStatistics | Sort TotalItemSize -descending | Ft Displayname,TotalItemSize,ItemCount,TotalDeletedItemSize,LastLogonTime

Il report generato sarà simile al seguente :

s17-42-18.jpg      (clicca per ingrandire)

Inserendo, per esempio “>C:\pippo.txt” in fondo al precedente comando, posso redirezionare l’output su file, e stamparlo.

Se nel comando non inserisco il parametro -Database “nome_db“, vengono restituite tutte le mailbox trovate su tutti i database e su tutti i server dell’organizzazione.

L’elenco degli attributi può essere modificato a piacimento, così come le formattazioni in output.  A questo proposito, consultare l’help riguardanti i seguenti cmdlet formattatori :

  • Format-List
  • Format-Table
  • Format-Wide
  • Format-Custom

Buon divertimento!!  :-)

    • Share/Bookmark

    Pubblicato in Exchange Server 2007, Exchange Server 2010 | Nessun commento »

    Visualizzare gli ExtendedRights degli utenti nella Exchange Management Shell

    Scritto da Ivan Salvade' il 13 novembre 2011

    In Exchange 2007 ed Exchange 2010 (anche se in quest’ultimo è preferibile utilizzare il nuovo sistema di autorizzazioni RBAC), può capitare di dover visualizzare (e/o assegnare agli utenti) alcune particolari autorizzazioni avanzate (chiamate “Extended Rights”) degli oggetti di Exchange pubblicati in Active Directory.

    Esistono i seguenti comandi di Exchange Management Shell per queste operazioni :

    • Add-ADPermission : aggiunge autorizzazioni nuove
    • Get-ADPermission : visualizza le autorizzazioni esistenti
    • Remove-ADPermission : rimuove autorizzazioni

    Il comando interrogativo Get-ADPermission non visualizza per default gli Extended Rights, a meno che non uso una pipe con il cmdlet  |fl * oppure con il cmdlet |ft opportunamente formattato.   Ecco degli esempi.

    Supponiamo di voler sapere quali autorizzazioni base ed estese ha l’utente “Administrator” sul database di Exchange di nome “Mailbox Database 1″.  Il comando base da lanciare potrebbe essere il seguente :

    Get-ADPermission “Mailbox Database 1″ -user Administrator |fl

    Il cmdlet Format-List (fl) indica di mostrare tutte le informazioni possibili in formato lista.  Ecco l’output del comando in Fig. 1 :

    12-34-23bs.jpg      Fig. 1  (clicca per ingrandire)

    Con le frecce rosse ho indicato i punti in cui il comando ci avvisa della presenza di particolari Access Rights di tipo Extended, ma non ci avvisa di quali sono effettivamente!   Con la freccia verde ho indicato un tipo di autorizzazione base (”GenericAll”).

    Vogliamo sapere con precisione quali sono gli Extended Rights.  Otteniamo il risultato con una modifica al comando precedente :

    Get-ADPermission “Mailbox Database 1″ -user Administrator |fl *

    Il carattere * dopo il cmdlet fl indica di mostrare anche attributi di tipo esteso.  Ecco l’output in Fig. 2 :

    12-36-56bs.jpg      Fig. 2  (clicca per ingrandire)

    Ora gli Extended Rights “Send-As” e “Receive-As” sono visibili.

    Un altro modo per ottenere gli Extended Rights è utilizzare il cmdlet ft, indicando il preciso elenco di attributi da visualizzare.  Il comando potrebbe essere il seguente :

    Get-ADPermission “Mailbox Database 1″ -user Administrator |ft User,AccessRights,ExtendedRights,Deny

    Ecco l’output del comando in Fig. 3 :

      19144727-11-2011.jpg   Fig. 3  (clicca per ingrandire)

    Il cmdlet ft visualizza in output esattamente gli attributi richiesti (tra cui gli Extended Rights) in formato colonnare.  L’attributo “Deny” indica se un certo Diritto Esteso è negato (True) o concesso (False).

    Se volessimo aggiungere un determinato Extended Right ad un certo utente, si utilizza il comando Add-ADPermission.  Per esempio, se volessimo assegnare all’utente ”Test User” il particolare diritto esteso chiamato “ms-Exch-Store-Bypass-Access-Auditing” (permette di evitare che l’utente subisca la tracciatura quando accede alle cassette postali di un certo DB), il comando potrebbe essere il seguente :

    Get-MailboxDatabase “Mailbox Database 1″ | Add-ADPermission -user “Test User” -ExtendedRight ms-Exch-Store-Bypass-Access-Auditing -InheritanceType All

    Ecco l’output del comando in Fig. 4 :

    19192727-11-2011.jpg      Fig. 4  (clicca per ingrandire)

    Una nuova interrogazione con il comando Get-ADPermission e il formattatore ft ci mostra il diritto assegnato (Fig. 5) :

     19204027-11-2011.jpg     Fig. 5  (clicca per ingrandire)

    Gli Extended Rights, sia quelli usati nativamente da Active Directory che quelli usati sugli oggetti di Exchange, sono tutti pubblicati in una particolare sezione della Configuration Partition di Active Directory.  Per accedervi, si usa Adsiedit.msc su un Domain Controller.  Bisogna posizionarsi nel seguente contenitore :

    CN=Extended-Rights,CN=Configuration,DC=dominio,DC=estensione

    Buon divertimento con le autorizzazioni estese!!  :-)

    • Share/Bookmark

    Pubblicato in Exchange Server 2007, Exchange Server 2010 | Nessun commento »

    Abilitare il Relay Anonimo in Exchange 2007 e Exchange 2010

    Scritto da Ivan Salvade' il 30 settembre 2011

    Può capitare che alcune applicazioni abbiano bisogno di spedire mail verso indirizzi di posta esterni all’azienda, utilizzando un server Exchange interno (2007 o 2010).  Alcuni esempi possono essere :

    • un software di backup che deve spedire le mail di avvenuto/fallito backup
    • un software di monitoraggio che deve spedire mail contenenti avvisi, alert, report o altro
    • un software fax che deve spedire periodicamente le mail contenenti il report dei fax ricevuti ultimamente
    • il Visualizzatore Eventi di Windows 7/Windows Server 2008, che dà la possibilità di spedire una mail a qualcuno al verificarsi di un certo evento

    Tipicamente, queste applicazioni sono in grado di formattare le mail, ci chiedono di indicare loro un server di posta a cui consegnarle, e poi dovrà essere compito del server di posta inoltrarle all’indirizzo SMTP di destinazione.   Inoltre, queste applicazioni di solito non sanno effettuare un’autenticazione col server di posta stesso.

    In questo caso, siamo davanti al cosiddetto “Relay Anonimo” : un server di posta deve, cioè, essere in grado di ricevere in carico una mail da un’entità non autenticata (l’applicazione), ed effettuarne un “relay” verso l’indirizzo SMTP esterno specificato nella mail.   I server Exchange di Microsoft rifiutano, per default, questo tipo di operazione, per ragioni di sicurezza.

    Il Relay Anonimo potrebbe essere utilizzato dagli spammer per nascondere la sorgente dei loro messaggi, e quindi rappresenta un grosso problema di sicurezza se utilizzato maldestramente.

    In Exchange 2007 e 2010 il relay si configura utilizzando gli “Accepted Domains”, configurati sui server Edge o Hub.  Per un certo dominio di posta (o per tutti i domini, ma non fatelo!!!…  vorrebbe dire “Open Relay”, e finireste subito in blacklist!!…), si può istruire il server Exchange a riceverne le mail e ad inoltrarle verso altri server di posta esterni.    Ma questo non è ciò che voglio spiegare in questo articolo.

    Vi farò invece vedere come restringere il relay anonimo in base alla sorgente del messaggio da inoltrare, che, ripeto, può essere un’applicazione interna non in grado di autenticarsi col server Exchange.

    Il trucco consiste nel creare un “Receive Connector” dedicato a ricevere mail dall’applicazione, al quale dovremo indicare di non autenticare l’applicazione stessa, e di considerarla in qualche modo un’entità “di fiducia”.  In questo modo Exchange eseguirà il relay delle sue mail anche verso l’esterno.

    Nel mio esempio, simulo l’applicazione non autenticata con un banale Telnet Client, aperto su un Windows 7 con indirizzo IP 10.10.0.50, mentre il server Exchange si chiama VAN-EX1, ed è nella stessa rete del client.  Sul server Exchange, i Receive Connectors sono configurati come di default (Fig. 1) :

    11.JPG      Fig. 1

    In Fig. 2 mi sono connesso dal client alla porta 25 di VAN-EX1 e ho provato a spedire una mail verso un indirizzo di posta esterno (info@ivansalvade.it), ottenendo come esito ”Unable to Relay” :

    iniz.JPG      Fig. 2

    Il comportamento è corretto : il Receive Connector “Default VAN-EX1″, non consente il relay anonimo verso l’esterno di una mail da lui ricevuta.

    Creo ora un nuovo Receive Connector che configurerò per il relay anonimo (Fig. 3) :

    22.JPG      Fig. 3

    Lascio inalterati i Local Network Settings… (Fig. 4) :

    31.JPG      Fig. 4

    … ma modifico i Remote Network Settings eliminando la voce preesistente “0.0.0.0-255.255.255.255″ ed inserendo unicamente l’indirizzo IP del client (Figg. 5 e 6) :

    42.JPG      Fig. 5

    52.JPG      Fig. 6

    Terminata la creazione del nuovo Receive Connector, si entra nelle sue proprietà per modificare due parametri (Fig. 7) :

    61.JPG      Fig. 7

    Nel tab “Permission Groups” devo selezionare la voce “Exchange Servers” (Fig. 8 ) e nel tab “Authentication” devo selezionare la voce “Externally Secured” (Fig. 9) :

    7.JPG      Fig. 8

    81.JPG      Fig. 9

    Cosa significano questi due parametri?

    Con il settaggio “Externally Secured” si avvisa Exchange di considerare la connessione sicura, senza preoccuparsi di doverla autenticare.  Questo è utile quando tra client e server esiste già un’associazione IPSec o una VPN (non è il nostro caso), oppure quando noi personalmente riteniamo il client “sicuro” (è il nostro caso).

    Quando imposto “Externally Secured” nel tab “Authentication” sono obbligato a selezionare anche la voce “Exchange Servers” nel tab “Permission Groups”.  La selezione è imposta dal wizard, che altrimenti genererebbe un errore.

    La combinazione di “Externally Secured” e “Exchange Servers” assegna al Receive Connector (e quindi alle connessioni entranti su di esso) le seguenti autorizzazioni :

    •  Ms-Exch-Accept-Headers-Routing
    •  Ms-Exch-SMTP-Accept-Any-Sender
    •  Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
    •  Ms-Exch-SMTP-Submit
    •  Ms-Exch-Accept-Exch50
    •  Ms-Exch-Bypass-Anti-Spam
    •  Ms-Exch-Bypass-Message-Size-Limit
    •  Ms-Exch-SMTP-Accept-Any-Recipient
    •  Ms-Exch-SMTP-Accept-Authentication-Flag

    L’autorizzazione “Ms-Exch-SMTP-Accept-Any-Sender” permette al connettore di accettare qualunque tipo di mittente nelle mail.  L’autorizzazione “Ms-Exch-SMTP-Accept-Any-Recipient” è proprio quella che garantisce al connettore di eseguire relay dei messaggi a qualunque destinatario.  Se non ci fosse questa autorizzazione, sarebbe garantito solo il relay verso destinatari facenti parte della lista dei domini accettati.

    Molto interessanti anche le autorizzazioni “Ms-Exch-Bypass-Anti-Spam” e “Ms-Exch-Bypass-Message-Size-Limit”: significa che i messaggi provenienti dagli IP specificati nel connettore bypassano i controlli anti-spam e pure i controlli sulla grandezza massima dei messaggi.

    Ricordo ancora che, con questo sistema, gli indirizzi IP di provenienza delle mail sono considerati totalmente “di fiducia”, ed Exchange si fida della nostra valutazione “personale” fatta su tali indirizzi.

    Rifacciamo ora la prova di spedizione di una mail dal client 10.10.0.50 verso l’indirizzo esterno info@ivansalvade.it.  Questa volta l’esito è “Recipient OK” (Fig. 10) : Exchange ha infatti utilizzato il nuovo connettore impostato su “Externally Secured”, in quanto la mail proveniva esattamente dall’indirizzo IP 10.10.0.50, dichiarato come IP sorgente nel connettore.   In presenza di due connettori con indirizzi IP parzialmente sovrapposti (nel nostro caso il connettore “Default VAN-EX1″ comprende anche 10.10.0.50), viene utilizzato quello con l’indirizzo IP (o il range di indirizzi IP) più specifico.

    a1.JPG      Fig. 10

    Buon Relay Anonimo a tutti….  ma non esagerate perchè è pericoloso!!!  :-)  :-)

    • Share/Bookmark

    Pubblicato in Exchange Server 2007, Exchange Server 2010 | 7 Commenti »

    Event ID 3006 su Exchange Server 2007

    Scritto da Ivan Salvade' il 26 gennaio 2011

    Su un server Exchange 2007 è possibile trovare nell’Application log una cospicua ricorrenza di eventi con codice 3006, simili al seguente :

    Event Type: Warning
    Event Source: LoadPerf
    Event Category: None
    Event ID: 3006
    Date:  dd/mm/yyyy
    Time:  hh:mm:ss
    User:  N/A
    Computer: YourExchangeServer
    Description:  Unable to read the performance counter strings of the xxx language ID. The Win32 status returned by the call is the first DWORD in Data section.

    Questi eventi  sono dovuti ad un’errata registrazione di alcuni contatori di performance riguardanti l’Exchange stesso.  Un primo tentativo di risoluzione può essere tentato utilizzando da Command Prompt il comando

    • LODCTR /r

    Questo comando tenta di restorare dal registro di sistema le impostazioni e il testo di spiegazione dei contatori di performance.  L’operazione potrebbe andare totalmente o parzialmente a buon fine.  Se l’esito è parziale, compariranno nell’Application Log ulteriori eventi con codice 3009 e/o 2007, simili ai seguenti :

    Event Type: Error
    Event Source: LoadPerf
    Event Category: None
    Event ID: 3009
    Date:  dd/mm/yyyy
    Time:  hh:mm:ss
    User:  N/A
    Computer: YourExchangeServer
    Description:  Installing the performance counter strings for service MSExchangeFDS:OAB (%2) failed. The Error code is the first DWORD in Data section.

    Event Type: Warning
    Event Source: LoadPerf
    Event Category: None
    Event ID: 2007
    Date:  dd/mm/yyyy
    Time:  hh:mm:ss
    User:  N/A
    Computer: YourExchangeServer
    Description:  Cannot repair performance counters for MSExchangeFDS:OAB service. Please re-install manually using LODCTR tool.

    Questi eventi sono utili per comprendere quale preciso contatore il sistema non riesce a restorare.  Bisogna a questo punto procedere con una ricarica manuale del contatore, utilizzando sempre il comando LODCTR e alcuni files di Exchange che contengono le impostazioni e i testi di help di vari contatori .   Nell’esempio qui sopra, il contatore che non si riesce a restorare è quello collegato al servizio MSExchangeFDSOAB.  I files di configurazione dei contatori risiedono sempre nella seguente cartella del server Exchange : 

    • C:\Program Files\Microsoft\Exchange Server\Setup\Perf

    Bisogna localizzare il corretto file con estensione .INI (per esempio il file .ini corretto per l’evento riportato sopra, è “FDSOABPerformanceCounters.ini”).  Il file localizzato deve essere utilizzato nella sintassi del comando LODCTR.   Posizionare il Command Prompt sulla directory “…\Exchange Server\Setup\Perf”, e digitare il seguente comando :

    • LODCTR FDSOABPerformanceCounters.ini

    La corretta registrazione del contatore deve essere confermata da un evento informativo che comparirà nell’Application Log, simile al seguente :

    Event Type: Information
    Event Source: LoadPerf
    Event Category: None
    Event ID: 1000
    Date:  dd/mm/yyyy
    Time:  hh:mm:ss
    User:  N/A
    Computer: YourExchangeServer
    Description:   Performance counters for the MSExchangeFDS:OAB (MSExchangeFDS:OAB) service were loaded successfully. The Record Data contains the new index values assigned to this service. 

    Ripetere il comando LODCTR per tutti i contatori per i quali esistono errori con codice 3009 e 2007 nell’Application Log.

    • Share/Bookmark

    Pubblicato in Exchange Server 2007 | Nessun commento »

    Errore : Generate Activaton Context failed su Exchange Server 2007

    Scritto da Ivan Salvade' il 24 gennaio 2011

    Su un server Exchange 2007 SP2 con installati i ruoli CAS/HUB, possono comparire in alcuni casi errori simili al seguente :

    Event Type: Error
    Event Source: SideBySide
    Event Category: None
    Event ID: 59
    Date:  dd/mm/yyyy
    Time:  hh:mm:ss
    User:  N/A
    Computer: YourExchangeServer
    Description:   Generate Activation Context failed for C:\WINDOWS\WinSxS\amd64_ Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6E02DFE5\MFC80U.DLL.  Reference error message: The referenced assembly is not installed on your system.

    L’errore è facilmente eliminabile installando sul server il componente :

    • Microsoft Visual C++ 2005 Redistributable Package (x64)

    Il Componenente è scaricabile al seguente link : http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=it

    L’installazione del componente non richiede il riavvio del sistema.

    • Share/Bookmark

    Pubblicato in Exchange Server 2007 | Nessun commento »

     
    Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
    Ok