Chapter 2
Exchange Design Fundamentals
In Chapter 1, we introduced requirements elicitation as we grappled with the nuances of different types of requirements and how to distill those into a readable form. In this chapter, our goal is to transform those requirements into design decisions.
Before we delve into the meat of the design contents, let us examine the document structure. A good design document is not a purely technical record, nor is it purely a business or project-based one. A well-written design document is intended for many audiences, from the technical implementers on various teams right up to the CEO.
Let us take a moment to define what a design document is not. A design document is not written to sell Exchange 2013. That is, it is not a marketing document, and it should not be approached as such. It should not list every Exchange 2013 feature, and it should not ramble on about how wonderful a product it is or about the marvels of a given feature. The discussion of relevant features does have a valid place in the document; however, it should not bulk up the document unnecessarily with praise for the product and its features, or else it will alienate the vast majority of its intended consumers.
Ideally, this document should start with a structure in mind, which allows various teams to find the information that is most relevant to them without having to read through the entire document. You may choose to write this document in sections that pertain to various teams, for example, storage, security, and so on, or you may maintain a separate table of contents that calls out the sections pertinent to each team.
We prefer the second approach, because it allows us to design a document based on the major feature areas of Exchange and follow the natural flow of the product, rather than disassembling the product into the many disciplines for which Exchange offers support.
A requirement is translated into many design decisions. Though it often may be difficult to defend a particular decision beyond that you believe it is “right,” this belief is not nearly enough to justify technical decisions. Storage and availability are just two of many often contentious topics that may lead to emotionally charged discussions. Thus, the various chapters throughout this book, including those covering storage and availability, provide sufficient background as to how to make sound, justifiable technical decisions. Any documented design choice must be supported by solid reasoning, which can be clearly demonstrated in your design.
A requirement may often be interpreted or implemented in any number of ways. Without deep product knowledge and extensive experience in a product, this may be difficult to accomplish, because the business for which you may be consulting or working is adequately unique such that it will not fit into a standardized approach.
When a requirement may be implemented in different ways, formalize the decision-making process using a number of test cases, each with a view to satisfying the unique conditions of the business or the design constraints within which you may have to work. Wherever possible, build a representative lab that includes the source environment and the Exchange 2013 target environment, and work through the test cases to determine which implementation path works best for a particular design decision.
There is a fine line between providing sufficient detail to document the design principles and writing an implementation guide. How much detail is enough? If you are including the PowerShell scripts to set specific URLs, you're adding too much detail. A table of URLs is more appropriate. Remember that your design is intended for multiple audiences. As such, it should start out as broad as possible and narrow the focus going forward as required.
If you are doing this for the first time, consider reading the “Infrastructure Planning and Design Guides” available for free from Microsoft at
http://technet.microsoft.com/en-us/solutionaccelerators/ee382254.aspx
You may also want to check out “White Papers: Exchange 2010 Tested Solutions” from Microsoft TechNet at
http://technet.microsoft.com/en-us/library/gg513520(v=exchg.141).aspx
Both of these resources are great primers when pondering the amount of relevant detail necessary and how to document a design decision in light of the number of alternatives considered. You must demonstrate due care and consideration for alternative or competing choices. Doing so makes the choice of technology defensible in the context of the design.
Assuming that you have your requirements, assumptions, constraints, and scope and vision documented, you now need to apply these to a design in a logical manner that may be easily consumed. At minimum, we suggest that you consider the following sections for inclusion in your design:
This section should be a catalog of lists grouped by discipline, thus allowing the relevant individual to find the sections they need to review or implement quickly, without having to dig through the entire design. The security team leader, for example, is not going to be interested in your storage design but will be very interested in how Exchange 2013 is published externally. We suggest that you take your lead from the requirements elicitation sections as to how to group these. At minimum, however, you can expect to be addressing messaging, infrastructure, networking, security, business, storage, compliance, and auditing.
Following is a sample grouping of design document sections:
Business
Security
Infrastructure Teams
The Executive Summary is your elevator pitch, your two minutes of time with someone extremely busy and influential. The real trick with this section is to keep it precise and focused toward a senior management audience; that is, focus on the benefit to the business and costs rather than technical details. Provide as much rich information as you can realistically cram in. Quite often, the data that you provide in this section will be presented again, so make sure that anything you put in here is accurate and relevant.
This section should be no longer than one page, summarizing the pertinent points of the project and its reason for existence.
The Business Requirements are the reason for a design's existence. Failure to list actual business requirements in this section may cause the project sponsor or owner to dismiss the document and potentially the project outright.
As with the Executive Summary, this section needs to be precise and focused towards a senior management audience. This section must cover the business requirements which you would have gathered using the methods described in Chapter 1: “Business, Functional and Technical Requirements.”
The Vision and Scope document contains essential inputs to the design. If the document is small enough, consider repeating or quoting the necessary sections in your design. This may provide direction for you as you craft the design. It will also help the reader understand the context without continually referring to an external document.
The best way to think about the Vision and Scope document is as a frame for the solution. The vision part is intended to define what the end goal looks like. The scope part is intended to define how much of that vision you need to solve in this particular design. It is worth remembering this when you create your Vision and Scope document. Try to avoid solving things at this point in the process. The Vision and Scope document should be written so that it rarely or never requires an update during the project. The key words are high level; this is not a design document.
The Functional Specification is just a list of requirements. At its most basic, the Functional Specification defines precisely what the solution will provide. On large projects we typically like to see a separate Functional Specification document since it can get quite large and will often require significant effort to gain sign-off. From our perspective, this is probably the single most important document that will be created, because once it has been signed, it defines precisely what the final solution must do.
It is also worth mentioning here that the test process should be driven directly from the Functional Specification; that is, for each requirement that is defined and agreed on, there should be a matching test case in the test plan.
This approach supports two benefits:
For smaller projects, it is quite acceptable and often beneficial to include the Functional Specification as a section within your design documentation; however, we still recommend that formal sign-off of the section be recorded before beginning solution design.
The Architecture Summary is a two-page summary of the entire design from a technical perspective. This includes diagrams representing the existing messaging, networking, and possible datacenter design, as well as the end state of the new Exchange 2013 design.
This section is useful for someone who is new to the project and should show visually what the solution design looks like and how it will integrate with any other systems. Ideally, it should be quite high level; however, it should use customer specific nomenclature for sites, servers, and projects where possible.
This section captures the compliance-specific details of your Exchange 2013 design, and it should detail which feature or configuration is being used to meet a specific requirement. It is also useful to detail how a specific feature will meet the compliance requirement. Usually compliance requirements are also constraints, since they are mandatory and non-negotiable; that is, they must be met or the solution cannot be deployed. Make it clear wherever a constraint is met with a specific feature or configuration.
A compliance framework often requires a clear demonstration of a control being in place, such as the ability to perform a search. Depending on the specific requirements you receive from a business, you must show how each requirement is met by your recommended configuration. Journaling, archiving (both native and third-party), storage and retention policies, data leak prevention, integration with third-party compliance appliances, administrative logging, PowerShell, and command logging and search features are often listed in this section.
External publishing of Exchange services usually involves IT risk and security teams plus infrastructure and messaging. Where you have sections of your design document that many teams need to read, it pays to spend a little extra time to speak with them up front to find out what kind of information they would like to see in your design document. This section should include the basics, such as restating any requirements for external publishing of Exchange services and how you intend to provide them at a high level, for example, by reusing additional publishing infrastructure or deploying something entirely new for Exchange.
You should add in any additional information requested by the other team, such as firewall requirements, predicted network bandwidth, intrusion detection, certificate requirements, and so on. As a general rule, all of the teams involved with this section should already know what you are going to propose before they read it in your design document. Our recommendation is to involve key security stakeholders early in the design process.
The main aim of this section is to clearly specify the external publishing solution for Exchange 2013 and how Exchange 2013 service and data access will be secured.
The new design may reflect the first implementation of Exchange in the business. Novell GroupWise, Lotus Notes, Gmail, and other email systems have particular coexistence requirements in order to make the intended migration or end state as seamless and as painless as possible. This section should capture whether native or third-party tools will be used, the possible impacts on the business during the migration period, the risk-mitigation strategy, and roll-forward and roll-back plans, should they be required. If this includes too much detail, consider breaking this section out into a separate document called a migration design and referencing it in your design document.
Similarly, an upgrade from previous versions to Exchange 2013 in the same Exchange organization requires much thought and planning, and this section should list considerations for achieving a migration with as little impact on the business as possible. You may list interoperation requirements, such as the activation of Outlook Anywhere on all downstream versions of Exchange or the minimum Outlook versions required on the desktop, depending on the Exchange 2013 features implemented in the new end state.
Very few Exchange 2013 implementations will never interoperate with other systems. You may need to list Receive connectors with defined scopes. These allow devices or other systems to relay email through Exchange. CRM and instant messaging systems, such as Lync, often require Exchange Web Services to be published without the use of a wildcard certificate, preferring SAN certificates instead. While this detail is often reflected in the pertinent section such as the Transport Design for the Receive connectors, this section follows the theme of making the information available without requiring a developer or administrator to mine the entire design.
You may find that the amount of detail required for a specific application or technology is too much to call out of a specific section, for example, listing a Receive connector for third-party use when the Transport Design features a table with many other Receive connectors. In this case, it is appropriate to summarize that there is a requirement to integrate with legacy SMTP systems and that the specific details may be found in the Transport Design section.
Legacy protocols that are no longer supported, such as WebDAV and other types of integration, may require significant re-architecting of the application requiring such integration. Applications requiring integration points that have been deprecated from previous versions of Exchange should be listed, as well as your mitigation strategy, which may include a replacement of the application or a rewrite of the integration points, for example, from WebDAV to Exchange Web Services. The lack of mitigation of legacy integration can pose a significant delay to your project if not quantified and addressed as early on in the project as possible.
Site mailboxes and the eDiscovery features in SharePoint as well as specific Lync compliance features may need to be referenced in separate documents. However, you need to decide how much detail to include in your design in order to list the appropriate amount of coverage for Exchange. In addition, hybrid deployments with Office 365 will require significant detail as you call out the dependencies with AD FS, directory synchronization, specific versions of Office, and so forth in your design.
After listing the high-availability requirements, we like to address each requirement by major architecture feature as it affects Exchange (see Chapter 4, “Defining a Highly Available Messaging Solution”). Depending on the complexity of our design and the availability required, we like to take an outside-in approach as follows:
Each section should discuss the features of Exchange in light of the business requirement it satisfies as well as detail how the requirement is to be met.
As an alternative to providing significant detail that may be repeated elsewhere in the design, you may also choose to point out that the high-availability features for transport, storage, and so on are detailed in their respective sections. However, you should only do this after addressing the requirements for availability adequately in this section by documenting that the requirement has been met through the features you have selected to implement.
Where a specific section has a different service-level target, you should mention this and the business justification of why the service level is different. For example, it is common for some organizations to have a lower target service level in the event of a datacenter failure.
As we pointed out in the interoperation section, Exchange 2013 nearly always integrates with the outside world in some way. This often begins with transport, because the default transport configuration will require some modification in order to send and receive email via the Internet, legacy systems, or third-party email systems.
As part of the design, you will need to specify any modifications made to the default state in order to allow Internet email to flow, detail any edge requirements, and specify how email hygiene is performed either on-premises or via a cloud-based service such as Exchange Online Protection. If you are using Exchange 2013 integration with Active Directory Rights Management Services (AD RMS) via transport rules or other transport rule-based software to implement compliance features, consider adding a note to point to the Compliance section. Exchange hybrid deployment-specific detail, such as the Receive connector detail required to implement secure messaging, should also be mentioned. Bear in mind that in Exchange 2013 the CAS role has changed considerably, and performs the function of an SMTP proxy; as such all incoming and potentially all outgoing SMTP mail flow integrates with this role. The Receive connector configuration is required to be detailed for the Exchange 2013 CAS role, as opposed to the Hub Transport roles of Exchange 2007 and Exchange 2010. Transport will be covered in significant detail in Chapter 3: “Exchange Architectural Concepts.” The following list should be included at minimum:
Before we begin, it is worth explaining what has happened to the Client Access server (CAS) in Exchange Server 2013. In Exchange Server 2010, we also had a Client Access server role; however, its purpose was somewhat different from the CAS role in Exchange Server 2013. Fundamentally, most of what the Exchange 2010 CAS did is included in the Exchange 2013 Mailbox role, and Exchange 2013 CAS is a totally new role that acts as a front-end server and SMTP proxy for inbound email messages. Ideally, it would have been nice for it to have had a totally new name too, but I guess we can't have everything. The new CAS role will be covered in significant detail in Chapter 3: “Exchange Architectural Concepts”
Further detail should be supplied according to the following list:
For almost all deployments, it makes sense to collocate the CAS and Mailbox roles on the same server. The reasoning behind this decision is the same as it was for Exchange 2010 and fundamentally boils down to two benefits:
The Mailbox role is the core of your hardware design. We suggest reviewing the architecture, storage, and availability chapters of this book as preliminary reading.
If you are implementing database availability groups (DAGs), you will need to reflect the detail for each DAG, which includes the following in addition to other detail required for this role:
There are typically two approaches to storage design for Exchange. The first one is where the Exchange design team does the storage design itself; this is very common where direct attached storage and JBOD solutions are deployed. The second one is where the Exchange design team defines the storage requirements and then outsources the solution design to a hardware vendor.
The following must be reflected in this section:
Exchange 2013 may need to integrate with a Session Initiation Protocol (SIP)-based telephony solution such as Lync 2013. This section should clearly specify the Unified Messaging endpoints provided by Exchange 2013.
In that the Unified Messaging role is included in the Mailbox role, there is sufficient detail possible in this unit to justify its own section. Reciprocally, if there is no Unified Messaging requirement, you may choose to state that you have disabled this role or that it will not be implemented.
Virtualizing Exchange traditionally has been a contentious issue. Vendors often offer features or advertise capabilities that, if implemented, may cause your installation to become unsupportable by Microsoft support services or Microsoft partners. Because virtualization guidance may differ slightly between versions, and even between service packs or cumulative updates of Exchange, we like to list the pertinent information published by the product group at the time of writing in this section, in addition to how it applies to Exchange 2013 in the design.
In order for the design to be supported, the virtualization solution must be included in the Server Virtualization Validation Program (SVVP) and applied to the version of Exchange 2013 that you are implementing. The SVVP is found here:
http://www.windowsservercatalog.com/svvp.aspx
Detail those virtualization features that are included and excluded in your design in order to satisfy the requirements and make your solution supportable. More often, you may need to specify which virtualization features should be disabled as opposed to which features should be enabled.
Often, virtualization may carry a performance cost to the total system, including processor cycles, disk IOPS, and even memory. The Mailbox Server Role Requirements Calculator makes an allowance for this; however, you need to indicate your awareness as well as any mitigation steps required in the design.
One area that is often missed when considering virtualization is the concept of failure domains. A failure domain is a single point of failure that could affect multiple areas of your Exchange service. When considering virtualization it is crucial to consider each virtual host as a failure domain and avoid putting dependent Exchange servers on the same host; that is, do not store multiple database copies on separate virtual machines and then store both virtual machines on the same virtual host. Where you are mixing virtualization and Exchange high-availability features, your design document should clearly show how you are dealing with failure domains.
This section should reflect any network bandwidth-specific details or the impact of your design on bandwidth. For example, you may need to calculate the amount of client bandwidth required for a centralized Exchange 2013 deployment for either WAN or Internet-based clients. You may need to reflect the SMTP traffic bandwidth requirements in order to journal to a central location or to distributed points.
Networking parameters that may need to be listed are current available bandwidth, projected bandwidth impact of the new solution, and amount of bandwidth required if the current infrastructure cannot cope with the new requirements.
A significant aid in establishing a bandwidth model is the Exchange Client Network Bandwidth Calculator, which was announced here:
Another area of network bandwidth that often needs to be planned for is DAG replication traffic. This network traffic is caused by DAG nodes replicating data and maintaining a content index on passive copies. This is an extremely important metric to consider carefully because if your DAG spans multiple sites across a wide area network with limited network throughput, your choices for database copies in your DAG may be limited, not because of storage capacity or cost but because of a lack of network throughput. By far the best way to determine your DAG replication bandwidth requirements is by using the Exchange 2013 Server Role Requirements Calculator, which can be found here:
Sizing Exchange solutions is as much art as it is science. This may come as a surprise to some of you, but the reality is that Exchange sizing is based on a series of approximations that try to map end-user activity to server resource usage. With the best of intentions, end users rarely do what you expect them to, and so one of the primary goals of sizing is to make your solution large enough to cope with all demands and peaks but no larger than it needs to be.
This section will take a brief look at how to approach Exchange server sizing.
All sizing exercises begin by analyzing the identified requirements and defining the user profile. The user profile is the cornerstone of all Exchange sizing calculations. If you get your user profile wrong, you will get your Exchange sizing wrong. The user profile is defined as the average number of email messages that a user sends and receives within a working day, plus the average size of email messages sent by the users. This value is generally expressed as a value between 50 and 500 messages per day, and the average message size is in kilobytes.
Your requirements will also define what target service availability metrics your solution will need to reach. The higher the service availability, the more database copies and servers you will require. It is difficult to provide precise guidance on the quantity of database copies or servers required to reach a specific service level since the single most important aspect to service quality is how you operate your Exchange solution. As a rule of thumb, 99.9 percent availability requires three isolated database copies and 99.95 percent availability requires four or more.
There are two aspects to storage sizing:
Capacity sizing is fundamentally the process of determining how many mailboxes of a specific quota size can fit on a disk volume. This isn't quite as simple as it sounds since the capacity that a mailbox takes up on disk is made up of the message contents, mailbox white space, and recoverable items, plus you need to take into account the content index database and the database transaction logs. As a general rule, the following approximations can be made on a per-mailbox basis:
To calculate the maximum number of mailboxes per volume by capacity, you would perform the following tasks:
Now that you know that you can store 372 5 GB mailboxes on a 3 TB volume, you need to consider the performance of that volume and check to see if it will be sufficient for your users. To do this, you need to look at the random Input/Output Operations Per Second (IOPS) for both the volume and the mailboxes. Most manufacturers will provide random IOPS data for their disk spindles, but for the most part Exchange 2013 should be deployed on 7.2K RPM 3.5” SAS midline storage, and these spindles usually provide around 55 IOPS.
The next step is to determine how many IOPS your mailboxes will require. To do this, you multiply the user profile by 0.00067. Let's assume a user profile of 200 email messages per day. This gives you 200 × 0.00067 = 0.134 IOPS per mailbox. You can then divide the IOPS provided by your volume by the IOPS per mailbox, which in this case would be 55 / 0.134 = 410 mailboxes per volume from a performance perspective.
This very rough storage sizing exercise shows that you can fit 372 5 GB mailboxes on your 3 TB volume from a capacity perspective and 410 mailboxes from a performance perspective. You would therefore take the lower of these numbers when you size the solution and put no more than 372 mailboxes on each 3 TB disk drive.
This logic applies even if there are multiple databases per volume. In this instance, if you had two databases on your 3 TB volume, you would still store 372 mailboxes in total, but during normal operation 186 of the mailboxes would be active and 186 would be passive.
Let's assume that you're using 12 3 TB volumes within your server. Out of these 12, 2 are required for the host operating system and transport, which leaves 10 for mailbox database volumes. Let's leave one to function as an auto-reseed spare, which leaves 9 3 TB JBOD volumes for your databases. This means that your server could support 9 × 372 = 3348 mailboxes from a storage perspective.
Processor sizing is based on the same approach as storage. First, you need to know what your user profile is, and then you use that to determine your processor requirements per mailbox. Next, you calculate the processor capacity of your potential server and how many mailboxes it can support.
One of the first things you need to understand for processor scaling is the concept of megacycles. A megacycle is a processor term used to define the amount of work that a processor can complete in one million clock cycles. The first problem is that the amount of work that a processor can do in one clock cycle varies between processor types. To counter this you use a comparison benchmark called SPECint to help you compare workloads between different processor types.
However, you first need to determine your processor megacycles requirements per mailbox. To do this, multiply the user profile by 0.0425. If you stick with your profile of 200, this becomes 200 × 0.0425 = 8.5 megacycles/mailbox for the Mailbox role only. We will discuss processor requirements for CAS later on.
The next step is to calculate how many megacycles your server has available. For this example, let's assume that you're going to be using a server with two Intel XEON E5-2660 CPUs. According to the www.spec.org website, the SPECint2006 CINT2006 rate score for a system with two of these processors is 591. This system has 16 processor cores and so each one has a SPECint2006 rate score of 591 / 16 = 36.93. The base system used for all Exchange 2013 processor size calculations has a SPECint2006 rate score per core of 33.75. To estimate the available Exchange workload megacycles on the target server, you can use the following formula:
(Target platform per-core value x MHz per-core of baseline platform)/(Baseline per-score value)
In this case this becomes (36.93 × 2000 MHz) / 33.75 = 2188 megacycles/core. The system has 16 processor cores, and so the total available megacycles is 2188 × 16 = 35,015 megacycles.
The next step is to determine how many mailboxes you can support with your 35,015 megacycles of processing power. But before we dive in, you need to adjust your capacity a little since it is generally never a good idea to run your processors at 100 percent capacity. As a general rule, it is a good idea to aim for 80 percent utilization in the worst-case scenario, so immediately you know that each of your 200 user-profile mailboxes requires 8.5 megacycles, so to determine how many mailboxes your server can handle safely, you must divide 28,012 by 8.5 = 3295 mailboxes per server.
If you are planning to collocate mailbox and client access on this server, the formula changes slightly. A Client Access server requires roughly 20 percent of the processor power that is required for the Mailbox role. To approximate this, if you are sizing for a multirole server, you would take your system megacycles target of 28,012 and take off 25 percent for CAS, which would leave 28,012 × 0.75 = 21,009 megacycles. This means that your two-socket XEON E5-2660 server would support 21,009 / 8.5 = 2471 mailboxes on a multirole server.
Memory sizing follows a similar path to both disk and processor sizing. The amount of memory required is primarily based on the user profile. If you take our example profile of 200 messages per user per day, this would end up being 200 × 0.24 = 48 MB of RAM per mailbox.
Given our previous calculations,
You are essentially limited by your processor in this example, and so you need to provide sufficient memory for 2471 mailboxes with a 200-message profile. You know that each mailbox requires 48 MB of RAM, so your requirement becomes 48 × 2471 = 115 GB. However, this only considers the Mailbox role. You also need to consider the requirements for CAS, which requires 2 GB RAM per CPU core used. As a rough approximation, CAS requires 25 percent of the peak worst-case processor capacity on a multirole system, and so your calculation becomes 16 × 80% × 25% × 2 GB = 6.4 GB. When you add this to the 115 GB required for the Mailbox server role, you get a total Exchange Server RAM requirement of 115 GB + 6.4 GB = 121.4 GB. The only remaining thing you need to account for is the Windows operating system itself, which requires a further 2 GB, so your total system requirement becomes 121.4 GB + 2 GB = 123.4 GB.
We hope that this brief overview of Exchange sizing has been useful. It is not intended to provide a detailed set of instructions to help you to perform sizing; it is meant more to highlight some of the things that go into a successful sizing calculation.
For almost all scenarios, we recommend using the Exchange 2013 Server Role Requirements Calculator, which is discussed more in Chapter 5, “Designing a Successful Exchange Storage Solution.” The calculator can be found here:
If you are curious as to just what the calculator is doing, then we strongly advise that you pour yourself a large version of your favorite drink and spend some time reading Jeff Mealiffe's blog post about Exchange Server 2013 sizing, which can be found here:
http://aka.ms/Exchange2013SizingGuidanceBlog
You may be tempted to launch into documenting your new design immediately and use the lists provided in this chapter as your own design document headings. Before doing that, consider the following topics:
Design documents are considered to be “living documents” while they being are written. In other words, they are subject to change and may iterate through a number of versions before the final published report is released. Bear this in mind as you craft your design. Design documents are not considered set in stone until they are accepted as final via a formal sign-off mechanism.
Designs go through a number of iterations, and your customer may request various features at a late stage in the design process that they would like to include. The solution to this is to require a formal handover procedure. The key is identifying the stakeholders and gaining their approval of the requirements before the design is issued. Design approval then becomes a straightforward task of demonstrating that the proposed design meets the previously identified requirements.
If new requirements are added as the design progresses, then these must be identified as a clear change, and they are subject to change control and potential redesign.
Be careful not to overengineer a solution. Try to address each requirement as simply as possible without excessively complicating the solution. For example, external publishing and security may be achieved using a single service or appliance, or you may choose to implement multilayer security, using layers of network zones, routers, and software. The latter example may represent massive overengineering of the customer's actual needs.
Simple is relative in design terms. Essentially, you want to be careful not to design something that the final customer is unable to implement or operate. Complexity often increases total cost of ownership and can lead to lower service availability. As a design approach, try to identity the “total cost” in each of your decisions. That is, don't just concentrate on capital expense; consider what the impact of your decision will be on the operations teams. Typically, the capital expenditure for hardware on an Exchange project is small compared to the total cost of running the service for many years.
Don't design yourself into a corner. Remember that one day, your customer may need to migrate away from this shiny new platform to a newer platform. The more complicated you make things now, the harder it will be for your customer to migrate in the future. The best approach to this is to try to adopt recommended practices within your design wherever possible and only change default values or deploy third-party software as required.
You may decide to look at how Microsoft has implemented Exchange internally and want to implement Exchange 2013 in a similar fashion. You should bear in mind, however, that Microsoft is a unique organization, subject to compliance laws unlike those of your organization or client. Microsoft will also have particular business requirements that may be significantly different than those of your organization or client. For example, Microsoft IT has not implemented Exchange 2013 on-premises in any significant numbers outside of their own dog-food environment but has elected to move virtually all mailboxes to Exchange Online.
Looking at how other organizations have implemented Exchange 2013 is certainly interesting. However, just because a design solution works for another organization doesn't necessarily mean it is the ideal solution for you or your customer.