Planning the Exchange Server 2010 Infrastructure

Objective 1.3: Design the Mailbox Server Role

Exchange Mailbox servers are big message storage servers. Out of all of the Exchange roles that you can deploy, the Exchange Mailbox server will utilize the most disk space. Most IT Professionals have heard of Moore’s Law, which suggests that the number of transistors that can be placed on an integrated circuit doubles every two years. Although the growth isn’t nearly as rapid, the amount of information transmitted by email across the world also doubles approximately every four years. This increase in information is reflected in most people’s inboxes, and it is not unheard of in 2011 for some Exchange deployments to allow 50 GB mailbox quotas. This has become necessary because not only do people use Outlook to store email messages, but Outlook and Exchange mailboxes are also often used as informal document archives. In this objective you’ll learn about planning database sizes, how to determine what sort of performance mailbox server storage will require, how to implement a multi-forest mailbox deployment, how to design a public folder infrastructure, and how to develop recipient and distribution group policies. In Chapter 2 you’ll learn how to put these design decisions into operation.

Plan Database Sizing

Exchange Server 2010 mailboxes and public folders are stored in databases hosted on Exchange mailbox servers. Databases are stored in Extensible Storage Engine format. Each database has an associated set of transaction logs that record changes made to the database. Transaction logs are primarily useful during database recovery and you will learn more about using them in this manner in Chapter 4.

By default, each database and its associated transaction logs are stored in the same folder. These folders are unique to each database, with each database’s folder typically stored under the C:\Program Files\Microsoft\Exchange\Server\v14\Mailbox folder as shown in Figure 1-7. If you are deploying Exchange on standard disks that do not use RAID striping, you should consider placing the mailbox database and the transaction logs on separate disks. This has the benefit of improving performance and simplifying recovery. You have less reason to do this when you are using RAID striping because disk read and write operations are already optimized through the use of multiple drives and controllers.

The Standard edition of Exchange 2010 allows five databases per Mailbox server. One of these databases can be a public folder database. The Enterprise edition of Exchange 2010 allows 100 databases per Mailbox server. Only one of these databases can be a public folder database.

The following factors influence your plans when determining the size of mailbox databases:

• How many users will the mailbox database need to support?

• How large can mailbox databases grow? Even though most people won’t reach their mailbox quota, you will need to plan the mailbox database size on the assumption that every mailbox will reach quota.

• What deleted item retention settings will you use? Deleted items consume database space in the same way that undeleted items do.

• Service Level Agreement (SLAs). Mailbox database size impacts recovery time, with larger mailbox databases meaning longer backup windows and longer recovery times. Backup and recovery can be more important to limiting mailbox database size than storage capacity.

The default database size limit for Exchange 2010 Service Pack 1 Standard edition is 1024 GB. If a mailbox database grows beyond this limit, the database automatically dismounts. You can modify the size limit of a database on the standard edition of Exchange 2010 by editing the registry. You can increase the database size limit to approximately 16 terabytes.

Although it is possible for mailbox databases on the Enterprise edition of Exchange 2010 to grow to 16 terabytes in size, Microsoft recommends that you keep mailbox databases to approximately 2 terabytes in size—where that size is 120 percent of calculated maximum database size—if you are using a high-availability configuration. For example, if every user has a 5-GB mailbox quota and you use the 120 percent of calculated maximum database size rule, you’d be able to provision just over 340 mailboxes per mailbox database using the 2-terabyte limit. If you aren’t using a high-availability configuration, the recommended maximum database size is approximately 200 GB. This figure was arrived at based on backup and recovery times and the requirements of normal SLAs. Using Database Availability Groups gives you more flexibility in terms of recovery, allowing a substantially higher database size limit.

Determining mailbox database size is made more complicated by issues such as white space and database recoverable items. While an item deleted from a mailbox doesn’t count towards a user’s quota, the mailbox database still stores these items until the deleted item retention period expires. The amount of data consumed in this manner depends on the deleted item retention window. Microsoft provides the following formula for estimating how much storage is consumed in this manner:

• Dumpster Size = (Daily Incoming/Outgoing Mail × Average Message Size × Deleted Item Retention Window) + (Mailbox Quota Size × 0.012) + (Mailbox Quota Size × 0.03)

When planning mailbox database storage requirements, you must also consider the content index. Each mailbox database has a content index that allows users to be able to quickly search through mail items. This index usually consumes approximately 10 percent of a mailbox database’s size.

Plan Log Sizing

Transaction logs record every transaction performed by the Exchange database engine. Exchange writes each transaction to the log first and then those transactions are applied to the mailbox database later. Exchange Server 2010 transaction log files are 1 MB in size. Microsoft provides guidance that allows you to estimate the number of transaction logs that will be generated per mailbox per day assuming an average message that is 75 KB in size. A ballpark estimate is that for every five messages, Exchange generates one 1 MB transaction log file. Although you can enable circular logging, which overwrites transaction logs, Microsoft recommends you instead truncate transaction logs through regular backup. Products such as System Center Data Protection Manager 2012 allow you to perform backups every 15 minutes, truncating transaction logs regularly and minimizing the amount of transaction log data stored on the Exchange mailbox server.

Storage Performance Requirements

When planning storage for a mailbox server, you not only need to ensure that you dedicate enough space for the mailbox server, but you also need to ensure that the storage that you do use performs well enough to avoid being a bottleneck in the Exchange server’s performance.

The basic principles of storage performance for mailbox servers are as follows:

• A larger number of users increases disk utilization.

• Users who send and receive more messages increase disk utilization.

Mailbox database performance is enhanced substantially through the use of server RAM for database caching. A user who sends and receives fifty 75-KB messages per day will utilize approximately 3 MB of RAM in the database cache. This user will also generate approximately 0.06 mailbox database I/O operations per second. A user who sends two hundred 75-KB messages per day will utilize approximately 12 MB of RAM in the database cache. This user will generate approximately 0.24 database I/O operations per second. When considering your mailbox server storage performance requirements, do not underestimate the impact of RAM. If the mailbox server has less RAM than is required to service each user’s database cache needs, the number of database I/O operations per second will increase, reducing mailbox database performance.

The design of Exchange Server 2010 optimizes mailbox database I/O for standard hard disk drives. This means that you don’t need specialized storage equipment to run an Exchange Mailbox server and that you’ll have good performance even if you use “Just a Bunch of Disks” (JBOD), a technical way of describing standard, consumer-grade, hard-disk drives. Depending on your organization’s requirements, you might choose to forego RAID 10 disk arrays in your storage design, relying less on redundant local storage and more on redundancy technologies such as Database Availability Groups. Of course it is always better to have a greater level of redundancy in any design. As any systems administrator knows, if something can go wrong, it will go wrong—usually at 4:50 P.M. on a Friday afternoon, right before you are about to go home for the weekend.

You can use the Exchange 2010 Mailbox Server Role Requirements Calculator, which you can download from Microsoft’s website, to determine the precise storage and performance profile that will be necessary given your organization’s needs. The tool is a spreadsheet that allows you to input information about your intended design. In general, though, Exchange 2010 is designed so that a 7200-RPM SATA disk will be easily able to handle the read and write traffic generated by a 2-terabyte mailbox database that hosts mailboxes that send and receive several hundred messages per day.

When you are considering how to configure the disks used to host mailbox database and transaction logs, Microsoft recommends the following volume configurations:

• Use GUID partition table (GPT) rather than MBR in volume configuration. MBR is supported, but GPT is recommended.

• Only the NTFS file system is supported.

• Use an NTFS allocation unit of 64 KB for the volumes that host database files and log files.

• NTFS compression is not supported for database or log files.

• NTFS Encrypting File System is not supported for database or log files.

• BitLocker volume encryption is supported for volumes that host database files and log files.

Exchange supports the following storage architectures:

• Direct-attached storage (DAS) Directly attached to the server, without a storage network. Includes SCSI and SATA drives.

• Storage Area Network (SAN) Exchange supports the storage of mailbox databases on both iSCSI and Fibre Channel SANs.

• Solid-state drive (SSD) flash disk Exchange can be deployed on a solid-state (SSD) flash disk.

Windows Server 2008 and Windows Server 2008 R2 support 512-byte sector disks. Only Windows Server 2008 R2 with Service Pack 1 and Exchange Server 2010 with Service Pack 1 support 512e disks. All copies of the database must reside on the same disk type, you can’t have some copies of a database stored on a 512-byte sector disk and other copies stored on 512e. If your organization is not using a UPS, you should disable physical disk-write caching.

Best practice for hosting mailbox database or log data is RAID 1 or RAID 10. Microsoft recommends that when you use RAID 5, you have a maximum of seven disks in the array. If you are using RAID 6, you should enable high-priority scrubbing and surface scanning.

Mailboxes in Multiple-Forest Topologies

As you learned earlier, if your organization uses more than one forest, you can deploy Exchange in either the cross-forest topology or the resource-forest topology. When you deploy Exchange in a cross-forest topology, each Active Directory forest has its own Exchange organization and hosts its own Exchange mailboxes. When you use a resource-forest topology, one forest hosts the Exchange organization and the other forest hosts the user accounts used by recipients. You can give these users in a resource-forest topology mailbox access by using linked mailboxes.

Linked mailboxes are mailboxes in the resource forest that are associated with an account hosted in a trusted Active Directory forest. The accounts in the Exchange forest are disabled for logon. The disabled user account in the Exchange forest is then associated with an enabled user account in the accounts forest. You can create the disabled account separately, or have it created automatically as a part of the linked mailbox creation process.

To create a linked mailbox using EMC, perform the following general steps:

1. Navigate to Recipient Configuration console tree and click New Mailbox in the Action pane.

2. On the Introduction page, select Linked Mailbox and click Next.

3. On the User Type page, click New User and then click Next. This will allow you to create the dummy user account in the resource forest.

4. On the User Information page, enter the details of the dummy user account. You can choose a special Organizational Unit for the account. The password that you specify on this page will be used to access the mailbox even though the user account cannot be used for computer logon in the resource forest. This password does not have to match the password of the user account in the account forest.

5. On the Mailbox Settings pace, specify the mailbox database, retention policy, and Exchange ActiveSync mailbox policy that will be associated with the account.

6. On the Master Account page, shown in Figure 1-8, click Browse to specify the trusted domain, specify an account to access the linked domain controller, specify a domain controller in the trusted domain, and specify the account in the account domain that will be the master account for the linked mailbox. Click Next, New, and then Finish to complete the creation of the linked mailbox.

   

   Figure 1-8 Linked mailbox master account

You can also create a linked mailbox from EMS by using the New-Mailbox cmdlet with the LinkedMasterAccount parameter. For example, to create a linked account for David Ahs in the local adatum.com forest when a trust has been established with the WingTipToys forest, use the following command:

New-Mailbox -Database "MBX-DB1" -Name "David Ahs" -LinkedDomainController
"DC01wingtiptoys" -LinkedMasterAccount wingtiptoys\david -OrganizationalUnit Users
-UserPrincipalName david@adatum.com -LinkedCredential:(Get-Credential wingtiptoys\Admin01)

A mail forest contact is a mail contact that is associated with a recipient object in another forest. Mail forests are present in cross-forest topology deployments and are usually created through Microsoft Identity Integration Server (MIIS) synchronization. Mail forest contacts can only be created through synchronization with other forests in a cross-forest deployment—you cannot modify or remove mail forest contacts using EMC or EMS.

Recipient Policies

Recipient policies, also known as email address policies, allow you to configure email address formats for your organization. A single email address policy can define multiple address format variations. Email address policies allow you to generate addresses based on a person’s first name, last name, middle initial, and accepted domains. You can only use accepted domains as the email domain suffix in an email address policy. You learned about accepted domains earlier in this chapter. The default email address policy for an organization involves the user’s alias, the at symbol (@), and the default accepted domain.

You can use an email address policy to turn user name data into a variety of email addresses. By applying a policy, you could configure Exchange so that Kim Akers is given the following email addresses:

• k.akers@contoso.com

• kim.akers@contoso.com

• akers.kim@contoso.com

• akers.k@fabrikam.com

Although an email address policy can provision users with email addresses from multiple email domains, it’s probably better to use separate policies when dealing with different email domains, which keeps things less complicated and more manageable. To create an email address policy using EMC, perform the following general steps:

1. Click the Organization Configuration\Hub Transport node and then click New E-mail Address Policy in the Actions pane.

2. On the Introduction page of the New E-mail Address Policy Wizard, enter a name for the policy, choose whether you want it to apply only to objects stored within a particular Active Directory container, and select the recipient types (mailbox users, mail-enabled users, and so on). Click Next.

3. On the Conditions page select which conditions will be used to limit the scope of the address policy. It is not necessary to limit the scope of the address policy—for example, if you want to apply the policy to all addresses in the organization. You can select from the following conditions:

   • Recipient is in a State or Province Checks for a match against the State/Province attribute of the Active Directory account. This property is set on the Address tab of an account’s properties in Active Directory Users and Computers.

   • Recipient is in a Department Checks for a match against the Department attribute of the Active Directory account. This property is set on the Organization tab of an account’s properties in Active Directory Users and Computers.

   • Recipient is in a Company Checks for a match against the Company attribute of the Active Directory account. This property is set on the Organization tab of an account’s properties in Active Directory Users and Computers.

   • Custom Attribute equals Value It is also possible to configure up to 15 custom attributes for each account. The values of these attributes need to be set through Exchange management shell and aren’t something that you can use Active Directory Users and Computers to configure.

   More Info: Configuring Custom Attributes

   To learn more about configuring custom attributes, consult the following TechNet article: http://technet.microsoft.com/en-us/library/ee423541.aspx.

4. On the E-Mail Addresses page, click Add. On the SMTP E-Mail Address page, shown in Figure 1-9, select the format that you want to use for the email address and then click OK. If you want to add more address formats, you can click Add again. If you have multiple addresses listed in the policy, you need to specify one format as the default reply-to address. Click Next.

   

   Figure 1-9 Email address format

5. On the Schedule page, select whether the policy is applied immediately, at a time in the future, or not applied at all.

You can apply multiple email address policies to a user. When you have multiple policies, you need to choose the order in which they apply. The reply-to address that is set in the policy with the highest priority is used as the default reply-to address. You can also manually configure a user’s default reply-to address by editing the user’s account properties directly. The default reply-to address set at this level overrides any set by policy.

You can use the following EMS cmdlets to manage email address policies:

• New-EmailAddressPolicy allows you to configure new address policies.

• Get-EmailAddressPolicy allows you to view the properties of existing policies.

• Set-EmailAddressPolicy allows you to modify the properties of existing policies.

• Update-EmailAddressPolicy allows you to apply policy changes to recipients within the scope of the policy. You must run this cmdlet after you create or modify an email address policy.

• Remove-EmailAddressPolicy allows you to remove existing policies, but will not remove email addresses from users that were created by those policies.

Distribution Group Policies

A distribution group is a collection of recipients, sometimes known as mailing lists. When a user sends a message to a distribution group, Exchange will forward that message to all members of the distribution group. Exchange Server 2010 supports three types of distribution groups:

• Distribution groups A static group whose membership is managed manually.

• Mail-enabled security groups Similar to a distribution group, except that security permissions can be assigned to a mail-enabled security group. This static group type also requires that membership be managed manually.

• Dynamic distribution groups This group type has its membership generated automatically based on a query. For example, you might create a dynamic distribution group for everyone that works at a particular branch office according to their user account properties. When a person’s account properties are updated to indicate that she works at that branch office, she will receive messages sent to that group. Group membership is calculated by a Hub Transport server when it receives a message addressed to the group.

Static Distribution Groups

Static distribution groups have several advantages over dynamic distribution groups. Static distribution groups allow you to define a membership where the objects in the group don’t need to share a specific property. You can delegate management privileges of the distribution group to an ordinary user who can choose whom to add to the group. You can also configure group permissions so that users can add and remove themselves from the group as they choose. This functionality is very useful for things like project-based distribution groups. Mail-enabled security groups are also a type of static distribution group. If you are using the mail-enabled security group as a security group, remember that if you allow a non-administrative user to manage the group, you’re also allowing that user to grant access to any resources to which the group has been assigned permissions.

To create a static distribution group using EMC, perform the following general steps:

1. Select the Recipient Configuration\Distribution Group node and then click New Distribution Group. This will launch the New Distribution Group Wizard.

2. Select whether you want to create a new distribution group or mail-enable an existing universal security group. If you want to mail-enable an existing universal security group, choose Existing Group, click Browse, and select the group. You can’t mail-enable a security group with a domain local or global scope.

3. On the Group Information page, shown in Figure 1-10, choose between Distribution and Security. You can select an OU in which to place the group. You also need to provide a name, a pre-Windows 2000 name, and an alias name for the group. These can all be the same name. Then click Next, New, and then Finish.

To create a new distribution group using EMS, use the New-DistributionGroup cmdlet. For example, to create a new mail-enabled security group named Alpha-Sec which will be stored in the Users container of the contoso.com domain, use the following cmdlet:

New-DistributionGroup -Name Alpha-Sec -OrganizationalUnit "Contoso.com/Users"
-SAMAccountName Alpha-Sec -Alias 'Alpha-Sec' -Type Security

The default manager of a distribution group is the user account that used to create the group. To delegate the ability to manage the group to another user, either use the Set-DistributionGroup cmdlet with the ManagedBy parameter, or navigate to the Group Information tab on the group’s properties, shown in Figure 1-11, and click Add to specify a new group manager.

You can configure whether users are able to join the group themselves, whether they can join subject to approval, or if group members can only be added by the group managers on the Membership Approval tab, shown in Figure 1-12. You can also configure these settings using the Set-DistributionGroup cmdlet with the MemberJoinRestriction parameter using the options Open, Closed, or ApprovalRequired.

Dynamic Distribution Groups

Creating a dynamic distribution group involves creating a query that defines the membership of the group. This query runs each time a message is sent to the group. This means that the membership of the group is calculated each time the group receives a new message. For example, a dynamic distribution group might be defined by a query that locates all accountants in the Traralgon office. Each time a message is sent to the group, Exchange calculates which recipients are accountants located in the Traralgon office and forwards the message appropriately. To create a dynamic distribution group in EMC, perform the following general steps:

1. Select the Recipient Configuration\Distribution Group node and then click New Dynamic Distribution Group in the Actions pane.

2. On the Introduction page, specify an Organizational Unit container to host the group if you do not want the group account stored in the default container. Specify a group name and alias. Click Next.

3. On the Filter Settings page, choose whether you want to only include objects from a specific Active Directory Domain or OU. Also, choose whether you want to include all recipient types or if you want to restrict the group to one or more of the following: mailbox users, mail-enabled users, resource mailboxes, contacts, and mail-enabled groups.

4. On the Conditions page select which conditions will be used to limit the scope of the address list. You can choose to limit the scope based on recipient Active Directory attributes including State or Province, Department, Company, or a custom attribute value. Click Next, New, and then Finish.

You can use EMS to create more complicated dynamic distribution groups—such as creating a distribution group that only includes users who have mailboxes on a specific mailbox server—through the use of recipient filters and the New-DynamicDistributionGroup cmdlet. For example, to create a dynamic distribution group called SYD-MBX-Users that contains only those users who have mailboxes on server SYD-EX1, use the following command:

New-DynamicDistributionGroup -Name "SYD-MBX-Users" -OrganizationalUnit Users
-RecipientFilter {((RecipientType -eq 'UserMailbox' -and ServerName -eq 'SYD-EX1') -and
-not(Name -like 'SystemMailbox{*'))}

Public Folders

You need to include public folders in your design if you need to support clients that use Outlook 2003 or earlier. This is because these clients need to use public folders for performing free/busy searches and use them to obtain offline address books. A public folder database will be created on the first Exchange mailbox server that you deploy in your organization if you are deploying in a mixed environment, or indicate that you still need to support clients running Outlook 2003 or earlier.

Public folders almost always are inherited from a previous Exchange deployment. Organizations stick with them because of the effort involved in migrating to another solution. Microsoft recommends that organizations performing new deployments of Exchange use SharePoint rather than public folders. This is because the document management, authoring, and revisioning functionality of SharePoint better addresses how organizations interact with shared documents than Exchange public folder infrastructure does.

When designing public databases, consider the following:

• How large will your public folders be? As almost all organizations that use public folders with Exchange Server 2010 have used public folders with previous versions of Exchange. This means that you should be able to reasonably estimate the size of the necessary public folder databases. Unless you modify the registry, a public folder database cannot exceed 1024 GB in size on a computer running Exchange 2010 Standard edition.

• How often will public folders be accessed? The more often public folders are accessed, the greater the disk utilization.

• Do you need to support Outlook 2003? If your organization does not need to support Outlook 2003, you may wish to plan a migration of public folder content to SharePoint.

• If you want to support public folder replication as a way to make public folder content more failure tolerant, you will need to deploy a minimum of two public folder databases, each on a separate mailbox server.

You’ll learn more about configuring public folders in Chapter 2.

Mailbox Provisioning Policies

Mailbox provisioning policies are a way of deciding where to place a specific Exchange mailbox. If you don’t specify a mailbox database when provisioning a mailbox, the mailbox will be assigned automatically to an available mailbox database using a load-balanced approach. This can cause problems if you aren’t careful—a new user’s mailbox could be automatically deployed to a location that is geographically remote from where the user actually works.

Although placing a mailbox in the same Active Directory site as a user may be optimal from a performance standpoint because it allows high-speed access to a local Mailbox server, such a strategy might not be practical from an economic perspective. Mailbox servers cost money and you need to balance localized access performance with the economic realities of deploying multiple mailbox servers. If an organization has a large number of branch office sites with a relatively small number of employees, placing a Mailbox server at each site may not be viable from an administrative or economic standpoint. It may be cheaper to improve the connection to a central site than it is to provision that site with a local Mailbox server.

When deciding where to place a mailbox, consider the following:

• Attempt to ensure that the mailbox is placed on a mailbox database that is either geographically close to the user or sufficiently provisioned with bandwidth that it does not cause the user performance problems.

• You can assign different quotas at the mailbox database and the individual mailbox level. Using a database-wide quota makes planning storage simpler than having a multitude of quotas applying to mailboxes hosted in the same database. If you need to use separate mailbox storage quotas in your organization, provision mailboxes to mailbox databases configured with appropriate quotas.

• If you use Exchange Online in conjunction with an on-premises deployment, it may make sense to place some mailboxes in the cloud rather than on a locally managed Exchange Mailbox server. This can be especially useful for remote sites with few users, though will require a cost benefit analysis to determine whether it is a more reasonable solution than hosting the mailbox at an on-premises location.

• Products such as Forefront Identity Manager (FIM) 2010 can be used to automate account and mailbox provisioning.

Your organization should also develop a mailbox deprovisioning policy. A mailbox deprovisioning policy details what steps should be taken in the event that a user leaves an organization. Although it might be tempting to simply delete the user mailbox after the user has left the building, compliance requirements often mean that the mailbox needs to be kept available in some manner for a certain period of time. How you design your deprovisioning policies will depend very much on your organizational needs and most organizations find a balance between deleting user mailboxes immediately and keeping zombie mailboxes on production servers for years after the employee has left the organization.

Objective Summary

• When determining how much storage space will be required by a mailbox database, take into account quotas as well as deleted item retention requirements.

• The amount of space required by transaction logs depends on average message size and how often the mailbox database is backed up.

• Although it is possible to have mailbox databases that are 16 terabytes in size, Microsoft recommends that mailbox databases do not exceed 2 terabytes in size on high-availability configurations and which do not exceed 200 GB in size for non-high-availability configurations.

• Use linked mailboxes to provide Exchange mailboxes to users with accounts in trusted forests.

• A maximum of five mailbox databases can be deployed on a mailbox server running the Standard edition of Exchange 2010. A maximum of 100 mailbox databases can be deployed on a mailbox server running the Enterprise edition of Exchange 2010. A maximum of one public folder database can be deployed per mailbox server.

• Recipient policies, also known as email address policies, determine the format of email addresses in the organization and the default reply-to address format.

• The membership of static distribution can be managed. Mail-enabled security groups must always use the universal scope. The membership of dynamic distribution groups is determined by a query.

Objective Review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. Your organization uses a resource-forest model, with two account forests and a single resource forest where you have deployed Exchange 2010. The account forests consist of multiple Active Directory domains. Which steps do you need to take to provision users in each account forests with mailboxes in the resource forest? (Choose two. Each answer forms part of a complete solution.)

   1. Ensure that there are forest trusts between the resource forest and the account forests.

   2. Install Exchange 2010 in the account forests.

   3. Create linked mailboxes in the resource forest.

   4. Create linked mailboxes in the account forests.

2. You have been asked by someone in management whether it is possible to configure a special address in Exchange so that people in the organization can send an email to that address and that email will be forwarded on to reach everyone who is currently a member of the Research department. The manager wants the mechanism by which this process works to be automatic. It should not require someone having to manually update the list of people who are in the Research department. The Human Resources department of your organization automatically populates the Department attribute for all Active Directory user accounts in your organization. Which of the following Exchange management shell commands would you use to meet management’s goals?

   1. New-Mailbox

   2. New-DistributionGroup

   3. Set-DistributionGroup

   4. New-DynamicDistributionGroup

3. A mailbox database, hosted on a mailbox server running the standard edition of Exchange Server 2010 SP1, has dismounted because it has reached its maximum size. What steps can you take to increase the maximum size of the mailbox database beyond 1024 GB?

   1. Use the New-MailboxDatabase cmdlet.

   2. Use the Get-MailboxDatabase cmdlet.

   3. Edit the registry.

   4. Use the Set-MailboxDatabase cmdlet.

4. Your organization has three mailbox servers running Exchange Server 2010 SP1 Enterprise edition and two mailbox servers running Exchange Server 2010 SP1 Standard edition. What is the maximum number of Public Folder databases that you can deploy in this environment?

   1. 5

   2. 1

   3. 8

   4. 7

5. Your organization, currently known as Cohovineyard, is in the process of rebranding itself. An expensive consultant has decided that the name Cohowinery has more intrinsic synergy. You have obtained the appropriate rights to the cohowinery.com domain. You want to ensure that all users default reply-to address uses cohowinery.com rather than cohovineyard.com. Which of the following cmdlets should you use to accomplish this goal? (Choose three. Each answer forms part of a complete solution.)

   1. New-AcceptedDomain

   2. Get-EmailAddressPolicy

   3. New-EmailAddressPolicy

   4. Update-EmailAddressPolicy