I get bored (I believe this is the right word) to modifying CSV file every time after script has finished. Usually my customers are just leaving this activity to me, just sending CSV files to me. And quite often I want to get sent/received items and average message size when I am already onsite and analyzing their Exchange environment but getting CSV file is problem as I don’t have Internet access at customer site. That’s why I was starting to create script which will give you sent/received item count and average message size automatically as output of script work and without additional work. After starting to create the script I changed little bit the scope and added some additional functionality the script can do. So currently Powershell script is ready and these values you are looking are displayed at the end of script. And as bonus the script is working more than twice faster compared with the MessageStat script.

Finding good name for script was quite challenging. I finally decided to name it as CalcMsgAverage.ps1. You can get syntax for script with command CalcMsgAverage.ps1 -Help:

You can also use CalsMsgAverage.ps1 -Examples command to get view some examples which cover some basic scenarios:

Some comments for several parameters in script.

First bundle for specifying timeframe: Period, StartTime and EndTime. Script will need at least one of these present. If there is none of timeframe parameters specified then Period is set to 1, EndTime is set script startup time and StartTime as 1 day back from EndTime (so it will analyze last 24 hours records). Most common usage might be to analyze last 30 days from script startup: CalcMsgAverage.ps1 30 (Period is positional parameter and you don’t need to specify it). If all three time parameters are present then Period will be ignored and calculated from StartTime and EndTime parameter. By the way – you can use fraction part with Period parameter, for example 1.5 as Period means one and half day or 36 hours. Please take a note that period is important to calculate average values. For example if you have server log files for 10 days only but you are specifying Period as 20 days, then even if you have data for 10 days, average will be calculated for 20 days (instead of dividing by 10, it will be divided by 20). It means smaller number compared actual value. Usually this might happen for new servers only where collecting message tracking information haven’t done for longer period.

You can also specify what servers to analyze (using Servers parameter). This could be useful if you want to analyze only few servers from bigger range. The opposite functional approach using SkipServers parameter which enables you skip certain servers from analyzing results (for example some servers might be down). For both parameters if there are more than one name then include text to parenthesis (single or double) and separate values by coma or semicolon. If you include both Servers and SkipServers parameters then SkipServers parameter will be ignored (why the hell you need specify servers and then skip them?).

There is one parameter I created targeted to Exchange 2013 only (it will make no difference for older Exchange versions). This parameter is SkipHealthMailboxes which makes script to skip all Exchange 2013 health messages from calculation and analyze activities. Usually the difference is very small and not so different from actual value. It might give some effect if you have Exchange 2013 installed for some period but no user mailboxes migrated to this server yet. So no sent/received mails for users but all traffic is only for health mailbox probe messages.

I did testing comparing CalcMsgAverage script by analyzing 30 days of data for about 700 user environment and then using exactly the same timeframe for MessageStats script.

First example using CalcMsgAverage with 30 days period, running 40 minutes 40 seconds.

Second example using CalcMsgAverage with 30 days (exactly the same start and end time) but using SkipHealthMailboxes parameter (MBX01 and MBX02 is Exchange 2013). Running time 40 minutes 6 seconds.

Third example using MessageStats with 30 days (exactly the same start and end time written inside to script). Running time 7300 seconds which is little more than 2 hours. It means CalcMsgAverage is more than twice faster compared to MessageStats (40 minutes versus 121 minutes).

I also found that there are some inconsistency between CalcMsgAverage and MessageStats. I did some tests to find out why it’s happening and found out that MessageStats is analyzing incorrectly under certain conditions (it will add e-mail size to calculation but don’t increase user count which will give back wrong statistical results).

Please let me know your feedback, also suggestions and bug report (I really hope there are none but you never know). You can download CalcMsgAverage script from TechNet Gallery here.

Exchange 2007:

• W3wp.exe consumes excessive CPU resources on Exchange Client Access servers when users open recurring calendar items in mailboxes by using OWA or EWS
• The last public folder database on Exchange 2007 cannot be removed after migrating to Exchange 2013 (kes migratsiooni teevad, siis nende jaoks väga oluline)

Exchange 2010:

• W3wp.exe process for the MSExchangeSyncAppPool application pool crashes in an Exchange Server 2010 SP2 or SP3 environment
• EdgeTransport.exe crashes when an email message without a sender address is sent to an Exchange Server 2010 Hub Transport server (parandab vea, mis avaldus SP3 RU1 peal, kus EdgeTransport jooksis kokku ja jättis jättis sõnumid nn Poison Queue järjekorda saatmise asemel)
• Slow performance in some databases after Exchange Server 2010 is running continuously for at least 23 days
• iOS devices cannot synchronize mailboxes in an Exchange Server 2010 environment (parandab CAS serverite tulemuslikkust, mis pakuvad teenust iOS jaoks)
• You cannot send an RTF email message that contains an embedded picture to an external recipient in an Exchange Server 2010 SP3 environment (saates Rich Text Format kirja, mis sisaldab pilti, välisele aadressile, siis kiri jääb Submission Queue-sse pidama ja ei saadeta. Probleem ainult kui Exchange 2010 SP3 on Windows Server 2012 masinale installeeritud. See oli parandatud juba varem 2013-l, nüüd siis ka 2010 jaoks)
• Error message when you try to activate a passive copy of an Exchange Server 2010 SP3 database: "File check failed" (tuntud ka 8dot3 bugina, workaround oli olemas, aga nüüd ka parandatud)

Lähemalt võib lugeda ka TechNetist Exchange 2007 SP3 RU11 ja Exchange 2010 SP3 RU2 artiklitest.

Parandatud CU2 on kättesaadav Cumulative Update 2 for Exchange Server 2013 (KB2859928) lingilt.

Parandus nimetatud probleemile peaks tulema lähiajal Microsofti poolt välja lastava vaheparandusega (Interim Update). Lisaks sisaldab nimetatud parandust ka sügise poole välja lastav CU3. Kuni nimetatud parandusi peale pandud pole, ei ole soovitatud Public Folder migratsiooni Exchange 2013 peale, või kui see juba tehtud, siis mitte tõsta Public Folder postkasti ühest baasist teise (või vähemalt mitte primaarset PF postkasti).

Lähemalt saab lugeda Exchange Team blogi artiklist.

• Per-server database support
• OWA Redirection
• High Availability
• Managed Availability
• Cmdlet Help
• OWA Search Improvements
• Malware Filter Rules

CU2 sisaldab ka mõned AD skeemi muutusi ja AD muutusi (RBAC rolli muutusi). Seega on vaja installeerimiseks vajalik vastavaid õigusi ja vajadusel kõigepealt setup.exe käivitada /PrepareSchema ja /PrepareAD võtmetega.

Lähemalt tasub lugeda Exchange Team Blogi artiklist. Exchange Server 2013 CU2 on ise alla laetav siit.
 

Nii Exchange 2013 Server Role Calculator kui ka sizing guidance muudetakse ennem CU2 väljatulekut, et kohandada ka seal 100 baasi võimalust.

Lisaks veel üks näpukas selle paranduspaketiga - nimelt kui soov see maha intallida peale installeerimist, siis vaja süsteemi keel muuta US English peale (pärast võib jälle tagasi panna). Jällegi kord koosneb maailm ainult USA-st :-)

Täna üllatas Exchange PG teatega, et kalkulaator on valmis ja avalikult kättesaadav! Ning erinevalt varasematest Exchange versioonidest, saab sellega arvutada kõikide Exchange rollide nõudeid välja (mitte ainult Mailbox rolli nõudeid). Elu läks järsku märksa kergemaks ja ilusamaks

Lähemaid selgitusi võib lugeda vastavas Ross Smith IV blogi artiklist. Kalkulaator versiooni numbriga 5.1 on ise kättesaadav siit ja üldine kasutusjuhend siit.

Exchange 2013 juures on mitmeid muutusi, alustades sellest, et 4+1 rolli asemel on nüüd 2 rolli - Mailbox roll ja Client Access roll. Võrreldes Exchange 2010-ga, on enamus Client Access tegevusi viidud Mailbox rolli teenuse peale, samuti Hub Transport tegevus on Mailbox rolli koosseisus. Client Access on nüüd sisuliselt sõltumatu seisundiga proxy server, kelle ainuke ülesanne ongi vahendada. Mailbox roll on samas nüüd praktiliselt kogu töö ära tegev multi-teenuste kogum. Riistvara planeerimist alustataksegi sellepärast Mailbox rolli parameetrite leidmisest, ning alles siis CAS rolli parameetrite leidmisega, mis on sõltuvad osadest Mailbox serveri parameetritest (tegelikult oli selline lähenemine ka Exchange 2010 korral). Kõigepealt leitakse kettaruumi mahud, seda siis nii baaside, logide, indeksite kui ka transport baasi jaoks (lisaks veel vajalik kasvuruum). Kui kettamahud on teada, siis leitakse vajalikud kiirusnäitajad (IOPS) ja sellest omakorda, mis parameetritega kettasüsteem olema peab. Järgmiseks leitakse nõuded protsessorile - vajaminevate tuumade arv ja megatsüklite arv. Lõpuks leitakse vajamineva mälu maht. Tihti on kasulikum võtta suurema megatsüklite arvuga protsessor ja vähendada tuumade arvu, sest tuumade arv määrab ka mälu mahtu ja tuleb kokkuvõttes optimaalsem.

Exchange 2013 juures on kasvanud mäluvajadus, seda nii fikseeritud mälueraldusega ESE cache jaoks (25%) kui ka uudse kiire indekseerimismootori tõttu, mis vajab oma tööks samas rohkem protsessori jõudlust kui ka mälu. Samuti on suurenenud CPU kasutamine. Teiselt poolt on vähenenud ketta I/O nõuded - testkeskkonnas isegi kuni 50% väiksemat IOPS näitajad, mis võimaldab pareminin ära kasutada odavamaid kettaid ja süsteeme. See kõik tuleb nii efektiisemast cache ära kasutamisest, kui ka pöördumiste optimeerise tulemusena. Näiteks on ka failover ja switchover kuni 2 korda kiiremad võrreldes Exchange 2010-ga.

Juhend on kättesaadav algselt Exchange Team blogi lehelt, ning uuendatakse ka TechNet lehekülgi. Exchange Team lehe juhendi võid leida siit.

CU1 on iseseisev paranduste komplekt, mis tähendab, et terve Exchange 2013 võib installeerida selle abil - pole vaja installeerida kõigepealt RTM ja siis lisada CU1, vaid piisab ainult CU1 installeerimisest.

Lähemalt saab lugeda Exchange Team Blogist Released: Exchange Server 2013 RTM Cumulative Update 1 ja Release Notes for Exchange 2013. CU1 ise on allalaetav siit ja on üsna pirakas (1,3 GB), mis on mõistetav, sest sisaldab kogu Exchange 2013 installi.

Nüüd enam üleminekul uuele Exchange versioonile (migratsioonile) puhtfüüsilisi takistusi pole, puudu on veel endiselt Exchange 2013 kalibreerimis juhendid (sizing guidance), et leida firma suuruse ja muude parameetrite järgi sobivate Exchange serverite parameeetrid. Loodetavasti peaks need ka lähitulevikus tulema.