It has been about a couple of months since we released Exchange Server 2007 Service Pack 2. About 3 years ago when we shipped Exchange Server 2007 we promised cumulative update rollups every couple of months. Keeping with that promise we have released Update Rollup 1 for Exchange Server 2007 Service Pack 2 (KB 971534) to the download center today. The release of the rollup via Microsoft Update will happen on November 24. Update rollups are service pack dependent, so you need to first upgrade to Exchange Server 2007 SP2 before deploying this Update Rollup.

While the bulk of the changes in this rollup are bug fixes we have also made some improvements to the experience when installing the patch. We laid the foundation for these improvements in the Exchange Server 2007 SP2 product MSI which also included requiring everyone to upgrade to Windows Installer 4.5. We are building upon it in this rollup and hope to improve your experience during installation of these patches.

1) Ability to cancel installation of a rollup - As most of you have noticed the cancel button in the rollup is disabled for most of the time. This is because the custom actions implemented in the patch did not have corresponding rollback versions. Hence a cancel of the install would have meant that the system state would not have been rolled back. We have redesigned this area of the code and enabled the administrators to cancel installation and rollback the system to the initial state whenever possible. Note that there are still some critical points during setup where we disable canceling, for example when we reach the end of the installation sequence where canceling install at that point would take longer than finishing up the rollup deployment.

2) Pre-installation checks for common issues faced by customers

a. We now check for the lack of internet connectivity, which can cause longer installation times due to the system trying to obtain the Certificate Revocation List from the HTTP URL specified in the signing certificate. If we detect the absence of internet connectivity we provide a warning (see below). The link points to the topic How to Install the Latest Service Pack or Update Rollup for Exchange 2007 in the Exchange Server 2007 TechCenter documentation which covers the steps to update the system configuration to not do the check under the section "When Exchange cannot connect to the Internet". We will also post a blog shortly on the technical details about this.

b. KB 970104 - We check if the user account initiating the install of the rollup has adequate permissions. If the user does not have Exchange Organizational Administrator permissions, the installation throws an error before making any changes to the system. The most common case of this is seen when users install the rollup using an account which is a local administrator and see that Outlook Web Access is not working because the user account did not have permissions to update the OWA component in Active Directory which requires running some cmdlets which require Exchange Server Administrator privileges.

3) Shorter downtime of Exchange Services during deployment of the rollup by doing a 2 step Native Image Generation. This is the place where the rollup installer seems to be stuck for a long time with the message "Creating native images for .NET assemblies. This process can take an extended period of time to complete." If NGEN is busy imaging non-Exchange .NET assemblies in the system due to a pending queue then Exchange services are down for a lot longer than they need to be.

a. Step 1 will keep Exchange services running while imaging non-Exchange .NET assemblies in the system.

b. Step 2 will stop Exchange services and then image the Exchange assemblies.

The advantage to this two step process is that if Step 1 takes a large chunk of the maintenance interval than expected, the administrator can cancel the rollup installation and reschedule the installation of the rollup to a future time.

4) Ability for Exchange administrators to execute custom PowerShell scripts before and after rollup installation to stop 3rd party services loading Exchange assemblies and causing a reboot. More on this in a blog post coming up soon.

Some of the other critical product bug fixes in this rollup which we would like to call out are

1) KB 971010 - Intermittent issue where a database does not mount when CCR failover happens due to missing temp log file

2) KB 941775 - Running Isinteg for the first time on a newly created DB fails with Error: FULLCHKMGR::EcReadRowCountGlobalFlag failed with error JET_wrnColumnNull

3) KB 972115 - Transport rule does not fire for Message Delivery Notifications if header is folded because the report-type is not evaluated

KB 971534 has more details about this release and a complete list of all fixes included in this rollup.

We welcome your feedback on the improvements we have made in this rollup. Also, a friendly reminder again that we will be watching our Exchange Software Updates forum which is available to provide assistance if you encounter issues when deploying the rollup.

- Exchange Customer Experience team

By now most of you have heard about the release of Exchange 2010.  Those of you that are upgrading from Exchange 2003, Exchange 2007 or a mixture of the two, are probably curious about the client access upgrade strategy.  To satisfy your curiosity, we are releasing a series of blog articles on the subject.  The first in this series provides a summary of the steps that are required to introduce Exchange 2010 within your environment from a client access perspective.  More detailed information about the upgrade process is discussed in TechNet and within the Deployment Assistant.  The second and third parts in this series will discuss the end user experience for OWA and ActiveSync, respectively.  Look for those in upcoming weeks.

Many of you have been asking how you can transition your existing Exchange environment to Exchange 2010 from a client access perspective. For most of you, this will also mean coexisting with legacy Exchange and Exchange 2010 for a period of time. This post will hopefully answer these questions by breaking down your transition into two scenarios:

1. Transitioning an Exchange 2003 environment to Exchange 2010.
2. Transitioning an Exchange 2007 (that may or may not contain Exchange 2003 mailbox servers) environment to Exchange 2010.

The underlying goal here is to move your primary namespace, mail.contoso.com and autodiscover.contoso.com, over to Exchange 2010 and introduce a new namespace for legacy access, legacy.contoso.com and associate it with your legacy Exchange client access infrastructure. Users will continue to use mail.contoso.com as their access point into the organization for messaging services. While Exchange 2003/2007 end users will see the legacy.contoso.com namespace in their browser address bar, ActiveSync settings, and Test Auto-Configuration output within Outlook, they only need to use the mail.contoso.com namespace as their primary entry point into the organization; in addition, IT should continue directing customers to utilize the mail.contoso.com namespace for all external connectivity mechanisms.

Note: The host names, mail.contoso.com or legacy.contoso.com, that are referenced in this document are not hard-coded or required. You can utilize whichever names make the most sense for your environment (e.g. owa.contoso.com and legacyowa.contoso.com). From a documentation perspective, we are going to utilize mail.contoso.com and legacy.contoso.com so that we are consistent in our transition story. For more information on Autodiscover namespaces, please see http://technet.microsoft.com/en-us/library/bb332063.aspx.

Transitioning an Exchange 2003 Environment to Exchange 2010

When you are ready to begin transitioning your organization to Exchange 2010, you must transition the "Internet Facing AD Site(s)" first, and then transition your internal Active Directory sites. It is not supported to transition an internal Active Directory site before all your Internet-accessible sites have been transitioned.

The steps for introducing Exchange 2010 into the environment are:

Note: These steps do not discuss how to set up your CAS2010 servers in a load balancing array. Please review your load balancing solution's instructions for how to properly create and join your CAS2010 servers in a load balancing array.

1. In order to support external client coexistence with CAS2010 and legacy Exchange in your "Internet Facing AD Site", you will (potentially) need to acquire a new commercial certificate.  As a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can utilize a wildcard certificate as well.

This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN values (note that other scenarios may require you to add additional values):

1. mail.contoso.com (your primary OWA/EAS/OA access URL)
2. autodiscover.contoso.com
3. legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)

Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that mail.contoso.com is listed as the Subject Name in your certificate unless you plan on changing the configuration which can be achieved by using the Set-OutlookProvider cmdlet with the EXPR parameter as described in http://msexchangeteam.com/archive/2008/09/29/449921.aspx.

2. Ensure all Exchange 2003 servers are at Service Pack 2 and that you meet all forest/domain pre-requisites.

3. Install CAS2010 and configure it accordingly:

• During the installation of CAS2010 you have the option to enter the external namespace that will be used for the virtual directories. You can enter this value in both the graphical user interface or the command-line setup:
• For the graphical user interface setup experience of CAS2010 you are asked to configure a Client Access external domain. At this point you canter the domain name of mail.contoso.com.
• If installing via the command line, you can utilize the setup property /ExternalCASServerDomain and specify mail.contoso.com
• If you haven't already done so, install the RPC over HTTP proxy component.  You can do this utilizing the ServerManagerCmd tool: ServerManagerCmd.exe -i RPC-over-HTTP-proxy
• Configure your OWA settings appropriately (e.g. forms based authentication vs. basic authentication). For the purpose of this document, the default OWA settings are assumed.
• Configure your EAS authentication settings appropriately (e.g. Basic vs. certificate authentication). For the purposes of this document, the default authentication mechanism, basic authentication, is assumed.
• Enable Outlook Anywhere (for the purposes of this document, the default authentication settings are assumed): Enable-OutlookAnywhere -Server:<CAS2010> -ExternalHostName:mail.contoso.com - SSLOffloading $false

4. If you chose to not specify the external domain name for CAS during setup, you will need to enable the following ExternalURLs to ensure that clients that leverage Autodiscover function correctly:

• Offline Address Book: Set-OABVirtualDirectory <CAS2010>\OAB* -ExternalURL https://mail.contoso.com/OAB
• Web Services: Set-WebServicesVirtualDirectory <CAS2010>\EWS* -ExternalURL https://mail.contoso.com/ews/exchange.asmx
• ActiveSync: Set-ActiveSyncVirtualDirectory -Identity <CAS2010>\Microsoft-Server-ActiveSync -ExternalURL https://mail.contoso.com/Microsoft-Server-ActiveSync

5. To ensure that Outlook Web Access functions correctly, you will need to enable the following URLs:

• Outlook Web Access:
• For environments without Exchange 2003: Set-OWAVirtualDirectory <CAS2010>\OWA* -ExternalURL https://mail.contoso.com/OWA
• For environments with Exchange 2003 mailbox servers: Set-OWAVirtualDirectory <CAS2010>\OWA* -ExternalURL https://mail.contoso.com/OWA -Exchange2003URL https://legacy.contoso.com/exchange
• Exchange Control Panel: Set-ECPVirtualDirectory <CAS2010>\ECP* -ExternalURL https://mail.contoso.com/ECP

6. For your Outlook clients, you can configure CAS2010 to participate in an RPC Client Access Service array:

• Create a load balancing array for CAS2010, if one has not already been created.
• Create a DNS entry in your internal DNS infrastructure that resolves to the Virtual IP Address (VIP) of the CAS load balancing array. The DNS entry, for example, could be outlook.contoso.com.
• Configure your load balancing array to load balance the MAPI RPC ports:
• TCP 135
• UDP/TCP 1024-65535
• Run the following cmdlet to create the Client Access Service array: New-ClientAccessArray -Name outlook.contoso.com -FQDN outlook.contoso.com -Site "Internet Facing AD Site"

7. Install the HT2010 and MBX2010 server roles into the "Internet Facing AD Site" and configure accordingly.

• You can change the Offline Address Book generation server and enable web distribution on CAS2010 by performing the following steps:
• To move the Offline Address Book: Move-OfflineAddressBook "Default Offline Address List" -Server <MBX2010>
• To add CAS2010 as a web distribution point:
• $OABVDir=Get-OABVirtualDirectory -Server <CAS2010>
• $OAB=Get-OfflineAddressBook "Default Offline Address List"
• $OAB.VirtualDirectories += $OABVdir.DistinguishedName
• Set-OfflineAddressBook "Default Offline Address List" -VirtualDirectories $OAB.VirtualDirectories

8. Create the legacy host record (legacy.contoso.com) in your external DNS infrastructure and associate it either with the FE2003 infrastructure (less likely) or your proxy infrastructure (more likely).

9. You will configure External DNS and/or your reverse proxy infrastructure's publishing rules to have the autodiscover.contoso.com namespace point to CAS2010.

10. If utilizing a reverse proxy infrastructure, you will publish the legacy namespace to the FE2003 infrastructure so that at this point the FE2003 infrastructure can be accessed either via mail.contoso.com or legacy.contoso.com namespaces.

11. You will then schedule Internet protocol client downtime (please note that this downtime window should be relatively small - enough time for you to make the change and validate that everything works as desired) and perform the following steps:

• You will reconfigure External DNS and/or your reverse proxy infrastructure's publishing rules to have the mail.contoso.com namespaces point to CAS2010. 
• Users with mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This allows the Exchange 2010 Client Access Server and the Exchange 2003 back end server to communicate using Kerberos authentication.

To enable this authentication change on Exchange 2003 you need to either:

• Install http://support.microsoft.com/?kbid=937031 and then use the Exchange System Manager to adjust the authentication settings of the ActiveSync virtual directory. Repeat this for each Exchange 2003 mailbox server in your organization.
• Or, set the msExchAuthenticationFlags attribute to a value of 6 on the Microsoft-Server-ActiveSync object within the configuration container on each Exchange 2003 mailbox server.  An example script is provided at http://technet.microsoft.com/en-us/library/cc785437.aspx.

Note: It is important that you do not use IIS Manager to change the authentication setting on the Microsoft-Server-ActiveSync virtual directory as the DS2MB process within the System Attendant will overwrite the settings that are stored in Active Directory.

• Disable Outlook Anywhere by utilizing the Exchange System Manager and selecting the "Not part of an Exchange managed RPC-HTTP topology" radial button on the RPC-HTTP tab of the Front-End server's properties. Optionally, you can also remove the RPC over HTTP proxy component (refer to your Windows Server documentation for more information).

Important: This requires an up-front investment in CAS2010 architecture as all Outlook Anywhere clients will utilize CAS2010 once you transition the Outlook Anywhere endpoint. Be sure to follow all proper scalability planning documentation when deploying CAS2010 to ensure that you do not create a bottleneck in your CAS infrastructure due to Outlook Anywhere clients.

• Test all client scenarios and ensure they function correctly.

12. Complete downtime and enable Internet protocol client usage.

As a result of following these steps, the environment would look similar to this diagram:

Transitioning an Exchange 2007 environment to Exchange 2010

When you are ready to begin transitioning your organization to Exchange 2010, you must transition the "Internet Facing AD Site" that is associated with your external Autodiscover record, then regional Internet facing AD Sites, and then transition your internal Active Directory sites. It is not supported to transition an internal Active Directory site before all your Internet-accessible sites have been transitioned.

The steps for introducing Exchange 2010 into the environment are:

Note: These steps do not discuss how to set up your CAS2010 servers in a load balancing array. Please review your load balancing solution's instructions for how to properly create and join your CAS2010 servers in a load balancing array.

1. In order to support external client coexistence with CAS2010 and legacy Exchange in your "Internet Facing AD Site", you will (potentially) need to acquire a new commercial certificate.  As a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can utilize a wildcard certificate as well.

This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN values (note that other scenarios may require you to add additional values):

1. mail.contoso.com (your primary OWA/EAS/OA access URL)
2. autodiscover.contoso.com
3. legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)

Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that mail.contoso.com is listed as the Subject Name in your certificate unless you plan on changing the configuration which can be achieved by using the Set-OutlookProvider cmdlet with the -EXPR parameter as described in http://msexchangeteam.com/archive/2008/09/29/449921.aspx.

2. Ensure all Exchange 2007 CAS within the organization are at Service Pack 2, all Exchange 2003 servers (if they exist) are at Service Pack 2, and that all Exchange 2007 Mailbox, Hub Transport, and Unified Messaging servers are at Service Pack 2 in the "Internet Facing AD Site". Also, ensure you meet all the forest/domain pre-requisites.

3. Install CAS2010 and configure it accordingly:

• During the installation of CAS2010 you have the option to enter the external namespace that will be used for the virtual directories. You can enter this value in both the graphical user interface or the command-line setup:
• For the graphical user interface setup experience of CAS2010 you are asked to configure a Client Access external domain. At this point you canter the domain name of mail.contoso.com.
• If installing via the command line, you can utilize the setup property /ExternalCASServerDomain and specify mail.contoso.com
• If you haven't already done so, install the RPC over HTTP proxy component.  You can do this utilizing the ServerManagerCmd tool: ServerManagerCmd.exe -i RPC-over-HTTP-proxy
• Configure your OWA settings appropriately (e.g. forms based authentication vs. basic authentication). For the purpose of this document, the default OWA settings are assumed.
• Configure your EAS authentication settings appropriately (e.g. Basic vs. certificate authentication). For the purposes of this document, the default authentication mechanism, basic authentication, is assumed.
• Enable Outlook Anywhere (for the purposes of this document, the default authentication settings are assumed): Enable-OutlookAnywhere -Server:<CAS2010> -ExternalHostName:mail.contoso.com -SSLOffloading $false

4. If you chose to not specify the external domain name for CAS during setup, you will need to enable the following ExternalURLs to ensure that clients that leverage Autodiscover function correctly:

• Offline Address Book: Set-OABVirtualDirectory <CAS2010>\OAB* -ExternalURL https://mail.contoso.com/OAB
• Web Services: Set-WebServicesVirtualDirectory <CAS2010>\EWS* -ExternalURL https://mail.contoso.com/ews/exchange.asmx
• ActiveSync: Set-ActiveSyncVirtualDirectory -Identity <CAS2010>\Microsoft-Server-ActiveSync -ExternalURL https://mail.contoso.com

5. To ensure that Outlook Web Access functions correctly, you will need to enable the following URLs:

• Outlook Web Access:
• For environments without Exchange 2003 mailbox servers: Set-OWAVirtualDirectory <CAS2010>\OWA* -ExternalURL https://mail.contoso.com/OWA
• For environments with Exchange 2003 mailbox servers: Set-OWAVirtualDirectory <CAS2010>\OWA* -ExternalURL https://mail.contoso.com/OWA -Exchange2003URL https://legacy.contoso.com/exchange
• Exchange Control Panel: Set-ECPVirtualDirectory <CAS2010>\ECP* -ExternalURL https://mail.contoso.com/ECP

6. If you have Exchange 2007 deployed in "Non-Internet Facing AD Sites" then you must copy the Exchange 2007 OWA binaries to CAS2010:

• On the CAS2010 server(s), establish a connection to the CAS2007 server's drive that contains the Exchange binaries and navigate to the \Client Access\OWA directory (e.g. \\cas2007\c$\Program Files\Microsoft\Exchange Server\Client Access\Owa).
• Copy the highest version folder (e.g. 8.2.140.0) from the CAS2007 to CAS2010 Exchange binaries \Client Access\OWA directory (e.g. C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa).
• Execute IISReset on all the CAS2010 machines.

7. For your Outlook clients, you can configure CAS2010 to participate in an RPC Client Access Service array:

• Create a load balancing array for CAS2010, if one has not already been created.
• Create a DNS entry in your internal DNS infrastructure that resolves to the Virtual IP Address (VIP) of the CAS load balancing array. The DNS entry, for example, could be outlook.contoso.com.
• Configure your load balancing array to load balance the MAPI RPC ports:
• TCP 135
• UDP/TCP 1024-65535
• Run the following cmdlet to create the Client Access Service array: New-ClientAccessArray -Name outlook.contoso.com -FQDN outlook.contoso.com -Site "Internet Facing AD Site"

8. Install the HT2010 and MBX2010 server roles into the "Internet Facing AD Site" and configure accordingly.

• You can change the Offline Address Book generation server and enable web distribution on CAS2010 by performing the following steps:
• To move the Offline Address Book: Move-OfflineAddressBook "Default Offline Address List" -Server <MBX2010>
• To add CAS2010 as a web distribution point:
• $OABVDir=Get-OABVirtualDirectory -Server <CAS2010>
• $OAB=Get-OfflineAddressBook "Default Offline Address List"
• $OAB.VirtualDirectories += $OABVdir.DistinguishedName
• Set-OfflineAddressBook "Default Offline Address List" -VirtualDirectories $OAB.VirtualDirectories

9. Create legacy host record (legacy.contoso.com) in your external DNS infrastructure and associate it either with the CAS2007 infrastructure (less likely) or your proxy infrastructure (more likely).

10. If utilizing a reverse proxy infrastructure, you will publish the legacy namespace to the CAS2007 infrastructure so that at this point the CAS2007 infrastructure can be accessed either via mail.contoso.com or legacy.contoso.com namespaces.

11. You will then schedule Internet protocol client downtime (please note that this downtime window should be relatively small - enough time for you to make the change and validate that everything works as desired) and perform the following steps:

• You will re-configure your CAS2007 URLs in the "Internet Facing AD Site". This ensures that clients that leverage Autodiscover function correctly and that legacy mailboxes can be redirected to Outlook Web Access:
• Outlook Web Access: Set-OWAVirtualDirecotry <CAS2007>\OWA* -ExternalURL https://legacy.contoso.com/owa
• Offline Address Book: Set-OABVirtualDirectory <CAS2007>\OAB* -ExternalURL https://legacy.contoso.com/OAB
• Unified Messaging: Set-UMVirtualDirectory  <CAS2007>\UnifiedMessaging* -ExternalURL https://legacy.contoso.com/UnifiedMessaging/Service.asmx
• Web Services: Set-WebServicesVirtualDirectory <CAS2007>\EWS* -ExternalURL https://legacy.contoso.com/ews/exchange.asmx
• ActiveSync: Set-ActiveSyncVirtualDirectory -Identity <CAS2007>\Microsoft-Server-ActiveSync -ExternalURL https://legacy.contoso.com
• If you have Exchange 2003 mailbox servers in your environment, then users with mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This allows the Exchange 2010 Client Access Server and the Exchange 2003 back end server to communicate using Kerberos authentication.

To enable this authentication change on Exchange 2003 you need to either:

• Install http://support.microsoft.com/?kbid=937031 and then use the Exchange System Manager to adjust the authentication settings of the ActiveSync virtual directory.
• Or, set the msExchAuthenticationFlags attribute to a value of 6 on the Microsoft-Server-ActiveSync object within the configuration container on each Exchange 2003 mailbox server.  An example script is provided at http://technet.microsoft.com/en-us/library/cc785437.aspx.

Note: It is important that you do not use IIS Manager to change the authentication setting on the Microsoft-Server-ActiveSync virtual directory as the DS2MB process within the System Attendant will overwrite the settings that are stored in Active Directory.

• Disable Outlook Anywhere on your Exchange 2007 CAS infrastructure in the "Internet Facing AD Site" by utilizing the cmdlet, Disable-OutlookAnywhere -Server <CAS2007>. Optionally, you can also remove the RPC over HTTP proxy component (refer to your Windows Server documentation for more information).

Important: This requires an up-front investment in CAS2010 architecture as all Outlook Anywhere clients will utilize CAS2010 once you transition the Outlook Anywhere endpoint. Be sure to follow all proper scalability planning documentation when deploying CAS2010 to ensure that you do not create a bottleneck in your CAS infrastructure due to Outlook Anywhere clients.

• You will reconfigure External DNS and/or your reverse proxy infrastructure's publishing rules to have the autodiscover.contoso.com and mail.contoso.com namespaces point to CAS2010.
• Test all client scenarios and ensure they function correctly.

12. Complete downtime and enable Internet protocol client usage.

As a result of following these steps, the environment would look similar to this diagram:

So why the additional namespace?

To understand why we are introducing a new namespace for the legacy Exchange environment, it is important to understand what the Internet client behavior will be by introducing Exchange 2010.

• For Outlook Web Access, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange.  Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location:
• If the Exchange 2007 mailbox is in the same AD Site as CAS2010, CAS2010 will silently redirect the session to the Exchange 2007 CAS.
• If the Exchange 2007 mailbox is in another Internet facing AD Site, CAS2010 will manually redirect the user to the Exchange 2007 CAS.
• If the Exchange 2007 mailbox is in a non-Internet facing AD site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
• If the mailbox is Exchange 2003, CAS2010 will silently redirect the session to a pre-defined URL.
• For Exchange ActiveSync, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange.  Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location, and device capabilities:
• If the Exchange 2007 mailbox is in the same AD Site as CAS2010 and the device supports Autodiscover, CAS2010 will notify the device to synchronize with CAS2007.
• If the Exchange 2007 mailbox is in the same AD Site as CAS2010 and the device does not support Autodiscover, CAS2010 will proxy the connection to CAS2007.
• If the Exchange 2007 mailbox is in a non-Internet facing AD site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
• If the mailbox is Exchange 2003, CAS2010 will proxy the connection to the Exchange 2003 mailbox server.
• For Outlook Anywhere, you are going to move the Outlook Anywhere endpoint from the Exchange 2003 Front-End or Exchange 2007 CAS to the Exchange 2010 CAS.  Exchange 2010 CAS will always proxy the Outlook MAPI RPC data that is embedded in the RPC-HTTPS packet to the target legacy mailbox server (regardless of AD site or version) or to the appropriate Exchange 2010 CAS.

Important: This requires an up-front investment in CAS2010 architecture as all Outlook Anywhere clients will utilize CAS2010 once you transition the Outlook Anywhere endpoint. Be sure to follow all proper scalability planning documentation when deploying CAS2010 to ensure that you do not create a bottleneck in your CAS infrastructure due to Outlook Anywhere clients.

Conclusion

Hopefully this information improves your understanding of client access coexistence with legacy versions of Exchange while transitioning to Exchange Server 2010.  Please let us know if you have any questions.

- Ross Smith IV

This one can be a bit counter intuitive for folks coming from any legacy version of Exchange...

Issue

You got your shiny new Exchange 2010 download and excitedly installed it on your 2010 hardware. You have setup all your CAS server settings, your DAG is up and running. Your pilot users have been moved over and everything went well.

Now you move over the executives and not two days later they are in your office complaining that they can't manage the distribution groups that they own. They were able to do it previously but now it isn't working.

A little bit of testing later and you see that they are right. You are hitting an error message in Outlook 2007 when trying to manage groups:

So what does the "Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on this object." error mean, when you are connecting to an Exchange 2010 server?

It means Exchange 2010 is doing its job - as designed...

Why is it doing this?

Exchange 2010 has quite a few features built in to allow your users to manage their own accounts and information. One of these features is the ability to manage distribution groups in a much richer format than Outlook 2007 provides.

This allows your users to join existing group, manage some of the properties of groups they own, membership in groups they own, and even create and remove groups. It is that last piece that got our beta customers a bit concerned. The ability to manage your own groups is good... the ability to create and remove groups - not so good.

Also this feature was turned on by default. So by default you would install Exchange 2010 Beta and any users you put on it could create and remove Distribution Groups. With that in mind the Product group decided to turn this feature off by default going forward and in RTM.

Turning it off is very easy... so is turning it on. All you have to do is assign the MyDistributionGroups RBAC role to the Default Role Assignment Policy. We even have the ability to do that in the ECP.

Since all of the built in RBAC roles have to function as parents to any roles that you create the product group had to leave the ability to create and remove distribution groups on this role to ensure that any customers that wanted their users to have that functionality would be able to assign it.

So how do I fix it?

"Fix" isn't really the right word. We need to modify the default solution to meet this specific need. For a number of customers the needs are going to be the following:

1. I want my users to be able to manage distribution groups they own.
2. I don't want them to be able to create distribution groups.
3. I don't want them to be able to remove distribution groups even if they do own them.

To help customers fill these needs we have created a short little script. This script will allow you to make any combination of the above work in your environment.

Link to script

How do I run this thing?

To run the script you need to copy the contents of the script to a text file on the machine you are going to run it on. Then save the file as a .ps1... I recommend Manage-GroupManagementRole.ps1 .

To fill all of the above requirements with minimal effort run the following from an Exchange Powershell Prompt:

This will create everything you need with the correct settings using the default names in the script. If you would like help on the script you can either look in the contents of the file or run it with no switches.

What does the script do?

What the script does is actually rather simple:

1. Creates a new RBAC role that is a child of the MyDistributionGroups Role
2. Removes the cmdlets remove-distributiongroup and new-distributiongroup from the new role that was just created.
3. Assigns the new role to the Default Role Assignment Policy

When complete your users will be able to manage distribution groups but not create or remove them.

Each step the script takes is documented in the script and you are welcome to extract just what you need from it. It is designed to handle more than just the basic scenario to give it a bit more flexibility.

What do I end up with if I take the defaults?

When finished you end up with a new role and a new role assignment. If we look at these in PowerShell we see:

Here is the Role that is created by the script. By default it is named MyDistributionGroupsManagement and is a child of the MyDistributionGroups role.

Here we can see all of the cmdlet that the role authorizes users to use. You can see that remove-distributiongroup and new-distributiongroup are not listed.

This is the piece that glues everything together. The role assignment is created using the name of the role and the name of the policy we are assigning the role too. The Default Role Assignment Policy applies to all users in the org by default. So everyone on Exchange 2010 will now have the ability to manage their own distribution groups.

Conclusion

Hopefully this post and the attached script will help you in getting your 2010 environment up and running where you want it. If you have any questions about the script or this process please feel free to post them here and I will do my best to address them.

- Matt Byrd

Introduction

Role Based Access Control (RBAC) is the new permissions model in Microsoft Exchange Server 2010. With RBAC, you don't need to modify and manage access control lists (ACLs), which was done in Exchange Server 2007 and earlier. On the flip side - as with anything new, RBAC can seem a bit intimidating at first.

I am going to try an explain how to think about RBAC, and the order to create things in so that you end up with a working RBAC setup that does exactly what you want. As we go thru each piece we will be setting up a custom role so feel free to follow along with the commands in your environment.

The Triangle of Power

We jokingly call this image the RBAC triangle of Power. It is the key to understanding RBAC and exactly where each piece of the puzzle fits. Once you understand the triangle understanding what is going on with RBAC is quite easy.

I will explain each of the nodes of the Triangle then put them back together for us at the end.

The Where

The first thing that you should work with when setting up RBAC is the where. By where we mean, where can the assignment you are about to build operate? Can it operate on one OU, a group of users, or maybe in the configuration container?

By default all RBAC roles have a defined where. That is the default scope that is assigned to the Role. You can see the default scope of a role by running

This will show you the implicit scopes of the role. The ones to pay attention to are the implicit write scopes. These will define where the cmdlets in the role can write.

When you create a new RBAC role it has to be a child of an existing RBAC role. If you do not define a scope for your newly created role it will inherit the scope of the Parent role. If you didn't want to use the default scope; say you wanted a role that could only work against VIPs you would need to create a new scope.

You can define the scope directly when you assign the role; but if you think there is any chance that you will need this same scope again for another role I would recommend that you create a new scope object. To do so you would use the New-ManagmentScope cmdlet to do something like this:

This will create a scope named "VIP Users" that will apply only to people that are in the group VIPs. Once you have your scope object created you need to define the What part of the triangle.

 The What

Now that you know where your role is going to be able to act it is time to create, what your role is going to be able to do.

By default Exchange 2010 has 65 built in roles. Each of these roles was created to cover a given set of discreet tasks that the product group thought would be useful to how our customer's environments work. But they are not going to cover all scenarios.

So we gave you the customer the ability to create child roles off of the built in parent roles and to use these to customize how your users and administrators can interact with Exchange.

There are some key things to know about user created roles.

1. You can create a custom role that is the child of an existing custom role.
2. A child role CANNOT have more rights than its parent role; even if the parent role is a custom role.
3. You should always have a get cmdlet for each set / remove / etc. cmdlet that you have in the role.

You control what a role can and can't do by adjusting the cmdlets and cmdlet parameters that are on the role. To see what entries already exist on a role we run:

That will show us all of the cmdlets that the Role "Mail Recipients" is allowed to run. We will create a child role of the "Mail Recipients" role and give it only the ability to modify a few things on another user's mailbox.

First we create the Role:

Now since we only want this role to do a few things the easiest thing to do is to remove everything from the role and only put back the one or two things we want.

What we did was remove all but one Entry from the role. Powershell won't let you remove all of the entries and for what I am building leaving the get-user cmdlet on was a reasonable one to leave there. It is very important to note that if you want to do the set version of a cmdlet you should have the get version of the same cmdlet on the role. It is hard to modify what you can't see.

Now we add back the one set cmdlet that we want with only the parameters that we need.

This allows our "VIP Editor" role to only edit the attributes listed in the Parameters section of the cmdlet.

At this point we have created the What and now we need the Who.

 The Who

The Who is simply; who is going to be able to perform, the What on Were.

For that we have to decide if we are going to assign this role to one specific person or to a group of people. The best practice is to always assume that you are going to assign the role to a group of people.

To provide the Who for a group of people we use a role group. A role group is actually just a normal Universal Security group that we have flagged to indicate it is being used for RBAC role assignments. This is done to make it easier to manage these groups.

We can see the built in exchange role groups by running:

This will show us the default role groups that Exchange ships with that are designed to handle most of the big bucket administrative tasks that a majority of customers use. For our purpose we want to create a new role group to define who can work with our what, where.

When you create a role group you must assign at least one role to the group. You can assign multiple roles if you need the members of the group to perform more than one set of tasks. Optionally you can also assign the scope when you create the role group. If you do not assign a scope it will take the default scope of the role.

Once the role group is created the role, and scope combination will take effect. The reason it takes effect is that the New-RoleGroup cmdlet has automatically created the glue for us.

The Glue

The Where, What, and Who are all AD objects. The Where is a scope object. The What is a role object, and the Who is a special security group. So naturally the Glue is another AD object, the Role Assignment, which sticks these three other objects together to create a working RBAC definition.

Above when we created the Role group the New-RoleGroup cmdlet created the role assignment for us in the background. We can see the role assignments with:

You will see that there are around 160 or so of them. This is because each role assignment is a 1 to 1 mapping of a Role, to a Scope, to a Role Group/user/Role Policy. So every time I assign a role to a role group it will create another unique role assignment that glues together the needed objects.

NOTE: This is critically important! RBAC roles are not like security permissions where the most restrictive wins. RBAC instead provides the end user with the UNITY of all roles that have been assigned to them. So only apply the exact roles to a user that you want them to have.

I take a role away from a role group by simply removing the role assignment that glued that role and role group together.

Pulling it all together

I know I have thrown quite a bit at you, and that I skimmed over a few things. But, I am trying to give you the basic structure and to get you thinking about RBAC roles in the right way. You have to think about them in the right order and know where all of the little bits fit before it makes sense. I know for quite a few of us on the Exchange 2010 beta team we heard the explanation then three days later we went... Oh... So that's how it works.

From our experience the key when working with RBAC is to think of the triangle and to do things in the right order so that all of your bits are there and setup when you need them. Here is the finished Triangle of power that will help pull it all together:

Conclusion

RBAC isn't that hard. The key is to follow the triangle and create things in the right order. Create the Scope first, then the Role, then the Role Group. With the understanding that the Role Assignment is created to glue together these three pieces.

The only other thing with RBAC that makes it hard to work with, and communicate about is the fact that there are so many words in RBAC that contain the word role... it is easy to get confused about what is what. So here is a handy Reference of what each key concept means and the cmdlet noun associated with it. Make sure to communicate exactly what you are talking about when discussing this with others.

Scope - The scope defines the objects in AD that the Role can act on. It is considered the Where part of the triangle since it defines Where the role can act. The noun associated with scope is ManagmenetScope

Role - The Role is the collection of Role Entries that defines a set of cmdlets and parameters that can be run. It is the What part of the triangle since it defines What you can do. The PowerShell noun associated with Role is ManagmentRole

Role Entry - The Role entry is the actual entry on the role that defines an individual cmdlet and parameters on the role. This is the granular piece that you edit when you make a custom role to do only what you want. The PowerShell noun associated with Role Entries is ManagmentRoleEntry

Role Group - The Role group is a security group that defines Who gets a specific role or scope applied to them. It is the Who part of the triangle since it defines who is able to perform the actions. The PowerShell noun associated with role groups is RoleGroup

Role Assignment - The Role Assignment is the glue that holds together the Who, What, and Where. It is the AD object that pulls together the other three and defines Who can do What, Where. The PowerShell noun associated with the Role Assignment is ManagmentRoleAssignment

- Matt Byrd
Special thanks to Jonathan Runyon for some of the information used in this post.

By now you have seen our interviews with both Global Crossing and Lifetime Products and you've heard what excites them most about moving to Exchange 2010 àcheck out the video interviews with Global Crossing and Lifetime Products. We headed down to Memphis to visit one more  customer, Morgan Keegan & Company to get their take about why they too moved to Exchange 2010.  Morgan Keegan CIO John Threadgill, says the number one reason they chose to move to Exchange 2010 was the cost savings their organization expects to  see. (insert video here)

Wall Street and Technology  was also interested in what Morgan Keegan has to say about Exchange 2010 and their cost savings story is pretty compelling. Check it out here.

See for yourself how Morgan Keegan is doing more with less and saving money along the way.

Thanks,
Crystal Flores

In Microsoft CSS (Customer Service and Support) we deal with many anti-spam questions. While the anti-spam features that come out of the box with Exchange 2007 provide a robust level of protection against unwanted garbage in your inbox, there is still a lot of confusion out there as to how all the parts work together. The purpose of this post is to dispel some misconceptions about the E2007 AS features (where applicable differences introduced in Exchange 2010 will be pointed out as well). I present you the top 6 SMTP anti-spam myths - revealed! (drum roll)

Myth 1: Creating a hub transport rule to set the SCL will affect the behavior of SCLDeleteThreshold and SCLRejectThreshold.

This myth applies particularly to the case of Hub server role with anti-spam agents installed. While it is fine to install the anti-spam agents on a hub transport server, expecting that a hub transport rule with "set the spam confidence level to value" action will influence the content filter delete/reject/quarantine is false.

• This is a misconception due to where in the transport pipeline the content filter agent (which does the actual deleting/rejecting) fires. If we run Get-TransportPipeline we will see that the content filter agent fires at OnEndOfData (EOD) while the transport rules fire during the OnRouted stage.

Since the Transport Rule Agent fires after the Content Filter Agent (CFA) anything the rule action does will have no effect on CFA behavior.

Conversely while this would work on an Edge server anti-spam solution due to the location in the pipeline where the Edge rule fires this actually leads me to Myth 1b.

Myth 1b: Setting an edge rule to inspect SCL value that the content filter sets will work out of the box.

Unlike Hub Transport Rules Agent, Edge Transport Rules Agent fires BEFORE the content filter.

So if we leave the default settings with Edge rules firing first we have nothing to inspect or act on since the CFA has not gotten the message yet.

Your best bet for using rules that operate in conjunction with content filtering is to run content filtering on an Edge role and the Transport Rules on the Hub role.

Myth 2: You need the CFA to move items to junk mail folder.

Unlike SCLDeleteThreshold and SCLRjectThreshold, SCLJunkThreshold is a store setting. It is a combination of a hidden rule in the client's inbox when junk mail is enabled and the value of the SCLJunkThreshold attribute on the OrganizationConfig and/or mailbox object within Active Directory that determines and moves the message to the junk mail folder when over the junk threshold.

The only role the CFA plays here is stamping an SCL rating on the message which store then acts on. However, you can set the SCL rating through an Edge or Hub transport rule as well to get the same result.

Speaking of SCLJunkThreshold, this can be set in two locations: on the mailbox object via set-mailbox or on the OrganizationConfig object with Set-OrganizationConfig. I bring this up because it leads me to Myth 2b.

Myth 2b: Setting the SCLJunkThreshold on the OrganizationConfig object from an Edge server will affect junk mail actions.

Setting this will actually do nothing. Since the edge server by definition is not part of an exchange org, and since this setting is only utilized by the hidden inbox rule, changing this value will not do anything.

While we are on junk mail thresholds I really have to pause (no, really) for a misconception that is so big that it probably deserves its own separate blog post, but since I have got your attention, I will just give it a myth number instead. Without further ado, here is Myth 3.

Myth 3: Exchange/Outlook junk mail filtering is one single monolithic entity.

This is the single largest point of confusion for Exchange administrators, and requires further elaboration due to the complex interaction between Outlook and Exchange junk mail.

Outlook uses its own SmartScreen filter technology separate from Exchange junk mail screening to filter junk mail. While the two sometimes agree Outlook ignores any SCL which Exchange may set on a message and uses its own criteria to determine the "spaminess" of a message. This is the client side filter (It should be noted here that Outlook will honor an SCL of -1. The above only applies to any SCL ratings other than -1.).

Now here is where the confusion begins. The server side filter that Exchange store uses to deliver messages to junk mail has two parts. There is the setting on the mailbox and/or OrganizationConfig object to determine at what SCL value we decide to send a message to the junk e-mail folder. However, for the spam to actually be moved to the junk e-mail folder, a hidden inbox rule has to be enabled. This rule can be enabled in a number of ways. One way is to log into your inbox with Outlook in cached mode. Another is to turn on junk mail filtering in Outlook Web Access (by going to Options and then Junk E-Mail).

Now if you weren't confused already here is the super confusing part- Enabling the rule with the Outlook cached mode way also enables Outlook's client side filtering as well. Turning it on in OWA but not in Outlook (either never logging in with Outlook or going to Tools, Options, Junk E-Mail Options, and clicking the "No Automatic Filtering" radio button in the Outlook client) only turns on the server side Exchange filtering.

In fact while troubleshooting issues with junk mail here in CSS we usually make sure that the client side filter is turned off so we know which filter is not working. Starting with Outlook 2007 sp2 the InfoBar will tell you if Outlook client filtering moved the message or some other filter did the deed (Exchange, rule, 3rd party, etc). See http://support.microsoft.com/kb/968383 for an overview.

If you are not running Outlook 2007 sp2 an alternate way to check if Outlook is moving the message is to fire up MFCMapi, open the mailbox in question, browse to the Junk E-Mail folder, and then highlight the email of interest. Search the lower pane in the "Named Prop Name" tab for a property with the name of "0x859C=34204 = PidLidSpamOriginalFolder, dispidSpamOriginalFolder".

If this property is present then the Outlook client filter moved the message to junk mail.

Your best bet when deploying Outlook clients that will be used exclusively with Exchange is to not install the Outlook SmartScreen filter, as this feature complicates troubleshooting and will not be as effective as the Exchange server based Content Filter Agent.

Speaking of Junk Mail filter behavior we should take a brief stop at Myth 3b.

Myth 3b: Running Set-OWAVirtualDirectory -JunkEmailEnabled $True/False will turn on/off the server side filtering.

This is false. The above cmdlet will only influence the presence of the Junk E-Mail management option in OWA. It has no effect on the server side filter. We get asked all the time if there is a way to programmatically enable junk mail filter within OWA and while there are scripts out there on the Internet that do just that we do not directly support any of them. While these scripts may work now, they are always subject to break with each new RU/SP/version of Exchange. In Exchange 2010 we have a new set of cmdlets, Get-MailboxJunkEmailConfiguration/Set- MailboxJunkEmailConfiguration. These allow us to view the blocked senders and domains in addition to enabling the hidden junk mail rule on a particular mailbox.

Since we are on the topic of Edge servers lets go to myth 4 (ok we weren't talking about Edge servers but that last myth got me really confused and I didn't have a good segue handy)...

Myth 4: You need an Edge server to use safe list aggregation

Safe list aggregation is a feature of exchange 2007 anti-spam is where running the update-safelist cmdlet for a particular mailbox will update the msExchangeSafeSenderHash attribute on the mailbox object in Active Directory with the safe senders list from a user's mailbox. This feature is a useful way to prevent false positives from being generated by anti-spam agents.

A common misconception is that this requires an Edge server with an edge subscription. However, this feature will work on a hub transport server with the anti-spam agents installed. The CFA will read these values from AD much in the same way it would read them from ADAM if we were running on an edge server subscribed to the AD site.

Since we are on the subject of safe list aggregation, I would be remiss in not pointing out that some people add themselves to their outlook contact list. By default all outlook contacts are added to the Safe Senders list. You can see where I am going with this. Safe list aggregation will populate the mailbox's safe list hash in AD resulting in their own email address bypassing anti-spam checks. Since many spammers like to send messages spoofing the recipient address this would allow these types of spam to end up in the clients' mailbox. Because this value is hashed when placed into AD, there is no way to parse the information without logging into the user's mailbox. However In Exchange 2010 we have the Get-MailboxJunkEMailConfiguration/Set-MailboxEMailJunkMailConfiguration cmdlet come to rescue us again where we can view and configure this information from a remote power shell session.

Also it might be informative to note here that you no longer have to run the update-safelist cmdlet either manually or via a script in Exchange 2010 as it is now run automatically out of the box with no special configuration.

For more information on Exchange 2007 Safelist Aggregation can be found here: http://technet.microsoft.com/en-us/library/bb125168.aspx

Myth 5: Putting a server IP on the InternalSMTPServers list of the TransportConfig object AND IP Allow List is a good idea.

A bit of background before we tell you it's a bad idea (just a bit I promise).

Putting an IP on the IP allow list via Exchange Management Console or Add-IPAllowListEntry cmdlet allows any connection coming from that IP to bypass all anti-spam filtering except sender/recipient filter. It gives any message a SCl of -1 that originates from that IP.

The internal servers list is a list of IPs in your perimeter that you wish to bypass SenderID/IP BlockList provider/IP block list agents. It is NOT intended to bypass all AS filtering. InternalSMTPServers will cause the anti-spam analysis to be performed against the "Received" headers rather than the incoming protocol. In the case of a relay between the Internet and your first Exchange hop, this will prevent Exchange from seeing all email (spam and legitimate) as coming from the same source and blocking that source.

As you can see, these features are not the same. So, putting a server IP in both lists will not give you results. One of these is that we will still stamp an SCL rating on the message and not give the expected "-1" for a server on the allow list.

Below is a comparison of the anti-spam headers on a message of a server on the allow list and a message from a server on both:

Figure 1 above - Headers when only on IP Allow List

Figure 2 Header when on both IP Allow and InternalSMTPServers lists

As can be seen the results are completely different. For a great over view of the InternalSMTPServers attribute (as well as other aspects of the Anti-Spam agents) please take a look at this great post here: http://msexchangeteam.com/archive/2008/06/23/449070.aspx

Finally we arrive at our last myth.

Myth 6: Running Enable-AntispamUpdates forces you to download all windows updates to your Exchange server.

Enabling automatic anti-spam updates does use the windows automatic update API and does require that you opt in one time for windows update for the AS server. However, it does not require that you download all the other updates available on Windows Update like service packs and rollups etc.

In fact the anti-spam update does not use the schedule available in AU but instead uses its own download timeframe listed here: http://msexchangeteam.com/archive/2007/01/03/432050.aspx

When running the cmdlet from your edge server (or HT server with the AS agents installed) you can specify "RequestNotifyDownload" value for the -MicrosoftUpdate parameter. This maps to the "Notify me but don't automatically download or install them" radio button on the Automatic Updates client (for Windows 2008 this is worded as "Check for updates but let me choose whether to download and install them").

The above is only available from EMS and not the GUI in EMC.

Ok so that's it. I hope I was able to clear up some confusion on how Exchange anti-spam agents function.

Special thanks go to Scott Landry and Dave Forrest for their invaluable assistance with this post.

- Tom Kern

<edit 11/12/09 10:48pm: Added some additional information, links, etc.>

On November 9^th, many of our web properties were updated with new content and information to coincide with the general availability of Exchange 2010. With all the new information out there, where do you start? What should you be sure not to miss? Below is quick list of items and sites you should definitely check out.

The Virtual Launch Event Site:

If you’re lucky, you had the opportunity to attend one of the two events this week that included an Exchange 2010 keynote: TechEd EMEA in Berlin or Exchange Connections in Las Vegas. However, anyone can attend the Virtual Launch Event online and watch Stephen Elop on stage with Julia White, who demos the new features of Exchange. Or you can check out Rajesh Jha on stage at Exchange Connections, with guest appearances from many members of the Exchange team in Redmond. And if you are looking for more informal interviews that capture the excitement of launch– then head over to TechNet Edge where you will find videos created by members of the Exchange team and our amazing evangelists.

After watching one of the keynotes out on our Virtual Event site, take a minute to explore and discover all the other videos and resources the Exchange team has developed. We have a 12 session track dedicated to Exchange and Unified Communications, and also a virtual booth – where you can find Exchange demos, customer case study videos, and resources such as the searchable Exchange 2010 Customer Case Study.

Exchange TechCenter

The Exchange TechCenter experienced a complete design and content refresh. Our Exchange TechCenter maintains its charter or providing resources for our IT Pro customers to download and get started with the product and is a front end to Help, community and support content. IT PROs and Exchange admins can easily discover all the resources needed to be successful with Exchange Server. Check it out:

For the 2010 launch, the new center features easy access to the Exchange 2010 bits, a dedicated TechNet forum for Exchange 2010, key downloads like the Exchange 2010 Deployment Assistant that we mentioned in a recent blog post, Exchange MVPs, Exchange 2010 videos and webcasts, community launch events, and more.

Microsoft.com/Exchange 

Looking for customer case studies? Product news and reviews? Or perhaps information on licensing and pricing? The Microsoft site contains all this information, along with the ability to live chat with a Microsoft representative about the product.

Tweet!As a member of the Exchange community – you have the opportunity to interact with members of our team through blogs, forums, and now a Twitter feed. Get all the latest Exchange news direct from the product team!

What’s next? We will have new webcast, videos and virtual labs coming out in the next couple of months – all of which will be highlighted here on the Exchange Team blog.

We heard concerns from our early adoption Exchange Server 2010 customers regarding transitioning from Exchange Server 2003 and/or Exchange Server 2007 in a few key areas. One of which is the fact that you, Exchange/IT administrators, are burdened with complex migration steps (multiple firewall rules, multiple certificates, multiple external URLs/ports for clients). This complexity means there is opportunity for misconfiguration, which causes deployments to stall-not to mention a lot of frustration.

Based on this feedback and our desire to help streamline the deployment experience, we created Exchange Server 2010 Deployment Assistant which can be accessed at http://technet.microsoft.com/exdeploy2010

It allows you to create Exchange 2010 on-premises deployment instructions that are customized to your environment. The Assistant asks a small set of questions, and based on a your answers, it provides a finite set of instructions that are designed to get you up and running on Exchange 2010.  The idea is that, instead of wading through the 2000+ topics in the Exchange 2010 library, you can answer a few simple questions, and the Assistant gives you just enough customized content to do the upgrade.

More content is coming:
In this version of the Deployment Assistant, content is available for customers upgrading from Exchange 2003. Additional upgrade scenarios will be available in early 2010 (upgrading from Exchange Server 2007, or a mixed Exchange Server 2003/2007 environment for example). We will also work on the integration of cross-premise scenarios.

Here is a screenshot from the Assistant, after the initial set of questions were answered and instructions generated.

We would love your feedback. Prior to this launch, feedback from Exchange subject matter experts and a group of our Microsoft field consultants and engineers who work with you every day was incorporated.  Feel free to leave a comment here, or send an email to edafdbk AT microsoft DOT com via the 'Feedback' link located in the header of every page of the Deployment Assistant. Also, please send us your 'success stories' after using this tool... we'd love to hear about them!

-Katie Kivett
Microsoft Exchange Deployment Assistant PM

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 (2x4 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 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

- Ross Smith IV

It is my distinct pleasure to announce today the global availability of Exchange Server 2010. This has been an amazing journey from conception to launch, and the team has delivered an unprecedented line up of innovations in this release. I am incredibly proud of the team and our product.

The dedication of the Exchange community working side by side with us to deliver Exchange 2010 has been inspiring for me. I want to thank you for your commitment over the past 3 years helping us develop new ideas, make product enhancements and test pre-release bits to ensure our final product is rock solid. I believe Exchange has the most impressive IT Pro and Developer community in the world today. We could not have shipped this product without you!

In return, I hope you realize the full value of everything Exchange 2010 offers. We are all working in a very challenging economic environment today. Being cost conscious has never been more important - but also helping your organizations differentiate themselves and compete effectively is just as critical. I am delighted to see how Exchange 2010 is helping early adopters accomplish these goals. I want to share just a sampling of their stories, so you can see for yourself.

Organizations are cutting costs and simplifying administration with Exchange 2010.

"Performance with large mailboxes greatly exceeds our expectations. With the growing amount of data that needs to be retained, it is not uncommon for us to have 30-gigabyte plus mailboxes, making these performance improvements crucial to our business. I have been using Exchange 2010 and Outlook 2010 for e-mail since June and have been extremely satisfied with the performance and the user experience. It is a robust, very stable platform. And, we found RBAC to be a huge benefit. That is something I have needed for a long time-to have more granular rights for administrators and lower-level IT staff to do targeted tasks." - Alexander Diaz, Enterprise Development Manager, Katten Muchin Rosenman LLP

"The cost savings from switching from fiber channel to SATA disks is about 70 percent. The I/O system of Exchange Server 2010 is really optimized. If you look at Exchange Server 2007, it's good; but Exchange Server 2010 is really great. You can significantly reduce the disk costs when you run Exchange Server 2010." - Thomas Keck, CIO, Elabs

"We're always moving users around. We've been doing that with custom scripts in Exchange Server 2003, but we will definitely be using the Online Move Mailbox feature in 2010. Now we can move them without taking the mailbox offline." - Allan Tagg, SVP, Global Messaging Exec, Bank of America

Organizations are improving everyday productivity and meeting the expectations of a new generation of workers with Exchange 2010.

"Our salespeople need to respond quickly to dealer concerns. With Exchange Server 2010 and voice-to-text conversion, within 20 seconds after a dealer leaves a voice-mail message, our users see an e-mail preview on their cell phone. Our mobile employees might check voice mail anywhere from 5 to 10 times a day, at 5 to 10 minutes a session. By using Office Communications Server 2007 R2 and taking advantage of the voice-mail preview feature in Exchange Server 2010, they can increase their responsiveness while saving more than 15 minutes a day. From a business perspective, that's an incredibly valuable productivity increase." - George Hamin, Director of E-Business and Information Systems, Subaru Canada

"Having Conversation View on the new mobile client is really nice. It provides an extremely fast and efficient means of surveying my inbox and taking needed actions on the go." - Steven Schafer, Director of Collaboration and Network Services, Global Crossing

"By taking advantage of Outlook Web App, employees can start being productive from new locations almost immediately. As soon as they get their workstation and network connectivity, administrators can quickly provide them with access to e-mail and IM at a moment's notice without having to manage a lot of logistics. That's tremendous. Just simplifying the process of giving our remote employees access to e-mail and IM with Exchange Server 2010 will increase the productivity of our IT administrators by at least 20 to 30 percent." - Dan Evans, Manager of Messaging and Collaboration, Morgan Keegan & Company

Organizations of all sizes are better managing risk and the cost of compliance with Exchange 2010.

"With Exchange Server 2010, we can give the auditors permission to pull mail out of mailboxes themselves, rather than having me pull the data and ship it to them in a PST file. Now the nine hours a month I spend on compliance will be cut down to zero. Getting rid of PST files using Exchange Server 2010 solves a whole series of nightmares that I'm sure every Exchange Server administrator has had" - Andrew McNair, Wintel Infrastructure Manager, Cell C

"By using the compliance features in Microsoft Exchange Server 2010, we can save about $400,000 in hardware and software costs. That's a big savings." - Joseph Nguyen, Systems Architect at a large U.S. university.

"With Exchange Server 2010, we can set up transport protection rules for things like social security numbers to comply with HIPAA and for voice mails to ensure that they can't be forwarded outside the company." - Thomas Dechmann, Senior Principal IT Technologist, Medtronic

I'm also particularly proud of the work the team has done delivering Exchange as a server and a service. This has been an incredible engineering endeavor that no one else in the industry comes close to delivering. Today, we've successfully scaled Exchange 2010 to more than 15 million Outlook Live accounts around the world and, moving forward, to millions more with Exchange Online. Our promise to deliver a seamless Exchange experience on premises with the server, in the cloud as a service or a combination of the two truly gives customers choice and peace of mind.

You can see more customer results from the case studies published today, read about the launch in press coverage, hear from MBD President Stephen Elop in his TechEd Europe keynote launching Exchange 2010 and this evening at the Exchange Connections conference in Las Vegas in my keynote.

I know many of you are already underway with your Exchange 2010 deployments and many more will be starting today. The Exchange Server 2010 bits are available for download now. As always, keep the feedback coming. Listening to customers and partners is how the team has made Exchange the premier e-mail solution across the globe and that's the way we intend to keep it.

Thank you!

- Rajesh Jha

Coming off the heels of our interview with Lifetime Products and hearing what excites them most about moving to Exchange 2010 (check out the interview here), I caught up with our customer, Global Crossing, while attending the recent SharePoint conference in Las Vegas.

Global Crossing is upgrading to Exchange 2010 to take advantage of the great new e-mail archiving, cheaper storage options, and as a replacement for its legacy voicemail system.

CIO Magazine also caught up with Global Crossing this week and posted this story on the cost savings the company hopes to realize by standardizing on Windows phones and EAS and moving off of BlackBerry smartphones.

I'd like to thanks Global Crossing for chatting with us. As you can see, they are very enthusiastic about Exchange 2010! See you soon.

-- Crystal Flores

We've just finished our 6 part series of webcasts on six key topics that developers need to know about as they start planning for moving their applications to Exchange 2010.  Those webcasts are now available as on-demand webcasts below, check them out today!  If you'd like a bit more human contact than these webcasts, then come join us at TechEd in Germany or Exchange Connections in Las Vegas next week; or the Microsoft Professional Developers Conference in LA November 17-19^th where we'll have great Exchange 2010 Web Services sessions and program managers from the Exchange Web Services team there to answer your questions and get your applications Exchange 2010-ready.

View the webcast now- Exchange Server 2010 Development (Part 1 of 6): Migrating Applications to Exchange Web Services

View the webcast now - Exchange Server 2010 Development (Part 2 of 6): A Deep Dive into Using Autodiscover Service in Exchange Web Services

View the webcast now - Exchange Server 2010 Development (Part 3 of 6): A Deep Dive into Impersonation and Delegation in Exchange Web Services

View the webcase now - Exchange Server 2010 Development (Part 4 of 6): A Deep Dive into Exchange Web Services Notifications (Push/Pull)

View the webcast now - Exchange Server 2010 Development (Part 5 of 6): A Deep Dive into the Exchange Web Services Managed API

View the webcast now - Exchange Server 2010 Development (Part 6 of 6): Best Practices for Building Scalable Exchange Server Applications

- Jason Henderson

I had a chance to go on the road and talk to a few of our Exchange 2010 early adopter customers. My first stop was in Clearfield, Utah where I met up with the folks at Lifetime Products. Lifetime Products is an early adopter of E2010, and appreciates the concept of a unified Inbox-and related cost savings. 

Check out the video:

CIO Magazine also thinks Lifetime Product's story is pretty compelling. Check it out here.

It was great chatting with the folks at Lifetime. As you heard, they are really excited about all the new features in Exchange 2010. I'll be back soon with more great customer videos.

-- Crystal Flores

We always talk about listening to customers and sometimes this is written off by many as 'marketing speak'.  In fact, we do take feedback seriously and no input is more important to our engineering processes than your voice.

Earlier this year we made a decision in one direction, and due to the feedback we have received on this blog and elsewhere, we have reconsidered.  In the coming calendar year we will issue an update for Exchange 2007 enabling full support of Windows Server 2008 R2.  We heard from many customers that this was important for streamlining their operations and reducing administrative challenges, so we have changed course and will add R2 support.  We are still working through the specifics and will let you know once we have more to share on the timing of this update.

So, keep the feedback coming.  We are listening.

Kevin Allison
GM Exchange Customer Experience

The management experience given by Exchange 2010 through PowerShell has been moved all the way from Local to Remote. This will mean that enterprise Admins will have to adjust their regular scripts to connect to Remote PowerShell instead of creating a local session.

Here are some examples on how can this be achieved and the differences that may have to be done in order to create the connection and run the cmdlets.

Using programmatic API

The programmatic API is the simplest method that will allow you to make a remote connection requiring only the Uri for the connection and a set of suitable credentials that need to be provided through a method.

SCredential credential = new PSCredential(username, password);

Note: The password here must be of type SecureString.

After you just need to create the connection Information that will allow the creation of the runspace.

// Set the connection Info
    WSManConnectionInfo connectionInfo = new WSManConnectionInfo(
      new Uri(liveIdconnectionUri),
      http://schemas.microsoft.com/powershell/Microsoft.Exchange,
      credential);

    connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Basic;

// create a runspace on a remote path
// the returned instance must be of type RemoteRunspace

Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(connectionInfo);

From here it is just you only need to create a PowerShell instance and fill it with your cmdlets and then invoke it through the run space we've just created. Here is a simple example with get-mailbox.

PowerShell powershell = PowerShell.Create();
      PSCommand command = new PSCommand();
      command.AddCommand("Get-Mailbox");
      command.AddParameter("Identity", mailboxName);
      powershell.Commands = command;
      try
      {
          // open the remote runspace
          runspace.Open();
          // associate the runspace with powershell
          powershell.Runspace = runspace;
          // invoke the powershell to obtain the results
          return powershell.Invoke();
      }
      finally
      {
          // dispose the runspace and enable garbage collection
          runspace.Dispose();
          runspace = null;
          // Finally dispose the powershell and set all variables to null to free
          // up any resources.
          powershell.Dispose();
          powershell = null;
      }

Using Programmatic API and Certificate Thumbprint

This uses the exact same syntax than the Programmatic API except that we would need to connect to a Uri that is has a Certificate Thumbprint enabled when we create the WSMAN connection in this syntax.

WSManConnectionInfo connectionInfo = new WSManConnectionInfo(
              "E75C847ADF7B355DAAC2C6D1A4EDD8284A0C0FDC",
              new Uri(certconnectionUri),
              "http://schemas.microsoft.com/powershell/Microsoft.Exchange");

Remote Request using a local run space (Scripting the remote class)

This is the best to create scripts and run your cmdlets using remote PowerShell. For this case, we have to script in the code a call to create a New-PSSession using our credential, the connection Uri and method of authentication. This is basically using the cmdlet:

New-PSSession -ConnectionUri Microsoft.Exchange -ConnectionUri $Uri -Credential $LiveCred -Authentication Basic

To do this, we have to create the Run space in which we will run the cmdlet and then create a PowerShell instance to add the cmdlet.

Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace();
        PowerShell powershell = PowerShell.Create();
        PSCommand command = new PSCommand();
        command.AddCommand("New-PSSession");
        command.AddParameter("ConfigurationName", "Microsoft.Exchange");
        command.AddParameter("ConnectionUri", new Uri(liveIdconnectionUri));
        command.AddParameter("Credential", cred);
        command.AddParameter("Authentication", "Basic");
        powershell.Commands = command;

Now invoke this cmdlet and set it as a variable on the local Run Space that will be used to do the remote calls.

try
     {
         // open the remote runspace
         runspace.Open();
         // associate the runspace with powershell
         powershell.Runspace = runspace;
         // invoke the powershell to obtain the results
         Collection<RemoteRunspaceInfo> result = powershell.Invoke<RemoteRunspaceInfo>();
         foreach (ErrorRecord current in powershell.Streams.Error)
         Console.WriteLine("The following Error happen when opening the remote Runspace: " + current.Exception.ToString() + " | InnerException: " + current.Exception.InnerException);
         if (result.Count != 1)
             throw new Exception("Unexpected number of Remote Runspace connections returned.");
         // Set the runspace as a local variable on the runspace
     powershell = PowerShell.Create();
     command = new PSCommand();
     command.AddCommand("Set-Variable");
     command.AddParameter("Name", "ra");
     command.AddParameter("Value", result[0]);
     powershell.Commands = command;
         powershell.Runspace = runspace;
         powershell.Invoke();

After we have done this, we can now do the remote calls that will be executed on the server side as script blocks.

         powershell = PowerShell.Create();
     command = new PSCommand();
     command.AddScript("Invoke-Command -ScriptBlock { Get-Mailbox -Identity:" + mailboxName + " } -     Session $ra");
     powershell.Commands = command;
     powershell.Runspace = runspace;
         return powershell.Invoke();
     }
     finally
     {
         // dispose the runspace and enable garbage collection
         runspace.Dispose();
         runspace = null;
         // Finally dispose the powershell and set all variables to null to free
         // up any resources.
         powershell.Dispose();
         powershell = null;
     }

- Mario Trigueros Solorio