Peppacci

Il blog di Giuseppe Traficante
posts - 31, comments - 15, trackbacks - 1

Friday, October 01, 2010

Rinnovo Award Microsoft MVP



Ho appena scaricato una Mail :) e con molto piacere sono stato informato che per il terzo anno di fila ho ricevuto il Microsoft® MVP Award per la categoria Exchange Server.

Ringrazio la community di SysAdmin.it ed in particolare Alessandro Teglia.

Grazie a tutti.

posted @ Friday, October 01, 2010 2:52 AM | Feedback (0) |

Sunday, December 27, 2009

Installare un Active Directory Certificate Services su Win2008 R2 e crare un certificato per un server Microsoft Exchange Server 2007 ed uno per un Microsoft Exchange Server 2010.

Installare un Active Directory Certificate Services su Win2008 R2 e crare un certificato per un server Microsoft Exchange Server 2007 ed uno per un Microsoft Exchange Server 2010.
Scenario:
Le macchine sotto elencate, quelle dove andremo ad eseguire alcune configurazioni fanno parte di un Dominio AD Win2008 R2 con installato un ambiente misto con Microsoft Exchange Server 2007 e 2010.
DC01: Win2008 R2 Domain Controller
CAS01: Win2008, Microsoft Exchange Server 2007 roule: Client Access Server
CAS02: Win2008 R2, Microsoft Exchange Server 2010 roule: Client Access Server
Quello che andremo a fare è installare un CA interna al nostro Dominio AD dove genereremo due certificati per i due CAS server avendo prima sottomesso le rispettive richieste.
Per prima cosa installiamo l’ Active Directory Certificate Services sul DC01:
Apriamo il server manager --> Roles --> Add Roles
Selezioniamo “Active Directory Certificate Services
Selezioniamo “Certificate Autority, Certificate Autority Web Enrollment” e confermiamo le relative Features dipendenti.
Per i successivi step lasciamo le impostazioni di default:
Per i parametri sottostanti potete lasciare quelli di dafault se intende usare questa CA solo per rilasciare un certificato per Exchange Server o altri servizi che soddisfano quei prerequisiti, contrariamente potete variare sia l’algoritmo di HASH che la lunghezza della chiave.
Qui potete specificare la posizione del Database dei certificati ed i relativi log.
Confermate e installate.
Verificate che la CA sia raggiungibile all’indirizzo http://DC01/certsrv
Ora andiamo a generare la richiesta di certificato sul server CAS01.
Apriamo la EMSExchange Management Console
Prima di generare il certificato vanno fatte un paio di premesse: il certificato deve avere nel “Common Name“ l’indirizzo della WebMail di OWA es: webmail.peppacci.it per l’indirizzo di OWA https://webmail.peppacci.it/owa, nei vari “Subject Alternative Name” per la corretta generazione di un certificato per Exchange 2007 dobbiamo indicare altri parametri come: autodiscover.peppacci.it per la gestione del servizio Autodiscover dei client Outlook dal 2007 in poi, CAS01 che è l’indirizzo Netbios del server CAS, CAS01.domain.local che è l’indirizzo DNS del CAS all’interno del dominio AD ed infine dobbiamo reinserire anche l’indirizzo inserito come Common Name: webmail.peppacci.it assicurandoci che sia il primo della lista “si potrebbe discutere a livello security aver reso visibile il nome DNS AD del server CAS ma non è argomento di questa guida”. Ora possiamo generare la richiesta di certificato con la cmdlet “New-ExchangeCertificate”, di seguito la sintassi:
New-ExchangeCertificate -GenerateRequest -KeySize 1024 -SubjectName "c=IT, s=italia, l=Roma, o=Peppacci, ou=Web Administration, cn=webmail.peppacci.it" -DomainName webmail.peppacci.it,  autodiscover.peppacci.it, cas01.domain.local, cas01 -PrivateKeyExportable $True –path c:\cert_req.txt
Come vedete è stata generata una richiesta di certificato con il suo Thumbprint. Ora andiamo ad aprire quasta richiesta e selezioniamo tutto il contenuto copiandolo:
Apriamo la URL per richiedere un certificato: http://DC01/certsrv e selezioniamo “Request Certificate
Selezioniamo “Advanced certificate request
Selezioniamo “Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.”
Nella maschera “Saved Request” incolliamo la richiesta del certificate e come template selezioniamo “Web Server” e clickiamo su “Submit
Ora possiamo salvare il nostro certificato
Ora importiamo il certificato appena creato e lo abilitiamo per i servizi IIS POP3 IMAP4:
[PS] C:\>Import-ExchangeCertificate -Path C:\certnew.cer
[PS] C:\>Enable-ExchangeCertificate 2A9F14ABB9C0CA903A76BCC2B3F61C2A5BA2942C -Services "IIS, POP, IMAP"
Verifichiamo la presenza del certificato appena creato da EMS e dalla console di IIS
 
Ora faremo le stesse operazioni sul CAS di Exchange Server 2010, generando la richiesta, creando il certificato, importando il certificato ed abilitarlo ai servizi di Exchange.
La sintassi della cmdlet per “New-ExchangeCertificate” è leggermente diversa:
Set-Content -path "c:\newcert.req" -Value (New-ExchangeCertificate -GenerateRequest -KeySize 1024 –SubjectName "c=IT, s=Italia, l=Roma, o=peppacci, ou=Web Administration, cn=webmail2010.peppacci.it"     -DomainName webmail2010.peppacci.it, cas02, cas02.hypermail.local -PrivateKeyExportable $True)
Come per il CAS01 andremo a generare il nostro certificato dalla CA sul DC01 inserendo il contenuto del file newcert.req appena creato. Ottenuto il certificato seguendo la stessa procedura per quello precedentemente creato lo andremo ad importare sul CAS02 ed associarlo ai servizi “IIS, POP, IMAP
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certnew.cer -Encoding byte -ReadCount 0))| Enable-ExchangeCertificate -Services "IIS, POP, IMAP"
Chiaramente i certificati appena emessi sono stati erogati da una CA interna al Dominio AD, quindi questi risulteranno al mondo esterno provenienti da fonte non attendibile mostrandoci il classico allert nei browser IE 7 in poi. Quello che potete fare per risolvere il problema soprattutto se volete collegarvi ai servizi di OutlookAnyWhere è installare il certificato sui client che dovranno utilizzare i servizi di Exchange Server, oppure potete acquistare un certificato valido dalle società abilitate a questo servizio.
 
Saluti.
 

posted @ Sunday, December 27, 2009 6:42 AM | Feedback (0) | Filed Under [ Exchange Server ]

Monday, October 12, 2009

Ricaricare manualmente i Performance Counter Library di Microsoft Exchange Server 2003

Spesso capita per chi amministra una farm con molti server Microsoft Exchange 2003 che su alcune macchine nel Performance Monitor risultano mancanti alcuni se non tutti i Counter di Exchange.
Tali informazioni vengono memorizzate nei file %Systemroot%\System32\Perfc009.dat e %Systemroot%\System32\Perfh009.dat e nella seguente chiave di registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Perflib\009.  Facendo un export della chiave appena indicata vedrete una lista indicizzata di tutti i Performance Counter e chiaramente non troverete quelli che vi mancano, non provate ad inserirli a mano perche sarebbe inutile.
Il modo più veloce per fare il rebuild dei Performance  Counter di Exchange 2003 è quello di estrarre la lista dei file.ini utilizzati per caricare i contatori e rilanciare l’installazione, di seguito cinque semplici passaggi:
1)      Posizionarsi nella cartella dei binari di Exchange (c:\program files\exchsrvr\bin) con una sessione cmd.exe
2)      Eseguire il seguente comando: findstr /m drivername *.ini > exchperf.cmd
3)      editare con notepad il file exchperf.cmd e per ogni riga in cui compare un file .ini preporre il comando: lodctr.  Es. linea originale = alfa.ini -> modificata= lodctr alfa.ini
4)      salvare le modifiche al file e sempre da cmd eseguire il file exchperf.cmd
Terminata la procedura riavviate la macchina.
Va sottolineato che per i Counter di OMA “Outlook Mobile Access” va eseguita la re installazione dei contatori diversamente da quanto detto precedentemente, va eseguito il seguente file d’installazione con i parametri indicati:
"C:\Program Files\Exchsrvr\OMA\browse\bin\OmaBrowseInstall.exe" counters /create
 
Nel seguente link http://support.microsoft.com/kb/300956/en-us  viene descritto come ripristinare i Performance Counter di default caricati al momento dell’installazione del Sistema Operativo, fate attenzione però, tutti quelli aggiunti dalle varie applicazione nel tempo andranno persi quindi ricaricati a mano.
 
Saluti.

posted @ Monday, October 12, 2009 9:45 PM | Feedback (0) | Filed Under [ Exchange Server ]

Wednesday, August 12, 2009

Creare numerosi utenti e relative mailbox con EMS "Exchange Management Shell"

Creare numerosi utenti e relative mailbox con EMS "Exchange Management Shell"
Ambiente: Domain Controller win 2008r2 Enterprise Edition + win 2008 Enterprise Edition con Exchange 2007 Enterprise Edition.
Spesso capita la necessità in un ambiente di test di creare numerosi Users con le relative mailbox associate in maniera automatizzata senza doverlo farle singolarmente.
Di seguito verranno elencati i passi fondamentali da eseguire con EMS “Exchange Management Shell” e come realizzare un file Users.csv da cui fare l’import dei dati.
Per prima cosa dobbiamo creare un utente di riferimento con la sua MailBox inserendolo nella Organizational Unit di riferimento “TestGroup01”
New-Mailbox -Alias user01 -Database "mailbox01\First Storage Group\Mailbox Database" -Name user01 -OrganizationalUnit TestGroup01 -FirstName user01 -LastName user01 -DisplayName "user01" -UserPrincipalName user01@2008r2domain.local
Come vedete dall’output bisogna impostare la password dell’utente.
L’utente appena creato.
Ora useremo l’utente appena creato per impostare un Template di riferimento:
$Template = Get-Mailbox "user01"
Stesso discorso per impostare un template per la password:
$Password = ConvertTo-SecureString Pass.123 -AsPlainText -Force
 Ora dobbiamo creare un file users.csv dove andremo ad inserire gli utenti da importare:
Chiaramente con un minimo di manualità con Microsoft Excel questa lista può facilmente raggiungere numerose righe.
Ora andremo a fare un import dal file Users.csv creando degli utenti inseriti in quella lista prendendo come riferimento i Template precedentemente creati sia per l’utente che per la password:
Import-CSV C:\Users.CSV | ForEach { New-Mailbox -Name $_.Name -UserPrincipalName $_.UPN -Database $_.MailboxDatabase -OrganizationalUnit $_.OrganizationalUnit -Password $Password -Template $Template }
Lista aggiornata degli utenti:
 
Saluti a tutti.  

posted @ Wednesday, August 12, 2009 9:21 AM | Feedback (0) | Filed Under [ Exchange Server ]

Thursday, June 25, 2009

Messaggio di servizio.

posted @ Thursday, June 25, 2009 11:19 PM | Feedback (0) |

Monday, May 11, 2009

Tar Pit

Tar Pit
Di seguito riporto gli appunti di un collega “Stefano Clabrese” di cui o condiviso tale problematica.

Sui server della piattaforma che gestiamo “macchine Win 2003 con Exchange 2003 e Recipient Filtering abilitato” arrivano quotidianamente migliaia (per qualcuno anche milioni) di email spam, inviate a utenti esistenti e non. Una volta accettata la mail, l'RFC 2821 vorrebbe che per queste email venga generato un rapporto di mancato recapito che ritorna al mittente della email. Queste “persone” malintenzionate mediante uno script possono in poche ore inviare milioni di richieste al server smtp pubblicato su Internet, filtrando quindi le risposte di tipo 550 – user unknown per catturare gli indirizzi email validi e quindi per loro (ma anche per chi deve gestire la posta elettronica) estremamente preziosi.
Si rende quindi necessaria una scelta, filtrare al livello di server MX questi indirizzi, verificando preventivamente all'accettazione della mail l'esistenza della mailbox oppure smettere di inviare NDR verso internet. Raccomandazioni RFC a parte, finiremmo per filtrare anche gli NDR destinati verso utenti esistenti che hanno semplicemente sbagliato a digitare l'indirizzo del nostro utente (non possiamo mica pretendere che tutti conoscano il CTRL+K ... ).
Se si dovesse optare per la prima scelta, è molto probabile che ad una prima diminuzione dello spam e del numero di NDR inviate verso internet, vedremmo seguire un aumento della dimensione dei log SMTP. Dovuti a cosa? Immaginate un po’, qualcuno si è accorto che stiamo filtrando gli utenti, per cui molto semplicemente sta usando uno script che genera indirizzi email in modo casuale e li sta confrontando con le risposte del nostro smtp.
550 - non buono
550 - non buono
550 - non buono
250 - ah... questo è buono. Da domani questo indirizzo può iniziare a ricevere Unsolicited Content Email... cioè SPAM.

Si vabbè, le possibili combinazioni sono troppe per riuscire a matchare completamente la nostra rubrica, però se considerate che si può partire con un "dizionario" prepopolato di parole, nomi, cognomi e che probabilmente si può inviare un rcpt to: ogni pochi ms (dipende ovviamente dalle performance del server), qualche email valida di sicuro la trova. E vi gonfia il log in modo totalmente incontrollato.
Soluzioni?
Ad esempio il tar pit, letteralmente una macchia di catrame in cui far impantanare gli spammer. Cioè si "degradano" leggermente i tempi di risposta dell'SMTP ed il gioco è fatto. Prerequisito è Windows Server 2003 SP1, nessuna patch o fix, solo l'implementazione di un parametro sul registro del servizio SMTPSVC ed un riavvio dello stesso.
Il parametro è una DWORD chiamata TarpitTime che va popolata con un valore decimale corrispondente al numero di secondi che il server SMTP dovrà attendere prima inviare una risposta di verifica degli indirizzi SMTP immessi. E' sufficiente una manciata di secondi, probabilmente anche uno solo per scoraggiare o questo tipo di attacco, che, nel tentativo di verificare anche un milione di indirizzi (ma potrebbero essere molti di più...), non può attendere le risposte per un milione di secondi (circa 11 giorni e mezzo...).
E per gli utenti legittimi? Beh anche se una mail dovesse essere indirizzata a 100 recipient, 100 secondi di attesa totale non sono poi moltissimi. E' chiaro che va monitorato l'effetto sul nostro server. Peraltro questa modifica funziona per gli invii di posta non autenticati, per cui se ci fosse necessità di ricevere grandi quantità di posta da un dominio esterno, si potrebbe sempre configurare un invio autenticato dall'altro smtp (sempre che ci si riesca...).
La DWORD va creata (se non esiste già) sotto:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters

Ulteriori info le trovate qui: http://support.microsoft.com/kb/842851/en-us

 

posted @ Monday, May 11, 2009 9:48 PM | Feedback (0) | Filed Under [ Exchange Server ]

Wednesday, May 06, 2009

Sarà finita? To be continued...

posted @ Wednesday, May 06, 2009 9:05 AM | Feedback (2) |

Sunday, April 26, 2009

Defrag DB exchange 2003

Uno dei maggiori problemi che si hanno lavorando sui DB di Microsoft Exchange Server è l'allocazione di spazio sul disco. I DB di exchange crescono all'aumentare del volume delle singole Mailbox e fin qui niente di strano, il problema lo abbiamo se facciamo un pò di pulizia sulle cassette postali magari con qualche policy di Exchange o addirittura concellando quelle Mailbox che non hanno più ragione di esistere, noteremo che il DB non diminuusce di dimensioni come ci aspettavamo, anzi rimane esattamente lo stesso. Questo accade perché il database di Exchange è costituito da pagine che aumentano all'aumentare della richiesta di spazio ma non diminuiscono se vengono cancellati i dati sul db, vengono semplicemente liberate che teoricamente vengono rese disponibili al database per archiviarci i nuovi dati.

Per eliminare definitivamente queste pagine bisogna eseguire un defrag off-line del database tramite l'utility ESEUTIL

http://technet.microsoft.com/en-gb/library/aa998249.aspx

Nello specifico "eseutil /d db.edb", questa sintassi implica che nella posizione dove lanciamo l'eseutil ci sia anche il file db.stm, contrariamente la sintassi diventa la seguente "eseutil /d db.edb /s x:\db.stm". Ricordate che questa operazione si fa a db smontato, quindi mailbox non disponibili.

Quando si esegue un defrag bisogna ricordarsi che l'utility eseutil genera dei file temporanei sia per il file db.edb che per il file db.stm, quindi per questi file bisogna avere spazio libero sul disco per tale operazione. La quantità di spazio libero a detta di Microsoft deve essere del 110% della somma dei file da deframmentare ma non è proprio così, lo spazio libero che ci serve deve essere la somma dei nuovi DB che si andranno a ricreare più un 10% per stare tranquilli.

ma quanto sarà questo spazio?

Per capire di quanto il db verrà ridimensionato quindi di quanto spazio libero su disco ho bisogno devo usare sempre l'utility ESEUTIL  con la seguente sintassi "eseutil /ms db.edb /s x:\db.stm". Questa operazione va fatta sempre a db smontato ed impiega un pò di tempo dovuto da diversi fattori: dimensione e stato dei db, performance del computer, comunque risulta essere inferiore al tempo che impiegherebbe a fare il defrag completo.

L'output di questa procedura sembra abbastanza complesso ma a noi interessa la parte iniziale e quella finale.

Sulla parte iniziale dobbiamo andare ad osservare questi dati: 

Il volere evidenziato è relativo al database di streaming db.stm ed indica il numero di pagine libere per quel db. Nello spececifico sono 72102, questo valore se moltiblicato per 4000 che è la dimensione in byte di ogni singola pagina ci da come risultato 288 mb. circa di pagine libere. Il db.stm in questione è un file di circa 16,9 gb che se gli sottraiamo 288 mb. di pagine libere avremo un db deframmentato di 16,6 gb circa, di conseguenza questo sarà anche la dimensione massima del file temporaneo in fase di deframmentazione per il db.stm.

Questa è invece la parte finale dell'output:

 

In questo caso abbiamo il numero delle pagine libere per il db.edb pari a 575377 che moltiplicate per 4000 ci da un totale di 2,3 gb. circa di pagine libere che sottratti ai 14,8 gb. del db.edb ci darà un db deframmentato di 12,5 gb.

Dopo il risultato dell'output dato da "eseutil /ms" siamo in grado di dire quanto guadagneremmo ad eseguire un defrag off-line dei db e di quanto spazio libero su disco ho bisogno per eseguire tale operazione. Se sul disco dove sono presenti i db da deframmentare non ho spazio ha sufficienza per allocare i db temporanei del defrag posso usare le opzioni di eseutil per indirizzare i db temporanei su altri volumi, di seguito la sintassi completa:

"eseutil /d x:\db.edb /s y:\db.stm /t v:\temp.edb /f z:\temp.stm"

 

Prima di eseguire un defrag off-line di un db vanno fatte delle riflessioni, considerazioni. E' nella natura di un db di exchange allocare e liberare delle pagine, quindi fin quando ho delle pagine libere le dimensioni del db non cambieranno, naturalmente un valore spropositato delle stesse potrebbe giustificare un defrag off-line. I tempi di esecuzione del defrag non sono rapidissimi, anzi, mediamente si deframmentano circa 10 gb. ora per un db, e se i temp db li abbiamo allocati su ulteriori volumi o unità di rete va considerato anche il tempo che impiegano questi file a fare il move sulla posizione corretta, di conseguenza per un db di 100 gb. potrebbero volerci 10 ore tempo, tempo da considerare per il disservizio erogato.

 

Come ultimo consiglio, dopo aver effettuato il defrag del vostro db, eseguite subito un backup in quanto avendo ricostruito anche gli indici del db un eventuale backup incrementale che avevate memorizzato non è più utile per un ripristino dati.

 

Saluti.     

posted @ Sunday, April 26, 2009 4:35 AM | Feedback (1) | Filed Under [ Exchange Server ]

Monday, March 09, 2009

Prima o poi..

posted @ Monday, March 09, 2009 6:57 AM | Feedback (0) |

Friday, March 06, 2009

Bella pe voi...

mmmmbè........

posted @ Friday, March 06, 2009 9:41 AM | Feedback (0) |

Powered by:
Powered By Subtext Powered By ASP.NET