Nici hotfix-ul nu este nou insa acum a fost inclus in ultimul update pentru Internet Explorer:

MS11-099- Cumulative Security Update for Internet Explorer- December 13, 2011

Mai multe detalii aici:

http://support.microsoft.com/kb/2624899

Nu-l instalati (asteptati RU5) sau daca l-ati instalat fiti pe faza.

http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx

Pana acum multe scenarii nu erau suportate in mediu virtual,insa se pare ca de acum puteti beneficia de toate functionalitatile Exchange 2010 pe platforma virtuala. Inclusiv rolul de Unified Messaging. Iar pentru cei ce stiu sa citeasca atent detaliile, suportul asta e valabil si pentru Exchange pe Vmware.

http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm

PS: asta e cumva efectul comunitatii care a tot tipat pana cand MS nu a mai avut ce face si a schimbat ceva.

http://www.microsoft.com/downloads/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b&displaylang=en

Atentie ca exista si cateva known issue dupa instalare; mai bine nu va grabiti decat daca sunteti foarte siguri pe ceea ce faceti.

Probabil voi reveni si cu cateva new features aduse de SP1.

Pana acum a fost anuntat doar un beta care va fi distribuit dupa cum am zis in Iunie asa ca pana atunci ne vom multumi cu cateva din detaliile care au fost postate pe net:

- va contine toate update-urile pana la momentul lansarii SP1

- imbunatatiri pe partea de Online Archiving – mailboxul arhiva va putea fi stocat si in alta baza de date (nu cea in care se afla mailboxul primar al userului).

- va fi posibil importul de PST (in mailbox sau arhiva) fara a mai fi nevoie de Outlook

- OWA imbunatatit (cu suport de teme)

- imbunatatiri pe parte de retention policies (wizarduri in EMC)

- managementul Role Based Access Control (RBAC) mult imbunatatit din interfata grafica.

- configurare MailTips din interfata grafica.

- imbunatatiri pe partea de IRM si Outlook Mobile

Si multe altele; probabil ca pana cand va fi lansat o sa vedem si alte lucruri noi. Pentru mai multe detalii va recomand sa cititi:

http://msexchangeteam.com/archive/2010/04/05/454533.aspx

Arhiva separata pe mailbox a fost una din marile promisiuni ale lui Exchange 2010. In momentul de fata chiar si dupa ce Exchange 2010 a fost lansat e tot doar o promisiune. O sa explic in continuare noua functionalitate din Exchange.

In prima faza trebuie sa activam optiunea de arhiva la nivel de mailbox. Putem face asta din wizard-ul New Mailbox:

Sau click dreapta pe un mailbox existent si Enable Archive.

Se mai poate si din Powershell cu New-Mailbox si parametrul Archive insa nu am avut curiozitatea sa testez.

In momentul in care activam arhiva din ESM primim mesajul urmator:

Ok. Macar de-ar fi o functionalitate care sa justifice un CAL mai scump (o sa vedem in continuare).

Dupa activare iconita userului se modifica putin, in acest fel putand identifica userii care au activata arhiva.

In mare, cam atat e de setat. Imediat dupa, userul va vedea optiunea Online Archive in Outlook (si in OWA), putand sa mute mesaje in folderele din arhiva.

Arhiva se vrea a fi un inlocuitor pentru PST-urile locale ale userului, insa problema este ca aceasta arhiva nu sta pe server intr-un mailbox store separat, ci se afla in acelasi store cu mailboxul normal al user-ului, facand toate promisiunile MS sa pice. Dupa cum spune si denumirea – Online Archive, arhiva e disponibila numai online, neputand fi cache-uita in OST ca si mailboxul normal.

Initial se vorbea de storage mai lent si mai ieftin pentru arhiva, backup separat (si mai ieftin normal), eventual si server separat, etc. Insa toate acestea nu sunt posibile in Exchange 2010 RTM.

Cam singurul scenariu util care il vad pana acum ar fi in cazul reinstalarii OS-ul pentru un user. In loc sa-si sincronizeze tot continutul din Exchange, va sincroniza doar ce se afla in mailbox-ul primar ignorand arhiva care poate fi accesata doar online. De fapt scenariul e fortat de limitarile din Exchange.

Totusi, promisiunile facute inainte de aparitia Exchange 2010 RTM se pare ca vor fi respectate in SP1 care vine cu multe imbunatatiri. Data viitoare o sa detaliez cate ceva din SP1.

PS: treaba cu SP1 este inca o dovada ca MS scoate produsele in mare graba chiar si cu functionalitati incomplete si intareste regula “instaleaza abia dupa ce apare primul SP”. Iar smecheriile cu produs lansat direct cu SP1 nu tin

MS a facut ceva recomandari de pe cand a aparut Exchange 2007 si a recomandat ca SIS sa nu fie luat in calcul atunci cand se face dimensionarea serverelor; chiar daca la Exchange 2007 SIS era folosit doar la atasamente.

Iata ca incepand cu Exchange 2010 am aflat de ce s-au facut acele recomandari. Pentru ca in Exchange 2010 nu mai exista SIS. Pentru cei care si-au consolidat foarte multi useri pe cateva servere in datacenter, efectul o sa se faca simtit. Ca exemplu luati un mail de 5Mb trimis catre o lista de 2000 de useri de pe aceeasi baza de date. O sa ocupe ceva, nu? O sa conteze mai ales diferenta intre cat ocupa in Exchange 2007 si cat ocupa in 2010.

Bineinteles cu un planning facut cum trebuie inainte de implementarea Exchange 2010 nu ar trebui sa existe probleme. Sper ca beneficiile aduse prin performanta si HA sa compenseze lipsa acestui feature deoarece reactiile clientilor nu au fost foarte placute. Unii au venit chiar cu argumente care demonstreaza ca SIS aducea un plus de performanta care nu are cum sa fie acoperit de schimbarile din Exchange 2010 si platforma pe 64 de biti. De exemplu un atasament de 5Mb citit o singura data de pe disc si cache-uit o singura data in memorie. Asta comparativ cu 1000 de accese la disc si mult mai multa memorie ocupata. Cum poti intrece asta? Eu cred ca s-au impiedicat cumva in SIS la realizarea DAG-ului si nu au stiut ce scuza sa gaseasca.

Argumentul ca storage-ul e ieftin in ziua de azi nu e suficient pentru un bun admin. Exista costuri asociate si cu partea de backup & recovery care cresc odata cu dimensiunea bazelor de date.

PS: Exista si database compression in Exchange 2010 insa nu cred ca va compensa lipsa SIS-ului deoarece nu comprima atasamentele – este exact opusul lui Exchange 2007. 2007 comprima doar atasamentele, iar 2010 comprima doar message body-ul.

Vit mi-a atras atentia ca ne alerteaza si atunci cand trimitem catre un recipient extern. Doar ca by default nu face asta. Optiunea trebuie  activata la nivel de organizatie.

Cu Get-OrganizationConfig | fl *mailtips* vedem setarile ce tin de mailtips.

Ca sa activam mailtips pentru external recipients folosim comanda urmatoare:

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled:$True

Acum cand trimit un email unui user extern organizatiei mele primesc un avertisment in Outlook:

La fel se intampla si atunci cand trimit unei liste de distributie care contine un recipient extern.

MailTipsLargeAudienceThreshold se refera la numarul de membri ai unui liste pentru a fi considerata Large Audience.

Pentru a intelege mai bine la ce se refera MailTipsGroupMetricsEnabled ar fi bina sa aruncati un ochi aici. MailTips se foloseste de Group Metrics pentru a determina daca un grup intra la categoria Large Audience sau are recipienti externi. Group Metrics ruleaza odata pe zi pe serverul care genereaza OAB si singura metoda de a-l forta sa ruleze in afara perioadei schedulate este de a restarta serviciul Exchange Service Host. Atentie si la scenariile de coexistenta 2007 cu 2010: daca OAB-ul este generat pe un server cu Exchange 2007, informatiile despre Group Metrics nu vor fi generate. La fel si pentru cazul in care OAB-ul este distribuit numai prin Public Folders.

Informatiile despre Group Metrics sunt puse intr-un share numai Group metrics pe serverul de pe care se genereaza urmand a fi preluate de acolo de CAS prin serviciul Exchange File Distribution.

Ultima optiune despre care vom discuta este MailTipsMailboxSourcedTipsEnabled si se refera la adaugarea de MailTips la nivel de obiect (mailbox, contact ,grup). Pentru a face acest lucru folosim optiunea MailTip din urmatoarele cmdlet-uri:

Set-Mailbox
Set-MailContact
Set-MailUser
Set-DistributionGroup
Set-DynamicDistributionGroup
Set-MailPublicFolder

In exemplul de mai jos am setat o descriere pentru un grup; descriere care va fi afisata de fiecare data cand cineva incearca sa trimita un email grupului.

Exista o limita de 250 de caractere pentru aceste MailTips, si mai pot fi setate si traduceri ale acestor mesaje prin parametrul – MailTipTranslations.

That’s all for today!

HTH

O arat cum functioneaza Mail Tips printr-un scenariu foarte simplu. Trimiterea unui email la un user care are setat Out of the office. Inainte sa apuc sa trimit emailul (de fapt asta se intampla la cateva secunde dupa completarea adresei de email in Outlook), clientul de mail ma avertizeaza ca acel user are Out of the office setat, deci e posibil sa nu fie la birou si atunci mailul meu sa fie trimis degeaba.

Alte exemple in care ajuta Mail Tips: trimiterea unui mesaj unui user cu mailbox-ul plin; mesaje cu atasamente care depasesc limitele setate de administrator, sau mesaje trimise unui recipient care are “delivery restrictions” setat.

MailTips mai avertizeaza utilizatorul si atunci cand se trimite un email catre o lista cu mai mult de 25 de membri. Inca un avertisment bine venit este acela de Reply-All BCC – atunci cand dai reply all la un mesaj in care adresa ta era initial in BCC.

Aceste MailTips-uri pot fi customizate la nivel de organizatie sau la nivel de recipient in Exchange, dar mai multe despre asta in alta zi .

LCR – local continuous replication – este folosit in cazul organizatiilor de mici dimensiuni, care doresc sa replice o copie a bazei de date Exchange pe un alt volum, pe acelasi server.

SCC – single copy cluster – a fost preluat din versiunile mai vechi de Exchange. Este implementarea standard de cluster care foloseste storage partajat si permite tuturor nodurilor clusterului sa acceseze resursele. Un nod al clusterului va detine resursele pentru un anumit grup, iar celelalte noduri vor comunica cu quorum-ul pentru evita situatia in care resursele partajate ar fi accesate de un alt nod decat cel activ in urma producerii unei erori.

CCR – cluster continuous replication – este folosit pentru a replica bazele de date Exchange intre servere oferind redundanta atat la nivel hardware cat si din punct de vedere al storage-ului.Unul dintre impedimente il reprezinta faptul ca acest tip de cluster nu suporta decat un singur nod activ.

SCR – standby continuous replication – a devenit disponibil odata cu lansarea Exchange 2007 SP1 pentru a putea replica bazele de date Exchange intr-o locatie aflata la distanta, cum ar fi un centru pentru disaster recovery.

Lansarea celei mai noi versiuni de Exchange, 2010, aduce o modificare majora a solutiei de clustering prin introducerea noului feature numit DAG(Database Availability Group).In principiu, DAG combina functionalitatile CCR si ale SCR din Exchange 2007 acoperind atat partea de high availability, cat si cea de disaster recovery.In aceasta noua versiune de Exchange Server LCR si SCC nu mai sunt disponibile, singura metoda de a configura un cluster Exchange reprezentand-o DAG.

Alte schimbari majore fata de versiunea anterioara de Exchange este faptul ca putem instala si alte roluri pe serverul care este configurat ca membru al DAG(mai putin Edge Server) si ca a fost eliminat conceptul de Storage Group, in aceasta versiune replicarea se produce la nivel de baza de date, caz in care numele acelei baze de date trebuie sa fie unic in organizatie.

Dupa crearea DAG si adaugarea celui de al doilea server(numarul maxim de servere care pot fi adaugate intr-un grup este de 16) administratorii pot adauga copii ale bazelor de date ce vor fi replicate incremental, iar serverul Exchange va folosi mecanisme interne pentru a folosi ca si activa o copie sau alta in cazul in care va fi nevoie, pentru a mentine disponibilitatea serviciilor.

Mediul de test consta in 5 servere pe care am instalat Windows Server 2008 SP2 si o masina client cu Windows 7 RC si MS Outlook 2007.

Unul dintre servere a fost promovat la DC(are instalate rolurile de Active Directory Domain Services si DNS Server), altul are instalate rolurile Exchange HUB si CAS, iar celelalte trei au instalat rolul de Mailbox.

Pentru a instala Exchange 2010 Enterprise Edition trebuie sa fie indeplinite urmatoarele cerinte:

- procesor x64 Intel64 sau AMD64, Itanium IA64 nu sunt suportate

- memorie minim 4GB RAM.In cazul in care serverul detine rolul de Mailbox Server se adauga de la 2 pana la 10 MB/mailbox in functie de profilul utilizatorului

- spatiu pe disc de cel putin 1,2GB pentru instalarea Exchange Server plus 200MB pe system drive

- sistem de operare Windows Server 2008 x64 SP2 sau Windows Server 2008 R2

- forest functional level trebuie sa fie cel putin Windows Server 2003 si DC-ul care detine rolul de Schema Master trebuie sa ruleze cel putin Windows Server 2003 SP1

Mailbox serverele ce vor fi adaugate ca si membru in DAG trebuie sa aiba cel putin 2 placi de retea deoarece una dintre ele va fi folosita pentru comunicarea cu reteaua interna iar cea de a doua pentru replicarea bazelor de date in DAG.Aceste servere, membre ale DAG, vor trebui instalate pe editiile Enterprise ale Windows Server 2008 x64 sau Windows Server 2008 R2 deoarece Standard Edition nu suporta instalarea componentelor necesare pentru configurarea in DAG.

Dupa instalarea sistemului de operare trebuie instalate ca .NET Framework 3.5 SP1, Windows Management Framework Core (PowerShell si WinRM), Microsoft Filter Pack (pe acele servere care vor detine rolul de Hub sau Mailbox Server) si Exchange 2010 prerequisites care pot varia in functie de rolul pe care il va avea instalat serverul.Inca de la lansarea versiunii RC, Exchange 2010 contine cateva fisiere de raspuns xml preconfigurate, cu ajutorul carora pot fi instalate componentele necesare unui anumit rol sau unei anumite combinatii de roluri.

Primul va fi instalat serverul care va detine rolurile de HUB si CAS, EXCHHUBCAS01, ruland urmatoarele comenzi din command prompt:

sc config NetTcpPortSharing start= auto

ServerManagerCmd -ip Exchange-Typical.xml –Restart

Dupa instalarea componentelor, poate fi pornit wizard-ul de instalare Exchange Server 2010.Din moment ce acesta este primul server din organizatia Exchange si nu am pregatit in prealabil schema AD pentru aceasta instalare, userul cu care rulam setup-ul trebuie sa faca parte din grupurile Enterprise Administrators si Schema Administrators.

In principiu, procesul de setup al Exchange 2010 se aseamana cu cel din versiunea anterioara, insa se poate observa in aceasta faza ca nu mai sunt disponibile optiunile de instalare a rolurilor Active si Passive Clustered Mailbox.

Ca si la versiunea anterioara, trebuie sa alegem numele organizatiei, sa specificam daca in aceasta organizatie exista clienti de mail Outlook 2003(si versiuni mai vechi) sau Entourage, iar dupa verificarea instalarii componentelor necesare va incepe instalarea rolurilor selectate.

Procesul de instalare al rolului de mailbox pe celelalte 3 servere, EXCHMBX00, EXCHMBX01 si EXCHMBX02, este similar cu exceptia faptului ca va trebui rulata alta comanda pentru instalarea componentelor necesare:

ServerManagerCmd -ip Exchange-MBX.xml –Restart

Apoi va trebui selectat rolul de Mailbox:

Desi intentionam sa configuram aceste servere ca si noduri ale unui cluster, in aceasta versiune nu este necesara instalarea feature-ului Failover Clustering inainte de a instala Exchange Server.

Dupa finalizarea instalarii se poate crea Database Availability Group accesand Organization Configuration>Mailbox>Actions>New Database Availability Group din Exchange Management Console. In wizard-ul de configurare va trebui sa specificam numele grupului, numele pentru witness server si witness directory.

La finalizarea acestui pas, va fi creat un computer account in AD cu numele pe care l-am specificat pentru DAG.

Pentru a fi creat si partajat witness directory, trebuie ca grupul Exchange Trusted Subsystem sa aiba drepturi administrative pe witness server.

Dupa crearea grupului, va fi necesar sa configuram interfetele de retea pentru DAG, o retea publica pentru comunicarea cu reteaua interna si o retea privata(intr-un alt subnet) folosita pentru replicarea bazelor de date.

Dupa configurarea interfetelor de retea putem adauga primul server in DAG accesand Manage Database Availability Group Membership si selectand apoi serverul pe care dorim sa il adaugam.

Celelalte servere se pot adauga ruland urmatoarea comanda din Exchange Power Shell:

Add-DatabaseAvailabilityGroupServer -Identity EXCH14RC1 -MailboxServer NumeServer

Dupa rularea acestei comenzi(sau apasarea butonului Manage din interfata grafica), componenta Failover Clustering va fi instalata automat serverele specificate, iar ele vor deveni noduri in clusterul EXCH14RC1 si vor putea fi vizualizate in consola Failover Clustering Management.

Imediat dupa adaugarea celui de al doilea server in DAG, witness share-ul este creat pe witness server care in acest caz este serverul pe care sunt instalate rolurile de HUB si CAS, EXCHHUBCAS01. Failover clustering quorum-ul, care inainte de adaugarea celui de al doilea server era setat ca “Node Majority”, va fi schimbat automat in “Node and file share majority”.

Pentru adaugarea copiilor bazelor de date trebuie sa specificam numele bazei, numele serverului pe care se va afla acea copie si “activation preference number”, numar ce reprezinta ordinea in care copiile bazei de date vor fi montate in cazul aparitiei unei erori si pornirii procesului de failover.

Numarul maxim de mailbox servere ce pot fi adaugate in DAG este de 16 si pot fi create copii ale bazelor de date de pe un server-membru pe un altul sau pe toate celelalte servere din acel grup, deci putem avea pana la 15 copii ale unei baze de date.

Odata cu lansarea Exchange 2010 o noua componenta, numita Active Manager, determina care dintre copiile unei baze de date va fi activa si care va fi pasiva. Informatiile de configurare ale Active Manager sunt stocate in Active Directory (in timp ce datele DAG sunt stocate atat in AD cat si in baza de date a clusterului) si ruleaza pe fiecare server membru al DAG.

In cazul in care baza de date activa va deveni corupta, Active Manager va selecta urmatoarea copie care va fi montata, iar pentru a suporta noul mod de failover, toti clientii indiferent de protocolul utilizat (chiar si cei MAPI care inainte se conectau direct la mailbox serverul Exchange 2007) se conecteaza acum la serverul cu rolul de CAS; acest mod de conectare se numeste “MAPI on the Middle Tier”.

Pasii pentru replicarea continua intre bazele de date sunt urmatorii : actualizarea bazei, copierea logurilor, analizarea logurilor si comiterea tranzactiilor in baza de date.

Serviciul de replicare al Exchange 2007 foloseste protocolul Server Message Block (SMB) si notificarile pentru a transfera logurile, in timp ce in Exchange 2010 replicarea se face folosind TCP si notificari catre sursa despre logurile care sunt necesare pentru actualizarea datelor astfel existand posibilitatea de a cripta si comprima logurile, optiuni care se configureaza la nivel de Database Availability Group.Dupa analizarea logurilor, serviciul de replicare va efectua o serie de teste de validare, iar dupa ce aceasta etapa va fi finalizata, tranzactiile vor fi comise in baza de date.

Odata create copiile bazelor de date putem testa functionarea clusterului prin deconectarea interfetei de retea care este folosita pentru deservirea cererilor MAPI.

In prima faza am configurat un profil Outlook pentru userul test00-1 pe statia de lucru care se conecteaza la serverul cu rolul de CAS EXCHHUBCAS01.Mailbox-ul acestui user se afla in baza de date MBX00-1, care este montata pe mailbox serverul EXCHMBX00.

In aceslasi timp, am folosit OWA(care in aceasta versiune de Exchange este acronimul pentru Outlook Web App) pentru a accesa mailbox-ul altui user, test01-1, aflat pe baza de date MBX01-1 montata pe serverul EXCHMBX01.

Dupa un schimb de email-uri intre aceste conturi am deconectat interfata de retea(cea folosita pentru comunicarea cu reteaua interna, implicit si cu CAS-ul) a serverului EXCHMBX00 din consola VMWare.

Dupa deconectare procesul de failover a pornit automat si a montat copia bazei MBX00-1 pe serverul EXCHMBX01.

In acest timp Outlook s-a deconectat de la server, iar email-ul de test pe care am incercat sa il trimit a ramas in Outbox pana cand procesul de failover s-a terminat si mailbox-ul a putut fi accesat, durata fiind de aproximativ 45 de secunde .

In cazul in care este utilizat OWA in acest timp, dupa failover este necesar ca userul sa se reconecteze la acel mailbox cu log off/log on.

Pentru a incepe procesul de failback, am reconectat interfata de retea pe EXCHMBX00 si am verificat daca datele sunt sincronizate.La inceput, CopyStatus pe nodul afectat devine Unknown, apoi in timp ce sunt copiate logurile si comise tranzactiile in baza de date devine Failed, iar la final trece in Healthy.

Dupa identificarea sursei si rezolvarea problemei din cauza careia baza de date a devenit indisponibila(in cazul nostru intreruperea conexiunii) si verificarea consistentei bazei, putem porni procesul de failback selectand copia bazei de date(care inainte de intrerupere a fost cea activa) accesand Activate Database Copy din Action Pane, iar modificarile vor fi efectuate imediat fara a mai afecta utilizatorii.

Daca este necesar, pentru operatiunile de mentenanta, administratorii se pot folosi de facilitatile oferite de aceasta arhitectura cu baze de date replicate pe diferite servere, montand copii ale bazelor de date(configurandu-le ca baze active) situate pe alte servere membre DAG.

Toate etapele de configurare de mai sus pot fi efectuate si din Exchange Management Shell si, la fel ca si in cazul Exchange 2007, comenzile pot fi copiate din ferestrele wirzard-urilor de configurare atunci cand este folosita consola EMC.