Welcome to Kraft Kennedy

Named properties are a legacy mechanism by which Exchange reserves a property ID in a limited addressable space for use by applications.  The history of and issues with named properties are discussed in detail at the MS Exchange Team Blog here but the important note is that, with the explosion of Internet e-mail and numerous applications requiring Exchange to allocate named properties for debatably useful reasons, the number of named properties in Exchange can grow quickly toward predefined quota thresholds.  At this point users could be prevented from sending e-mail from Outlook.

Continue reading…

Every so often, you may encounter issues with DAG name and/or IP address resources going offline in your DAG Failover Cluster with the following (or similar) error code:

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.

Continue reading…

If you read Microsoft’s documentation and guidance regarding DAG design, you will note guidance that the greater number of DAG members that you have, the better.  This is because, with more DAG members, you can increase your resiliency in the event of member failures.

For example, with two, three-node DAGs, each DAG can sustain only a single member failure and still remain online.  Since a three-node DAG requires two voting members for quorum, two simultaneous voting member failures would result in a loss of quorum and the DAG going offline.  However, a single, six-node DAG (stretched across sites if desired) can sustain three simultaneous voting member failures before going offline.  Since a six-node DAG would require four online voting members, you could have three Mailbox server members online plus your Witness Server and sustain simultaneous failures in the three other Mailbox server members without losing quorum.
Continue reading…

This has been frequently blogged about by a number of people but this, in my opinion, can be one of the single biggest causes of issues when deploying a new Exchange 2010 environment. Unlike previous versions of Exchange, Exchange 2010 requires RPC encryption between clients and the server, by default. This is not an issue for Outlook 2007 or Outlook 2010 clients since both enable this encryption by default (and fail back to unencrypted communications if the server does not support it). However, legacy Outlook 2003 clients and potentially some third party applications do not enable this by default.

To enable Outlook 2003 to communicate properly, you can simply check the “encrypt data between Microsoft Office Outlook and Microsoft Exchange Server” in the MAPI profile properties (see below). You can also leverage Group Policies to enforce this setting or automate the deployment firm-wide.

Alternatively, if you need to disable RPC encryption to support other applications, you can disable RPC encryption requirement via the following cmdlet:

Set-RPCClientAccess -Server SERVER-NAME -EncryptionRequired $false

If you have multiple servers or have broken out your CAS and Mailbox roles onto separate servers, be sure to disable encryption for both your CAS servers and your Mailbox servers. While Exchange 2010 moved the RPC endpoint for mailbox access to the CAS role, the RPC endpoint for public folder access is still the Mailbox role. If you don’t disable RPC encryption on the Mailbox role as well, you won’t be able to connect to public folders from a client that doesn’t support RPC encryption.

If RPC encryption is disabled, you should make a note to re-enable it when your application set allows you so that you can further secure your environment.

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

As I’ve discussed in a few previous blog posts, there are numerous reasons that make Exchange 2010 a compelling upgrade for firms running Exchange 2003 or even Exchange 2007.  Specifically, most of my clients have determined the general storage efficiency enhancements and high availability and site resiliency improvements of the Database Availability Group (DAG) to be so compelling as to warrant aggressive timelines for an upgrade.  As a result, since the beginning of 2010, I’ve been involved in over 12 separate Exchange 2010 projects through August 2010, from architecture consulting and design through deployment and transition.  While Exchange 2010 is a stable and robust platform, there are a few quirks or subtleties that I wanted to share for those that are planning or beginning an upgrade.

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!

A common situation in organizations is to make calendars public, so that employees can see other employee’s availability, and collaborate better.  Users may also delegate rights to other users to view their messages, tasks, and contacts.  In these situations, people may rely on marking sensitive items private to hide them from other users.  In Outlook or OWA, other users will see a placeholder for the private items, but won’t be able to view any of the details.  However, you should keep in mind that this privacy is only a feature of the client application–Outlook or OWA–and is not inherent to Exchange.  Exchange itself does not support any kind of item-level security or privacy, and only has a field called “sensitivity” which is used by Outlook and OWA.  The client applications look at that field to determine whether to display the item.
Continue reading…