Peppacci

Rinnovo Award Microsoft MVP

Peppacci — Fri, 01 Oct 2010 14:52:48 GMT

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.

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.

Peppacci — Sun, 27 Dec 2009 18:42:42 GMT

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 EMS “Exchange 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.

Ricaricare manualmente i Performance Counter Library di Microsoft Exchange Server 2003

Peppacci — Tue, 13 Oct 2009 09:45:41 GMT

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.

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

Peppacci — Wed, 12 Aug 2009 21:21:27 GMT

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.

Messaggio di servizio.

Peppacci — Fri, 26 Jun 2009 11:19:31 GMT

Tar Pit

Peppacci — Tue, 12 May 2009 09:48:45 GMT

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

Sarà finita? To be continued...

Peppacci — Wed, 06 May 2009 21:05:56 GMT

Prima o poi..

Peppacci — Mon, 09 Mar 2009 18:57:03 GMT

Bella pe voi...

Peppacci — Fri, 06 Mar 2009 21:41:20 GMT

mmmmbè........

L'importante è capirsi...

Peppacci — Tue, 24 Feb 2009 13:28:38 GMT

R: M.. garda questa macchine mi sembra un affare....

M: Sembrerebbe, ma è un coupè o una cabriolet?

R: mmmm..... è un B... serie ......

M: Ok, ma è una coupè o una cabriolet?

R: mmm... te l'ho detto, è una B.. serie.......

M: AOH!!!!! ce l'ha o nun ce l'ha er tetto????

LOL