Exchange 2010 – A quick look

A checklist with some of the new features in Exchange 2010.
Feature Description
Editions Standard Edition- Host 5 databases
Enterpsire Edition- Host 100 databases
Version Can run only on 64 bit machines. Even trial version does not support 32 bit machines.

CAL (Client Access License) Standard CAL : Licenses for emails, calendaring, OWA and ActiveSync for Mobile devices. Enterprise CAL : Additional license for compliance functionality like anti spam and anti virus for Exchange.
OWA Not anymore Outlook Web Access. Exchange 2010 calls it Outlook Web Apps. Very Similar to Outlook. New features include setting favorites, attaching messages to messages, integration with Office Communicator, a new Conversation View , integration with SMS (text) messages and the possibility to create Outlook WebAccess policies
CCR, SCR, LCR None of these features are available. CCR and SCR combined to be DAG.
Storage Groups No more Storage Groups. Databases and log files still exist.
Single Instance Storage (SIS) No more SIS
Browser for OWA Cross browser support- Apple mac Safari users have the same experience as IE users.
High Availibility CCR and SCR is now Database Availability. Databases are created in a Database Availability Group. We need not install Microsoft Cluster Service (MSCS) before installing Exchange.
Memory Utilization The 64-Bit platform makes it possible for servers to cache information in their memory instead of reading and writing everything to the disk. I/O requirements of an Exchange Server 2010 server can be up to 50% less the same confi guration in Exchange Server 2007.
Design The schema for Exchange has now be flattened due to which SIS had to be removed. However, performance has improved

Powershell Exchange 2010 uses Powershell version 2.
Windows Remote Management Exchange 2010 uses Windows Remote Management version 2. We can remotely manage an Exchange server from a workstation without installing Exchange Management Tools on the workstation.
Send Mail Feature We can now send mails directly from Exchange Management Console. For testing purposes, the same will be effective.
Exchange Control Panel From Options in OWA, we now have features to change user properties, create users, Distribution Groups etc

Rights Management We can now disable options like Forward for mails, to prevent them from going outside the organization.

Message Routing In a mixed environment with few mailboxes hosted with ISP and few with Microsoft Online services, messages are routed smoothly.

Disclaimers We can add HTML Content to disclaimers. Infact, we can also modify AD Attributes for user to create a personal disclaimer.

Shadow Redundancy In Exchange 2007, messages are deleted from database in Hub Transport as soon as the messageis sent to the next hop. However, in Exchange 2010, the message is deleted from database only after a successful delivery message is reported after the hop.
If the delivery message is not successful, the Hub transport server will resend the message again.
Archive Exchange 2010 now has personal archive which is a secondary mailbox associated with the primary mailbox of a user. Secondary mailbox is located in the same databaseas the primary mailbox.
Active Directory Minimum requirement is Windows Server 2003. There should be at least 1 Windows 2003 Server (or higher) as GC in each site.
Interop Routing Group Connector.
If an Exchange 2003 co-exists with Exchange 2010, then the Interop Routing Group Connector should be configured. It is not possible to have a co-existing environment of Exchange 2010 and Exchange 2000.
Mailbox Server Role This is solely dedicated for mailbox and Public folder databases. MAPI Outlook clients now connect to a service called MAPI running on CAS.
Default First DB Location C:\Program Files\ Microsoft\Exchange Server\V14\Mailbox\Mailbox Database <>

Exchange 2010 Interview Questions

Explain the Topology changes in Exchange servers?

In Exchange server 2003, we have one two server roles that is front end and back-end server architecture

In Exchange server 2007, Exchange architecture changes and we have 5 key server roles that depend on the functions it does. They are Edge Transport Server Role, Hub transport Server Role, Client Access Server Role, Mailbox Server Role and Unified Messaging Server Role.

In Exchange Server 2010, there is no change in the topology, there is only changes in the key architecture component in the Server role level
For example

Client Access Server, changes are
· Storage access path
· Introduction of RPC Client Access Service
· Client RPC connection changes

Transport Server, changes are
· Resiliency issues are removed
· Shadow redundancy
· Exchange Storage Engine changes
· Increase in DB cache size and check point depth
· Edge sync
· Support for safe sender and blocked sender
· Information leakage protection and control

Mailbox Server Role, changes are
· Store schema changes
· DB I/O size improvements
· New message records management features
· High Availability changes
· Introduction of Database Availability Group
· DAS supportable to reduce cost
· Large mailbox support up to 10 GB
· Support for Public Folders

1. What are the new features introduced in Exchange Server 2010 on overview perspective?
1. Protection and compliance
2. Anywhere Access
3. Flexible and reliable

2. What’s new in Protection and compliance?
· Email Archiving
· Protect Communication
· Advanced Security

3. What’s new in anywhere Access?
1. Manage Inbox Overload
2. Enhanced Voice Mail
3. Collaborate efficiently

4. What’s new in Flexibility and reliability?
· Continuous Availability
· Simplified Administration
· Flexible deployment of Exchange Server 2010

5. Explain the E-Mail Archiving feature in Compliance?
We can set email retention mail policy from end user level
Message expiration
We can search for individual or Multi user mailboxes from compliance officer perspective

6. Exchange the protection features in Exchange Server 2010?
Hub Transport Server provides
1. Automatically protect Messages with the centralized Rights Management Service
2. Automatic Content Based Protection
3. Transport rule action to apply template to E-Mail or Voice Mail
4. Support for scanning of attachment
5. Internet confidential and DO NOT Forward E-Mail Polices
6. Information Protection Cross PC, Web and Mobile devices

7. What are the Advanced Security features in Exchange Server 2010?
Exchange server 2010 comes up with the advance security feature of stopping malicious software and spam from enter into the message environment
1. We can have Forefront Security to have this advance security, which has
2. Multiple scan engines throughout the corporate infrastructure
3. Easy to use management console provides central configuration and operation

8. What’s New in Anywhere Access?
Manage inbox overload using enhanced conversation view and filtering the messages
Mail Tips – if no permission to send mail, popup will show mail tips to reduce NDRS
Can access Voice Mailbox with features like
1. Audio play back
2. Text preview
3. Quick option to add the user to contacts and phone number
Auto attend – we can manage auto attend, define personalized voice menu

9. What are the supportable clients for Exchange Server 2010?
Desktop – office 2007 and entourage MAC
WEB – OWA, OFFICE outlook web access, IE, Firefox and safari
Mobile – office outlook mobile, windows mobile, and Exchange active sync for third party’s

10. What are the outlook features now introduced to mobile devices?
1. Auto complete cache – used email address in OWA in cache will be shared mobile
2. Conversation view – if any change in messages on outlook that will be applied to Mobile
3. Contact to see the availability of the users
4. Voice Mail Preview – see voice mail
5. Send and receive text message in OWA and mobile
6. Admin can control which mobile devices can connect
7. Downloadable mobile devices

11. What is universal Inbox In OWA?
Its provides a solution to have one E-Mail inbox for E—Mail, Text messages and Voice messages
Can have multiple E-Mail accounts in one OWA window

12. What is federation?
Federation is new feature in Exchange server 2010 to share the company users calendars to the partners. A trust relationship to be made to have this feature

13. What is continuous availability feature in Exchange Server 2010?
In Exchange Server 2007, we have server to server failover scenarios, and we need to use failover clustering to configure the HA options which is very difficult to manage
In Exchange Server 2010, HA modified to Database level which provides quick recoverability in disk and database failures. We can have multiple database copies up to 16 mailbox copies in a database availability group. Admin have replicate mailbox copies up to 16 replicated copies. Capabilities of having CCR and SCR into single platform

14. Continuous availability in user level?
If a mailbox move is happening, the users will be stay online and there wont be be any discontinuity in sending or receiving mails

15. Explain the administration option in Exchange Server 2010?
Exchange Server 2010 provides simplified administration by providing options like
1. Compliance office can easily search for mailboxes
2. HR can easily update the user information
3. Help desk can easily manage mailbox quotas
4. User can easily track the status of the message easily
5. User can easily create own Distribution group
6. User can modify the contact information

16. What are the storage options supported in Exchange Server 2010?
Exchange Server 2010 can support the DAS and Also JBOD disks its because of the HA option depends only on the Database level

1. Why Archive?
1. Growing E-Mail Volume – everyone wants to have more E-mail because of this the storage, Backup disk should be increases
2. Performance and storage issue – increase in Storage costs
3. Mailbox quota – users are forced to manage quota
4. PSTs – quota management often results in growing PSTs – outlook Auto Archive
5. Discovery and Compliance issues – PSTs difficult to discovery centrally, regulatory retention schedules contribute to further volume/storage issues

2. How Archiving improved in Exchange Server 2010?
Archiving improved by providing larger mailbox architecture, simple migration of PSTs back to server, discovery options, retention policies and legal hold.
Large mailbox Architecture – maintains performance and provides option for DAS-SATA storage to reduce costs
Archiving enables simple migration of PSTs back to server. If the archiving option sin enabled for a user, a new Mailbox will be created to the user name archive in which the user can set retention policies to move the mails to archive mailbox or the admin can set retention policies for the user mailbox.
Archiving simplifies discovery, retention and legal hold

3. What are the archiving options introduced in Exchange Server 2010?
1. Personal Archive – secondary Mailbox Node, they are the PST files of primary Mailbox
2. Retention Policies – folder/item level and archive/delete policies
3. Multi-Mailbox search – Role based GUI, admin can assign this permission to legal team
4. Legal Hold – monitor or control a user from delete a mail by legal hold and searchable with Multi Mailbox Search
5. Journaling – Journal de-duplication (unwanted journaling on distributed mails). One copy of journal per database and
6. Journal decryption – HT role will do the decryption and send the decrypted copy for journaling

4. What is personal archive in Exchange Server 2010 archiving?
It is a Secondary mailbox that is configured by the administrator, this appears along with user’s primary mailbox in outlook or OWA, and the PST files can be dragged and dropped to personal archive Mailbox. Mails in Primary mailbox can be moved automatically using Retention policies. Archive quota can be set separately from primary mailbox

5. What are retention policies? And what we can do with retention policies in Exchange Server 2010?
Retention policy is an option to move/ delete certain mails by applying rules. We can set retention policies at Item or Folder level. Policies can be applied directly within e-mail. We can set expiration date stamped directly on e-mail. Policies can be applied to all email within a folder. We can configure delete policy to delete the mail after certain period and Archive policies to move certain mails with the certain period to archive mailbox

6. What are the Retention Policies in Exchange Server 2010?
1. Move Policy – automatically moves messages to the messages to the archive Mailbox with the options of 6 months, 1 year, 2 years, 5 years and never – 2 years is default. Move mailbox policies helps keep mailbox under quota. This works like outlook Auto Archive without creating PSTs
2. Delete Policy – automatically deletes messages. Delete policies are global. Removes unwanted items
3. Move + Delete policy – automatically moves messages to archive after X months and deletes from archive after Y Months. We can set policy priority: Explicit policies over default policies; longer policies apply over shorted policies

7. What is Multi Mailbox Search?
This option delegated access to search to HR, compliance, legal manager. Administrator has to provide access permission on to use this feature, this will provide an option to search all mail items ( email, IM contacts, calendar) across primary mailbox, archives. The filtering option in Multi Mailbox search includes sender, receiver, expire policy, message size, send/receive date, cc/bcc, regular expressions, IRM protected Items

8. What are E-Discovery features?
Following are the E-Discovery features introduced in Exchange Server 2010
1. Search specific Mailboxes or DLS
2. Export search results to a mailbox or SMTP Address
3. Request email alert when search completes
4. Search results organized by per original hierarchy
Lot more will be added in the original release

9. What is Legal Hold and what are the features in Legal Hold?
New feature in Exchange Server 2010 to monitor or control a user from deleting a Mail or Mailbox, the features available in Legal Hold are
1. Copy edited and deleted item – this option is in Exchange server 2007 to hold the auto deleted items
2. Set duration for auto delete – indefinite or specify time period
3. Auto alert notification – sends alerts to users that they are on hold, eliminates manual process
4. Search dumpster – use Multi Mailbox search to retrieve deleted/edited items indexed in dumpster folder

10. What is journaling and what are the journaling features in Exchange Server 2010?
Journaling is an option to track mails from particular user or from a group of users. The New Features in Journaling for Exchange server 2010 are
1. Transport Journaling – ability to journal individual Mailboxes or SMTP address and also this gives a detailed report per To/Cc//Bcc/Alt-Recipient and DL expansion
2. Journal report de duplication – reduces duplication of journal reports. Exchange server 2010 creates one report per message

11. What is journal decryption?
Journal decryption is a new feature in Exchange Server 2010, if a user sends an encrypted message to recipient and if journaling was enabled for that user, then the Hub transport Server decrypts the message and sends that decrypted message for journaling. The intended recipient will receive the encrypted message

12. What is Set Quota in Archive management?
With Mailbox quota Management, we can assign mailbox size for a user. This option can be enabled from the properties of the user account, and the default settings to Mailbox quota is 10 GB

1. What is federated sharing?
Federated Sharing allows easy sharing of availability information, calendar, and contacts with recipients in external federated organizations

2. What are the options shared in federated sharing?
1. Free busy information
2. Calendar and contact sharing
3. Sharing policy

3. How federated sharing works in Exchange server 2010?

4. Explain the operation of federation?

5. What are the benefits of federation?
Allow users to act on behalf of specific user
· Specific user identified by E-mail address
· User not prompted for credentials
Reduces explicit trust management
· No AD trusts, service to cloud accounts to manage
· Minimizes certificate exchanges
· Verifies domain ownership

6. Explain the federation commands in Exchange server 2010?
Establish federation trust = New-federation Trust
· Install signing certificate on CAS servers
· Exchange certificate with federation gateway
Prove domain ownership = domainname.com IN TXT AppId = xxxxxxxx
· Create DNS TXT record
Add domain to trust = set-federatedOrganizationIdentifier
Add-federatedDomain
· Must be accepted domain

7. How to establish federated sharing in Exchange Server 2010?
1. Create trust with certificate exchange
2. Prove domain ownership
3. Add domains

8. What is Microsoft Federation Gateway?
Exchange Server 2010 uses Microsoft Federation Gateway (MFG), an identity service that runs in the cloud, as the trust broker. Exchange organizations wanting to use Federation establish a Federation Trust with MFG, allowing it to become a federation partner to the Exchange organization. The trust allows users authenticated by Active Directory , known as the identity provider (IP), to be issued Security Assertion Markup Language (SAML) delegation tokens by MFG. The delegation tokens allow users from one federated organization to be trusted by another federated organization. With MFG acting as the trust broker, organizations are not required to establish multiple individual trust relationships with other organizations. Users can access external resources using a single sign-on (SSO) experience

9. What is Federation Trust?
A Federation Trust is established between an Exchange organization and MFG by exchanging the organization’s certificate with MFG, and retrieving MFG’s certificate and federation metadata. The certificate is used for encrypting tokens

10. What is Sharing Policy?
Sharing policies allow you to control how users in your organization can share calendar and contact information with users outside the organization. To provision recipients to use a particular sharing policy
Prerequisites to create a Sharing Policy
 A federation trust has been created between your Exchange 2010 organization and Microsoft Federation Gateway, and the Federated Organization Identifier is configured.
 Although you can create a sharing policy for any external domain, recipients from the specified domain can access your users’ information only if they have a mailbox in an Exchange 2010 organization and their domain is federated

Only Questions 🙂

1. What is RPC Client Access Service?
2. Why RPC Client Access Service in Exchange Server 2010?
3. How the client Access in Exchange Server 2010 changes by RPC Client Access Service?
4. How directory referral connection works in RPC Client Access Service?
5. What are the outlook Anywhere improvements using RPC Client Access Service?
6. What are the considerations for Client Access Server in Exchange Server 2010?
7. What is the resilience issue in Exchange Server 2007? How it is overcome in Exchange Server 2010?
8. What are the resilience improvements in Exchange Server 2010?
9. How does shadow Redundancy works?
10. How Exchange Server 2010 supports the legacy exchange clients that not support shadow redundancy?
11. What are the performance enhancements changes in Exchange Server 2010 Transport roles?
12. Explain the Performance Changes in Edge Transport Server Role?
13. Explain the Architectural consideration for Exchange Server 2010 Transport Roles?
14. What are the issues in ESE of Exchange Server 2007?
15. How the issues are overcome in Exchange Server 2010?
16. Explain the High Availability Changes in Exchange Server 2010 Mailbox server role?
17. What are the considerations for deploying mailbox server roles?
18. Explain the Architectural consideration for Exchange Server 2010 Mailbox Server role?
19. Explain Public Folders in Exchange Server 2010?

What’s the difference between Unified Messaging and Unified Communications?

ShareIn my previous post, I spent some time outlining the features of Exchange Unified Messaging (UM). From time to time, I’m asked to explain how UM relates to Microsoft’s Unified Communications (UC) strategy and products. In this post, I’ll try to give a personal view on the relationship between UM and UC.

UM is a part of UC. In other words, UC includes UM, but UC also includes a lot of other important products and technologies. A customer who uses Microsoft’s Office, SharePoint, Exchange and Office Communications Server products has an opportunity to experience many more UC scenarios than a customer using Exchange (and UM) only. Office Communications Servers’ support for enterprise class presence, instant messaging and voice, combined with the ability of Office, SharePoint and Exchange to use this support, creates many useful and interesting new possibilities for the end user.

A simple example of the power and convenience of UC can be seen when a user receives a voice message (created by Exchange UM) from another user and opens it in Outlook. Not only can they listen to the message, but they can see the other user’s presence status, and start an instant messaging or voice conversation with them. Not only are there more ways for users to communicate with each other, but they are woven together into an intuitive, unified experience by the software.

UC offers so many possible combinations and sequences of interactive communication that it is easy to be dazzled by the details and lose sight of the underlying principles. The user is placed at the center: they are able to communicate with others from the most convenient device, with the most appropriate method, at the right time. Unified Messaging (UM) participates in some of these scenarios (indeed, it is an integral part of many of them), but is just a component of the larger UC picture.

In the “old world”, customers had a PBX and voice mail. Now, they can have a Unified Communications system, where Office Communications Server plays the part of the PBX (and much more), and Exchange Unified Messaging replaces legacy voice mail. In this “new world”, many new possibilities have opened up, but some familiar patterns and interactions still occur.

Unified Communications, Unified Messaging and Good Old Voice Mail

ShareThis is my first posting as a “Unified Communication”, so it seems like a good moment to explain what I mean when I use terms such as UC and UM. Some people whom I’ve talked with at TechEd and other events were rather hazy about the differences between UC and UM, so there seems to be a need to clarify it. In this posting I’ll cover UM only, to keep things brief.

Unified Messaging (UM) is itself a rather nebulous term. Everyone seems to agree on some of the characteristics of UM. Voice mail and e-mail are presented together, visually, to the user in their mail client. There is an over-the-phone interface to allow messages to be listened to, replied to and deleted. Beyond that, there is little consensus. Should all messages be contained in a common store? Should fax be supported, and how? How is identity managed? And so on.

I’m happy to talk about Microsoft Exchange Unified Messaging as “UM”. It’s the product I work on, and it’s the product I use every day. So, as long as I’m careful to say “Exchange UM” when there is any danger of confusion, I can clarify the underlying principles and describe the features when I’m asked about it.

Exchange UM is packaged as one of the server roles in Exchange 2010. (It was introduced in Exchange 2007). It has three main feature areas:

•Voice Mail. The basic call-answering functionality. If a user does not answer a call to their phone, the call is eventually forwarded to a UM server. It answers, and plays the user’s greeting, such as: “Hello, this is Michael. I’m sorry I can’t take your call. Please leave a message.” The caller then hears a BEEP and records their message for the user. UM arranges for the message to be delivered to the user’s Exchange Inbox. The user can listen to the message by using a mail client such as Outlook or Exchange 2010 Outlook Web App (OWA), or by using…
•Outlook Voice Access. This provides a telephone interface to Exchange that works for any phone. A user calls a number that is answered by UM; they identify themselves to the system with a sequence of touch tone keys. UM then tells them what’s new, for example: “You have 2 new voice messages and 8 new e-mails…” What sets UM apart from older voice mail and unified messaging systems is that users are able to access not only voice mail and e-mail over the phone, but can also access their calendar, and call or send voice messages to Personal Contacts or other users. And they can do this with voice commands, because speech recognition is enabled in all of Exchange 2010 UM’s 26 language packs.
•Automated Attendant. Many companies want to provide telephone callers with a convenient way of reaching their employees, even if the caller doesn’t know the employee’s telephone number, but only the company’s main “switchboard” number. An Automated Attendant is a system that answers the phone in such a case, prompts the caller, collects their input and tries to direct their call to the correct person. Automated Attendants are sometimes chained together to make multi-level menus. Exchange UM allows the Automated Attendants to be speech-enabled, so that the caller can simply say the name of the person that they want to contact.
The architecture that underpins Exchange UM is true to the “Unified” name. All messages are stored in Microsoft Exchange. All messages are transported by Microsoft Exchange. All identities (and the vast majority of configuration details) are managed by Microsoft Windows and Active Directory. Administrators who already know Exchange will find a few new concepts in UM, but they all relate to its connection to the world of telephony. Much of UM will seem very comfortable to the Exchange administrator.

In my next post, I’ll try to differentiate UM, now defined, from UC. In later posts, I’ll talk about Exchange UM’s relationship to the “world of telephony”, and how to connect the two together.

Exchange 2010 Mailbox Role Calc Released

Overview
The Exchange Mailbox Server role is arguably one of the most important roles within an Exchange deployment for it stores the data that users will ultimately access on a daily basis. Therefore, ensuring that you design the mailbox server role correctly is critical to your design.

With Exchange 2010 you can deploy a solution that leverages mailbox resiliency and has multiple database copies deployed across datacenters, implements single item recovery for data recovery, and has the flexibility in storage design to allow you to deploy on storage area networks utilizing fibre-channel or SATA class disks or on direct attached storage utilizing SAS or SATA class disks with or without RAID protection. But, in order to design your solution, you need to understand the following criteria:

•User profile – the message profile, the mailbox size, and the number of users
•High availability architecture – the number of database copies you plant to deploy, whether the solution will be site resilient, the desired number of mailbox servers
•Server’s CPU platform
•Storage architecture – the disk capacity / type and storage solution
•Backup architecture – whether to use hardware or software VSS and the frequency of the backups, or leverage the Exchange native data protection features
•Network architecture – the utilization, throughput, and latency aspects
Previous versions of Exchange were somewhat rigid in terms of the choices you had in designing your mailbox server role. The flexibility in the architecture with Exchange 2010, allows you the freedom to design the solution to meet your needs. Prior to making any decisions, please review the following topics from the Exchange 2010 Online Help:

•Understanding High Availability and Site Resilience
•Planning for High Availability and Site Resilience
•Understanding Backup, Restore and Disaster Recovery
•Mailbox Server Storage Design Recommendations
After you have determined the design you would like to implement, you can follow the steps in the Understanding Exchange Performance section of the Exchange 2010 Online Help to calculate your solution’s CPU, memory, and storage requirements, or you can leverage the Exchange 2010 Mailbox Server Role Requirements Calculator.

The calculator is broken out into the following sections (worksheets):

•Input
•Role Requirements
•LUN Requirements
•Backup Requirements
•Log Replication Requirements
•Storage Design
Important: The data points provided in the calculator are an example configuration. As such any data points entered into the Input worksheet are specific to that particular configuration and do not apply for other configurations. Please ensure you are using the correct data points for your design

Input
When you launch the Exchange 2010 Mailbox Server Role Requirements Calculator, you are presented with the Input worksheet. This worksheet is broken down into 5 key areas. This section is where you enter in all the relevant information regarding your intended design, so that the calculator can generate what you need in order to achieve it.

Note: There are many input factors that need to be accounted for before you can design your solution. Each input factor is briefly listed below; there are additional notes within the calculator that explain them in more detail.

Environment Configuration
Within Step 1 you will enter in the appropriate information concerning your messaging environment’s configuration – the high availability architecture and database copy configuration, the data and I/O configuration, and CPU inputs.

Note: For optimal sizing, choose a multiple of the total number of database copies you have selected for the number of mailbox servers.

Exchange Environment Configuration

1.Do these servers only have the mailbox server role installed? Having the Hub Transport and Client Access server roles also installed on the along with the mailbox server role affects your design in the areas of load balancing client requests, memory utilization, and CPU utilization.
2.Are you deploying a database availability group (DAG)? Deploying the solution as DAG provides you additional flexibility and resiliency choices like having multiple mailbox database copies, leveraging flexible mailbox protection features in lieu of traditional backups, and flexibility in your storage architecture (e.g. RAID or JBOD).
3.Are you deploying the DAG in a site resilient configuration? A DAG can be stretched across 2 or more datacenters (the calculator only allows for 1 datacenter) without requiring the AD site or network subnet to be stretched.
4.What user distribution model will you be leveraging in your site resilient architecture? When planning a site resilience model with Exchange 2010, keep in mind there are two variables that need to be considered: namespace model and user distribution model. For the namespace or datacenter model, Exchange 2010 requires both datacenters to be in an Active/Active configuration. This means that both datacenters participating in the DAG solution must have active, reachable namespaces and have the ability to support active load at any time. For the user distribution model, the design can support both Active/Passive and Active/Active user distribution. At this time, the calculator only supports and Active/Passive user distribution model. An Active/Passive user distribution architecture simply has database copies deployed in the secondary datacenter, but no active mailboxes are hosted there and no database copies will be activated there during normal runtime operations. However, the datacenter supports both single cross-datacenter database *overs, and full datacenter activation.
5.In your site resilient architecture, how far behind can you get in terms of log shipping between datacenters? The effect of the RPO is to evaluate the non-contiguous peak hours (defined in Step 5), say 8am and 4pm, and determine the resulting throughput requirement, assuming that you can take the time in between 8 and 4 to catch up (within the specified RPO, of course). By allowing replication to get behind there are two outcomes: 1. Active Manager is less likely to choose a database copy that has a high copy queue length (unless more viable alternatives aren’t available). 2. If the copy queue length is greater than the target server’s AutoDatabaseMountDial setting, the database will not automatically mount once activated. Manually mounting that database will result in the loss of data that had not been copied.
6.How many mailbox servers are you going to deploy within the primary datacenter? If you enter more than a single server (remember a DAG requires at least two and can support a maximum of 16), the calculator will evenly distribute the user mailboxes across the total number of mailbox servers and make performance and capacity recommendations for each server, as well as, for the entire environment. As for the secondary datacenter, the calculator will determine the number of mailbox servers you need to deploy there based on the requirements (number of databases, number of copies, etc).
7.How many DAGs are you planning to deploy in the environment? If you enter more than a single DAG, then the calculator will distribute the user mailboxes across the total number of DAGs and make performance and capacity recommendations for each server and each DAG, as well as, for the entire environment.
Mailbox Database Copy Configuration

1.How many mailbox database copies do you plan to deploy within a DAG? Enter in the number of highly available database copies you plan to have within the environment. This value excludes lagged database copies. For optimal sizing, choose a multiple of the total number of mailbox servers you have selected.
2.How many lagged database copies do you plan to deploy within a DAG? Lagged database copies are an optional feature that can provide protection against certain disaster scenarios (like logical corruption). Lagged database copies should not be considered an HA database copy as the replay will delay the availability of the database for use once activated. While technically there is no limit to how many lagged copies you can deploy within a DAG, the calculator limits you to a maximum of 2 copies.
3.How many mailbox database copies do you plan to deploy within the secondary datacenter? If you are deploying a site resilient solution, you can choose to a portion of the total HA database copies deployed in the secondary datacenter.
4.How many lagged database copies do you plan to deploy within the secondary datacenter? If you are deploying a site resilient solution, you can choose to have a portion or all of your lagged database copies deployed in the secondary datacenter.
Lagged Database Copy Configuration

1.Will you deploy the lagged database copies on a dedicated server? Using a dedicated server for lagged database copies certainly makes it easier to manage. For DAGs where the lagged database copies are evenly distributed across all the DAG mailbox servers, you will need to use the Suspend-MailboxDatabaseCopy with the -ActivationOnly flag to prevent them from being mounted, but there are scenarios that can clear this. With a dedicated server you can activation block the entire server and the setting is persistent. The choice can also affect your storage design in terms of choosing RAID or JBOD. Unless you have multiple lagged copies, lagged copies should be placed on storage that is utilizing RAID to provide additional protection. The calculator will determine the appropriate number of lagged copy servers you need to deploy based on the requirements (number of databases, number of copies, etc).
2.How long will you delay transaction log replay on your lagged copy? This parameter is used to specify the amount of time that the Microsoft Exchange Information Store service should wait before replaying log files that have been copied to the lagged database. The maximum amount of replay delay you can set is 14 days. The value you specify here will influence the log capacity requirements for all copies and the amount of time required to mount a lagged copy.
3.How long will you delay transaction log truncation on your lagged copy? This parameter is used to specify the amount of time that the Microsoft Exchange Replication service should wait before truncating log files that have been copied to the lagged database. The time period begins after the log has been successfully replayed into the lagged copy. The maximum allowable setting for this value is 14 days. The minimum allowable setting is 0, although setting this value to 0 effectively eliminates any delay in log truncation activity. The value you specify here will influence the log capacity requirements for all copies.
Exchange Data Configuration

1.What will be the Data Overhead Factor? Microsoft recommends using 20% to account for any extraneous growth that may occur.
2.How many mailboxes do you move per week? In terms of transactions, you have to take into account how many mailboxes you will either be moving to this server or within this server, as transactions totaling the size of the mailbox will always get generated at the target database.
3.Are you going to deploy a Dedicated Restore LUN? A dedicated restore LUN is used as a staging point for the restoration of data or could be used during maintenance activities; if one is selected then additional capacity will not be factored into each database LUN.
4.What percentage of disk space do you want to ensure remains free on the LUN? Most operations management programs have capacity thresholds that alert when a LUN is more than 80% utilized. This value allows you to ensure that each LUN has a certain percentage of disk space available so that the LUN is not designed and implemented at maximum capacity.
5.Do you have log shipping compression enabled within the DAG? By default, each DAG is configured to compress and encrypt the socket connection used to ship logs across different IP subnets (you can disable these features all together or enable them for all communications regardless of subnet).
6.What is your compression rate? The compression capability that is obtained for the socket connection used to ship logs will vary with each customer, based on the data obtained in the transaction log files. By default, Microsoft recommends using a value of 30%, however, you can determine this value by analyzing your environment (e.g., once Exchange 2010 is deployed you could evaluate the throughput rate with compression disabled and then compare with compression is enabled) .
IOPS Configuration

1.What will be the I/O Overhead Factor? Microsoft recommends using 20% to ensure adequate headroom in terms of I/O to allow for abnormal spikes in I/O that may occur from to time.
2.What additional I/O requirements do you need to factor into the solution for each mailbox server’s storage design? For example, let’s say the solution requires 500 IOPS for the mailboxes and you have decided you want to ensure there is extra I/O capacity to support additional products (e.g. antivirus) to generate load during the peak user usage window. So you enter 300 IOPS in this input factor. The result is that from a host perspective, the solution needs to achieve 800 IOPS. This may require additional testing by comparing a baseline system against a system that has the I/O generating application installed and running.
Database Configuration

1.Do you want to follow Microsoft’s recommendations regarding maximum database size? For standalone mailbox server role solutions, Microsoft recommends that the database size should not be more than 200GB in size. For solutions leveraging mailbox resiliency, Microsoft recommends that the database size should to exceed 2TB. Neither of these is by any means a hard limit, but a recommendation based on the impact database size has to recovery times. If you want to follow Microsoft’s recommendation, then select Yes. Otherwise, select No.
2.Do you want to specify a custom Maximum Database Size? If you selected No for the previous field, then you need to enter in a custom maximum database size.
Server Configuration

1.How many processor cores and what is their megacycle capability are you planning to deploy in each server? For each server type (primary datacenter, secondary datacenter, and lagged copy server) you plan to deploy, select the number of processor cores and the core’s corresponding megacycles. For example, the Intel Xeon x5470 3.33GHZ processors (2×4 core arrangement) can deliver 3300 MCycles of performance throughput. Other processor configurations can be estimated by comparing this measured platform to server platforms tested by http://www.spec.org (SPEC CPU2006 Results).
Mailbox Configuration
Within Step 2 you will define your user profile for up to three different tiers of user populations.

1.How many mailboxes will you deploy in the environment? If deploying a single server environment, this is how many mailboxes you will deploy on this server. If you are deploying multiple servers, then this is how many mailboxes you will deploy in the environment. If you are deploying multiple DAGs, then this is how many mailboxes you will deploy across all of the DAGs. For example, if you choose to deploy 5 servers, and want 3000 mailboxes per server, then enter 15000 here. Or if you plan to deploy 2 DAGs, each with 6 servers, and you entered 24000 total mailboxes, then 12000 mailboxes will be deployed per DAG.
2.What is the solution’s projected growth in terms of number of mailboxes over its lifecycle? Enter in the total percentage by which you believe the number of mailboxes will grow during the solution’s lifecycle. For example, if you believe the solution will increase by 30% over the lifecycle of the design and you are starting out with 1000 mailboxes, then at the end of the lifecycle, the solution will have 1300 mailboxes. The calculator will utilize the projected growth plus the number of mailboxes to ensure that the capacity and performance requirements can be sustained throughout the solution’s lifecycle.
3.How much mail do the users send and receive per day on average? The usage profiles found here are based on the work done around the memory and processor scalability requirements.
4.What is the average message size? For most customers the average message size is around 75KB.
5.What will be the prohibit send & receive mailbox size limit? If you want to adequately control your capacity requirements, you need to set a hard mailbox size limit (prohibit send and receive) for the majority of your users.
6.If deploying a personal archive mailbox, what will be the personal archive quota limit? If you want to adequately control your capacity requirements, you need to set a hard mailbox size limit (prohibit send and receive) for the majority of your users.
7.What is the deleted item retention period? Enter in the deleted item retention period you plan to utilize within the environment. The default retention period is 14 days, however, you should adjust this to match your policy concerning deleted item recovery when enabling Single Item Recovery to eliminate going to backup media to recover deleted items.
8.Are you deploying Single Item Recovery? Single Item Recovery ensures that all deleted and modified items are preserved for the duration of the deleted item retention window. By default in Exchange 2010 RTM, this is not enabled. When enabled, this feature increases the capacity requirements for the mailbox.
9.Will you have calendar version logging enabled? By default, all changes to a calendar item are recorded in the mailbox of a user to keep older versions of meeting items for 120 days and can be used to repair the calendar in the event of an issue. This data is stored in the mailbox’s dumpster folder. When enabled, this feature increases the capacity requirements for the mailbox.
10.Do you want to include an IOPS Multiplication Factor in the prediction or custom I/O profile? The IOPS Multiplication Factor can be used to increase the IOPS/mailbox footprint for mailboxes that require additional I/O (for example, these mailboxes may use third-party mobile devices). The way this value is used is as follows: (IOPS value * Multiplication Factor) + IOPS Value = new IOPS value.
11.Do your Outlook Online Mode clients have versions of Windows Desktop Search older than 4.0 or third-party desktop search engines deployed? The addition of these indexing tools to the online mode clients incur additional read I/O penalties to the mailbox server storage subsystem. Care should be taken when enabling these desktop search engines. Windows Desktop Search 4.0 and later utilizes synchronization protocols that are similar to how Outlook operates in cached mode to index the mailbox contents, and thus has a very minor impact in terms of disk read I/O.
12.Are you planning to use the I/O prediction formula or define your own IOPS profile to design toward? This question asks whether you want to override the calculator in determining the IOPS / mailbox value. By default the calculator will predict the IOPS / mailbox value based on the number of messages per mailbox, and the user memory profile. For some customers that want to design toward a specific I/O profile, this option will not be viable. Therefore, if you want to design toward a specific I/O profile, select No.
13.What is your custom IOPS profile / mailbox? Only enter a value in this field if you selected “No” to the “Predict IOPS Value” question.
14.What will be the database read:write ratio for your custom IOPS profile? Only adjust this value if you selected “No” to the “Predict IOPS Value” parameter. When IOPS prediction is enabled, the calculator will calculate the read:write ratio based on the user profile.
Backup Configuration
Within Step 3 you will define your backup model and your tolerance settings, as well as, choose whether to isolate the transaction logs from the database.

1.What backup methodology will be used to backup the solution? You have several options for a backup methodology, including leveraging a VSS solution (hardware or software based) or leveraging the native data protection features that Exchange provides. The solution you choose will depend on many factors. For example, if you are deploying the mailbox resiliency and single item recovery features, you may be able to forgo a traditional backup architecture in favor of leveraging Exchange as its own backup. Or if you still require a backup (e.g. legal/compliance reasons), then you need to deploy a VSS solution. The type of VSS solution you deploy will depend on your storage architecture. Hardware VSS solutions are available with storage area networks. Software VSS solutions can be leveraged against either storage area networks or direct attached storage architectures. Also, the backup methodology will affect the LUN design; for example, hardware VSS solutions require a LUN architecture that is 2 LUNs / Database.
2.What will be the backup frequency? You can choose Daily Full, Weekly Full with Daily Differential, Weekly Full with Daily Incremental, or Bi-Monthly Full with Daily Incremental. The backup frequency will affect the LUN design and the disk space requirements (e.g. if performing daily differentials, then you need to account for 7 days of log generation in your capacity design).
3.How many times can you operate without log truncation? Select how many times you can survive without a full backup or an incremental backup (the minimum value is 1). For example, if you are a performing weekly full backup and daily differential backups, the only time log truncation occurs is during the full backup. If the full backup fails, then you have to wait an entire week to perform another full backup or perform an emergency full backup. This parameter allows you to ensure that you have enough capacity to not have to perform an immediate full backup. If you are leveraging the native data protection features within Exchange as your backup mechanism, then you should enter 3 here to ensure you have enough capacity to allow for 3 days’ worth of log generation to occur as a result of potential log replication issues.
4.How long can you survive a network outage? When a network outage occurs, log replication cannot occur. As a result, the copy queue length will increase on the source; in addition, log truncation cannot occur on the source. For geographically dispersed DAG deployments, network outages can seriously affect the solution’s usefulness. If the outage is too long, log capacity on the source may become compromised and as result, capacity must be increased or a manual log truncation event must occur. Once that happens, the remote copies must be reseeded. The Network Failure Tolerance parameter ensures there is enough capacity on the log LUNs so that you can survive an excessive network outage.
Storage Configuration
Within Step 4 you will define your storage configuration.

Storage Options

1.Do you want to consider storage designs that leverage JBOD? JBOD storage refers to placing a database and its transaction logs on a single disk without leveraging RAID. In order to deploy this type of storage solution for your mailbox server environment, you must have 3 or more HA database copies and have a LUN architecture that is equal to 1 LUN / Database. If you select yes for this input, the calculator will attempt to design the solution so that it can be deployed on JBOD storage. Please note that other factors may alter the viability of JBOD, however (e.g. deploying a single lagged database copy on the same mailbox servers hosting your HA database copies).
Disk Configuration

1.What are the disk capacities and types you plan to deploy? For each type of LUN (database, log, and restore LUN) you plan to deploy, select the appropriate capacity and disk type model.
Log Replication Configuration
Within Step 5, you will define your hourly log generation rate, the network link, and the network link latency you expect to have within your site resilient architecture.

Log Replication Configuration

1.How many transaction logs are generated for each hour in the day? Enter in the percentage of transaction logs that are generated for each hour in the day by measuring an existing Exchange 2003 or Exchange 2007 server in your environment. If the existing messaging environment is not using Exchange, then evaluate the messaging environment and enter in the rate of change per hour here.
Now you may be wondering how you can collect this data. We’ve written a simple VBS script that will collect all files in a folder and output it to a log file. You can use Task Scheduler to execute this script at certain intervals in the day (e.g. every 15 minutes). Once you have generated the log file for a 24 hour period, you can import it into Excel, massage the data (i.e. remove duplicate entries) and determine how many logs are generated for each hour. If you do this for each storage group, you will be able to determine your log generation rate for each hour in the day. This script is named collectlogs.vbsrename (just rename it to collectlogs.vbs) and you can find it here: Collectlogs VBS script

Network Configuration

1.What type of network link will you be using between the servers? Select the appropriate network link you will be using between the two datacenters.
2.What is the latency on the network link? Enter in the latency (in milliseconds) that exists on the network link.
Role Requirements
This section provides the solution’s I/O, capacity, memory, and CPU requirements.

Calculations Pane
The Calculations Pane performs all the calculations based on the input factors and outputs the key calculations into the Results Pane.

Results Pane
Based on the above input factors the calculator will recommend the following architecture:

Database Configuration

The Database Configuration table provides you with:

•The Number of Databases is the calculated number of databases required to support the mailbox population within a standalone server or DAG.
•The Recommended Number of Mailboxes / Database is the calculated number of mailboxes per database ensuring that the database size does not go above the recommended database size limit.
•The Number of Tier-x Mailboxes / Database provides a breakdown of how many mailboxes from each mailbox tier will be stored within a database.
•The Database Read I/O Percentage defines the percentage of database required IOPS that are read I/Os. This information is required to accurately design the storage subsystem I/O requirements.
•The Available Database Cache / Mailbox value is the amount of database cache memory that is available per mailbox. A large database cache ensures that read I/Os can be reduced.
User Mailbox Configuration

The Mailbox Configuration table provides you with:

•The Number of Mailboxes that you entered in the Input section (this value will include the projected growth).
•The Mailbox Size is the actual mailbox size on disk that factors in the prohibit send/receive limit, the number of messages the user sends/receives per day, the deleted item retention window (with or without calendar version logging and single item recovery enabled), and the average database daily churn per mailbox. It is important to note that the Mailbox size on disk is actually higher than your mailbox size limit; this is to be expected.
•The Transaction Logs Generated / Mailbox value is based on the message profile selected and the average message size and indicates how many transaction logs will be generated per mailbox per day. The log generation numbers per message profile account for:
◦Message size impact. In our analysis of the databases internally we have found that 90% of the database is the attachments and message tables (message bodies and attachments). So if the average message size doubles (from 75 to 150), the worst case scenario would be for the log traffic to increase by 1.9 times. Thereafter, as message size doubles, the impact doubles.
◦Amount of data Sent/received.
◦Database health maintenance operations.
◦Records Management operations
◦Data stored in mailbox that is not a message (tasks, local calendar appts, contacts, etc).
◦Forced log rollover (a mechanism that periodically closes the current transaction log file and creates the next generation).
•The IOPS / Mailbox value is the calculated IOPS / Mailbox value that is based on the number of messages per mailbox, the user memory profile, and desktop search engine choices. If you had chosen to enter in a specific IOPS / mailbox value rather than allowing the calculator determining the value based on the above requirements, then this value will be that custom value.
•The Read:Write ratio / Mailbox value defines the ratio of the mailbox’s IOPS that are read I/Os. This information is required to accurately design the storage subsystem I/O requirements.
Database Copy Instance Configuration

This table highlights how many HA mailbox database copy instances and lagged database copy instances your solution will have within each datacenter for a given DAG.

Environment Configuration

This table identifies how many mailbox servers and lagged copy servers you will deploy in each datacenter.

Server Configuration

The Server Configuration table provides you with the following:

•The Recommended RAM Configuration for the primary datacenter mailbox servers, secondary datacenter mailbox servers, and lagged copy servers. This is the amount of RAM needed to support the number of maximum activated database copies on a given server, in addition to, the number of mailboxes based on their memory profile.
•The Mailbox Role CPU Megacycle Requirements value defines the amount of megacycles the primary datacenter servers must be able to sustain when either all mailbox databases are active or the number of mailbox database copies that are activated based on a single server or double server failure event. For secondary servers hosting HA copies, this value defines the amount of megacycles required to support the activation of all databases after datacenter activation. For lagged copy servers, this value defines the amount of megacycles required to support all of the passive lagged copies.
•The Mailbox Role CPU Utilization value is the expected CPU Utilization for a fully utilized mailbox server role based on the megacycles associated with the user profile and the number of database copies. Depending on the environment, this will either be for a standalone server hosting 100% active databases, or a server participating in a DAG that is dealing with a single or double server failure event (or secondary datacenter activation). It is recommended that standalone servers with only the mailbox role be designed to not exceed 70% utilization during peak period. If deploying multiple roles on the server, then the mailbox role should be designed not to exceed 35%. For solutions leveraging mailbox resiliency, it is recommended that the configuration not exceed 80% utilization after a single or double member server failure when the server only has the mailbox role installed. If deploying multiple roles on the server, then the mailbox role should be designed not to exceed 40%. The CPU utilization value is determined by taking the CPU Megacycle Requirements and dividing it by the total number of megacycles available on the server (which is based on the CPU and number of cores). If the calculator reports “Insufficient Processor Cores” this means the design cannot sustain the load – either you must change the design (number of mailboxes, number of copies, etc) or change the server CPU platform.
•The Recommended Storage Architecture outlines whether the solution should utilize RAID or JBOD for the primary datacenter servers, secondary datacenter servers, and lagged copy servers. JBOD is only considered under the following conditions (this assumes you configured the calculator to consider JBOD):
◦In order to deploy on JBOD in the primary datacenter servers: You need a total of 3 or more HA copies within the DAG. If you are mixing lagged copies on the same server that is hosting your HA copies (i.e. not using dedicated lagged copy servers), then you need at least 2 lagged copies.
◦For the secondary datacenter servers to use JBOD: You should have at least 2 HA copies in secondary datacenter. That way loss of a copy in the secondary datacenter doesn’t result in requiring a reseed across the WAN or loss of data (in the datacenter activation case). If you are mixing lagged copies on the same server that is hosting your HA copies (i.e. not using dedicated lagged copy servers), then you need at least 2 lagged copies.
◦For dedicated lagged copy servers: You should have at least 2 lagged copies within a datacenter in order to use JBOD. Otherwise loss of disk results in loss of your lagged copy (and whatever protection mechanism that was providing).
Database Copy Configuration

The Database Copy Configuration table provides you with:

•The total number of DAGs being deployed in the solution.
•The total number of mailboxes being deployed within each DAG and within the environment.
•The number of database copies being deployed within each server and the total number of database copies within the DAG.
Active Database Configuration

The Active Database Configuration table provides you with:

•The Number of Active Databases (Normal Run Time) value defines the number of active databases hosted on each server when there are no server outages. Unlike Exchange 2007, Exchange 2010 is no longer bound by an active/passive high availability model. Instead, each server within a DAG can host active mailbox database copies. The calculator distributes the number of unique databases across the primary datacenter servers within the DAG, ensuring an equal distribution of mailbox database copies are activated on each server. In addition, you can also see the total number of mailboxes that are accessible on each server as a result of the activated database copies.
•The Number of Active Databases (After First Server Failure) value defines the number of active databases hosted on each server when there is a single server outage. As a result of the single server outage, the database copies that were activated on the failed server are equally redistributed across all remaining server nodes. In addition, you can also see the total number of mailboxes that are accessible on each server as a result of the activated database copies.
•The Number of Active Databases (After Double Server Failure) value is populated when you have at least 3 HA mailbox copies and at least 4 mailbox servers within your design. It defines the number of active databases hosted on each server when there are two server outages. As a result of the double server outage, the database copies that were activated on the failed servers are equally redistributed across all remaining server nodes In addition, you can also see the total number of mailboxes that are accessible on each server as a result of the activated database copies.
•The Number of Active Databases (Secondary Datacenter Activation) value defines the number of database copies that are activated on each server within the second datacenter in a site resilient scenario. In addition, you can also see the total number of mailboxes that are accessible on this server as a result of the activated database copies.
Transaction Log Requirements

The Transaction Log Requirements table provides you with:

•The User Transaction Logs Generated / Day indicates how many transaction logs will be generated during the day for each active database, each server, within the DAG, and within the environment.
•The Average Mailbox Move Transaction Logs Generated / Day indicates how many transaction logs will be generated during the day for active database, each server, within a DAG, and within the environment. This number is an assumption and assumes that an equal percentage of mailboxes will be moved each day, as opposed to moving all mailboxes on the same day.
•The Average Transaction Logs Generated / Day is the total number of transaction logs that are generated per day for active database, each server, within a DAG, and within the environment (includes user generated logs and mailbox move generated logs).
Disk Space & Performance Requirements

The Disk Space & Performance Requirements table provides you with:

•The Database Space Required is the amount of space required to support each database and its corresponding copies. This value is derived from the mailbox size on disk, the data overhead factor, whether a dedicated restore LUN is available. This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
•The Log Space Required is the amount of space required to support each database log stream and the corresponding copies. This value takes into account the number of mailboxes moved per week (assumes worst case and that all mailboxes are moved on the same day), the type of backup frequency in use, the number of days that can be tolerated without log truncation and the number of transaction logs generated per day. This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
•The Database LUN Space Required is the LUN size required to support the database (and potentially its log stream). This calculation takes the total disk space required for the database and adds to it the size of a database plus 110% (if a dedicated restore LUN does not exist) for offline maintenance operations, an additional 10% of the database size for content indexing (if enabled), and includes an amount of free space to ensure the LUN is not 100% utilized (based on LUN Free Space Percentage). This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
•The Log LUN Space Required is the LUN size required to support the databases log stream. This field lists the amount of space required to support the transaction logs for a given set of databases and includes an amount of free space to ensure the LUN is not 100% utilized (based on LUN Free Space Percentage). This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
•The Restore LUN Space Required is the amount of space needed to support a restore LUN if the option was selected in the Input Factor section; this will include space for up to 7 databases and 7 transaction log sets. Each server will be provisioned with a restore LUN. This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
•The Total Required Database IOPS is the amount of read and write host I/O the database disk set must sustain during peak load (this does not factor in any RAID penalties). This row also shows you the IOPS requirements for each server (based on the total number of database copies), each DAG, and within the environment
•The Total Required Log IOPS is the amount of read and write host I/O that will occur against the transaction log disk set. This row also shows you the IOPS requirements for each server (based on the total number of database copies), each DAG, and within the environment.
Special Notes

The Special Notes table will provide you with additional information about your design:

•When to use GPT disks (when a LUN size is greater than 2TB).
•How to configure your mailbox server to control the maximum number of mailbox databases that can be activated.
•Whether the design parameters you have chosen have resulted in more mailbox servers being required to support the design than what a DAG can support.
The LUN Requirements section is really a continuation of the Storage Requirements section. It outlines what we believe is the appropriate LUN design based on the input factors and the analysis performed in the previous section.

Note: The term LUN utilized in the calculator refers only the representation of the disk that is exposed to the host operating system. It does not define the disk configuration.

LUN Design
The LUN Design highlights the LUN architecture chosen for this server solution. The architecture is derived from the backup type, backup frequency, and high availability architecture that were chosen in the Storage Requirements section.

There are three types of LUN architecture that can be leveraged within Exchange 2010:

•1 LUN / Database
•2 LUNs / Database
•2 LUNs / Backup Set
1 LUN / Database

A single LUN per Database architecture means that both the database and its corresponding log files are placed on the same LUN. In order to deploy a LUN architecture that only utilizes a single LUN per database, you must have a Database Availability Group that has 2 or more copies and not be utilizing a hardware based VSS solution.

Some of the benefits of this strategy include:

•Simplified storage administration. Fewer LUNs to manage.
•Potentially reduce the number of backup jobs.
•Flexibility to isolate the performance between Databases when not sharing spindles between LUNs.
Some of the concerns with this strategy include:

•Limits the ability to take hardware based VSS backup and restores (e.g., clone snapshots). See Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 for more VSS details.
2 LUNs / Database

With Exchange 2010, in the maximum case of 100 Databases, the number of LUNs you provision will depend upon your backup strategy. If your recovery time objective (RTO) is very small, or if you use VSS clones for fast recovery, it may be best to place each Database on its own transaction log LUN and database LUN. Because doing this will exceed the number of available drive letters, volume mount points must be used.

Some of the benefits of this strategy include:

•Enables hardware-based VSS at a database level, providing single database backup and restore.
•Flexibility to isolate the performance between databases when not sharing spindles between LUNs.
•Increased reliability. A capacity or corruption problem on a single LUN will only impact one database. This is an important consideration when you are not leveraging the built-in mailbox resiliency features.
Some of the concerns with this strategy include:

•100 databases requires 200 LUNs which could exceed some storage array maximums.
•A separate LUN for each database causes more LUNs per server increasing the administrative costs and complexity.
2 LUNs / Backup Set

A backup set is the number of databases that are fully backed up in a night. A solution that performs a full backup on 1/7th of the databases nightly (i.e. using a weekly or bi-monthly full backup with daily incrementals or differentials) can reduce complexity by placing all of the databases to be backed up on the same log and database LUN. This can reduce the number of LUNs on the server.

Some of the benefits of this strategy include:

•Simplified storage administration. Fewer LUNs to manage.
•Potentially reduce the number of backup jobs.
Some of the concerns with this strategy include:

•Limits the ability to take hardware based VSS backup and restores (e.g., clone snapshots). See Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 for more VSS details.
•A capacity or corruption problem on a single LUN could impact more than one Database.
Calculations Pane
The Calculations Pane performs all the calculations based on the input factors and outputs the key calculations into the Results Pane.

Results Pane
Based on the above input factors the calculator will recommend the following architecture:

LUN Design

The LUN Design table highlights the recommended LUN architecture.

LUN Configuration

The LUN Configuration table highlights the number of databases that should be placed on a single LUN. This is derived from LUN Architecture model.

This section also documents how many LUNs will be required for the entire solution, broken out by Database and Log sets, and the number of restore LUNs per server.

Database Configuration

The Database Configuration table outlines the number of databases (or copies) per server, the number of mailboxes per database, the size of each database, and the transaction log size required for each database.

Database and Log LUN Design

The database and log LUN Design table outlines the physical LUN layout and follows the recommended number of databases per LUN approach based on the LUN Architecture model. It also documents the LUN size required to support layout (this is where we factor in the additional capacity for content indexing, the LUN Free Space Percentage, and whether you are using a Restore LUN), as well as the transaction log LUN.

Important: The DB and Log LUN Design Table identify databases by a unique number. However, databases copies are distributed across the servers, and thus, these numbers hold no significance and are used solely as an example to show a server’s LUN layout.

Backup Requirements
The Backup Requirements section is really a continuation of the Role Requirements section. It outlines what we believe is the appropriate backup design based on the input factors and the analysis performed in the previous sections.

Backup Configuration

The Backup Configuration table outlines the number of databases that will be placed within a single LUN and the type of backup methodology and frequency in which the backups will occur.

Backup Frequency Configuration

The Backup Frequency Configuration section will provide you with an outline on how you should perform the backups for each server, utilizing either a daily full backup or weekly or bi-monthly full backup frequency.

Log Replication Requirements
The Log Replication Requirements section is another continuation of the Role Requirements section. It outlines what we believe is the throughput required to replicate the transaction logs to each target database copy in the secondary datacenter.

Peak Log and Content Index Replication Throughput Requirements

The Peak Log and Content Index Replication Throughput Requirements table provides you with:

•The Peak Log & Content Index Throughput Required / Database is the total throughput required for a single log stream and content index. This value is based on the peak log generation hour.
•The Peak Log & Content Index Throughput Required Between Datacenters / DAG is the total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for the database availability group.
•The Peak Log & Content Index Throughput Required Between Datacenters / Environment is the total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for all database availability groups.
RPO Log and Content Index Replication Throughput Requirements

In terms of log replication, RPO means how behind can you get in log shipping? The lower the RPO (a value of 0 or 1 essentially means you want to only lose the open log file), the higher the bandwidth you need because you cannot get behind in log replication. The higher the RPO (approaching 24) less bandwidth is needed as you are expecting to be behind (up to x hours) in log replication and to catch up at some point in the day.

The RPO Log and Content Index Replication Throughput Requirements table provides you with:

•The RPO Log & Content Index Throughput Required / Database is the required throughput necessary to replicate the transaction logs and content index based on the RPO to the mailbox servers that are located within the secondary datacenter per database.
•The RPO Log & Content Index Throughput Required Between Datacenters / DAG is the RPO total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for the database availability group.
•The RPO Log & Content Index Throughput Required Between Datacenters / Environment is the RPO total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for all database availability groups.
Chosen Network Link Suitability

The Chosen Network Link Suitability table will dictate whether the chosen network link has sufficient capacity to sustain the peak replication throughput requirements and/or the RPO replication throughput requirements. If the network link cannot sustain the log replication traffic, then you will need to either upgrade the network link to the recommended network link throughput, or adjust the design appropriately.

Recommended Network Link

The Recommended Network Link table recommends an appropriate network link if the chosen network link does not have sufficient capacity to sustain log replication for solution for both the peak and RPO throughput requirements.

Note: The Network Link recommendations do not take into account database seeding or any other data that may also utilize the link.

Storage Design
The Storage Design worksheet is designed to take the data collected from the Input worksheet and Storage Requirements worksheet and help you determine the number of physical disks needed to support the databases, transaction logs, and Restore LUN configurations.

Storage Design Input Factors
In order to determine the physical disk requirements, you must enter in some basic information about your storage solution.

RAID Parity Configuration

For the RAID Parity Configuration table you need to select the type of RAID building block your storage solution utilizes. For example, some storage vendors build the underlying storage in sets of data+parity (d+p) groups. A RAID-5 3+1 configuration means that 3 disks will be used for capacity and 1 disk will be used for parity, even though parity is distributed across all the disks. So if you had a capacity requirement that would utilize 15 disks, then you would need to deploy 5 3+1 groups to build that RAID-5 array.

•RAID-1/0 supports 1d+1p, 2d+2p, and 4d+4p groupings
•RAID-5 supports 3d+1p through 20d+1p groupings (though storage solutions could support more than that).
•RAID-6 supports 6d+2p groupings.
RAID Rebuild Overhead

When a disk is lost, the disk needs to be replaced and rebuilt. During this time, the performance of the RAID group is affected. This impact as a result can affect user actions. Therefore, to ensure that RAID rebuilds do not affect the overall performance of the mailbox server, Microsoft recommends that you should ensure sufficient overhead is provisioned into the performance calculations when designing for RAID parity. Most RAID-1/0 implementations will suffer a 25% performance penalty during a rebuild. Most RAID-5 and RAID-6 implementations will suffer a 50% performance penalty during a rebuild.

The calculator defaults with the following as Microsoft recommendations, but they are adjustable:

•For RAID-1/0 implementations, ensure that you factor in an additional 35% performance overhead.
•For RAID-5/RAID-6 implementations, ensure that you factor in an additional 100% performance overhead.
In addition, you should consult with your storage vendor to determine the appropriate RAID rebuild penalty.

RAID Configuration

By default, for RAID storage solutions, the calculator will recommend either RAID-1/0 or RAID-5 by evaluating capacity and I/O factors and determining which configuration utilizes the least amount of disks while satisfying the requirements. If you would like to override this and force the calculator to utilize a particular RAID configuration (e.g., RAID-0 or RAID-6), select “Yes” to this option and then select the appropriate RAID configuration in the cell labeled “Desired RAID Configuration.”

By default the calculator utilizes RAID-5 for the Restore LUN. However, you can define a specific RAID configuration for the Restore LUN.

Note: The calculator prevents the use of RAID-5 or RAID-6 with 5.2K, 5.4K, 5.9K and 7.2K disk types, due to performance implications.

Calculations Pane
The Calculations Pane performs all the calculations based on the input factors and outputs the key calculations into the Results Pane.

Results Pane
The Storage Design Results section outputs the recommended configuration for the solution. The recommendations made are for implementing the solution potentially on RAID and JBOD storage.

RAID Storage Architecture

The Storage Architecture Table recommends which servers (primary datacenter servers, secondary datacenter servers, or lagged copy servers) should be deployed on RAID storage.

The Recommended Storage Architecture / Server table recommends the optimum RAID configuration and number of disks for each LUN (database, log and restore LUN) for each mailbox server ensuring that performance and capacity requirements are met within the design.

The Storage Configuration table will output the total number of disks required for each mailbox server that requires RAID storage, as well as, identify the total number of disks requiring RAID storage in each datacenter.

JBOD Storage Architecture

The Storage Architecture Table recommends which servers (primary datacenter servers, secondary datacenter servers, or lagged copy servers) should be deployed on JBOD storage.

The Recommended Storage Architecture / Server table recommends the optimum JBOD configuration and number of disks for each LUN (database, log and restore LUN) for each mailbox server ensuring that performance and capacity requirements are met within the design.

The Storage Configuration table will output the total number of disks required for each mailbox server that requires JBOD storage, as well as, identify the total number of disks requiring JBOD storage in each datacenter.

Total Disks Required

The Disk Requirements table outlines the total number of RAID and JBOD disks that are required for each DAG and within the environment.

Conclusion
Hopefully you will find this calculator invaluable in helping to determine your mailbox server role requirements for Exchange 2010 mailbox servers. If you have any questions or suggestions, please email strgcalc AT microsoft DOT com.

For the calculator itself, please see the following link:

Exchange 2010 Mailbox Server Role Requirements Calculator

Forefront Protection for Exchange – Antispam Video HERE

Alex Nikolayev, a program manager on the Forefront Server Protection team, was recently interviewed on video about the new antispam filters available in Forefront Protection 2010 for Exchange Server (FPE). Alex gives an excellent overview of the antispam filters in FPE and how they are integrated into a seamless antispam solution for protecting Exchange servers from unwanted spam e-mail.

You can watch the video at: http://edge.technet.com/Media/Forefront-Protection-for-Exchange-FPE-Anti-Spam/

Exchange 2010 perf counters and thresholds to watch

“Seeing that many will be finding a copy of Exchange 2010 under the tree soon (…right?), we wanted to let you know that we have been working to create the performance counter guidance for Exchange 2010 as we have for Exchange 2007 (see Monitoring Without System Center Operations Manager).

We are planning to release the official Exchange 2010 version of such document within a month or two. But – for those of you that just can’t wait, and will be / are installing Exchange 2010 now – you can find a preview of our perf counter guidance in the following Excel spreadsheet:

http://msexchangeteam.com/files/12/attachments/entry453578.aspx

We do not expect many changes to this between now and official release, but if you have any kind of feedback on it – we’d love to hear it!

What’s New in Exchange Server 2010

Microsoft Exchange Server 2010 brings a new and rich set of technologies, features, and services to the Exchange Server product line. This topic includes a list of the new features and functionality that are included in Exchange 2010. The list isn’t comprehensive, but it provides important information to use when you’re planning, deploying, and administering your Exchange 2010 organization. This topic also includes information about some of the limitations of this release and features from Exchange Server 2007 that have been removed.

New Rights-Protected E-Mail Functionality with Active Directory RMS

The following is a list of new rights-protected e-mail functionality with Active Directory Rights Management Services (AD RMS) that has been included in Exchange 2010:

•Transport rules to apply AD RMS protection to messages based on conditions.
•Persistent protection of attachments in rights-protected messages.
•Support for AD RMS templates.
•An Internet confidential AD RMS template for protection over the Internet.
•AD RMS protection for Unified Messaging voice mail messages
New Transport and Routing Functionality

The following is a list of new transport and routing functionality that has been included in Exchange 2010:

•Cross-premises mail routing An organization can choose to outsource some of their mailboxes to a hosted solution while maintaining their on-premises deployment. For example, a university can choose to host the mailboxes for all faculty and staff in their on-premises deployment and use a hosted solution for student mailboxes. Exchange 2010 allows routing of messages between the on-premises and hosted mailboxes.
•Enhanced disclaimers Exchange 2010 lets you add disclaimers that can include hyperlinks, images, and HTML-formatted text. You can also insert Active Directory attributes that are substituted for the sender’s attributes when a disclaimer rule is triggered.
•Transport rules integration with AD RMS Exchange 2010 gives you the ability to create rules that require AD RMS protection based on keywords or patterns.
•Moderated Transport Exchange 2010 provides an approval workflow for sending messages to recipients. When you configure a recipient for moderation, all messages sent to that recipient must go through an approval process.
•Shadow redundancy Messages that are submitted to an Exchange 2010 Hub Transport server are stored in the transport database until the next hop reports successful delivery of the message. If the next hop doesn’t report successful delivery and it fails, the message is resubmitted for delivery.
•Transport Dumpster truncation based on log copy status When messages that are in the dumpster are replicated to all mailbox databases, they’re removed from the dumpster.
•Latency SLA management Exchange 2010 Transport lets you measure service levels delivered relative to your service level agreement (SLA) goals. Exchange 2010 gives you the ability to measure latencies for each hop, as well as end-to-end latency.
•Transport database improvements Performance improvements in the Transport database result in reduced database I/O per second (IOPS) per message, which increases message throughput.
New Permissions Functionality

In Exchange 2010, Role Based Access Control (RBAC) has replaced the permissions model that was used in Exchange 2007. RBAC lets you define extremely broad or extremely precise permissions models based on the roles of you administrators and users.

For administrators and specialist users, management role groups define what these users can manage in the organization. Role groups associate role group members to a set of management roles that define what the members can do. By adding or removing users as members of role groups, and adding or removing role assignments to or from a role group, you can control what aspects of the organization the members can manage.

For end users, management role assignment policies define what users can configure on their own mailbox. Assignment policies are applied to every mailbox either by default or manually, and enable you to control whether users can change their personal information, contact information, distribution group membership, and so on.

Both group groups and role assignment policies are assigned management roles. Management roles control access to the cmdlets and parameters required to perform a task. For example, if a cmdlet exists on a management role, and that role is assigned to a role group, the members of that role group can then use that cmdlet.

For more information about RBAC, see Overview of Permissions.

New High Availability Functionality

Exchange 2010 integrates high availability into the core architecture of Microsoft Exchange to enable customers of all sizes and in all segments to be able to economically deploy a messaging continuity service in their organization.

Exchange 2010 includes many changes to its core architecture. The following features in Exchange 2007 and Exchange 2007 Service Pack 1 (SP1) no longer exist in Exchange 2010:

•Local continuous replication (LCR)
•Single copy clusters (SCC)
In addition to these features, the concept of a clustered mailbox server no longer exists in Exchange 2010. Two other features, cluster continuous replication (CCR) and standby continuous replication (SCR), have been merged and renamed as a set of new features in Exchange 2010: incremental deployment, continuous mailbox availability, database mobility, database copies, and database availability groups.

For more information about Exchange 2010 high availability features, see New High Availability and Site Resilience Functionality.

New Messaging Policy and Compliance Features

Exchange 2010 compliance features make retention independent of users’ mailbox management and filing habits, and ensure retention policies are applied continuously. The following is a list of new messaging and compliance features that have been included in Exchange 2010:

•New interface for applying retention policies
•Auto tagging for retention policies
•Mailbox search features for cross-mailbox search with AQS support
•New transport rules predicates and actions
For more information, see New Messaging Policy and Compliance Functionality.

New Outlook Web App Features

The following is a list of new features in Outlook Web App in Exchange 2010.

•Favorites in the Navigation Pane
•Search folders
•Message filtering
•The ability to set categories in the message list
•Options in the Web management interface for Outlook Web App
•A side-by-side view for calendars
•Multi-client language support
•The ability to attach messages to messages
•Expanded right-click capabilities
•Integration with Office Communicator, including presence, chat, and a contact list
•Conversation view
•The ability to send and receive text (SMS) messages from Outlook Web App
•Outlook Web App mailbox policies
New Unified Messaging Features

The following is a list of new Unified Messaging features that have been included in Exchange 2010:

•Call answering rules
•Additional language support including in Outlook Voice Access
•Enhancements to name lookup from caller ID
•Voice mail preview
•Messaging Waiting Indicator
•Missed call and voice mail notifications using text messaging (SMS)
•Protected voice mail
•Incoming fax support
•Addressing to Groups (Personal Distribution Lists) support
•Built-in Unified Messaging administrative roles
For more information about the new Unified Messaging functionality and new voice mail features, see New Unified Messaging Functionality and Voice Mail Features.

Web Management Interface

The following is a list of the features available in the new Web management interface for Outlook Web App.

•Text messaging (SMS) integration
•Voice messaging integration
•Mailbox Search
•Additional proxy addresses for mailboxes
•Moderation and approval for distribution list submission
New Exchange Store and Mailbox Database Functionality

The following is a list of core store functionality that is included or has been changed in Exchange 2010:

•Storage groups are deprecated.
•Mailbox databases are no longer connected to the server object.
•Extensible Storage Engine (ESE) has many improvements for high availability, performance, and database mobility.
•The Exchange Store schema has been flattened.
•Enhanced reporting with Public Folders
For more information about these changes, see New Exchange Core Store Functionality.

New Mailbox and Recipient Functionality

The following is a list of the new mailbox and recipient functionality that is included or has been changed in Exchange 2010.

•Users can share information such as calendar free/busy and contacts with users who reside in a different organization
•Scheduling and configuring resource mailbox calendar processing has been improved
•You can now move a mailbox while the end user is still accessing it
•New parameters have been added to the distribution group cmdlets to allow users to create and manage their own distribution groups in Outlook Web App and Outlook 2010
•You can manage folder-level permissions for all folders within a user’s mailbox
•Bulk recipient management has been expanded to allow you to bulk manage recipient properties
•You can send mail to recipients from the EMC
New Administration Functionality in the Exchange Management Console

The following is a list of the new core Exchange Management Console (EMC) features that have been included in Exchange 2010. The core EMC refers to new functionality that affects how you use the Exchange Management Console, not how you use specific features:

•Customer Experience Improvement Program (CEIP)
•Organizational Health
•Community and Resources
•Command logging
•Property dialog command exposure
•UI is RBAC aware
For more information about these features, see New Administrative Functionality in the Exchange Management Console.

New Administration Functionality in the Exchange Management Shell

The following is a list of features available in the new Exchange Management Shell:

•Remote administration With the new Shell, you can connect to remote Exchange 2010 servers across the network with only the Windows Management Framework installed, which includes Windows PowerShell. For more information, see Overview of Exchange Management Shell.
•RBAC integration The Shell works with RBAC to give you and your users access only to the cmdlets and parameters they’re allowed to use. If your permissions don’t allow you to configure a certain feature, you aren’t given access to the cmdlets, parameters, or both, that manage that feature. For more information, see Understanding Role Based Access Control.
•Administrator audit logging Actions that result in the modification of Exchange organization configuration and other object properties in the Exchange Management Console, the Web management interface, and the Shell can now be logged for later review. For more information, see Overview of Administrator Audit Logging.
•Improved multiple-valued property syntax Instead of running multiple commands to add and remove values from a single property, you can now add and remove values with a single command line. For more information, see Multi-Valued Properties.