Summary

A cumulative security update has been recently released for Internet Explorer 6 for Microsoft Windows XP Service Pack 2 and Microsoft Windows Server 2003 Service Pack 1. This update changes the way in which Internet Explorer handles some Web pages that use ActiveX controls and Java applets. As we have seen some questions around this, we wanted to cover them here.

The below document describes the changes that this Update introduces, how it affects Outlook Web Access and how we can mitigate the effects of this change.

What has changed and why

A Cumulative security update for Internet Explorer (MS06-013) introduced a change in the way IE handles Web pages that use ActiveX controls and Java applets.

After you install this update, you cannot interact with ActiveX controls from certain Web pages until these controls are enabled. This change was deemed necessary for security reasons to avoid the remote code execution. Outlook Web Access is affected by this change as follows:

Symptoms related to Exchange

We see red X in the body of Outlook Web Access (OWA) email, when we use OWA with IE 7 (Windows Vista). The Red X error will not allow to compose a new message, reply to an email, or create a new task, note, journal entry, or an appointment. It may also not allow change any configuration in the Outlook Web Access options folder. The body of the message is grayed out, or has a Red X as below:

On a computer on which you have installed update 912945, you must first click one time in the compose frame in Outlook Web Access before you edit text. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

912945: (http://support.microsoft.com/kb/912945/) Internet Explorer ActiveX update

On a computer on which you have installed security update 912812 that is described in security bulletin MS06-013, you must first click one time in the compose frame in Outlook Web Access to activate the edit control.

Impact of the update when installed on a desktop

Installing the Update 912945 or 912812 on a computer which uses Internet Explorer 6 causes Internet Explorer to now prompt before the control is enabled and used.

Thus Internet Explorer 6 with this update installed will now prompt that you click one time on ActiveX control to enable the edit control.

Example Picture:

Impact on OWA

Since Outlook Web Access uses ActiveX controls heavily this could mean clicking to enable a control whenever we click on Compose a new e-mail message , Reply to an e-mail message, Create a new contact, or appointment to name a Few.

Example Picture:

Windows Vista

This also affects OWA when accessed from Windows Vista as Windows Vista no longer includes support for the ActiveX control that is used for HTML editing in Outlook Web Access.

ActiveX controls are unsafe for IE users who turn on the browser's ability to download and activate ActiveX controls within a web page. The problems occur when a user surfs to a non-trusted web page and that web page contains a malicious ActiveX control. This is a very common means of distributing spyware; the easiest way to avoid it is to not install ActiveX controls from non trusted sites. This is the reason why ActiveX control is eliminated from IE 7.

Solution

Exchange 2000/2003:

On an Exchange 2000/2003 server installing update 911829 on the Exchange server enables a new editor for Internet Explorer. The new editor uses an Internet Explorer "iframe" instead of an ActiveX control. Thus after you apply update 911829, you are not required to first click to enable a control in the compose frame of Outlook Web Access before you edit text.

In Case of other websites which use ActiveX:

If you are a Web site owner, you can rewrite your Web pages so that users are never presented with a tooltip or a dialog box.

The following MSDN link gives us how.

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/activating_activex.asp

Compatibility Patch:

A compatibility patch that will disable the behavior of the Internet Explorer ActiveX update has also been released. (Update 917425) Note that this patch is temporary, and will only apply to KB 912812. This IE compatibility patch will not be available for future security updates. 

Pre - Internet Explorer 6

Since this update is currently released for Internet Explorer 6 only this would not cause any behavior change when a pre-Internet Explorer 6 browser is used.

Additional Reading

http://support.microsoft.com/kb/912945

http://support.microsoft.com/kb/911829

http://support.microsoft.com/kb/917425

While at issues surrounding Internet Explorer and OWA, you might want to also check our previous post on Exchange 2003 SP2 SMIME update released (KB 924334) - resolves compatibility with IE 7.

- Manoj Dhadwal

Exchange Server 2007 introduces a new mechanism for distributing Offline Address Books (OAB) that doesn't require Public Folders. It instead uses HTTP(S) and the Background Intelligent Transfer Service (BITS). There are several potential advantages of the new distribution mechanism including supporting more concurrent clients, reduced bandwidth usage, and more control over the distribution points. It is important to note that the new distribution mechanism requires Outlook 2007, but you can always choose to use both Public Folder Distribution and Web Based Distribution of OABs. That way, older clients can still access their OABs using Public Folders while Outlook 2007 clients can take advantage of the enhanced functionality.

The new web-based OAB distribution process depends on several components working together and without one of them will not function properly:

• OABGen – this service runs on the OAB Generation server to create the OAB. This must be an Exchange 2007 Mailbox server to support OAB Distribution
• Exchange File Distribution Service – this service runs on CAS servers and is responsible to getting the OAB content from the OABGen server.
• OAB Virtual Directory – This is an IIS virtual directory on a CAS server where the OAB is downloaded from.
• Autodiscover – Autodiscover runs on a CAS server and handles returning the correct OAB URL for a given client connection.

I think a few examples are in order to fully understand what is happening at a high level. The following diagram shows the topology which will be used for the examples. The assumption here is that all users have the same OAB and that OAB is distributed to all CAS servers.

Before a user even connects, the following happens:

1) OAB is generated on one of the mailbox servers in London

2) The Exchange File Distribution Service on each of the CAS Servers in London copies the new OAB Files from the OAB Generation Server in London

3) The Exchange File Distribution Service on the CAS server in Sao Paulo wakes up and copies the files over the slow link from the OAB Generation Server in London. This could take a while depending on the speed of the slow link. The new OAB is not made available until it is completely copied and verified

Note: Not all CAS servers will download the new OAB at the exact same time. There is a Poll Interval (default 8 hours) which starts the copying if there are new files. The first poll happens when the Exchange File Distribution Service starts, so the exact time a server polls will be different on each CAS server unless they all started up at the same time.

Once all of the CAS servers have the OAB, there are several user download scenarios:

User A:

4) Outlook Connects to the Autodiscover service to get the closest OAB distribution URL

5) Autodiscover returns the URL to one of the CAS servers in London

6) Outlook connects with BITS to the URL autodiscover provided and downloads the OAB

User B:

4) Outlook connects to the Autodiscover service to get the closes OAB Distribution URL

5) Autodiscover returns the URL to the CAS server in Sao Paulo

6) Outlook connects with BITS to the URL autodiscover provided and downloads the OAB

User B's mailbox resides in the London site since there are no mailbox servers in the Sao Paulo office, but his OAB will be downloaded from the closest CAS server.

User C:

4) Outlook connect to the Autodiscover service to get the closest OAB Distribution URL

5) Autodiscover returns the URL to one of the CAS servers in London

6) Autodiscover then finds a CAS server in the same site as the Mailbox Server in step 5

7) Outlook connects with BITS to the URL autodiscover provided and downloads the OAB

For any Internet user, the system has no idea where the closest CAS server is, so it defaults to a CAS server close to their mailbox server.

Each CAS server can handle a large number of concurrent connections since the download is happening via BITS and is being sent in small chunks at a time. Much of the bandwidth savings comes from only copying an OAB to a remote site once and then having clients at that site automatically download their OAB from there rather than using the site-link.

The OAB Virtual Directory supports direct connection as well as connections through ISA server. However, the BITS client does not support self-signed certificates so by default, OAB distribution points are created to use HTTP. You can enable SSL support if you provide a fully trusted certificate in IIS.

- Jim Edelen

Yesterday afternoon, I was trying to send a large video of my new born baby to my mom through Exchange Server 2007 Outlook Web Access (OWA). And when I tried to upload the video, OWA would not let me do so. Darn it - cannot even share my baby's first shower with my mother. And then I realized - hey, didn't I write some code to prevent such uploads?

Now, you might say that sending my baby's video does not exactly constitute the best use of company resources but I can think of a lot of Administrators that might want to have control over attachment size in OWA.

If you are an administrator of an Exchange Server of your organization, read on...

By default, Exchange 2007 OWA will let you send attachments of up to 30 MB in size. Depending on your situation, you might want to either increase or decrease this number as we have a mechanism by which you can change the default upload limits of file attachments in OWA.

For example: in order to send attachments which are 50 MB or larger:

1. You need to set the MaxRequestLength in web.config to a value larger than 50 MB. The MaxRequestLength in web.config is an ASP.NET setting that prevents requests larger than a certain length which was added to prevent DOS attacks. It is set to 30 MB by default and needs to be increased in order to send attachments larger than 30 MB. This could also be decreased to enforce a lower limit.

2. You need to increase the MaxSubmitMessageSize which is a readonly Mailbox property (MaxSubmitMessageSize = 0x666D0003) and this is where we are getting the 10 MB limit from.

This is read from the following places:

1. First read from Mailbox object of the user itself
2.  if not found as denoted by "unlimited", Transport Settings Container
3.  if not found as denoted by "unlimited", from Org Container (default read from Org Container)

In order to set the value, use the following tasks in the Exchange Management Shell:

1. set-transportconfig and then set MaxSendSize (this is in KBs) to 51200 for 50 MB attachments. This will set it for all users

Or

2. set-mailbox and set the MaxSendSize (this is in KBs) to 51200 for 50 MB attachments for a specific set of users.

Once you set either, you need to recycle store or not access the mailbox for about 15-20 minutes (to let store cache expire) in order for the size change to have affect. Also, the property is stored in AD and subject to replication delays.

One more thing that you need to be aware of (sorry, the list just goes on):

We have a Request timeout of 60 minutes for any attachment upload request or attachment download (in OWA Basic and Premium). So, if you are trying to upload a 50MB attachment over a 56Kbps link, you will time out and get a HttpWebException (e.g., the max upload is about 25 MB over a 56 Kbps link).

So, to summarize, there are two keys to send a large attachment:

1. Modify ASP.NET web.config settings.

2. Modify the MaxSendSize using either the set-TransportConfig (for all users) or Set-Mailbox for individual users.

And you need to

3. Make sure the total upload time will be less than 60 minutes (based on your size and the speed of your network link)

The web.config change is immediate but the MaxSendSize change takes time, due to caching policy (Mailbox cache, DSAccess delays, and replication delays).

Examples:

Web.Config change

By default, web.config under OWA Vdir (Microsoft\Exchange Server\ClientAccess\Owa) will have the following entry (by default, the max request size is approximately 30MB):

<system.web>

<httpRuntime maxRequestLength="30000" />

....

</system.web>

Change <httpRuntime maxRequestLength="30000" /> to <httpRuntime maxRequestLength="X" /> where X is the desired value in KBs. So, for 50MB, X will be approximately 50000.

Change per-user message size limit

Go to Exchange Management Shell, and type the following command:

Set-mailbox -id:"username" -MaxSendSize:50000

Where "username" is the mailbox identity. This will set the maximum message send limit to approximately 50 MB. You will need to restart store to see the effect immediately.

Change all-user message size limit

Go to Exchange Management Shell, and type the following command:

Set-transportconfig -MaxSendSize: 50000

This will set the maximum message send limit to approximately 50 MB. You will need to restart store to see the effect immediately.

- Raj Mukherjee

As many of you know, there will be a change next year in the transition dates for US daylight saving time. I won't go into all the gory details here, but if you want them follow this link http://www.microsoft.com/windows/timezone/dst2007.mspx This site will be updated to provide all the latest information about daylight saving time, including updates from Microsoft products affected by daylight saving time, as well as links to KB articles when they are available.

The Exchange team, along with Windows and Office have been giving this a lot of attention. We will be providing, free of charge, a solution for Exchange products in mainstream support. This solution will consist of changes in CDO to support these new dates as well as rebasing tool for calendar items that are already existent in users calendars. This rebasing tool is a server side tool. There will also be a client side tool available from Outlook. For products that are no longer under Mainstream support, these non-security updates will only be offered to customers that have an Extended Hotfix Agreement. For more information on the current support status of your Microsoft products and the Support Lifecycle Policy, please visit http://support.microsoft.com/lifecycle.

- Elizabeth Scott

After the success of Microsoft Exchange Server 2003, the Microsoft Exchange team was pondering what the next-generation Exchange Server should look like. We had several high-level goals, which we won't go into in this blog, but let's look at a few specific details that motivated us to redesign for Exchange 2007:

• Separation of server roles
  • Customers liked the idea of Exchange playing different server roles. For example, it was easier for administrators to maintain a Mailbox server role and a Transport server role separately. The separation was good for introducing new scenarios such as Unified Messaging and for building robust components.
• We wanted to create the first ever Microsoft Edge Transport server
  • Microsoft Exchange decided to introduce a new stand-alone server role in the perimeter network and to fulfill our customers' needs in that area. To achieve this, we had to design a unique gateway management model that isolates servers (active directory) in the perimeter network from the rest of the organization. It made sense to redesign instead of change Exchange 2003 behavior to achieve this goal.
• Efficient routing
  • For some time, we'd been thinking about how to change the underlying routing concept so that it's easy for customers to deploy Microsoft Exchange. The decision was made to move to an Active Directory-based routing concept instead of a unique Exchange routing group concept. Also, we wanted to figure out how to remove the link state concept to achieve robust server-to-server mail delivery. Redesigning helped give our architects the freedom to explore this area.
• A better extensibility model
  • With our customers' ever-growing need to extend the Microsoft Exchange platform, it was apparent that we needed to provide an agile and rock-solid extensibility layer. Redesign would empower agent developers
• Extraction from the Microsoft Windows code base
  • We didn't want our customers to have any protocol prerequisites, such as Internet Information Services (IIS), to installing Microsoft Exchange, and we knew that maintaining two SMTP code bases was expensive for us. The redesign helped Microsoft Exchange eliminate the IIS dependency from the SMTP architecture.
• In-house benefits
  • This redesign helped us achieve a much cleaner infrastructure to support new initiatives like the Trustworthy Messaging and Messaging Policy.
• Managed code for better security
  • As we made the redesign, the Microsoft Exchange team decided to take an additional step to use managed code. This provides better security against buffer overflow type issues and also enhances Microsoft Exchange developers' long-term productivity.

- Agnita Pandian

We get the following questions quite often:

What will be the difference between Standard and Enterprise versions of Exchange 2007?

What about CALs (Client Access Licenses)?

And the answers are on this page.

- Nino Bilic

A little while ago we posted about a little swag giveaway we wanted to do: see here and here for more details.

The wait is over. We know the suspense has been killing you!

Out of many excellent submissions (thank you!!) and with the help of highly sophisticated methods and complicated algorithms, the panel of judges (KC and Nino) produced their favorites. It was a close race!

Without further ado, the favorites were:

Grand Prize: Alex Zammit

First prize: Luke Edson

Second prize: Jeff Guillet

Honorable mention: Jeremy Reichman and Russ Kaufman

Congratulations! You will be receiving your swag packages in the mail!

• We chose Alex because of his continuous involvement in our Exchange newsgroups, where he helped others in multiple different cases. Additionally, he is keeping and updating a site where he shares different areas of the product with others. Great job!
• Luke was chosen because of his helpful replies on forums that he sent us links to. Looking around, he is definitely very active there!
• Jeff was chosen because of multiple helpful posts and great follow-up in our own Exchange newsgroups.
• Jeremy was chosen because of his active involvement in several different sites, covering a lot of Entourage questions, like this one for example.
• Russ was chosen because of work that he put into explaining and helping people with clustering and Exchange. Check this site for more info.

Thank you all for sending us your "proofs" - we had a good time checking them out. It is easy to see that Exchange community is quite active and helpful! Keep on helping!

- The Exchange Team

I wanted to draw some attention to this article as I think it is very cool as it shows how different analyzer tools have impacted you, our customers, and us in Support Services, when helping you.

Ed Beck wrote the article titled Exchange Analyzer Tools Success Stories, check it out! If you have any sort of feedback on those tools - we'll take it here too!

- Nino Bilic

As discussed in the earlier blog post introducing the new Exchange 2007 console, the Exchange Management Console GUI has been completely redesigned in Exchange 2007. While redesigning the Exchange Management Console for Exchange 2007, we used specific ground rules to help guide what features and settings should be exposed in the console and how the console itself should be built. These guidelines allowed us to ensure that we had designed a rich, functional tool that wasn't overwhelming and complex. It also ensured a console where additional feature GUI could be added to respond more effectively to customer requests.

Exchange 2007 GUI Console Goals and Ground Rules

To meet these goals, we developed the following ground rules and reasoning:

1. Rewrite our Exchange management console GUI to consume cmdlets directly. This means that the GUI shares business logic with the cmdlets (reuses the existing cmdlet business logic, really) and so we can easily add additional GUI in later service packs and releases simply by building on existing cmdlets.
   Note: In previous releases GUI elements had to use embeded business logic which translated to much more time and difficulty in adding GUI. These complications in adding GUI after the initial product release often led to configuration settings being exposed via registry keys or AD attributes that required KBs to be written to explain how to use them.
2. The most common features & settings used by most of our customers should always be exposed in the console.
   Note: In the past, Exchange 2003/2000, this hasn't been the case. For example, OWA administrators had to download a tool to manage very common settings.

Naturally, when moving from Exchange 2003 to the Exchange 2007 console using the above ground rules, there have been changes in what is exposed in the console. Those changes have led to some features being removed from the console GUI. The reasons for removing some specific GUI generally fall into one of the three following categories:

1. Feature was an advanced scenario, not commonly used by most customers and thus added to complexity and confusion (and clutter) in the GUI.
   Note: In previous versions of Exchange, features not visible in the GUI were frequently not available through any administrative interface. In Exchange 2007, we have a great mitigation for features not exposed in the console GUI - the Exchange management shell!! The shell provides rich error handling, validation, and discoverability for configuration settings - a feature not found in registry editor or ADSIEdit!
2. Feature was removed from Exchange 2007 entirely
3. Feature or setting was replaced by a better solution in Exchange 2007 - for instance it works out of the box without requiring the previously complex configuration.

Exchange 2007 GUI Result

Based on these guidelines, we did an evaluation of all GUI available in Exchange 2003 and also took into consideration any GUI required for new Exchange 2007 features. Then we made some hard choices on what belonged in the new GUI console for Exchange 2007 and where these should be placed. The surprising outcome was that only a handful of features are completely removed from the GUI, and there's actually more (quantity) GUI exposed in Exchange 2007 than there was in Exchange 2003.

Think of it a bit like cleaning out your garage. When you start out, it's a huge mess and there's no room anywhere to hold even the stuff you've already got. But by the time you've reorganized everything more efficiently, you find there's suddenly room to hold the car again!

The table below lists the various GUI features that were removed for Exchange 2007 RTM. Please have a look through the list and let us know your opinion on the decisions we made. In particular, we'd love to know if you think we missed anything critical from Exchange 2003 GUI or if the mitigations seem insufficient to you.

Did we get it right?

If you've made it all the way through that table, you're a trooper and we thank you! We've done lots of usability testing around the new Exchange 2007 console and the use of various Exchange 2007 features, but there's sure to be some folks who disagree with one or more of the items in the list above.

That's where you come in! Now that we have developed a much more flexible GUI architecture (ie - built on cmdlet business logic), it's far more possible than in previous versions of Exchange to correct problems in the GUI or to add in necessary GUI after the initial release of the product.

We'd love to hear from you if there are features you believe are missing from the GUI that should be there. It's our goal to keep the GUI simple and uncluttered - following the ground rules at the top of this blog post, but we definitely want to make sure we haven't overlooked some critical GUI features. Please let us know what you think!

- Evan Dodds and Amanda Langowski

There is a lot of emphasis on Exchange database backups. As a result most Exchange administrators plan regular backups with considerations for their specific environment. In the process of developing a backup solution, Exchange administrators have to answer multitude of questions: Shall I protect my databases with daily Full backups, or weekly Full complemented with daily Incrementals? Shall I use VSS technology with hardware clones? Shall I include multiple Storage Groups in a single backup set? How about the IO/CPU impact? Is there enough network bandwidth to complete backups within nightly backup window? Where shall I store backups? How often should I retire the backup media? How do I monitor backups? ...
 
Successful backups are all goodness and a must have, but do you know if your backups are good enough to restore, well at least good enough to bet your job on it?   One of the horror stories I remember hearing from PSS was an Exchange administrator thinking backups were succeeding daily came to realize the good backups were all overwritten by bad ones when excessive database corruptions finally took his database offline. There was no hope of restoring from backups, and repair was not an option either. Granted a good monitoring solution (and an administrator paying attention to monitoring reports) can go a long way, but unlike good wine backups don't get better with age. A restore process that was perfect six months ago can fail to work due to changes on the backup product, changes in configuration, changes in the process, or a simple change of personnel in charge of the restore.
 
Just like you schedule regular backups, you should also schedule regular testing of your restore procedures. I am not asking you to restore all your backups all the time, neither am I telling you to restore some of your backups some of the time, what I am advising is "to restore some of your backups all the time".  When it comes to being prepared for database failures, running weekly or biweekly restores to a Recovery Storage Group is a small step for an administrator but a giant step for your users' precious data.
 
Be prepared with backups, and don't be afraid to use them.

- Ayla Kol

Working with Active Directory directory service permissions related to Microsoft Exchange can be a complex task. This article has been written to aid Exchange architects in their understanding of how they may implement a split permissions model.

In many organizations, there are separate administrators for Exchange and Active Directory, which means that there is a need to delegate administrative functions, so that distinct boundaries of administrative rights are maintained. This is known as a split permissions model. In this type of model, operations are decentralized in that two or more operation teams manage aspects of Exchange and Active Directory. For example, one operations team might manage domain and forest functions (creating DNS zones, establishing new domains, and creating user accounts), while another operations team manages Exchange-related functions (installing Exchange servers, mailbox management, and e-mail routing). In these situations, certain rights must be delegated to all parties so that they may complete their prescribed job functions without compromising the operational and security boundaries.

Organizations that implement a split permissions model typically want to restrict permissions granted to administrative personnel to the extent possible, thereby ensuring accountability and increasing security.

While the majority of this guide focuses on understanding and configuring a split permissions model, there are several other permission-related topics that may need to be reviewed beforehand:

• Explanation of the schema, domain, and configuration partitions - http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/61080b45-8bce-4c23-b744-ed264d5f0b7d.mspx.
• Explanation of the administrative roles available in Exchange 2007 and the permissions granted - http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/2964c198-e624-46a1-ad3b-2e4f529466e3.mspx.

Permission Model

Unlike previous versions of Exchange, implementing a split permission model will require far fewer access control entries than before thanks to the implementation of property sets (see previous blog post). For an Exchange administrator to manage all mail-related properties, the administrator only needs the following permissions within the domain partition:

• Read and write access to the following property sets:
  • Exchange Personal Information
  • Exchange Information
• Read and write access to the following attributes:
  • legacyExchangeDN
  • displayName
  • adminDisplayName
  • displayNamePrintable
  • publicDelegates
  • garbageCollPeriod
  • textEncodedORAddress
  • showInAddressBook
  • proxyAddresses
  • mail
• Create msExchDynamicDistributionList objects access right
• Delete msExchDynamicDistributionList objects access right
• Full control over msExchDynamicDistributionList objects
• Read Permissions access right
• List Contents access right
• Read All Properties access right

Please note that the above list is for managing recipient attributes that are specific to Exchange. Attributes that were created outside of Exchange will not be manageable by Exchange administrators unless they are delegated the appropriate permissions.

Address Book Attributes

Exchange utilizes many attributes for storing Exchange related data. In addition, Exchange utilizes other recipient attributes that are utilized by other directory aware applications. As a result, these attributes were not added to the Exchange specific property sets; these attributes may reside in other property sets created during Active Directory installation or they may not belong to any property set.

The attributes listed below constitute the data that is provided to end users via the Global Address List service. If Exchange administrators require the ability to update these attributes and they are not a member of a domain privileged security group (e.g. Account Operators), then the Active Directory administrator will need to grant read/write access using similar procedures as outlined in the next section.

Planning a Split Permission Model

The administrative model prescribed by the default configuration of Microsoft® Exchange and Active Directory® directory service, especially with regard to user administration, may not fit with the security and administrative roles defined by your organization. For some organizations, the helpdesk-level administrators that create user accounts are not the same administrators that administer mailboxes.

By default, only Exchange Organization Administrators have the ability to manage Exchange recipient data in addition to managing Exchange configuration data. However, in order to manage object creation/modification/deletion within the domain partition, these administrators also require membership in at least the "Account Operators" security group, but this is not granted by default.

This configuration may not fit the needs of all customers, thus many customers must plan a split permissions model accordingly using the steps identified below.

Access Control

To manage Exchange related-attributes on objects within the domain naming contexts of the forest, modify permissions must be granted to the Exchange Administrators group. This is accomplished by modifying the security descriptor on the object containing the attributes.

A security descriptor contains two access control lists (ACLs). An ACL is a list of user or security group objects that have been granted or denied access to a resource or object. ACLs allow granular permissions to be applied to the entire object, a set of the object's properties, or to an individual property of an object. Two types of access control lists are within an object's security descriptor:

• Discretionary access control lists (DACLs) DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, a DACL is controlled by the owner of an object or the person who created the object, and it contains access control entries that determine user access to the object.
• System access control lists (SACLs) SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. By default, a SACL is controlled by the owner of an object or the person who created the object. A SACL contains access control entries that determine whether to record a successful or failed attempt by a user to access a object using a given permission, for example, Full Control and Read.

An access control entry (ACE) is an entry in an object's DACL that grants permissions to a user or group. An ACE is also an entry in an object's SACL that specifies the security events that are to be audited for a user or group.

Where to Apply Permissions

An Active Directory forest is comprised of one or more domains that share a common configuration and schema boundary. Within those domains, objects can be further arranged into containers known as organizational units. Each organization should devise an organizational unit structure that meets their business needs and allows for optimum delegation of administrative privileges.

For more information about designing an organizational unit structure, see Best Practice Active Directory Design for Managing Windows Networks and Best Practices for Delegating Active Directory Administration.

When you design a delegation model, there are several possibilities for applying permissions; however, this guide discusses only the following two methods:

• Applying permissions at the domain level
• Applying permissions at the organizational unit level

Applying Permissions at the Domain Level

When you apply delegated permissions on the domain naming context, the permissions are inherited to all objects (user, contact, group, domain DNS, computers, and so on); regardless if the permissions only apply toward one specific class object.

On domain controllers that are running Microsoft Windows® 2000 Server, adding an inheritable ACE at the domain level will cause the DACL to change for every object within the domain. Depending on the number of ACEs added and the number of objects within the domain, these changes could result in an "ACL bloat" (that is, unnecessary ACEs on objects that increase the total size of the ACL). An ACL bloat ultimately increases the physical size of the NTDS.DIT file across all domain controllers within the domain.

On domain controllers that are running Windows Server™ 2003, a unique security descriptor is stored only once rather than being stored for every object that inherits it. For every object that inherits the security descriptor or otherwise stores an identical security descriptor, only a pointer is stored. This change eliminates data redundancy and the database growth that can result from changes to inheritable ACEs.

Applying Permissions at the Organizational Unit Level

The recommended practice for applying delegated permissions is to apply the permissions on a parent organizational unit. This approach isolates the application of the permissions to specific class objects contained within the organizational unit and its child containers.

This method requires that all the managed objects be placed beneath a parent organizational unit. Business requirements may prevent the organization from applying this methodology; therefore, the permissions may need to be applied across multiple organizational units.

How to Apply Permissions

There are several ways to apply permissions. Microsoft provides two tools: ADSI Edit (AdsiEdit.msc) and DSACLS (Dsacls.exe). Both tools are included on the Windows Server 2003 CD in Support\Tools. Several third-party products exist that can also be used to apply these rights.

In addition, if the Exchange administrator has the appropriate rights within the Active Directory domain partition, the Add-ADPermission cmdlet within the Exchange Management Shell can be used to apply the appropriate permissions, in lieu of ADSI Edit or DSACLS.

Note: Incorrectly modifying the attributes of Active Directory objects by using ADSI Edit, DSACLS, the LDP tool (ldp.exe), or any other LDAP (Lightweight Directory Access Protocol) version 3 clients can cause serious problems. These problems may require reinstallation of Windows Server, Exchange Server, or both. Problems that occur if Active Directory object attributes are incorrectly modified may not be resolved. Modify these attributes at your own risk.

Changing permissions in the domain naming partition may require Domain Admin rights on the object for which permissions are wanted.

Consider this example that shows how either one of the tools can be used to delegate certain rights to OU administrators that have a business requirement to manage the Exchange-related data for their recipient population. This example can be used as a sample for application of delegated rights over users, contacts, and groups.

OU Administrators in the universal security group "OU1AdminGroup" require the ability to manage Exchange related data (e.g. e-mail addresses, the display name, etc) for all mail recipients located in (and below) the organizational unit "OUContainer1" in the "company.com" forest that contains the CompanyOrg Exchange organization.

The example shows how to apply rights on the "OUContainer1" by specifying read and/or write access on the following attributes within the "OUContainer1":

• legacyExchangeDN
• displayName
• adminDisplayName
• displayNamePrintable
• publicDelegates
• garbageCollPeriod
• textEncodedORAddress
• showInAddressBook
• proxyAddresses
• mail

The group will also require read and write access to the following property sets:

• Exchange Personal Information
• Exchange Information

The group will require access to the following properties:

• Create msExchDynamicDistributionList objects access right
• Delete msExchDynamicDistributionList objects access right
• Full Control over msExchDynamicDistributionList objects
• Read Permissions access right
• List Contents access right
• Read All Properties access right

In addition, the group will also require:

• Access Recipient Update Service extended right on the Exchange 2007 administrative group
• Administer Information Store extended right on the Exchange organization container
• Exchange View-Only Administrator role (or higher)

Note: The permissions identified above will not provide the "OU1AdminGroup" group the ability to modify many Address Book related attributes (e.g. last name, etc).

How to Use DSACLS to Apply Permissions

DSACLS (dsacls.exe) is a command-line tool that you can use to query and change permissions and security attributes of Active Directory objects. It is the command-line equivalent of the Security tab in the Windows 2000 Active Directory snap-in tools such as Active Directory Users and Computers and Active Directory Sites and Services. DSACLS is included with the Windows 2003 Support Tools.

This topic serves as an example for using DSACLS. After application of the example in this topic, the "OU1AdminGroup" security group can mail-enable/disable mail recipients, manage e-mail addresses, display names, etc, for all users, groups, and contacts contained in the "OUContainer1" organizational unit hierarchy in the company.com forest that contains the CompanyOrg Exchange organization.

Before You Begin: DSACLS is case-sensitive. Therefore, you must be precise in the syntax that you pass to DSACLS because all characters, including white spaces and carriage returns, are passed literally. If you receive errors from DSACLS, review the command and/or try breaking the command into smaller segments.

ADSIEdit Procedure

Log on to a system within the forest that has the Windows Support Tools installed using an account that can perform the actions (for example, Domain Admin).

Open a command prompt, and type the following commands (remember to replace the relevant parts like domain name, Exchange organization, accounts):

dsacls "OU=OUContainer1,DC=company,DC=com" /I:T /G "company\OU1AdminGroup:RPWP;legacyExchangeDN" "company\OU1AdminGroup:RPWP;displayName" "company\OU1AdminGroup:RPWP;adminDisplayName" "company\OU1AdminGroup:RPWP;displayNamePrintable" "company\OU1AdminGroup:RPWP;publicDelegates" "company\OU1AdminGroup:RPWP;garbageCollPeriod" "company\OU1AdminGroup:RPWP;textEncodedORAddress" "company\OU1AdminGroup:RPWP;showInAddressBook" "company\OU1AdminGroup:RPWP;proxyAddresses" "company\OU1AdminGroup:RPWP;mail" "company\OU1AdminGroup:RPWP;Exchange Personal Information" "company\OU1AdminGroup:RPWP;Exchange Information" "company\OU1AdminGroup:CCDC;msExchDynamicDistributionList" "company\OU1AdminGroup:GR;"

dsacls "OU=OUContainer1,DC=company,DC=com" /I:S /G "company\OU1AdminGroup:GA;; msExchDynamicDistributionList "

dsacls "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" /I:S /G "company\OU1AdminGroup:CA;Access Recipient Update Service;msExchExchangeServer"

dsacls "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" /I:T /G "company\OU1AdminGroup:CA;Administer Information Store"

If successful, the command will output the revised Windows NT security descriptor in the command prompt window and output "The command completed successfully".

How to Use the Exchange Management Shell to Apply Permissions

The Exchange Management Shell is a command-line interface that allows you to retrieve and configure objects that pertain to Exchange. The Exchange Management Shell includes a task, Add-ADPermission that can be used to apply permissions against objects that are stored within the Active Directory.

This topic serves as an example for using Add-ADPermission cmdlet. After application of the example in this topic, the "OU1AdminGroup" security group can mail-enable/disable recipients, manage e-mail addresses, display names, etc, for all users, groups, and contacts contained in the "OUContainer1" organizational unit hierarchy in the company.com forest that contains the CompanyOrg Exchange organization.

Exchange Management Shell Procedure

Log on to a system within the forest that has the Exchange Management Tools installed using an account that can perform the actions (for example, Domain Admin).

Open the Exchange Management Shell and type the following commands (remember to replace the relevant parts like domain name, Exchange organization, accounts) for each container where you want to grant access:

Add-ADPermission -identity "ou=Container1,dc=company,dc=com" -user "company\OU1AdminGroup" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

Add-ADPermission -identity "ou=Container1,dc=company,dc=com" -user "company\OU1AdminGroup" -AccessRights GenericRead

Add-ADPermission -identity "ou=Container1,dc=company,dc=com" -user "company\OU1AdminGroup" -AccessRights GenericAll -InheritanceType Descendants -InheritedObjectType msExchDynamicDistributionList

Add-ADPermission -identity "ou=Container1,dc=company,dc=com" -user "company\OU1AdminGroup" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Type the following commands into the Exchange Management Shell (remember to replace the relevant parts like domain name, Exchange organization, accounts)

Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" -User "company\OU1AdminGroup " -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

Add-ADPermission -Identity "CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" -User "company\OU1AdminGroup" -ExtendedRights ms-Exch-Store-Admin -InheritanceType All

If successful, each command will output the access control entries that were added to the object.

- Ross Smith IV

Cross-org Mailbox Moves

Cross Org migrations are the ones where a mailbox needs to be moved from one Exchange Organization to another. Since there can only be one Exchange Organization per Forest, that means moving the mailbox between two different Forests.

Exchange Migration Wizard was used to perform this task in Exchange 2003. Exchange 2007 has incorporated Cross Org migrations into the server code base, so now Administrators can perform these moves by using the same task used for Intra Org migrations: Move-mailbox.

The following versions are supported for this kind of move:

Source Server:

• Exchange 2000 SP3 (or later)
• Exchange 2003 SP1 (or later)
• Exchange 2007

Target Server:

• Exchange 2003 SP1 (or later)
• Exchange 2007

Exchange Permission requirements:

• Logon account for the user who is running Move-Mailbox needs to be a granted the "Exchange Recipient Administrators" role for Source and Target Forests and "Exchange Servers" role for both source and target Server. Permissions for legacy Exchange Servers remain the same as they were for Exchange 2003 Migration Wizard.

Process Overview

Move-Mailbox in a Cross Org scenario can be divided in the following steps:

1. Open Server Connections

• Connect to the source and target server - checks if credential and server version is valid

1. Gather Source Information

• Read source User Mailbox attributes
• Check if source mailbox is a system mailbox (Fail if it is)
• Check if source user does not have a mailbox (Fail if it does not)

1. Gather Target information

• Check mailbox size limit against target database limits
• Check if we can match the source NT account in the target Forest (account match based on SMTP address, source objectSID and target sidHistory, and legacyExchangeDN). If match is found, this account will be email enabled.
• Check if target mailbox exists (used to determine if merge is needed)
• Check if source mailbox is a resource mailbox (If it is the target user must be disabled)

1. Update Directory Information before Move

• Lock access to source mailbox
• Create the target mailbox
• Lock target mailbox

1. Move Mailbox Content

• Move the mailbox content

1. Update Directory Information after Move

• Update mailbox location attributes on source and target user accounts
• Unlock target mailbox

1. Post-Migration Cleanup:

• Remove Source mailbox / Remove AD User if cleanup parameter was used
• Unlock Source mailbox if no cleanup was specified

New functionality added for Exchange 2007

Pre-Validation and New and Improved Logging

As described in my previous post, move-mailbox has added a pre-validation feature that performs a series of checks before actually trying to move the mailbox. This feature saves time by identifying errors right away instead of waiting until they happen during an actual move.

Also, Exchange 2007 Move-mailbox improves greatly on logging available for Migration Wizard (event logs). We now have more comprehensive Event logs, a XML Report and a troubleshooting log. All logs are enabled by default and are located at <Exchange Root> \Logging\MigrationLogs\.

New Options available

A variety of new options are available to Administrators when moving mailboxes across Exchange Organizations. Here are a few examples that demonstrate their syntax:

• Credentials example: Before going into move-mailbox examples, it is worth mentioning how the credentials variables are populated for the moves. Here is an example to add a credential to a variable called $s. After typing the command, a user and password dialog will pop up. You should enter the credential that will be used for the move, using the domain/user format for the user name:

$s = get-credential

• Example 1: The following command moves mailboxes in clone mode (specified by the NTAccountOU parameter) using specific Global Catalogs and target Domain controller (parameters SourceForestGlobalCatalog, GlobalCatalog and DomainController). Eight mailboxes will be moved simultaneous threads (-MaxThreads 8) and at the end the source NT account will be deleted (-SourceMailboxCleanupOptions DeleteSourceNTAccount).It also uses the -ReportFile parameter to specify the directory and file name for the migration XML report:

get-mailbox -DomainController 'forestAdc1.extest.com' -Credential $s -database 'Server1\DatabaseA' | move-mailbox -TargetDatabase 'Server2\Database1' -Identity 'testMailbox1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -MaxThreads 8 -SourceMailboxCleanupOptions DeleteSourceNTAccount -SourceForestCredential $s -TargetForestCredential $t -ReportFile "C:\Logs\migrationReport.xml"

• Example 2: The following command moves mailboxes in clone mode (specified by the NTAccountOU parameter) using specific Global Catalogs and target Domain controller (parameters SourceForestGlobalCatalog, GlobalCatalog and DomainController). By using the PreserveMailboxSizeLimit option the command preserves the existent mailbox limits after moving them to the target database. It also uses the IgnorePolicyMatch option which will move the mailbox without trying to match Managed Folder, Unified message and ActiveSync policies and therefore losing these settings (move-mailbox by default will try to match source mailbox's existent policies to same named policies at the target Organization and fail the move if no match is found). Finally, the command deletes the source mailbox after the move is complete (by using -SourceMailboxCleanupOptions DeleteSourceMailbox) :

get-mailbox -DomainController 'forestAdc1.extest.com' -Credential $s -database 'Server1\DatabaseA' | move-mailbox -TargetDatabase 'Server2\Database1' -Identity 'testMailbox1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -PreserveMailboxSizeLimit -IgnorePolicyMatch -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $s -TargetForestCredential $t

• Example 3: This command moves mailboxes in merge mode (specified by the AllowMerge parameter) using specific Global Catalogs and target Domain controller (parameters SourceForestGlobalCatalog, GlobalCatalog and DomainController). We only want to merge content that matches the specified date interval (-StartDate and -EndDate) and that has the work "Exchange" as part of the message subject (-SubjectKeywords). We also increased the Interval and Timeout settings for lookup operations (-RetryInterval and -RetryTimeout). No cleanup option is used because this is a merge move:

get-mailbox -DomainController 'forestAdc1.extest.com' -Credential $s -database 'Server1\DatabaseA' | move-mailbox -TargetDatabase 'Server2\Database1' -Identity 'testMailbox1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -AllowMerge -StartDate '01/10/06' -EndDate '01/11/06' -SubjectKeywords "Exchange" -RetryInterval 5 -RetryTimeout 90 -SourceForestCredential $s -TargetForestCredential $t

Deprecated Options

The following options present in Migration wizard are no longer supported:

• Creating new enabled user accounts: This option was removed because we found that most customers were already using ADMT to migrate their user accounts instead of creating a new account during migration and adding detailed information later. Move-mailbox is still able to create mailbox enabled disabled user accounts (used in the Resource Forest configuration).
• Graphic interface: Currently the only way to perform a Cross Org migration is by using the move-mailbox task from an Exchange Management Shell. An EMC wizard is planned for later versions.
• Support for Exchange 5.5 servers: Exchange 5.5 mailboxes need to be migrated to Exchange 2000/2003 first and then to Exchange 2007.

Move Mailbox Cross Org and Active Directory Forests

Most of the Move Mailbox Cross Org scenarios are closely related to the Active Directory Forests involved in the migration. Before looking at the customer scenarios and at their respective move-mailbox syntax, let's go over the definition of the different Forests types and all the supported combinations among them.

Active Directory Forests Configurations

There are basically four types of Forests related to Cross Org migrations:

• Single Exchange Forest: A single forest that has Exchange installed and it is not connected to any other Active Directory forest.
• User Forest: Forest that contains only User Accounts. An Exchange server is not installed in this forest. It can be connected to other Active Directory Forests but it does not require any synchronization.
• Exchange Forest: Forest that contains mailboxes and user accounts (enabled or disabled) and contacts. This type of configuration is actually divided in two distinct types: In a Single Forest and Cross Forest set up, user accounts are always enabled and mailbox enabled. In Resource Forest, the mailboxes are attached to disabled user accounts in one Forest and associated to user accounts in the user forest.
• Hybrid Forest: This is a Forest configuration that are each a mix of User and Exchange Forests. That is, each may contain a combination of enabled and disabled User Accounts that are either mail enabled or mailbox enabled. This configuration is different than a Resource Forest because both Forests have mailboxes, and is also different than a classic Cross Org configuration because you might find mail enabled users and disabled mailbox enabled users in the same Forest.

If we represent these types as blocks, we would have the following combinations:

Even though Move-Mailbox supports migrating content among all the four Forest types described above, GALSync does not support synchronizing a Hybrid Forest due to conflicts between contacts and enabled user accounts that are mail enabled. Therefore we will not cover any migration scenario that results in a hybrid Forest configuration in this post.

Customer scenarios for Cross Org mailbox move

These are the supported customer scenarios for Cross Org migrations:

1. Company Divestiture (Single Forest to Cross Forest)

This is a scenario where a company decides move some part of its business like a division, to separate forest, be it because the division will become an independent company or because it has different technical requirements. In this situation, the Administrator should use ADMT to move user's accounts from the source Forest to the target Forest and then use move-mailbox to move that same user's mailbox.

1. Company Merger/Acquisition (Cross Forest to Single Forest)

This is the scenario where a company decides to consolidate mailboxes from various Forests into a single Forest. Administrators should first migrate users using ADMT and then use move-mailbox to move that same user's mailbox.

1. Split Windows\Exchange Administration (Single Forest to Resource Forest)

By separating the User Account Forest from the Mailbox Forest, Exchange and Windows administrators can be completely separated. In this scenario mailboxes should be migrated by move-mailbox, leaving the enabled user account on the source Forest. Therefore the cleanup option used should be delete source mailbox.

1. Host External Company (Single Forest to Resource Forest)

Another scenario for migrating from a Single Forest to a Resource Forest is that of a company that outsources email management but retains User Account management. Technical requirements should be similar to the previous scenario.

1. Bring Email Management in House (Resource to Single Forest)

This is the opposite of the last two scenarios. If for some reason a company that had its mailboxes in a separate Forest decides to bring them to the User Forest, the easier solution would be to migrate all the external mailboxes back into the Login Account Forest. In this case however, the cleanup option should be to delete user account since the linked disabled user on the Resource Forest will not be needed anymore.

1. Upgrade Exchange Server

This is the case where an Exchange 2007 server is installed (in any Forest configuration) and mailboxes from a legacy server (Exchange 2000/2003) are moved to this server. Since this applies to any of the scenarios above, the cleanup option used should follow the requirements described earlier depending on the Forest configuration.

1. Re-Alignment due to organizational or physical location changes

This is the case where mailboxes are moved among Exchange 2007 servers inside a company due to some logical or physical change. Like the previous scenario, this applies to any of the Forest configurations described above and therefore the cleanup option used should follow the requirements described earlier accordingly.

Other Examples for moving mailboxes between different Forests:

• Migrate all mailboxes from a database and delete Source users:

Get-mailbox -DomainController 'forestAdc1.extest.com' -Credential $s -database 'SourceServer1\SourceDB1' | move-mailbox -TargetDatabase 'TargetServer1\TargetDB1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -SourceMailboxCleanupOptions DeleteSourceNTAccount -SourceForestCredential $s -TargetForestCredential $t

• Migrate all mailboxes from a database and delete Source mailboxes:

Get-mailbox -DomainController 'forestAdc1.extest.com' -Credential $s -database 'SourceServer1\SourceDB1' | move-mailbox -TargetDatabase 'TargetServer1\TargetDB1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $s -TargetForestCredential $t

• Migrate mailboxes of that belong to Accounting department and delete Source users:

Get-user -DomainController 'forestAdc1.extest.com' -Credential $s | where { $_.Department -ilike "Accounting" } | move-mailbox -TargetDatabase 'Server2\DB1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -SourceMailboxCleanupOptions DeleteSourceNTAccount -SourceForestCredential $s -TargetForestCredential $t

• Migrate mailboxes with storage limit smaller than 500KB and delete Source mailbox:

Get-mailbox -DomainController 'forestAdc1.extest.com' -Credential $s -database 'Database1' | where {$_.StorageQuota -gt "500KB"} | move-mailbox -TargetDatabase 'Server2\DB1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $s -TargetForestCredential $t

• Migrate mailboxes that are assigned to "MobilePolicy1" and delete Source users:

Get-CASMailbox -DomainController 'forestAdc1.extest.com' -Credential $s | where {$_.MobileMailboxPolicy -ilike 'MobilePolicy1*'} | move-mailbox -TargetDatabase 'Server2\DB1' -SourceForestGlobalCatalog 'forestA.extest.com' -GlobalCatalog 'forestB.extest.com' -DomainController 'forestBdc1.extest.com' -NTAccountOU 'OU=UsersOU, DC=forestB, DC=extest, DC=com' -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $s -TargetForestCredential $t

- Paul MacKnight

Routing changes recap

By now you're probably aware of the basics of Exchange Server 2007 routing:

• No more routing groups (except for legacy purposes)
• No more routing group connectors (except for legacy purposes)
• Uses AD sites and site links instead
• Uses least cost routing with no more rerouting over an alternate path (rely on network layer's OSPF capabilities to do that for us; more diagnosable due to being deterministic)
• Queue closest to point of failure (back-off)
• Improved bifurcation algorithm

However, many people are still confused about the exact message around co-existence.  Many of you remember how painful it was to transition to the LINKSTATE based routing because 5.5 had no concept of it.  Well, this time, not only do you have to deal with the fact that Exchange 2007, like 5.5, does not speak the language of LINKSTATE, but you also have to deal with entirely new concepts.  Add that to the fact that your legacy versions of Exchange will not even pretend to understand what goes on inside of the Exchange 2007 routing group.

The good news is that we've learned some from the past and we're providing what I think is some pretty solid guidance about how to do your migration and coexistence and survive with as little pain as possible.

Phase 1: The introduction of your first Exchange 2007 servers

The first obstacle you will face is that you want your new server roles to be able to communicate with your existing environment.  Assuming that you're not installing into a completely new forest, the first thing you will need to do is pick which of your existing routing groups you will connect with.  This is because all of your Exchange 2007 servers will exist in a special routing group that should only house Exchange 2007 servers.

Currently, when you run your first installation of a hub role, you will be prompted for this information so that a Routing Group Connector (RGC) can be created for you (if using setup unattended, this is specified with a switch).  In an ideal world, your first Exchange 2007 server is going to be near to one of your existing hub RGs and you'll just pick that. 

Introducing your first Exchange 2007 server:

If you're installing into a spoke site, then the decision becomes a bit more tricky - if you pick the spoke RG, then when you send mail back and forth between Exchange 2007 and legacy servers, it will all stay within the physical location.  However, when you go to add additional Exchange 2007 servers to other locations, you'll need to do some work so that all mail going between the Exchange 2007 and legacy worlds is not being directed through that location.  For example, if you deploy your first Exchange 2007 server in Chicago, you may not want mail going between your Hong Kong Exchange 2007 server and Hong Kong legacy servers to have to go to Chicago first.

All mail going between legacy and Exchange 2007 servers in Hong Kong will have to go across the RGC in Chicago:

However, if you pick an intermediary hub for your first co-existence RGC, then all mail making the transition between the Exchange 2007 and legacy worlds in both Ireland and Japan will have to go through that hub.

Bottom line: for your co-existence RGC that gets created as part of your first installation, pick the RG/location where you intend to deploy the most Exchange 2007 servers initially.  You can always add routes later (see phase 2). 

Important change from some of our very early documentation:  As long as you only have a single RGC between the Exchange 2007 world and the legacy world, you do NOT need to do anything to disable Linkstate.  If you have ever seen this guidance, you may ignore it for now.  Basically, except for the one link between the two worlds, Exchange 2007 and legacy servers will operate independently with no chance for loops to exist.  The true beauty of this is that many smaller customers with only 1 or 2 routing groups will probably never even have to think about this.

Phase 2: Coexistence is a necessary evil

No one that I know likes coexistence, but unless you have the tooth fairy working for you, I suspect you will need to plan for this phase.  Basically, now you're deploying in a few locations around the globe.  The single co-existence RGC is no longer adequate.  You want mail in Japan to stay in Japan, and mail in Ireland to stay in Ireland, but you're not quite ready to move everyone to an Exchange 2007 server to do it.

Fortunately, creating additional co-existence connectors is perfectly fine.  All you have to do is pick one or more Exchange 2007 and one or more legacy servers to be bridgeheads for the connector.  On the legacy side, pick server(s) from the routing group that matches the location.  On the Exchange 2007 side, you want to pick the server(s) that reside in the closest AD site.  For best results with Exchange 2007 routing group connectors, use the new PowerShell task "new-RoutingGroupConnector".  Optionally, you can still use Exchange 2003 ESM to create these, but you have to originate the connector in the E2K3 routing group & choose to create both directions at the same time; plus, there's an extra step of adding the legacy servers to the "ExchangeLegacyInterop" security group.

Creation of an additional RGC between Hong Kong routing group and the Exchange 2007 servers in that location:

But wait!  If you do that, you now have more than one way in and out of the Exchange 2007 routing group that has no idea about Linkstate.  Because of that, you could end up in a situation where E2K3 sees the best route as not necessarily being the least cost route (if a connector is marked down for example).  Exchange 2007, however, always picks the least cost route, and you now have a potential looping situation!

This is where we say you MUST "disable" Linkstate.  Well, technically, you're not going to disable it.  You're going to suppress the possibility for any connectors to be marked down.  You'll do this by setting the SuppressStateChanges registry key that is talked about in the Exchange 2003 Routing and Transport Guide.  This will ensure that legacy versions of Exchange also will only use least cost routing, and there will then be no chances for loops to occur.  You should set this registry key on all servers.  (Sidebar: It is technically not necessary to set it on all servers - there are many servers in a typical environment that do not host connectors, or that host connectors that already cannot be marked as down, such as a connector where no other route exists, or one with multiple bridgeheads.  However, this recommendation is being made for simplicity and because configuration changes could be dangerous if the registry key is not set everywhere.)

Linkstate will still propagate, but it will be a lot more boring because there won't be any connector state changes.  These are minor version changes.  Major version changes (configuration updates) and user version changes (used by status & monitoring) will still occur.  Make certain that you understand that by making this change, mail will no longer reroute to a different connector!

Some other things to remember: 

• When Exchange 2007 has to route mail over to the legacy environment, it will select the path that keeps the message in the Exchange 2007 environment as long as possible.  In other words, it will try to minimize the legacy connector costs before it tries to minimize the AD site link costs.  In this way, Exchange 2007 will always keep mail going to Exchange 2007 within the new environment - it will never attempt to backbone over a legacy server.
• When legacy Exchange has to route a message to the Exchange 2007 environment, or through it, it will pick the least cost route based on the legacy RGC costs.  It will never know anything about the AD topology.  For this reason, you want to consider your legacy connector costs carefully.  The current version of the new-RoutingGroupConnector task costs new connectors at 1 by default.  This may be too low if you're not ready to backbone over Exchange 2007.

Showing how Exchange 2007 calculates least cost routing in complex mixed topology:

Bottom line: you must suppress minor version changes in your legacy environment before introducing additional co-existence connectors.  It is also a good idea to understand basic route selection algorithms before setting the costs on RGCs - or mail may take a route that you do not expect.

Phase 3: Getting rid of legacy servers is easy, right?

Wrong!  This is actually where the biggest risks are.  One of the worst things you could do during the migration from Exchange 5.5 was to create a shiny new RGC to replace your 5.5 site connector, and then change your mind.  The reason is because once Linkstate propagation starts, you should not break it.  Configuration changes propagate via Linkstate (when a major version changes, this indicates a configuration change).  Once the major version for a particular routing group is non-zero, it will no longer be read from the AD, but instead will be expected to come via the Linkstate updates, from the routing group master which is authoritative for that routing group. 

Well, essentially, that's what you're doing now!  You're changing your mind and getting rid of the RGCs that propagate Linkstate and slowly going back to the least cost only world.  You're breaking propagation, because Exchange 2007 won't be propagating Linkstate information.  We call this creating Linkstate islands.  The good news is that users already on Exchange 2007 will never see any pain.  Also good news:  stragglers in the legacy world will always see things like new Internet SMTP connectors homed in Exchange 2007 (Exchange 2007 never will speak Linkstate, so it will always have a major version 0, and changes will always come from the AD).  The bad news is the stragglers in the legacy environment may not see routes changes that are created elsewhere in the legacy org.

Deleting the Chicago RG will create Linkstate islands:

The only simple solution to this problem is this:  if you create a situation where you backbone over the Exchange 2007 RG, then you must have an alternative path for Linkstate to propagate.  That is, there must be a path for every legacy server to talk to every other legacy server that does not pass through the Exchange 2007 RG.  You can cost these alternate paths such that no mail will ever flow through them - they will only be used for Linkstate propagation - so that no islands exist. 

How to properly remove the Chicago RG and solve the Linkstate island issue:

If this is too confusing for you, consider this option, which while not required, will also most definitely keep you out of trouble:  keep it such that emails between any two users anywhere in the legacy environment never have to go through an Exchange 2007 server.

Bottom line:  whenever you remove a legacy RGC, you must consider whether or not you are creating Linkstate islands in doing so.  If you do, then you must create a dummy connector between the two islands for Linkstate propagation - otherwise, configuration changes will not be known by both sides.

Conclusion

One last piece of good news. We are planning for ExBPA and the new Exchange Troubleshooting Resolution Assistant suite of tools (Mail Flow Analyzer) to eventually check to make sure that these recommendations are followed correctly.  If they are not followed, they will be flagged for you - but only when you run the tools.  It might therefore be a good idea to run the appropriate tools whenever you make a routing topology change.

If you follow these very simple recommendations, the hardest part of your transition away from Linkstate will be making the plans for the party to celebrate its demise.

See the Exchange 2007 technical documentation for more information.

-  Scott Landry

The Exchange Server documentation team is pleased to announce the following additions and changes to our content. For a complete list of topics that changed, see Exchange Server Documentation Updates.

Changes to Online Content

The following topics are new:

• Getting Started with Exchange Server 2007: Server Roles (1 topic)
• Exchange Analyzer Tools Success Stories (1 topic)

Changes to Downloadable Content

To read the most current version online of the Exchange Server 2003 documentation, see the Microsoft Exchange Server TechCenter.

The following documentation downloads have been updated:

• Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide
• Offline Address Book Best Practices Guide

- Cathy Anderson, Content Release Manager, Exchange User Documentation

The goal of this blog post is to build some familiarity and understanding of how Exchange uses WMI in representing the Status and Monitoring node in Exchange System Manager.

What is the Monitoring and Status tool?

The Monitoring and Status tool is an administrative tool built into Exchange System Manager that you can use to monitor the status and performance of servers, connectors, and resources. The Monitoring and Status tool has two components:

• Notifications: Use this component to create e-mail or script notifications that are triggered when the status of a server or connector changes.
• Status: Use this component to view the status of servers, connectors, and resources.

In this blog post, I am going to focus more on the "status" of the Exchange server viewing through ESM.

The following status states apply to servers:

• Available - indicates that the server is online and functioning normally.
• Unreachable - indicates that one of the main services on the server is down.

Note - If a server is unreachable and is in a different routing group, it may indicate that a connector between routing groups is down or does not exist.

• In Maintenance Mode - indicates that monitoring is temporarily disabled due to maintenance, backup, repair, or some other reason.
• Unknown - indicates that System Attendant cannot communicate with the local server.

The following status states apply to connectors:

• Available - indicates that the connector is functioning properly.
• Unavailable - indicates that a communication service, such as the routing service, is not functioning on this connector.

If you have configured monitors for specific resources such as SMTP queue or X.400 queue growth, when the threshold for either a warning or a critical error is exceeded, the state change will be displayed in the Status container. For example, when an SMTP queue grows continuously and reaches a critical state, the status container will display "Critical: SMTP queue growth" for the server object that is experiencing the problem.

Components Involved

There is 4 major components involved that interact to provide the server status data that is viewable through ESM.

- Exchange System Manager that shows the status.
- MAD (aka System Attendant, mad.exe) that decides what the status is.
- The routing table provider (exwmi.dll) which replicates the status around the organization.
- WMI which provides the interface between ESM/MAD and the routing table.

Monitoring Architecture

At startup, MAD spawns a monitoring thread which creates and initializes a CMonitoringTask object. This MonitoringTask object contains the WMI query which is used to figure out the state of the server. It is also used to write that state to the routing table (using WMI again).

This thread makes queries to WMI at various intervals to figure out the state of various components (CPU, memory, queues, etc...). Based on that information, MAD will decide what the state of the overall server is. It then writes this server state to its own instance of the WMI class ExchangeServerState.

When the WMI provider (exwmi.dll) receives the ExchangeServerState from MAD, it looks up the routing table and reads the previous state of the server. If there is no difference between the previous state and the one being written, nothing happens. This is important because the routing table replication algorithm doesn't react well to frequent write operations. If the state is different, then it is written to the routing table.

It is important to note that each MAD.exe process on each server monitors only itself (i.e the local machine). It does not monitor the state of other machines since the MAD process on those machines are responsible for local activity. When the information gathered by MAD causes a change to the previous state stored in the routing table, the routing engine on a slave node sends this information to the routing group master for dissemination to the other slave nodes.

When viewing the monitoring status, ESM connects to the WMI of one specific server and reads the ExchangeServerState instances of all servers. The server on which ESM is running is used for the WMI connection if Exchange is detected on it; otherwise the first server name returned from an Active Directory query for all Ex200x servers in the local AG is used. If the routing table is not getting replicated throughout the org, then the state information for some servers may be very stale. If a server is marked as 'Unreachable', it can mean one of two things: either the routing master for that server was unable to contact it, or the WMI server chosen cannot connect to its routing master (in which case all servers will be marked as 'Unreachable'). If you connect ESM to a server that is not connected to its master, then all servers will appear unreachable (since the routing table is stale, we can't use it).

Putting the pieces together

WMI architecture overview:

A provider is a COM object that monitors one or more managed objects for WMI. Similar to a driver, a provider supplies WMI with data from a managed object. A provider also handles messages from WMI to the managed object.

Exchange's providers are contained within these 2 DLLs:

Exmgmt.exe

- Responsible for message tracking, message tracking log location field & dsaccess tab.
- It runs as a standalone process
- owns root\MicrosoftExchangeV2 namespace

Exwmi.dll

- This dll is responsible for monitoring and status node in ESM, monitoring tab on server properties.
- loads under Winmgmt.exe in W2K and in Wmiprvse.exe in W2K3.
- owns root\cimv2\applications\exchange namespace

A managed object is a logical or physical enterprise component, such as a hard drive, network adapter, database system, operating system, process, or service. A managed object communicates with WMI through a WMI provider that calls methods in the COM API for WMI. Some examples of managed objects in the Exchange sense are:

- Contents of the directory access tab
- Message tracking data
- Status and notifications data

A management application or script is an application that interacts with the WMI infrastructure example ESM.

Exchange WMI Providers

Exchange 2000/2003 added three new WMI providers. These providers create a new namespace in the WMI Common Information Model (CIM) repository and add five new WMI classes. Each class is related to a different part of Exchange 2000 and 2003.

- The WMI ExchangeRoutingTable provider creates the ExchangeServerState and ExchangeConnectorState classes. The Exchange Routing Table provider runs on top of the routing API. The purpose of this provider is:

1. To publish the status of the local Exchange 200x server in the routing table, based on the monitoring conditions configured with the Exchange System Manager (ESM).
2. To retrieve the states of other Exchange 200x servers in the organization from the routing table, based on the monitoring conditions configured with the ESM.
3. To publish the states of the Exchange 200x local connectors in the routing table.
4. To retrieve the states of other Exchange 200x connectors in the organization from the routing table.

- The WMI ExchangeQueue provider creates the ExchangeLink and ExchangeQueue classes. The Exchange Queue provider runs on top of the Queue API.

- The WMI ExchangeCluster provider creates the ExchangeClusterResource class. The Exchange Cluster Provider runs on top of the Cluster API.

These three providers expose a set of classes available from the root\CIMV2\Applications\Exchange WMI namespace.

- ExchangeServerState - This class retrieves information about the status of relevant services, including memory used, processor type, disk space available, and the mail queue of Exchange 200x servers in an organization. The ExchangeServerState class works in conjunction with the monitoring configuration defined by the Exchange System Manager (ESM). ESM's monitoring section uses this class extensively to monitor servers.

For more information on ExchangeServerState, refer to:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_wmiref_cl_ExchangeServerState.asp

- ExchangeConnectorState - The ExchangeConnectorState class is based on the same principle as the ExchangeServerState class. The ExchangeConnectorState class monitors the connectors in an Exchange organization and publishes their states in the routing table. When this class is interrogated from ESM or by a script, it offers a list of the connectors available from the routing table with their corresponding states.

Both classes retrieve their information from the routing table. This information is available to administrators on any Exchange 200x server in an organization.

- ExchangeLink - This class provides information about link status and properties. The properties include the retry count, the size of the queue waiting for each link, and the link's current state (i.e., unavailable or up). The SMTP routing engine uses this information to determine link-state routing.

- ExchangeQueue - This class provides detailed information about message queues' contents-such as the protocol that the queue uses (i.e., X.400 or SMTP) and the name of the link that the queue is waiting on. A program can enumerate the individual messages in the queue. For example, Exchange System Manager (ESM) can use this function to count the messages in a queue.

- ExchangeClusterResource - This class provides information (in clustered environments only) about the status of a given cluster resource and the name of the Exchange Virtual Server (EVS) that uses that resource.

Soon, I will post another post that will go into troubleshooting ESM "status" problems.

- Nagesh Mahadev