For the last couple of years, I’ve had the privilege of leading a team of talented Exchange and Lync subject matter experts (either directly or more recently as a virtual team).  I’ve tried to keep up my technical skills but inevitably I’m not at the level of detail I once was and, as I switch to a more technical role, I’m expecting to have to re-learn a lot.

Thankfully, I won’t be alone – the team I’m joining is also full of talented subject matter experts – but I will need to stand on my own two feet.

That’s why I thought I’d write this post, with a few notes that are based on a recent conversation when my former colleague Mark Bodley checked over the Exchange calculations I’d used to create a guide price for a customer solution… [I’ve since made a couple of extra edits based on advice from Fujitsu’s resident Exchange Master, Nick Parlow]

Inputs

To get started, some educated guesses can be made to adjust the defaults:

• Exchange environment configuration:
  • 64-bit GCs, multi-role servers, non-virtualised, HA deployment (in line with our design principles).
  • Set number of servers per DAG and number of DAGs according to size of solution. Start DAG count low to keep hardware down – revise up later if required based on guidance elsewhere in the tool.
• Site resilience configuration:
  • Single active/active resilient DAG (i.e. no passive servers).
  • Watch the RPO value – it won’t affect the server count but could be a factor in inter-datacentre bandwidth calculations.
• Mailbox database copy configuration:
  • Increased HA database copies to 4; decreased lagged copies to 0 (lagged copies require more storage as transaction logs are retained for longer).
  • Increased number of HA database copies in secondary datacentre to account for non-lagged copies (in this case I had a 50/50 split between DCs).
• Lagged database copy configuration: not used.
• Exchange data configuration: left at defaults.
• Database configuration: left at defaults.
• Exchange I/O configuration: left at defaults
• Transport configuration:
  • Set Safety Net expiration to 2 days (unless using lagged copies).
• User mailbox configuration:
  • One tier for each logical group of users.
  • Days in work week set to 5 – unless there are significant groups of people working 7 days a week (affects log replication).
  • Mailbox configuration values will depend on organisation but the advice given for a starting point was to set:
    • Total send/receive capacity per mailbox per day to 100 (down from 200) messages.
    • Average messages size to 150KB (affects storage).
    • Mailbox size limits are used for capacity growth planning – split between main and personal archive should not affect the calculations.
    • Deleted item retention window may need to be increased to meet requirements (14 days is low if not using backups).
    • Multiplication factors come into play with mobile devices.
    • Desktop search engine value is more significant in Citrix environments than with Outlook cached mode clients.
• Backup configuration:
  • Assumed software VSS via SCDPM, daily full backups.
  • Calculator will take highest value of backup/truncation failure tolerance and network failure tolerance (so only one of these really matters!).
• Storage options:
  • JBOD with multiple databases per disk (in line with our design principles).
  • Main thing to watch here is the number of auto reseed volumes per server – align to failure rate of the disks.
• Disk configuration: will depend on servers in use. For reference, with our Fujitsu PRIMERGY servers, the available options led us to:
  • 900GB system disks (10K RPM SAS 2.5″).
  • 4000GB database plus log disks (7.2K RPM SATA 3.5″).
  • 4000GB restore volume (7.2K RPM SATA 3.5″).
• Processor configuration:
  • Core/server is of secondary interest but helps the calculator to advise on Global Catalog cores.
  • SPECint2006 value set to the lowest that will allow a suitable server utilisation number. In practice there will be a balance between servers/processor options and price. It’s useful to have a lookup of SPECint2006 values for a range of servers (e.g. Fujitsu PRIMERGY RX300) or you can search the SPECint site and take the value from the result column.
•   Log replication configuration:
  • Will vary according to environment (and international spread of users) but rule of thumb used was (this should add up to 100%):
    • 1: 0.33%.
    • 2: 0.24%.
    • 3: 0.24%.
    • 4: 0.2%.
    • 5: 0.82% (I’m not sure why we have a night-time peak – automated emails sent overnight? Or this could be spread across others…)
    • 6: 0.31%.
    • 7: 0.34%.
    • 8: 1.46%.
    • 9: 6.46%.
    • 10: 10.08%.
    • 11: 10.55%.
    • 12: 11.06%.
    • 13: 9.48%.
    • 14: 9.61%.
    • 15: 10.52%.
    • 16: 10.41%.
    • 17: 8.31%.
    • 18: 5.07%.
    • 19: 1.94%.
    • 20: 0.95%.
    • 21: 0.84% (I might be tempted to up this slightly for the evening email check in many organisations…).
    • 22: 0.36%.
    • 23: 0.21%.
    • 24: 0.21%.
  • Network configuration: latency will depend on available datacentre connectivity.
• Environment customisation: only used to generate naming configuration.

Check the results

With the main inputs in place, some fine tuning is probably required:

• Role requirements:
  • Watch out for errors (e.g. over-utilised servers).  This is where the server count may need to be adjusted, or a higher-specification server used (SPECint2006 values). Ideally, servers should be close to 80% utilised [in a failure scenario] but not over. Getting the right CPU is more critical than memory as RAM can normally be added later! [also bear in mind the impact of other software on utilisation – for example file level antivirus, and any message hygiene software running on the box.]
  • Also check the recommended transport database location (we’ll come back to that in a moment).
• Volume requirements:
  • Watch out for disk sizes/configurations that can’t be met!  If the solution is storage-bound, then it may be necessary to add additional servers (we use direct attached storage as a design principle) or, if available, then larger commodity disks would help. One clue to a potential issue is if the DB and log volume design/server table has DBx as a database copy name, rather than DB1-DB4, etc.
• Storage design: confirms (or otherwise) that the solution can be deployed in a JBOD configuration (as per our design principles, although RAID is also an option).
  • This worksheet will also give the number of disks required in each server. Note that this is the count for database and log disks, restore volumes and auto reseed volumes – don’t forget the system disks for operating system/application binaries… and then think about the transport database.
  • In my solution, the recommended transport database location (from the role requirements) was the system disk but we were using 900GB 10K RPM SAS 3.5″ disks. With OS (150GB), Anchor LUN (2GB), Exchange binaries (50GB), and consideration for Exchange Logs (maybe 600GB) those disks are already pretty full, so it’s worth considering an extra RAID 1 volume for the transport database (over-ruling the calculator) and possibly hot spares for the RAID volumes too (depending on your attitude to risk).

A couple of other points to consider: public folders and unified messaging. I didn’t need public folders but don’t overlook them in your plans if they are in use.  As for unified messaging, it’s no longer a server role so is included in the calculations, up to a point – UM is likely to hit the CPU load, so it might be prudent to factor in some additional headroom with the SPECint2006 of the servers (to keep the utilisation well below the 80% mark).

YMMV

Of course, there are just my notes on some of the things I checked to fit our reference design and they are not exhaustive. As the saying goes, your mileage may vary. For reference, I was using Exchange 2013 Server Role Requirements Calculator v6.6 but you should always use the latest available version and there is a very useful readme file which should be referenced when working with the calculator. You should also factor in this guidance on sizing Exchange 2013 deployments and consider the Exchange 2013 performance recommendations too.

[Edited 16 May 2015 to clarify comments re: server utilisation]