The first step is to create a contact that will serve as the recipient for the SMS message.  You will need to consult the settings for your particular carrier to find the format for this address.  For AT&T users, the format will be [10-digit phone number]@txt.att.net.  Once the contact is created, create an email rule similar to the one below:

This rule will tell Exchange to forward any message marked as “High Importance” to the contact that was created for the SMS address. While the above view is from a Windows Outlook client, the same can be accomplished through OWA, or in Entourage or Outlook 2011 for Mac.

Within a few minutes (depending on your reception and your carrier), you will receive a text version of the email message that was marked with high importance.  Because of the inherent 160 character limitation of SMS messaging, it is unlikely that you will be able to read the entire message, however the SMS message will alert you to the fact that you have a priority email and you can then read it in the native iOS email client. Keep in mind, the source of the text message may vary based upon your carrier. Here is how the text message may appear on an AT&T connected device. Note the highlighted portion of the text.

One thing to be careful of… Normal text messaging rates will apply, so if you receive a large number of priority messages, and do not have an unlimited messaging plan, this could get expensive very quickly.  You can lower the number of messages that get forwarded by tweaking the rule to filter for certain senders, but its always a good idea to be aware of your SMS plan.

While there are a number of hotfixes and other items included, there is also some key new functionality being introduced as well:

1. Cross-Site Silent Redirection for OWA – This is a tremendous improvement over current functionality where, if a firm leverages redirection between Client Access Servers in different sites (the preferred approach for optimal performance and implementation flexibility), users are prompted with a link and second authentication prompt if they login to a CAS server in a different site than where their mailbox is currently hosted.  With this new functionality, Exchange can be configured silently to redirect users to the correct CAS server in this situation (without reauthentication or prompting).
2. Address Book Policies – Address Book Policies provide the long-awaited native functionality support for what is typically referred to as GAL segmentation.  Previously, if firms wanted selectively to exclude some users or contacts from the GAL for specific subsets of users, the firm would need to create and manage security ACLs directly within ADSI.  This was unsupported in Exchange 2003 and 2010 and only narrowly supported for Exchange 2007 (with Dave Goldman’s specific whitepaper).  Address Book Policies will provide an object and policy based method for providing this functionality.
3. OWA Mini – This will be a lightweight, text-only version of OWA targeted for use on mobile devices or in low bandwidth/resolution scenarios.
4. Hybrid Configuration Wizard – This wizard will significantly reduce the number of steps required to streamline the process for establishing rich coexistence between an on-premises Exchange 2010 environment and Office 365 (formerly BPOS).

Due to the nature of the new features included, there is an Active Directory schema update required for SP2.

While modifying the FQDN of the SMTP Virtual Server certainly does mask this, the actual internal IP address of the server is still listed in the e-mail message headers and, as such, the identity of the server isn’t actually masked.  Furthermore, if a hacker were to compromise a perimeter firewall, not knowing the exact name of the server providing SMTP services will not deter much.

In most client environments, modifying this FQDN is mostly harmless, provided that the configured FQDN is resolvable in internal DNS.  This is because, when Exchange routing calculates a next hop, the announced FQDN of the appropriate SMTP Virtual Server is used.  If the configured name was not resolvable, Exchange would queue and bounce messages destined for a specific server if that server was the designated next hop for SMTP routing.  In addition to ensuring the configured FQDN is resolvable, it is also important to understand exactly why the change was made and the ramifications to doing so.

In one client environment I worked on, a specific Exchange 2003 server (SERVER2003_TLS, for example) was defined as the server to use for outbound communications to specific remote domains that required TLS (via an SMTP Connector and being defined as the associated bridgehead).  SERVER2003_TLS also had its SMTP Virtual Server FQDN configured to something along the lines of mail.client.com instead of the actual server FQDN.  mail.client.com was also the external and internal base URL for accessing OWA and ActiveSync services.

Everything worked fine in the Exchange 2003 environment because mail.client.com pointed to SERVER2003_TLS in DNS.  However, when Exchange 2010 was introduced and mail.client.com was moved to the client’s new Exchange 2010 load balanced CAS Array for coexistence purposes, TLS mail started bouncing with a “local loop detected” NDR.

The reason for the NDR was that a message sent to one of the remote domains defined on the SMTP Connector that required TLS would query SERVER2003_TLS since it was defined as the bridgehead for that SMTP Connector.  Since SERVER2003_TLS’s SMTP Virtual Server responded as mail.client.com, mail.client.com would be used for next hop routing.  However, since mail.client.com had been repointed to the Exchange 2010 CAS Array for CAS coexistence and these servers were also hosting the HTS role, these servers accepted the messages.  Since Exchange 2010 had not yet been configured with a direct outbound SMTP path to the Internet, all outbound Internet e-mail was routed across the coexistence Routing Group Connectors to one of two servers defined as transport servers for coexistence mail flow.

These Exchange 2003 servers then identified the same SMTP Connector for the configured remote domains requiring TLS and SERVER2003_TLS as the appropriate bridgehead, queried SERVER2003_TLS’s SMTP Virtual Server, received mail.client.com as the next hop, and the cycle continued until the message reached the maximum hop count limit.  Any number of solutions could have been used to resolve this issue once it was identified but changing the SMTP Virtual Server on SERVER2003_TLS to something other than mail.client.com was the preferred approach.

While this specific issue may not happen elsewhere, it highlights the need to truly understand the nature of changes made that alter default functionality.  In this case, changing the FQDN of the SMTP Virtual Server didn’t provide a lot of benefit to begin with but resulted in major mail flow issues down the road.

For more in my series on Exchange 2010 Notes from the Field, please click here.

By default in Exchange 2010, simultaneous RPC connections per user are limited to 20 (via the RCAMaxConcurrency parameter of the default client throttling policy).  In cases where many users share mailbox resources via delegate access, such as with attorney/secretary pairings, it is possible to reach the default limit of 20 simultaneous RPC connections for a mailbox.  Furthermore, the legacy Outlook 2003 client didn’t release any RPC connections associated with opening shared calendars until the Outlook client was closed.  If the RPC concurrency limit is reached, the affected user will receive an “unable to open your default e-mail folders” type error message when launching Outlook.

Many third party integrated applications require many simultaneous connections to Exchange via a defined service account due to how the application must interact with Exchange.  BlackBerry Enterprise Server and InterAction are two such applications that make many MAPI requests to Exchange through their service accounts and will quickly reach the defined limit of 20 simultaneous RPC connections.  Usually, a vendor’s documentation will dictate if the default Exchange 2010 client throttling policy must be modified to support their application but, in some cases, this is not the case.

Since client throttling is a good thing, it is not recommended to simply set any of the parameters associated with the default policy to no limit.  Instead, I recommend increasing the RCAMaxConcurrency limit on the default policy to a more reasonable value, such as 32 or 40.  For third party applications, I recommend creating a custom client throttling policy that either sets RCAMaxConcurrency to no limit or to a value that the vendor requires.  This custom policy can then be applied to the service accounts used by the third party applications.  Please note that, to set RCAMaxConcurrency to no limit, the parameter should be set to $null.  Setting the value to 0 will effectively prevent any MAPI access for the users to which the client throttling policy is applied.

For more in my series on Exchange 2010 Notes from the Field, please click here.

The store driver couldnt deliver the public folder replication message “Hierarchy (PublicFolder@client.com)” because the following error occurred: The Active Directory user wasn’t found.

These errors likely coincide with some public folder replication issues but, more importantly, can also result in NDRs when messages are sent to mail-enabled public folders!  This issue occurs because, even if you properly decommission Exchange 2003, the Servers containers within your legacy Exchange 2003 Administrative Groups still exist within Active Directory, albeit empty.  Exchange assumes that, if a Servers container exists (even if it is empty), a System Attendant object will also exist somewhere inside of it but, if all of your Exchange 2003 servers have been decommissioned, those System Attendant objects actually do not exist.

This issue has been recognized as a bug within Exchange (see the MS Exchange Team Blog article here) and a fix a scheduled for an upcoming Update Rollup release (perhaps Update Rollup 5).  In the meantime, you can safely delete these empty Servers containers via ADSI Edit but make sure that these containers completely empty before doing so.

For more in my series on Exchange 2010 Notes from the Field, please click here.

To resolve this issue for the specific case at my client, we simply needed to enable inheritance on the OUs or users where it had previously been disabled.

Resolving this issue for members of privileged groups is a bit more complicated.  Basically, the lack of inheritance is by design for users that are members of privileged AD groups.  Every hour, a background process runs on domain controllers to apply the permissions assigned to the AdminSDHolder template object to all members of privileged groups.  You can review the permissions that will be applied by launching Active Directory Users and Computers, enabling Advanced Features within the View menu, and then reviewing the security permissions of the AdminSDHolder object within the System OU.

The true solution is to provide administrators with separate administrative-only accounts (e.g. JohnAdmin.admin) that are members of the required AD groups and have these administrators use normal, non-privileged accounts (e.g. JohnAdmin) for e-mail functionality.  In some environments, this may not be possible and, as a result, you have two workarounds.  First, you could modify the permissions on the AdminSDHolder template object to include the required Exchange permissions.  I don’t recommend this since you would be modifying a fairly important and engrained aspect of Active Directory for what should be a few isolated users.  Instead, you could temporarily enable inheritance on your administrative users and, as long as you configure these users’ ActiveSync devices before the next application of AdminSDHolder permissions, it will work just fine.  Once an ActiveSync device is provisioned for the user, these special Exchange permissions are no longer required.

For more information on AdminSDHolder, the associated default permissions, and instructions for modifying these permissions, please refer to http://policelli.com/blog/?p=136.

For more in my series on Exchange 2010 Notes from the Field, please click here.

The issue can be caused by search folder problems in the Exchange 2003 mailbox and similar issues were fixed in Exchange 2007 via Service Pack 2.  Microsoft describes ways to purge the disconnected Exchange 2003 mailbox at http://support.microsoft.com/default.aspx?scid=kb;EN-US;930363 but the workarounds involve either a number of manual steps or reducing your mailbox retention settings to 0 days and allowing normal Exchange online maintenance to purge the mailboxes.  The latter would also purge any legitimately deleted mailboxes that you may want to retain for some period of time so the safest workaround may be to just wait for your normal online maintenance procedures to purge the mailboxes for you (30 days by default).

For more in my series on Exchange 2010 Notes from the Field, please click here.

Upon reaching your named properties threshold, Exchange will record a number of event log errors (generally MSExchangeIS event ID 9667) and e-mail sent from Outlook clients could be bounced back with a 5.2.1 NDR.  E-mail sent from OWA was unaffected in the client environments I’ve worked.  Unfortunately, I have seen similar issues when deploying Exchange 2010 into an Exchange 2003 environment, with or without Outlook 2007/2010, where Exchange 2010 users would see e-mail sent to Exchange 2003 users bounced back.  E-mail sent between Exchange 2010 users only or between Exchange 2003 users only were unaffected.

To resolve this issue, you need to increase the quota thresholds associated with named properties via a registry change per mailbox database in Exchange 2003 (or Exchange 2007) and then dismount/mount each database.  This process is described at http://support.microsoft.com/default.aspx?scid=kb;EN-US;820379 and I strongly recommend that you consider proactively increasing Exchange 2003 named properties quotas to 16,384 before moving any mailboxes to Exchange 2010 to avoid any potential issues.  In addition, there is a great MS Exchange Team blog post here that discusses named properties and some misconceptions in detail.

For more in my series on Exchange 2010 Notes from the Field, please click here.

Cluster IP address resource ‘Cluster IP Address’ cannot be brought online because the cluster network ‘Cluster Network 2′ is not configured to allow client access. Please use the Failover Cluster Manager snap-in to check the configured properties of the cluster network.

Since all end user client connectivity occurs through the CAS role, this is generally not a user-facing issue but integrated applications that depend on the DAG name for connectivity would fail to connect in this case.  The most common example of an application that could potentially be affected is an Exchange-aware backup application.

In most cases, the solution to this problem is fairly straightforward.  Launch Failover Cluster Management to connect your DAG cluster object, right click your cluster network associated with client access (if you break out client access and replication traffic), and click Properties.  Uncheck the “allow clients to connect through this network” checkbox, click Apply, re-check the checkbox again, and click Apply/OK.

Once this has been completed, right-click on your DAG IP address resource within Cluster Core Resources and bring it online manually.  Then bring your DAG name resource online, test pinging your DAG name, and then test your application.

Also, if you want to manually move the ownership of your cluster resources between nodes in the DAG, you can leverage the following PowerShell cmdlets.  This can be particularly useful after executing a failover to/failback from an alternate data center or merely because of normal server maintenance.

Import-Module FailoverClusters

Move-ClusterGroup -Name “Cluster Group” -Node SERVER-NAME

For more in my series on Exchange 2010 Notes from the Field, please click here.

A list of topics that I plan to cover can be found below and links will be created to each post as it is released.  In addition, as I uncover additional topics to discuss, I’ll add to this list going forward.  Please check back often!

• RPC Encryption
• Multi-Site Database Availability Group Design
• Database Availability Group Name/IP Resource Failures & Maintenance
• Named Properties Quotas
• Mailbox Move “Failed to cleanup the source mailbox” Errors
• ActiveSync and Active Directory Permissions Inheritance
• Public Folder Replication and Mail Flow Issues
• Client Throttling and Max Concurrency
• SMTP Virtual Server Changes

I hope you find this topics useful as you plan for or begin your own upgrades!