Exchange Queue & A: Upgrade Issues

Article
08/31/2016

There can be a number of unanticipated issues when upgrading to Exchange 2010, including address list segregation, relocating security groups and hosted messaging.

Henrik Walther

Segregating Address Lists

Q: We’re currently in the planning stages of upgrading from Exchange 2007 to Exchange 2010. We’re a large enterprise customer with hundreds of departments. We need to be able to segregate address lists so only a specific group of users can see their own address list. We put this in place following the “Configuring Virtual Organizations and Address List Segregation in Exchange 2007” white paper and it works great.

Now we’ve realized Exchange 2010 doesn’t support address list segregation. This is a showstopper for our upgrade process. Do you know of any way to get around this? Do you know what the Exchange product group is planning with respect to address list segregation? Will we have to deploy Exchange 2010 in hosting mode?

A: This is a good question, and well-timed. Exchange 2007 and previous versions of Exchange server support segregating address lists by setting specific permissions on the address list object in Active Directory. The plan with Exchange 2010 was to use similar steps to those used in the white paper you mentioned. When Microsoft was updating that white paper for Exchange 2010, it found issues such as users missing from the default global address list showing up in other departments or company address lists. In some instances, Outlook would crash when users logged into their mailbox. So there won’t be an Exchange 2010 version of that white paper.

You can try Exchange 2010 in hosting mode to segregate address lists. Keep in mind that Exchange 2010 in hosting mode is made for service providers hosting the Exchange messaging infrastructure for customers, not for internal address list segregation. There are also a lot of things not supported when running Exchange 2010 in hosting mode.

So are you stuck? The answer is yes—but just for now, not forever. Wait for Exchange 2010 SP2 to release to manufacturing (RTM). This service pack will introduce new functionality called “address book policies.” These will let you segregate address lists, as with previous versions of Exchange. The approach will be different, as you’ll no longer have to mess with ADSIEdit to set specific access control lists (ACLs) on address list objects. You’ll create one or more address book policies and assign it to a group of users. Check the recently published post on the Microsoft Exchange Team blog, where they announced these address book policies.

So what’s the timeline here? When can you expect Exchange 2010 SP2 to RTM? Most likely some time in late 2011.

Moving Security Groups

Q: We’ve just migrated from Exchange 2007 to Exchange 2010. Overall, we’re impressed with this latest release of Exchange server. As you know, during the Exchange 2010 preparation of Active Directory, Exchange 2010 setup creates a set of security groups and places them in an organizational unit (OU) in the root domain named “Microsoft Exchange Security Groups.”

In Exchange 2007, because the security groups have a well-known GUID and a distinguished name that can change, we were able to move these groups to other OUs in the root domain or even other domains within the Active Directory forest. Is the same true for Exchange 2010?

A: A lot has changed with Exchange 2010—especially the permission model, which is now based on role-based access control (RBAC). This means we’re a little more bound in regard to what we can do when it comes to moving the Exchange 2010 security groups around in the Active Directory forest.

With Exchange 2010, you should move all groups (more specifically role groups) to the same OU. You could also move the existing OU to the new location within Active Directory in order for this to work properly and be in a supported mode.

What about new role groups created after the groups or OUs have been moved? Will they be created in the default OU location or in the new OU location? Although you can’t specify an OU when running the New-RoleGroup cmdlet, you don’t need to worry about this. Exchange is clever enough to create any new role groups in the new OU.

Do Away with Delays

Q: We’re running Exchange 2010, but we still have Outlook 2003 clients. Some of those clients are running in cached mode because they’re published via a terminal server solution. Consequently, we’ve been hit by latencies caused by the lack of support for User Datagram Protocol (UDP) in Exchange 2010.

We followed your “Concern: Is having Outlook 2003 clients going to prevent me from deploying Exchange 2010?” TechNet Wiki article. We also saw your note about setting the polling frequency interval to as low as five seconds, which helps a lot. Our users don’t want to see any kind of delay in Outlook 2003, and we can’t move away from the published Outlook 2003 client. So we were wondering if you have any other tricks up your sleeve to get rid of all delays?

A: As you know, Exchange 2010 won’t support UDP-based notifications, and you can’t set the polling frequency interval lower than five seconds. If you do, the RPC Client Access (RPC CA) service won’t start.

There is good news, though. The Exchange team has once again listened seriously to customer feedback on this. So they plan to re-introduce UDP support with Exchange 2010 SP1 Roll-Up 3 (RU3). This is scheduled to release in March 2011. This means you need to include UDP in the RPC virtual services you create on the load balancing solution in your Exchange 2010 messaging infrastructure.

Check out the official announcement about the re-introduction of UDP.

Upgrade Hosted Messaging

Q: We’re a large services provider using a Hosted Messaging and Collaboration (HMC) 4.5 (Exchange 2007) solution to host mailboxes for our customer base. We’d like to upgrade the HMC 4.5 solution to Exchange 2010. More of our customers are asking for Exchange 2010 features like personal online archives and the new Outlook Web App (OWA) interface. Can you tell us how we get the HMC 4.5 solution upgraded to Exchange 2010?

A: You can upgrade from HMC 4.5 to Exchange 2010. Unlike Exchange 2007, Exchange 2010 natively includes multitenancy features (aka multiple Exchange organizations in the same forest). This means you no longer need HMC-specific things like the Microsoft Provisioning System (MPS).

Exchange 2010 in hosting mode is a different beast than HMC 4.5, so there’s no support for doing a direct upgrade from Exchange 2007 to Exchange 2010 in the same forest. Instead you’ll have to do a cross-forest migration to a brand new Active Directory forest. Here you’ll install Exchange 2010 using a special “/hosting” switch.

You should also know there are several things that won’t be supported in an Exchange 2010 hosting environment where Exchange runs in “hosting mode.” Non-supported features/scenarios include:

Exchange Management Console
Public Folders
Unified Messaging Server role
Federation
Global Address List Synchronization (GalSync)
Business-to-Business features like cross-premises message tracking and calendar sharing
Information Rights Management (IRM)
Managed folders
Outlook 2003 support (EnableLegacyOutlook)
Edge Transport Server role (more specifically EdgeSync support)
In-place upgrades (upgrading current Exchange 2003/2007 org to Exchange 2010)
Resource forest topologies (separate Exchange forest and account forests)
Parent-child domains
Multiple Active Directory sites (where there’s a mix of hosted and non-hosted)
SSO Active Directory Trusts
Dis-contiguous namespace
Disjoint namespace

There are a lot of detailed steps on how you should get started (more than we can cover here). So let me direct you to the “Exchange 2010 SP1 Information for Hosted Service Providers”TechNet Wiki article.

The End of HMC Support

Q: We’re a hosted services provider in the planning stages of migrating from two separate HMC environments—one running HMC 4.5 and one running HMC 3.5. Do you know when support ends for HMC 4.5 and HMC 3.5, respectively?

A: You should really get started, especially with the HMC 3.5 upgrade. Microsoft will continue to support HMC 4.5 and HMC 4.0 through December 2011. HMC 3.5 will be supported for existing customers until July 2011.

_Henrik Walther** is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years experience in the IT business. He works as a technology architect forTimengoConsulting (a Microsoft Gold Certified Partner in Denmark) and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services).* You can e-mail Walther at v-henwal@microsoft.com.* _