A theme in OWA is a collection of media (e.g. .GIF and .WAV files) and .CSS files. These files are installed in folders under in the vroot under 'version\themes'.

Out of the box, we ship with three themes: blue "Seattle Sky" (folder name 'base') and black "Carbon Black" (folder name '1') and a mountain image "Olympic Sunrise" (folder name '2'). Customers can add more themes by creating new folders and adding their own customized files.

We recommend here that you optimize your theme by changing only the logo, top banner area and the selection highlights so the theme will have less potential for destabilization and bugs. Using very bright or very light dark for the selection colors and the top banner are not advised - try to use subtle or primary colors for the banner area and medium-hued colors for the selection/highlight colors. If you want to use darker or very light colors, you'll need to also adjust the text for the appropriate level of contrast and the best legibility by testing on various monitors at different resolutions.

The base theme

The base theme lives under 'themes\base' and it contains all of the themeable files. Any other themes are built by overriding files in the base theme.

Say for example the base theme is made of files A, B, C and D. I can create a new theme by changing say, C and D, and leaving A and B untouched. Thus for the new theme, C and D will come from the new theme folder, while A and B will come from the base theme.

What's in a theme folder

The two most important types of files in a theme folder are icons (GIF files) and styles (CSS files). Specifically, premium.css is the style sheet file for Premium OWA (the OWA Light client is not themeable).

Premium.css can be edited to change things like colors, gradients and font styles.

The GIF files can be edited to change any icons in the UI. Keep in mind that the sizes of the images should not be changed.

This is an improvement over Titanium, where only a handful of GIFs could be themed (the logo and a couple of others), and only the colors in the .CSS file could be changed.

How to install a theme

Create a new folder under version\themes (e.g. "themes\viayoga").

Copy the files from the base theme that you will want to alter for your new theme. If for example, you want to change the logo, then copy 'logop.gif' from 'themes\base' to 'themes\viayoga. The viayoga folder at this point will contain only one file. If you also want to change some of the styles, then copy premium.css. You can do this with any files in the base theme. As they are copied to the new theme folder, the theming engine will pull the modified files from the 'green' folder while still using the unchanged files from the 'base' theme.

You can give a name to the theme in two ways:

Adding a file called themeinfo.xml and specifying the name in it (see below).

Leave it like this, and the name will come from the folder name (in this case, "viayoga").

Restart IIS so OWA automatically picks up the new theme.

Themeinfo.xml

The syntax of this optional file is very simple:

<theme displayname="theme name"/>

If present, the value of the displayname attribute is used as the name of the theme.

The themes we ship with contain a macro like this:

<theme displayname="$$_BASE_$$"/>

...which we use internally to map to localized strings.

How to create themes

First, start by setting up the theme without changing any files. Create a new folder under themes (call it 'test theme'), then copy premium.css, logopt.gif, logopb.gif and nbbkg.gif (the files for the top banner "brand bar") to begin with, which are probably the first files that you will be editing for your theme.

Changing the top banner can be done most easily using a solid color or a vertical gradient similar to what is already in place. Your custom nbbkg.gif (repeating background image) can be any width but must remain the same height.

If you want to include a more complex or interesting image as your background, be sure to create the right and left edges as a mirror so that the strip meets when it repeats and appears as a single image so it will work on a variety of screen resolutions. Or, you can create one long image for the target width you'd like to support.

Looking at these files in an image editing tool, you can see that logopt.gif and logopb.gif are the top and bottom of the OWA logo including a background, and nbbkg.gif is a gif that repeats as the background.

We split the images up so that we can add "Connected to Microsoft Exchange" as a live text string that can be localized into different languages. You can create one image and remove this string by editing the style sheet. Simply add "display:none" to the tdLogoB class, then save your image as one piece, 238 x 49 pixels, and edit the height of the image here:

}

td.tdLogoT

{

width:238;

height:49;

background:url("logopt.gif") no-repeat

}

td.tdLogoB

{

vertical-align:top;

height:16;

padding-left:42;

font-size:7pt;

font-family:tahoma;

color:#EEEEEE;

background:url("logopb.gif") no-repeat;

display:none;

}

Example theme

As an example, we created a theme for a Seattle yoga company that provides yoga retreats and surfing lessons in Mexico (yes, you should go!).

We removed the "Connected to..." string by editing the style sheet as shown above. You can see how it looked before and after editing the style sheet and adjusting the images slightly. The background image is simply filled with a solid, bold color. The resulting background image - nbbkg.gif - only needs to be 1 pixel wide.

Changing colors and other styles in premium.css is the tricky part:

Use an image editing tool like PhotoShop or PainShop Pro to take screenshots and sample colors that you want to change. For instance, to change the yellow color of the selected module in the secondary navigation:

First, obtain the html RGB values (#RRGGBB) for that yellow: that value is #FFEFB2.

Then look for this in premium.css:

/* NavBar buttons selection color */

a.nbHiLt

{

background-color:#FFEFB2;

}

Here's where the tricky part comes. In debug builds, we know this is the color because in most cases we have a comment above the style. As an OWA dev, we also have access to the sources so we can verify this is the color we want. For people without access or familiarity with the source code, this is a trial and error process: guess if this is the right style by the name of the class (which is relatively hard, because our names are shortened and not too easy to decipher unless you are an OWA dev), then apply the change, refresh your browser and see if you are lucky.

Continue changing the colors until the theme is starting to look right to you. For some pieces of the interface, there are two values specified for each end of a gradient, when a lighter color blends into a darker color. These work best with lighter hues of colors.

When creating your theme, you may find a color and want to do a straight find and replace action on the entire style sheet file. Be careful when doing this. For the areas defined as gradients (Find = "gradient" to see all the instances of these) you might accidentally change all the light grays to your new highlight color. Try saving and refreshing your build with your new theme selected in Options > General Settings > Appearance in order to make sure you've changed only the intended elements.

We don't recommend changing the colors of the red and yellow informational messages that appear at the top of the message forms, alerting users to potentially harmful content, phishing attacks, viruses and blocked or missing content. We call these "infobars" (non-phishing are yellow:#FFEFB2 ) and "error infobars" (errors and phishing alerts are light red:#FFAEB9). There is also an infobar for meeting conflicts on meeting invitations:

/* Non-phishing infobar messages */

div#divIB div#dvExp, div#divIB div#dvInf, div#divIB div#dvExpErr, div#divIB div#dvErr,

div#divIB div#dvJnkMl

{

margin:2 0;

padding:1 3;

background-color:#FFEFB2;

border:solid 1 #FDD981;

}

/* Phishing */

div#divIB div#dvPhsh

{

padding:1 3;

background-color:#FFAEB9;

border:solid 1 #FF99CC;

Main Selection Colors

Selection in mail list is probably one of the most important highlight colors. This is the color over the selected message which tells users what item they are currently reading. There is a primary color to indicate focus and a secondary highlight color that is slightly lighter to show selection when the focus moves away from the item, like the currently selected folder or the current day in the Calendar. For each theme, these two colors are the same color that we use for the primary and secondary highlight colors.

Shown below, the primary color is on the left, the secondary color on the right. You can see the difference is quite subtle.

In the premium.css style sheet, this highlight in the mail list is specified as:

tr.sel, tr.srsel, tr.lrsel

{

background-color: #FFEFB2;

color:#000000;

}

tr.shdw, tr.srshdw, tr.lrshdw

{

background-color:#F8F0D2;

Icons

In order to change icons, the process is quite similar, find out which icon it is you want to change in your theme, copy it to your theme folder and then change it there. Then verify the change in the product with your new theme name selected. We use .gif files with transparent backgrounds. Make sure to keep the image sizes unchanged.

Customize the Logon Screen

To customize the logon (and log off) screen, update the images and the background color to create a custom look. You can create your own custom look and feel by updating the image files that create the logon screen. Note that the logon screen cannot be customized per theme since the user needs to enter their credentials and be authenticated prior to accessing their own user settings (theme selection) for each session. Therefore, you'll need to directly manipulate the files in the base folder starting with the style sheet "logon.css" and the images that create the border and the main logo for the screen.

The screen is made up of several images for the border top, bottom, sides and also includes repeating images and corners for expansion. The images that create the logon screen are:

lgnbotl.gif

lgnbotm.gif

lgnbotr.gif

lgnexlogo.gif

lgnleft.gif

lgnright.gif

lgntopl.gif

lgntopm.gif

lgntopr.gif

To create a new look and feel, using a solid color is easiest since the screen uses the same collection of images for several screens and resizes horizontally and vertically based on the contents for each screen: logon, language selection (shown on the first logon per mailbox), and the log off screen that's shown each time the user presses the Log Off button.

Before changing the images, you can make a backup of the image files in case you need to revert your changes to the original configuration. Start by opening the Microsoft Outlook Web Access logo (lgntopl.gif):

...and change it to your own company logo:

Here is a general idea of how all of the new image files will fit together on the logon screen:

Logon Screen: background color

Editing the logon.css is necessary if you want to change font styles and other colors, including the background color that exists behind the controls in the middle of the screen. Currently the background color is specified as #7F90B1. For our custom logon for Via Yoga, we need to replace this with orange #E48310 for the area behind the controls that is not colored by the other images.

Logon Screen: active text color

The active text color on the existing OWA logon screen is yellow: #F8D328 since that stood out best on the blue background as a secondary font color. We'll want to change this for Via Yoga, but we still want the primary white text to come into focus first so we'll leave all that text white. We'll change the active text to the same blue used elsewhere in this theme to indicate that something is active or "clickable." That blue RGB value is #266CBC. Do a find and replace to make this color change in the logon.css.

Logon Screen: final details

After logging off, this is looking pretty good, but the lines used to separate text and form elements are hard to see in the existing gray #A9AAC4. Open the logon.css file and find that color value. Change it to something a little lighter than your background but darker than the text so that the text still stands out as the most important information on the screen. We replaced the gray with a light orange RGB value #FFC279.

Voila - looks good:

Good Luck creating your theme!

- Jorge Pereira and DJ Schwend

Looking back at last several weeks, we have posted a lot of Exchange Server 2007 posts to our blog. We have started getting some questions about posting Exchange Server 2003 posts to the blog too. Let me explain what is going on:

With Beta 2 of Exchange Server 2007, we finally came to the place where Exchange Server 2007 is in a shape that is finalized enough so we can start blogging about it more with a high degree of confidence that the information will not have to be changed as it will be "outdated" when Exchange Server 2007 releases. We cannot guarantee this of course but that is definitely our intention.

Additionally, you have to understand that the Exchange Product Group has been working on this new exciting software for literally years now; so it is understandable that we are eager to finally start talking about it more openly. There are tons of great very talented people that can’t wait to share with you what’s new and what’s cool!

On the other hand, we totally realize that vast majority of Exchange servers in the "real world" are not running Exchange Server 2007 yet. Therefore we definitely plan to keep posting about Exchange Server 2003 too, and do not plan to turn this blog into Exchange Server 2007 only blog. However, you should expect that we will be a bit "Exchange 2007 heavy" in our posts in next several months, as we are finalizing this product for you. We are also excited about the opportunity to share a lot of Exchange Server 2007 knowledge with you so when Exchange 2007 does release, you can search for the information you need and actually find it.

As mentioned before on this blog - all of Exchange Server 2007 posts can be found in their own category too, if you want to see them all.

So – please keep on suggesting the blog topics. We have posted on many of those and want to keep doing so!

Thank you,

- Nino Bilic

Beginning with Exchange Server 2003 SP1, there are two methods for moving mailboxes depending on the organization mode in which your Exchange environment is operating.

If you are in mixed mode, the Move Mailbox Task will present you with two options:

- Same Administrative Group Move

- Cross Administrative Group Move

If you are in native mode, you can move a mailbox within and between administrative groups.

Mixed Mode Cross Administrative Group Mailbox Move Permissions

To move mailboxes across the administrative group boundary while operating in mixed mode, the Exchange administrator must have:

- The Exchange delegated role, Exchange Administrator (or higher), on the source and destination administrative groups.

- If you are moving mailboxes from an Exchange 5.5 server, then you will need the Exchange delegated role, Admin (or higher) on the 5.5 site and configuration contexts that contain the mailboxes (this is granted through the Exchange 5.5 Administrator program).

- The Exchange delegated role, Exchange View Only Administrator role (or higher) delegated at the organization level to read the properties of the ADC Configuration Connection Agreements to determine the target administrative group's responsible SRS.

- The Exchange delegated role, Admin (or higher) on the source 5.5 site and the 5.5 site that contains the target administrative group's SRS (this is granted through the Exchange 5.5 Administrator program).

The Exchange Administrator must be a local administrator on the workstation which is being used to perform the Move Mailbox task. In addition, the Exchange Administrator must have Read and Write access to the following user or inetOrgPerson object attributes:

- homeMDB (Exchange Mailbox Store)

- homeMTA

- msExchHomeServerName (Exchange Home Server)

- targetAddress

- msExchADCGlobalNames

- proxyAddresses

- legacyExchangeDN

Mixed Mode Same Administrative Group and Native Mode Mailbox Move Permissions

To move mailboxes, the Exchange administrator must have the Exchange delegated role, Exchange Administrator (or higher), on the source and destination administrative groups.

The Exchange Administrator must be a local administrator on the workstation which is being used to perform the Move Mailbox task. In addition, the Exchange Administrator must have Read and Write access to the following user or inetOrgPerson object attributes:

- homeMDB (Exchange Mailbox Store)

- homeMTA

- msExchHomeServerName (Exchange Home Server)

- targetAddress

- msExchOmaAdminWirelessEnable (This attribute is removed if you are moving a mailbox to a server running Exchange Server 5.5 or Exchange 2000 Server.)

- msExchOmaAdminExtendedSettings (This attribute is removed if you are moving a mailbox to a server running Exchange Server 5.5 or Exchange 2000 Server.

- Ross Smith IV

Previously I posted an overview of Exchange Server 2007 recipient management at the Exchange Management console. That post only tells half the story; now we will explore recipient management through the Exchange Management Shell base on Windows PowerShell technology that is not only the underlying technology behind the GUI, but also enables bulk updates and automation that will significantly ease managing Exchange.

Exchange Server 2007 recipient management through PowerShell provides a solid management platform for use by the recipient management GUI built on top of it, as well as a flexible and powerful interface for you to use directly! The shell interface is flexible enough to be used for simple "one-liner" changes to a single user or hundreds of thousands of users. For bulk actions, or actions where you want to take some action against a filtered set of objects you will find using "one-liners" at the shell to be very effective.

Today I want to introduce the core cmdlets you can use to do recipient management through the shell interface. For each of these cmdlets I describe, you can find out more information and sample syntax by doing "help <cmdlet name>" through the Exchange Management Shell in Exchange Server 2007

Exchange Server 2007 Recipient management nouns

All cmdlets are structured as <verb> hyphen <noun>. If you think of the noun as the "type of object you will be doing some action against" and the verb as "the action you will be doing", it becomes relatively straight forward to determine which cmdlet you need to call.

We have built families of cmdlet actions around a number of object-type nouns explained in detail below.

Mailbox:

A mailbox is an AD user object that has additional Exchange mailbox properties set. These additional Exchange-related AD properties allow the user access into a "StoreMailbox" object which hosts the mailbox data within the Mailbox Database.

Historically, "mailbox" has had several possible meanings. This term was used to refer to the mailbox attributes on an AD user object, to the user object itself once it had been mailbox enabled, to the StoreMailbox data object in the mailbox database, and even to various combinations of these items. In Exchange Server 2007, "Mailbox" refers to the combination of user object with mailbox attributes in place and the StoreMailbox object in the mailbox database.

The AD properties associated with a Mailbox object are those properties that are part of the "Exchange Property Set". Some example properties are: Email addresses, HomeServer, Mailbox quotas, etc. Access to these properties is controlled by the "Exchange Recipient Administrators" delegated role, and does not rely on additional AD permissions such as Account Operator.

User:

A user is an AD user object that does not have any additional Exchange mailbox or mail properties set. User cmdlets ship with the Exchange PowerShell snapin and are not built-in cmdlets within PowerShell.

There are two reasons why User objects are exposed in Exchange PowerShell:

To allow administrators the ability to pipeline these user objects into other cmdlets (such as Enable).

To allow administrators access to those properties that are part of the "AD property set".

The AD properties associated with a User object are those properties that are part of the "AD Property Set". Some example properties are: Postal Address, Phone number, Manager, etc. Access to these properties is controlled by AD groups, such as Account Operator. Being granted "Exchange Recipient Administrators" delegated role will not give you access to these properties, you would need to be granted Account Operator or something equivalent.

Note that all Mailbox objects are also User objects, but not all User objects are also a Mailbox.

CASMailbox:

CASMailbox is a noun used to access various Client Access related properties on a mailbox object. It is not a separate object Recipient Type; it is simply used to segregate CAS-related properties into a separate view. Through these objects you will have access to the various protocol-related settings for Activesync, MAPI, OWA, etc for a mailbox.

UMMailbox:

UMMailbox is a noun used to access various Unified Messaging related properties on a mailbox object. Like CASMailbox, it is not a separate object RecipientType; it is simply used to segregate UM-related properties into a separate view. Through these objects you will have access to the various UM-related settings such as Extension, UM Mailbox Policy, Automatic Speech Recognition, etc for a mailbox.

MailUser:

A mailuser is an AD user object that has additional Exchange mail (not Mailbox) properties set. These additional Exchange-related AD properties allow the user to have mail forwarded out to some external email address. Mailuser is just like the more common MailContact type, except that it is associated with a user account security context rather than a contact.

The AD properties associated with a MailUser object are those properties that are part of the "Exchange Property Set". Some example properties are: Email addresses, External address, etc. Access to these properties is controlled by the "Exchange Recipient Administrators" delegated role, and does not rely on additional AD permissions such as Account Operator.

User:

User is already explained above in Mailbox. Since both Mailbox and MailUser are based on AD User objects, the User noun applies equally to both.

Note that all MailUser objects are also User objects, but not all User objects are also a MailUser.

MailContact:

A mailcontact is an AD contact object that has additional Exchange mail properties set. These additional Exchange-related AD properties allow the contact to have mail forwarded out to some external email address.

The AD properties associated with a MailContact object are those properties that are part of the "Exchange Property Set". Some example properties are: Email addresses, External address, etc. Access to these properties is controlled by the "Exchange Recipient Administrators" delegated role, and does not rely on additional AD permissions such as Account Operator.

Contact:

A contact is an AD contact object that does not have any additional Exchange mail properties set. Contact cmdlets ship with the Exchange PowerShell snapin and are not built-in cmdlets within PowerShell.

There are two reasons why Contact objects are exposed in Exchange:

To allow administrators the ability to pipeline these contact objects into other cmdlets (such as Enable).

To allow administrators access to those properties that are part of the "AD property set".

The AD properties associated with a Contact object are those properties that are part of the "AD Property Set". Some example properties are: Postal Address, Phone number, Manager, etc. Access to these properties is controlled by AD groups, such as Account Operator. Being granted "Exchange Recipient Administrators" delegated role will not give you access to these properties.

Note that all MailContact objects are also Contact objects, but not all Contact objects are also a MailContact.

DistributionGroup:

A distributionGroup is an AD group object that has additional Exchange mail properties set. These additional Exchange-related AD properties allow the group object to be the recipient of email which will then be distributed to all of the group members.

Note that AD has a different definition of "distributionGroup" in which the group does not have a security context, but may or may not be mail-enabled. In Exchange 2007, the use of "Distribution Group" refers to all mail-enabled groups, whether they are an AD "security group" or an AD "distribution group".

The AD properties associated with a distributionGroup object are those properties that are part of the "Exchange Property Set". Some example properties are: Email addresses, Expansion server, etc. Access to these properties is controlled by the "Exchange Recipient Administrators" delegated role, and does not rely on additional AD permissions such as Account Operator.

Group:

A group is an AD group object that does not have any additional Exchange mail properties set. Group cmdlets ship with the Exchange PowerShell snapin and are not built-in cmdlets within PowerShell.

There are two reasons why Group objects are exposed in Exchange PowerShell:

To allow administrators the ability to pipeline these group objects into other cmdlets (such as Enable).

To allow administrators access to those properties that are part of the "AD property set".

The AD properties associated with a Group object are those properties that are part of the "AD Property Set". Some example properties are: Group Type, Managed By, etc. Access to these properties is controlled by AD groups, such as Account Operator. Being granted "Exchange Recipient Administrators" delegated role will not give you access to these properties.

Note that all DistributionGroup objects are also Group objects, but not all Group objects are also a DistributionGroup.

DistributionGroupMember:

DistributionGroupMember is a noun used to access the membership of a particular distribution group. Only recipients (ie - mail-enabled or mailbox-enabled objects) can be added to the distribution group with Exchange 2007 recipient management tools.

DynamicDistributionGroup:

A DynamicDistributionGroup (DDG) is an AD object that is made available only after Exchange is installed. These objects only exist for the purpose of email, so they cannot exist as non-mail-enabled entities.

The purpose of a DynamicDistributionGroup (sometimes also referred to as Query Based Distribution Group - QBDG) is to provide dynamic group membership based on some criteria or an explicit query.

Exchange Server 2007 provides an updated and friendly set of "precanned" filter criteria that can be used to easily create DDGs. These precanned filters replace the older, overwhelming precanned filters available in Exchange Server 2003 with the most common precanned filters administrators use.

Additionally, if you need to use a filter outside of the scope of the available precanned filters, PowerShell OPATH filter syntax can be used to construct a custom filter query to meet the specific filter needs.

MailPublicFolder:

A MailPublicFolder is an AD object that is made available only after Exchange is installed. These objects only exist for the purpose of mail-enabling public folders, so they cannot exist as non-mail-enabled entities.

Recipient:

A Recipient is any of these previously discussed AD objects after it has been mail or mailbox enabled. All Mailboxes, MailUsers, MailContacts, DistributionGroups, DynamicDistributionGroups, and MailPublicFolders are Recipient objects. Recipient noun is typically used when your goal is to filter against the umbrella of all recipient types.

Exchange Server 2007 Recipient management verbs

Now that we've covered the basic recipient management nouns, let's move on to the verbs. We have a very specific pattern for the verbs that can be explained without even incorporating knowledge of the noun:

- New

- Enable

- Disable

- Remove

- Get

- Set

New:

New verb is used to indicate that you wish to create a new object in the AD and configure it as a recipient object. In order for the New verb to succeed, you must have the required AD rights to create the object (typically at least Account Operator for User, Group, Contact objects). Additionally, you must have rights to the "Exchange property set" attributes so that you can provision the Exchange properties on the AD object.

This verb is typically used in the case where "Split permissions" are not being used and one team owns the provisioning process for AD objects and Exchange recipients.

Since we only create new objects that are recipient objects, there is no concept of New-User, New-Group, or New-Contact. Similarly, we do not create New-MailPublicFolder directly (they must already exist and can only be "enabled"). However, there is New-Mailbox, New-MailContact, New-MailUser, New-DistributionGroup, and New-DynamicDistributionGroup.

Enable:

Enable verb is used to indicate that you wish to set Exchange properties on an existing object in the AD in order to provision it as a recipient object. In order for the Enable verb to succeed, you must have rights to the "Exchange property set" attributes so that you can provision the Exchange properties on the AD object. It is not generally necessary that you have "AD property set" rights from a group like Account Operators for this verb to succeed.

This verb is typically used in the case where "Split permissions" are in effect and AD objects are provisioned independently (and by a different team) than the Exchange provisioning.

There is no concept of Enable-DynamicDistributionGroup since these objects can only exist if they are already mail-enabled. However, there is Enable-Mailbox, Enable-MailContact, Enable-MailUser, Enable-DistributionGroup, and Enable-MailPublicFolder. Additionally, we add the concept of Enable-UMMailbox to configure UM-specific settings on an existing mailbox object.

It is a common use of the Get-* (User, Contact, Group) cmdlets to select some set of objects to be piped ("|") into the respective Enable verb.

Disable:

Disable verb is used to indicate that you wish to remove Exchange properties on an existing recipient object in the AD in order to discontinue its use as a recipient object. In order for the Disable verb to succeed, you must have rights to the "Exchange property set" attributes so that you can remove the Exchange properties from the AD object. It is not generally necessary that you have "AD property set" rights from a group like Account Operators for this verb to succeed.

This verb is typically used in the case where "Split permissions" are in effect and AD objects are provisioned independently (and by a different team) than the Exchange provisioning.

There is no concept of Disable-DynamicDistributionGroup since these objects can exist if they are mail-enabled. However, there is Disable-Mailbox, Disable-MailContact, Disable-MailUser, Disable-DistributionGroup, and Disable-MailPublicFolder. Additionally, we add the concept of Disable-UMMailbox to remove UM-specific settings from an existing mailbox object, leaving the rest of the mailbox settings intact.

It is a common use of the Get-User, Get-Contact, and Get-Group cmdlets to select some set of objects to be piped ("|") into the respective Enable verb.

Remove:

Remove verb is used to indicate that you wish to remove an existing recipient object from the AD. Note that this is a removal of the AD object, not just the Exchange properties. In order for the Remove verb to succeed, you must have the required AD rights to remove the AD object (typically at least Account Operator for User, Group, Contact objects).

This verb is typically used in the case where "Split permissions" are not being used and one team owns the provisioning process for AD objects and Exchange recipients.

Since we only remove AD objects that are recipient objects, there is no concept of Remove-User, Remove-Group, or Remove-Contact. Similarly, we do not Remove-MailPublicFolder directly (instead they must be mail "disabled"). However, there is Remove-Mailbox, Remove-MailContact, Remove-MailUser, Remove-DistributionGroup, and Remove-DynamicDistributionGroup.

Get:

Get verb is used to return some object or objects, including their property details. Couple of typical uses of the Get verb:

Inspect some specific property or properties on an object directly

Filter some set of objects down based on specific criteria and return only that filtered set of objects

Pipe some group of objects into a different cmdlet for some additional action

For Get verb to succeed you just need to have read access to the object or objects being read.

Get is a very powerful verb with many, many additional uses not described here. It is a standard verb for PowerShell and you'll find it used in this same capacity for much more than just recipient management.

Set:

Set verb is used to write a change to the property details of some object or objects. For Set verb to succeed you need to have write access to the object or objects being written. Note that in some cases this may require "Exchange Recipient Administrator" role delegation, and in other cases this may require AD permissions like "Account Operator". What rights are required will depend on which noun is being used and which properties are being "set".

Note that Set verb on some nouns has additional uses (for instance "mailbox type" conversion for Set-Mailbox). Also note that there is no concept of "Set" for Recipient noun, as this noun is used just as an means of conveniently aggregating the multiple recipient types together when filtering for output.

Miscellaneous

Note that not all verbs are available for all nouns (notice there is no "set-recipient" or "new-user", among others).

Additionally, note that there are a couple of oddball verbs that only apply to one noun or have special behavior with only one noun. The most obvious examples are:

Connect-Mailbox

Add-DistributionGroupMember

Remove-DistributionGroupMember

the storeMailbox purge behavior on "Remove-Mailbox"

- Evan Dodds

Exchange 2003 servers can benefit from an Active Directory design that utilizes site architecture to isolate Exchange.  This is best achieved through creating a dedicated Active Directory site which contains both Exchange 2003 servers and Global Catalog servers that are dedicated to the Exchange DSAccess process.  The potential benefits of this architecture are as follows:

- Reduction of Global Catalog overload potential through isolating Exchange messaging traffic and processes from the remainder of the environment by using dedicated Global Catalogs.

- Increased performance for Exchange LDAP queries through Global Catalogs that are dedicated to the Exchange DSAccess process.
NB: This assumes that you have the right number of GC processors to Exchange processors and a well connected network.

- Easier Management and monitoring of the Exchange environment due to segregating out of non-Exchange processes.
NB: However, this segregation will increase the number total number of domain controllers in your environment

- Increased performance for non-Exchange LDAP and directory services processes due to Exchange process segregation.
NB: This assumes that you have enough GC’s to service non-Exchange traffic

Excessive LDAP Read and Search Times can have a negative impact of the ability to service messaging requests. This could include:

- Impact to mail routing (for mail bound internally and externally)

- Impact to Client Ambiguous Name Resolution requests (i.e. address lookups DL expansions etc)

- Impact other functional processes, login authentication for resources (i.e. calendar and PFs) DL access Group Membership

As far as the Active Directory is concerned, Exchange is just an application. While it may be convenient for applications like Exchange to have dedicated sites, it adds complexity to AD. This may be the best approach from the application's perspective, particularly if AD isn't managed correctly or isn't being actively monitored for performance and scaled accordingly. From the AD service owner's perspective, it has dozens if not hundreds of applications to service. AD will strive to provide acceptable levels of service to all clients/apps without extra sites (Extra sites are defined as app-specific ones instead of those based on network topology). What level of performance is deemed acceptable for the AD and the Application (In this case Exchange)? It's entirely up to the application. The service owners need to understand this, monitor their systems closely, and ensure they have the right number of DCs available to meet application requirements.

There is also a risk angle. Even if AD can provide acceptable performance to applications during normal conditions, what happens when an applications starts to perform erratically? If steps are not in place to immediately isolate and repair this behavior, one bad application will begin to impact the others. Dividing AD into separate app-specific sites can help somewhat, but it's not a magic bullet. If another application decides to write millions of objects to the directory in a short period of time, the replication load would span sites and impact the "dedicated" Exchange DCs.

Application owners will generally prefer dedicated domain controllers over shared ones because it reduces the number of external influences on their application. This is not necessarily the best approach for the directory system as a whole because the added complexity is expensive and more difficult to manage. If an organization isn't comfortable with the risk of directory-enabled applications affecting each other, implementing dedicated sites is one way to reduce their risk. Exchange is a very important directory-enabled app and often warrants this kind of protection. That being said, the organization should evaluate their applications and rate each one on criticality, predictability, and supportability. There's nothing wrong with using those same Exchange DCs for other critical, predictable, supportable applications instead of building yet another set of sites.

If you consider Exchange and Outlook as a service (Email), then the change in the DSProxy algorithm introduced in Exchange Server 2003 Service Pack 2 (SP2) adds some additional concerns. If you have a multi domain forest, which has Exchange (and maybe some users) in one domain and users in another, then you may need to add GCs from the users domain into the Active Directory Site where the Exchange servers reside. Of course, this also increases the number of servers required for a dedicated Exchange Site.

Additional Reading Material

XADM: Exchange 2000 May Experience Performance Problems When PDC Emulator Is Used for DSAccess
http://support.microsoft.com/?id=298879

Exchange Server 2003 and Active Directory
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3TechRef/efc39d47-89dc-45de-b5b4-f1e73ac30b34.mspx?mfr=true

Exchange 2000 Server and Active Directory http://www.microsoft.com/technet/prodtechnol/exchange/2000/plan/exchange.mspx#XSLTsection125121120120

XADM: Exchange 2000 May Experience Performance Problems When PDC Emulator Is Used for DSAccess
http://support.microsoft.com/?id=298879

XGEN: Optimizing Windows 2000 Active Directory Servers with Six or Eight Processors to Run with Exchange 2000
http://support.microsoft.com/default.aspx/kb/271088

Within few days, I will talk more about measuring the AD performance.

- Paul Flaherty

Paul Tischhauser demonstrates the "Scheduling Assistant" feature in Outlook 2007 that is enabled with Exchange 2007. You can see the video here:

Jason Mayans discussed the behind-the-scenes evolution of this feature on his Exchange 2007 IW Connections blog. To read this, go to part 1 and part 2.

- The Exchange Team

In Exchange 2007, recipient management is incorporated into the Exchange Management Console and Exchange Management Shell based on Windows PowerShell technology. Shell based management for these recipients allows us to overcome several current challenges of Exchange 2003.

Challenges in Exchange 2003

There are a couple of key challenges in Exchange 2003 that we have specifically addressed with the Exchange 2007 recipient management model:

- Poor separation between Windows Active Directory administrators and Exchange administrators

- Split permissions model hard to implement, not available out of the box

- Automating user management and provisioning is difficult

- Recipient Update Service is a black box and not deterministic

How we've addressed these specific Exchange 2003 challenges

Split Permissions:

In Exchange 2003, splitting permissions for AD operations and Exchange recipient operations required some additional effort. ACLs had to be set throughout the AD to control which users had access to which objects and properties. In many cases, customers simply accepted that Exchange Recipient Administrators would need to be granted the "Account Operator" rights for the AD.

To address the split permissions separation difficulties of Exchange 2003, we've added a new Exchange Administrator role (formerly Delegation) just for recipient management: the "Exchange Recipient Administrator" role!

In Exchange 2007, Exchange-specific AD property sets were created to host the Exchange-related AD properties on recipient objects. Having these additional AD property sets, segregated from the standard AD property set, allows distinct ACLs to be placed on these property sets to allow for controlled access by an "Exchange Recipient Administrator" role, right out of the box.

You can grant someone the "Exchange Recipient Administrator" Exchange Administrator role directly through the console (image below) or the shell (Add-ExchangeAdministrator cmdlet) and they will be able to manage the Exchange-specific properties on the recipients without requiring additional AD permissions such as Account Operator, etc.

Automating Recipient Management:

Doing bulk recipient management in Exchange 2003 was no fun. Either you were forced to use tools like CSVDE/LDIFDE/ADSIEDIT/CDOEXM, or you ended up clicking, and clicking, and clicking, and clicking to work through the GUI for repetitive tasks. Doing these actions by clicking through the GUI might scale to 5 or 10 repetitions, but it definitely doesn't scale to 10,000!

In Exchange 2007, the inclusion of recipient management cmdlets in the EMS allows you unprecedented power and control over your bulk recipient management operations. Using the flexible filtering criteria and powershell object pipelining, you can easily build powerful bulk actions in a single line of "code" - an Exchange powershell "one-liner"!

For example, let's suppose you need to change the mailbox "send quota" for 1,000 mailboxes from 100mb to 200mb. Suppose these are the executives, and that all executives are identified as such by their "title" in the GAL. At its root, this bulk change requires just two basic actions:

1) Collecting the list of mailboxes to be modified

2) Making the change to the mailbox property on all of these collected mailboxes

In Exchange 2003, both of these actions may cause you some trouble. Building the collection in ADUC is not too difficult if you can figure out how to build the proper query with the "Find" command. Unfortunately, once you have your selection of mailboxes, you will need to open up the properties page, switch to Exchange General tab, click on Storage Limits button, uncheck the "use defaults" checkbox, enter the amount (in bytes!), and click ok... FOR EACH MAILBOX, ONE AT A TIME! Can you imagine doing that 1,000 times?

For Exchange 2007 in the shell, the process is much simpler. First, to collect the list of mailboxes to be modified. Execute a command like:

Get-User -Filter { Title -like '*executive*' }

That will return the object of all users in your current scope who have "title" that is "like" "*executive*" (ie - that has "executive" anywhere in the title string). For our simple example, let's assume that we don't have users who match the query which are not also mailbox-enabled. So that means the result of this cmdlet is our 1,000 executive mailboxes! Step one complete!

The second step is to take the action of setting the ProhibitSendQuota to 200mb on these 1,000 mailboxes. For a single mailbox, the syntax would be something like this:

Set-Mailbox Mailbox1 -ProhibitSendQuota 200mb

But the real power is when you bring these two actions together using the power of pipelining, like this:

Get-User -Filter { Title -like '*executive' } | Set-Mailbox -ProhibitSendQuota 200mb

With one line of "code" you've just changed the quota for all 1,000 mailboxes (and saved yourself a lot of time and clicking!)

Couple of quick answers for questions you may be asking:
How did I know to use Get-User vs Get-Mailbox? "Title" is in the Windows AD property set, and the Windows AD property set properties are available on all users, not just mailboxes, so they live on Get/Set-User. Exchange AD property set for mailbox-enabled users is accessed through Get/Set-Mailbox.

What's the filter syntax for PowerShell? There'll be a future blog post on this, but you can get started with some samples that are currently posted to: http://exchangeninjas.com/OPATHSyntaxforDynamicDistributionGroups

How did I know that the property was "ProhibitSendQuota"? I used Get-Mailbox cmdlet and looked for the one that sounded right (and/or I consulted the Get-Mailbox cmdlet help). I could also have gone to the property pages->Mailbox Settings->Storage Quotas and set the "Prohibit Send At (KB):" value for one mailbox to 200mb and then used Get-Mailbox cmdlet to find the property that had been so changed.

Removal of Recipient Update Service:

In Exchange 2003, provisioning a recipient was a bit of a black box. You'd use ADUC to set a couple of properties on an object, and the Recipient Update Service would come along some time later to set the rest of the properties (address list membership, email address proxies, etc). Depending on the complexity of your environment, this process could take several minutes or longer - during which the user could not logon to the mailbox or receive email. Worse yet, if the Recipient Update Service was non-functional for some reason, it was quite hard to tell that it was "not working" rather than just "being slow"!

Exchange 2007 has eliminated the asynchronous behavior of the Recipient Update Service in favor of a more predictable, synchronous provisioning process. When the Shell cmdlet is finished running successfully, the recipient object is fully provisioned (note that this also applies to the GUI since it's just running cmdlets underneath). The mailbox is INSTANTLY ready to be logged on to... go ahead, try it!

Further, in Exchange 2003 it was very easy for a Recipient Policy to be modified such that a number of recipients should have updated proxy addresses and yet these proxy addresses are not updated. The policy was very loosely enforced, and these proxy addresses would only be updated (often, at some unexpected future date) when the policy is specifically "applied" through Exchange 2003 ESM.

Email Address Policies (EAP) in Exchange 2007 (formerly called Recipient Policy) will no longer allow this unexpected behavior. If a recipient is part of an Email Address Policy it is expected that the enforced configuration of the policy would apply to this recipient. Exchange 2007 enforces the correct application of EAP criteria and settings at each save of the recipient object *OR* the EAP object. When an EAP is saved, all associated recipients must be updated with the change. Similarly, any time a recipient object is changed, its EAP membership is reevaluated and enforced. This closes the loop and makes the EAP apply reliably and like an actual "policy"!

Note that the same enforcement applies to AddressList(AL) and Global AddressList (GAL) objects as well.

Realizing that it can be a performance concern to apply these changes during working hours, a scheduling control is available to set these actions to run "after-hours":

- Evan Dodds

If you're part of an organization of any kind, that organization probably has records.  These records can exist in a variety of forms, from paper to Word documents to e-mail. And if you have records, you probably have some way of managing them. They may be in a pile on a desk, in a file cabinet, or stored on a computer or in a more complex filing system.

At a high level, records management is the way in which an organization handles their stored information.  This information carries with it a vast amount of intellectual property and to be productive workers need to have access to what's important to them. Organizations need to develop a system to manage what is kept and what isn't, control what is accessible and to whom, and make sure that workers can find why they need quickly while preventing information overload.  In addition to that, thousands of points of law and regulation exist governing the management of records.

None of this is new information, so why is everyone talking about it now? There have been some big changes over the last few years that have sparked a strong interest in records management:

There's a lot more data now than there used to be: University of California at Berkley researchers estimating that 5 exabytes of new data were created and stored in 2002, 92% of which was on hard drives (link). That's 37,000 US Libraries of Congress and the number is growing each year. Figuring out what to do all with all this data has become complex problem given its scale and accelerating growth.

Managing records has become more expensive. You may be wondering what I mean by that, given that the storage costs per gigabyte of data have been plummeting over the last few years. As storage costs drop, the legal penalties for mismanaging information have gone up dramatically. Here are a few examples:

In December of 2002,  The Securities and Exchange Commission, levied a fine of $8.25 million for failing to follow rules pertaining to electronic communications. This fine was split amongst Deutsche Bank Securities Inc.,  Goldman, Sachs & Co., Morgan Stanley & Co. Incorporated,  and Salomon Smith Barney Inc, (link).

 

In March of 2004, the SEC penalized Banc of America Securities for "Repeated Document Production Failures During a Pending Investigation" because they" "failed promptly to produce electronic mail" pertaining to ongoing litigation. The fine this time was $10 million and it was levied against one company alone. (link).

 

In May of 2005, Morgan Stanley was ordered to pay $1.45 billion in a civil lawsuit, due in large part to failure to properly produce electronic documents. The judge ruled that Morgan Stanley had committed "willful and gross abuse of its discovery obligations" and reversed the standard burden of proof, requiring Morgan Stanley to prove that it had not committed the infractions of which it was accused of instead of requiring the plaintiff to prove that it had (link).

New laws and court judgments have made records management downright scary. Individuals are increasingly being held liable for mistakes and negligence.

In July of 2002, the Sarbanes-Oxley Act became law in the U.S. Unless you've been living under a rock, you've probably heard of this one. Among other things, it specifies jail time for executives who knowingly sign off on inaccurate financial statements.  (link)

 

In April of 2003, former investment banker Frank Quattrone of Credit Suisse First Boston was indicted for obstruction of justice. He sent an e-mail instructing some of his colleagues to "clean up those files" while some of them are being sought by regulators and a grand jury (link).

Understanding these trends, the Exchange team has made some significant investments in Exchange Server 2007 to provide tools to help you better manage your e-mail. Over the next few weeks, we'll be providing some further posts that give you more insight into how this works.

-Julian Zbogar-Smith

Yesterday we gave an overview of the new Exchange 2007 Console, and today I want to cover just the recipient management aspect of the console in a little more detail.

Exchange 2007 Recipient console workcenters

Exchange 2007 incorporates the management of recipient objects and their Exchange-related properties into both the Exchange Management Console and the Exchange Management Shell built on Windows PowerShell techonology. Exchange 2007 introduces a number of new (explicit) Recipient Types that are used to control which set of objects will be shown in GUI pickers, what icon will be displayed for a particular object, etc. This change to explicit recipient types (from implied recipient types in Exchange 2003) allows a lot more certainty in handling objects, as you can always know what "recipient type" it is.

In Exchange 2007, all of our recipient management actions in the GUI are built on top of the Exchange Management Shell. This means that all actions that you can do in the GUI can also be done with a cmdlet in the shell.

In the Exchange Management Console you will see a Recipient Workcenter node, underneath which you will see various recipient type nodes:

-      Mailbox

-      Distribution Group

-      Mail Contact

-      Disconnected Mailbox

Each of these sub-nodes provides a "built-in filter" on the Recipients node to help you more easily scope down the objects to which you will apply some action.

Mailbox:

Mailbox node is where all mailbox user objects are displayed. Only objects that have been mailbox enabled will be visible in this recipient sub-node. This includes the various "recipient types" that correspond to mailboxes.

We now provide explicitly "typed" mailbox recipient types:

-      User mailbox

-      Conference room mailbox

-      Equipment mailbox

-      Linked mailbox

-      Shared mailbox. Note that Shared mailbox is visible from the shell, but is not shown in the GUI.

-      Legacy mailbox.

Since these mailbox recipient recipient types are now explicit, it is possible to filter or sort on this characteristic of a mailbox.

Legacy mailboxes are those mailboxes that are homed on Exchange version prior to Exchange 2007 (i.e. - Exchange 2003 or Exchange 2000). These mailboxes are exposed to Exchange 2007 recipient management, but not all Exchange 2007 features will apply to these mailboxes.

From this location in the GUI you can access property pages for mailbox, create new user accounts with a mailbox associated, enable existing users as mailboxes, disable existing mailboxes, and remove mailbox users from the AD. You can use the GUI to move the mailbox to a different database. Additionally you can do some Unified-Messaging actions, such as enabling UM Mailbox or resetting the Unified Messaging PIN for a UM Mailbox.

Here's what the Mailbox sub-node looks like:

Distribution Group:

Distribution Group node is where all of the distribution group and dynamic distribution group objects are displayed. Only group objects that have been mail enabled will be visible in this recipient sub-node. This includes all of the various distribution group recipient types that correspond to mail-enabled groups.

Here again, we now use explicitly "typed" group recipient types:

-      Mail-enabled universal security group

-      Mail-enabled universal distribution group

-      Mail-enabled non-universal group

-      Dynamic distribution group

Note that although preexisting mail-enabled non-universal groups (i.e. - global or domain local groups) will be shown in this GUI, administration of these groups will be limited. Using mail-enabled non-universal groups can lead to unpredictable membership expansion, and is not recommended. Exchange 2007 administration tools will guide you in all cases to provisioning only universal-scope distribution groups.

From this location in the GUI you can access property pages for distribution groups and dynamic distribution groups, create new distribution groups and dynamic distribution groups, enable existing universal groups as mail-enabled, disable existing mail-enabled groups, and remove distribution groups and dynamic distribution groups from the AD.

Here's what the Distribution Group sub-node looks like:

Mail Contact:

Mail Contact node is where all of the mail-enabled contacts are displayed. Only contact objects that have been mail enabled will be visible in this recipient sub-node.

From this location in the GUI you can access property pages for mail-enabled contacts, create new mail-enabled contacts, enable existing contacts as mail-enabled contacts, disable existing mail-enabled contacts, and remove mail-enabled contacts from the AD.

Note that although not present in Exchange 2007 Beta 2 GUI, Mail-enabled user objects will also be visible at this location when Exchange 2007 releases.

Here's what the Mail Contact sub-node looks like:

Disconnected Mailbox:

Disconnected Mailbox node is where mailboxes that exist in the mailbox database but have been disabled/disconnected can be found. This functionality is used to connect "StoreMailbox" objects inside the mailbox database to an AD user so that this AD user is transformed into a "Mailbox". Two common scenarios for reconnecting mailboxes are: 1) recovering a user's data after the mailbox had been disabled and 2) disaster-recovery of a mailbox database to a different server.

Mailbox objects shown in this node are retrieved from the mailbox table inside the mailbox database rather than from the AD.  Therefore you must specify a particular (single) server to which this action will be scoped. Similarly, these disconnected mailboxes will not be shown in the Recipients node roll-up as they are not found in the AD.

Here's what the Disconnected Mailbox sub-node looks like:

Recipients Node:

The top-level Recipients node is effectively the "roll-up" node where all AD recipient objects can be found.  This is a central location for doing any all-recipients filtering or sorting and many of the same per-recipient recipient-management actions listed for the sub-nodes above will apply equally at this level.

Here's what the Recipients node looks like:

What else is new in Exchange 2007 Recipient Management

We're planning a bunch of additional posts on Exchange 2007 Recipient Management (and Exchange 2007 Administration overall) over the next few months. In the meantime, here's a quick "teaser" list of some of the cool, new things in Exchange 2007 Recipient Management we'll be blogging on soon:

-      Recipient Types - Explicit recipient types replace the implicit recipient types used in Exchange 2003 ("is that a resource mailbox?"). Usable by the rich filtering functionality and Outlook 2007

-      Filtering - Very fast and powerful filtering control in Exchange Management Console. Up to 10 simultaneous expressions with support for implied AND/OR filtering. In the shell, using powershell OPATH filters, the sky's the limit to meet your filtering needs!

-      Scoping - Restrict or expand your scope of actions in Exchange Management Console or the shell all the way from a view of the entire forest down to a single sub-OU deep within your domain. Yes, that's right, you can filter or take other action on recipient objects with a scope of the ENTIRE FOREST! Try doing that in ADUC!

-      Simplified Precanned Filters - The most common "precanned" filters for EAP/AL/GAL/DDG are predefined and available with only a couple of clicks! If you've ever wrestled with the Exchange 2003 precanned filter GUI (nested lists with hundreds of properties listed) to create a simple filter, this new precanned filter control will save you lots of time and effort! And, of course, you can define custom filters on just about anything using the OPATH filter syntax in the shell.

- Evan Dodds

Exchange 2007 introduces a completely updated GUI management console to replace the Exchange System Manager of previous versions. This new Exchange Management Console is still a Microsoft Management Console (MMC) snap-in, just like the old version, and still uses standard GUI elements like a navigation tree, result pane, wizards, property pages, and dialogs.  However significant improvements have been made to greatly simplify the console experience without a complete paradigm shift - in short the console will provide a simplified, intuitive, and an organized management experience, but not a steep learning curve.

The apex of the changes have been in organizing the Exchange 2007 console into 4 work centers:

- Organization Configuration
- Server Configuration
- Recipient Configuration
- Toolbox

The work centers directly map to the type of data that Exchange administrators need to manage in their exchange organization, providing a very consistent and intuitive experience.  A work center is essentially a top level tree node with sub categories (or child tree nodes) as required.  Because the console tree is now used strictly for navigation, all dynamic data was moved from the tree and into the result pane. 

The outcome?  A static navigation tree that is only 3 levels deep and provides an effective way of organizing actions and data for the administrator and rich result pane views.

Here is a side-by-side comparison of the Exchange 2003 tree and the Exchange 2007 tree:

Note:  The Exchange 2003 tree could be expanded to 8 or more levels deep

Figure 1:  Navigation Tree Comparison

Console Frame

As shown below, the fundamentals of the console aren't that different from Exchange System Manager.  There is still a navigation tree and result pane.  The newest addition is the action pane, which is essentially an extension of the right-click menu.  The action pane allows all actions to easily be discovered at a glance without having to right click. The right click menu is still available of course; we understand people LOVE their right click!  In fact, an administrator can choose to save some screen real estate by turning off the action pane completely by going to the View menu and choosing customize (see "Figure 3:  Customize View").

Figure Figure 2:  Console Frame

Figure 3:  Customize View

Organization Configuration

The organization work center is for global or system-wide configuration data. It houses features like E-mail Address Policies (formerly Recipient Policies), Address Lists, and Accepted Domains.  In addition, this work center's sub-nodes are categorized by server-role.  This is because configuration data can both be server-level and organization-wide and thus the server-role grouping provides an effective sub-categorization for both server and organization configuration work centers.  It also makes it very easy to discover all of the configuration data for a particular server-role.  The top-level node of the work center "Organization Configuration" is used for general global data that doesn't map to a specific server role, for instance, managing your Exchange Administrator roles is found on this top-level node.

In addition, the "view" used in the result pane for this work center is a tabbed view.  The tabs across the top of the result pane allows the grouping of similar features & data together but still provides each feature with its own result pane; essentially it is another form of navigation.

Figure 4:  Organization Work Center - Hub Transport Node

Server Configuration

The server work center is for server centric data and contains features like database management and protocols.  Like the organizational work center, its sub-categories are based on server-roles.  The top-level node of this work center "Server Configuration" is used to provide an aggregate view of all Exchange 2007 and higher servers, regardless of server role.  This is really beneficial for an administrator who wants to find a specific server by filtering without having to choose a role. The admin can then select the server and use the "Manage <ServerRole>" link to navigate to the correct sub-node to manage the settings for that server (see "Figure 6: Server Work Center " below for an example).

The result pane for this work center utilizes a work pane which allows us to show child objects for the server and which also has tabs to group similar features.

Figure 5:  Server Work Center - Mailbox Node

Figure 6:  Server Work Center - Manage Role Links

Recipient Configuration Work Center

The recipient work center is for management for all types of recipients, such as mailboxes, distribution groups, and mail enabled contacts.  The functionality that used to be in Active Directory Users & Computers is now in the Exchange Management Console within the recipient work center.  The sub-categories of this work center group similar recipient types, for instance the mailbox node will show user mailboxes, linked mailboxes, resource mailboxes, and so on...  The top-level node of this work center "Recipient Configuration" provides an aggregate view of all recipient types.  The "Disconnected Mailbox" node is used for mailboxes which have been disconnected from the Active Directory user account and remain in the mailbox database.  You use this node to reconnect the mailbox to an AD user account.

Figure 7:  Recipient Work Center

Toolbox Work Center

The toolbox work center is a launching pad for additional tools needed to manage exchange. These are typically tools for troubleshooting, diagnostics, and analyzing your Exchange system.

Example tools that can be found here are Queue Viewer and the Exchange Best Practice Analyzer.

Figure 8:  Toolbox Work Center

- Amanda Langowski

Web servers, network security appliances, and system network stacks have a number of time-based thresholds that are intended to insulate these systems from buggy or malicious clients.  For example, a denial-of-service (DoS) attack could be mounted by failing to complete the handshake that is implicit in the creation of a TCP connection, but the TCP stack in Windows mitigates this threat by requiring that the handshake complete within a finite time.  Similarly, a DoS attack could be mounted against IIS by opening a larger number of TCP connections but never actually issuing an HTTP request.  IIS mitigates this threat by requiring that a client submit a fully-formed HTTP request within a certain time before dropping the connection.
 
Note, however, that there are timeout settings that can be safely increased without compromising the security of the network.  For Direct Push, the timeout of concern is the idle connection timeout; that is, given a fully established TCP connection, for how long should that connection be permitted to live in the absence of traffic?  Recall that the essence of Direct Push is a long-lived HTTP request: the device issues a request, and the server holds that request without responding until either a device-specified timeout (the "heartbeat interval") expires or new email arrives.  When either of those events occurs, the HTTP request is completed, but the connection is idle in the time between the request and response.
 
Now, the design of Direct Push makes no assumption as to the length of its sessions - email is delivered rapidly whether the heartbeat interval is one minute or thirty minutes.  However, using a heartbeat interval of 15-30 minutes has positive implications for battery life and bandwidth consumption: if the Direct Push sessions are permitted to live longer, there will be fewer HTTP roundtrips, less data sent and received, and less power consumed by the device.
 
We will characterize the different types of DoS threats regarding incoming connections and show that increasing the idle connection timeout neither increases nor decreases the exposure to attack:
 
   - An attacker attempts to create a large number of "half open" TCP connections by only partially completing the TCP handshake process.  Increasing idle connection timeouts is unrelated to this type of attack - the time within which a TCP handshake must complete is a separate threshold governed by the Windows TCP/IP stack.
 
   - An attacker establishes a large number of TCP connections but never issues an HTTP request over any of them.  These connections will be closed as soon as the "Connection Timeout" value in the IIS management console is exceeded (this defaults to 120 seconds).  We realize that this setting is misleadingly named, but here again, increasing the idle connection timeout of the firewall appliance does not further expose an enterprise because the attack is mitigated by a separate threshold that is reached before the firewall's idle connection timeout comes into play.
 
   - An attacker establishes a larger number of TCP connections, issues HTTP requests over all of them, but never consumes the responses.  This threat is mitigated by the same timeout as the previous scenario.  That is, the "Connection Timeout" setting in IIS defines the time within which a client must issue its first request after a TCP connection is established and any subsequent requests in an HTTP keep-alive scenario.

Microsoft has worked with mobile operators to increase the idle connection timeouts on their outgoing firewalls, but the enterprises that are deploying Direct Push will also need to increase those timeouts on their incoming firewalls.  In Microsoft’s own deployment, the timeouts on ISA are set to thirty minutes.

- Sami Khoury

We're happy to announce that we have set up a wiki just for Exchange 2007 at www.exchangeninjas.com (alternatively, you can also go to www.theexchangewiki.com). At this site you will find not only useful tips, scripts and FAQs related to Exchange 2007, but you can also show off your product knowledge by contributing and editing content.

Don't be afraid to make changes and add new content - if you mess up you can always revert to a previous version of the page. If you would like to request content or get answers to a question from the community just go ahead and ask a question.

Sign-up to be a ninja today and show the world your Exchange mastery!

- The Exchange Team

Introduction

Customers who are considering Unified Messaging (UM) will at some stage ask the question: "How Many Exchange 2007 Servers running the UM role will I need to support my users?". The short answer to the question is: "That depends". This blog post tries to illustrate the factors on which the answer will depend, and in so doing to give a longer and more helpful answer.

Factors Influencing the Number of Users Supported

Supply: Availability of Resources

The principal resource that is demand is the UM server's ability to sustain concurrent conversations (sessions) with telephone callers. Every voice-over-IP session requires the UM server to dedicate some network bandwidth, processing time and virtual memory. All of these are in limited supply, and so the UM server can handle only a finite number of telephone calls.

Strictly speaking, packet-switched (IP) networks do not exhibit the same characteristics as circuit-switched networks, and are not generally susceptible to the same kinds of traffic analysis. However, Exchange Server 2007 Unified Messaging imposes an absolute limit (which the administrator can configure, if required) on the number of concurrent calls that a given UM server will accept.

Given this limit, and assuming that the UM server is able to sustain this load, well-established techniques can be applied to the question of UM sizing. In particular, Erlang traffic analysis can be used to estimate the number of concurrent calls required to support the UM user population. This provides a mathematical model of competition for a limited number of ports. Such analysis been used for many years for circuit-switched telephony equipment.

If the number of concurrent calls required greater than that supported by a single UM server, the scale-out architecture offered by Exchange Server 2007 UM allows the capacity to be increased by adding UM servers to the Dial Plan.

Demand: Usage by UM-Enabled Users

UM-enabled users can consume UM server communications resources in several ways:

·         Directly

-        By calling into the UM pilot number, logging into their mailboxes, and accessing their messages, calendar, contacts and/or the directory

-        By using a UM server (under the control of Outlook or OWA) to play back voice content on a telephone

·         Indirectly

-        Each time that a caller to UM uses the system to identify and:

-        Transfer the call to the user's phone

-        Sends a voice message (without calling the user's phone)

-        Each time that someone calls the user, fails to reach them and instead:

   -         Leaves a voice message via UM

   -         Leaves a fax message via UM

Demand: Usage by Unauthenticated Callers

People who call into UM over the phone, but do not log into a mailbox, are unauthenticated callers. UM resources may be used in servicing their requests. Some of this usage has already been described above as related in an "indirect" way to contact UM-enabled users. However, there may also be usage that can not be associated with UM-enabled users.

Each time that a caller to UM uses the system to identify a non-UM enabled user (who may appear the directory as a user or a contact) they may:

-        Transfer the call to the user's phone

-        Send a voice message to the user

-        Use an Automated Attendant to transfer to another number, another Auto Attendant, or listen to recorded audio

Demand: Busy Hour and Probability of Not Finding a Resource

In most real-life systems, demand will not be distributed evenly through the day. There will be periods when the demand is low (often at night and in the early morning), and periods of high demand (perhaps shortly after business hours begin, and after lunch). Traditionally, this has been simplified to a single statistic: the fraction (or percentage) of calls arriving in the busiest hour of the day.

If calls arrive with equal probability during the day, the busy hour (like all other hours) will receive (100 × 1 / 24)% = 4.2% of those calls.

A figure of 14% for calls arriving in the busy hour is considered fairly typical. Here, about one-seventh of all the day's calls arrive in just one hour.

UM system managers should try to arrange good service for callers. The most important metric is the fraction of calls offered to UM that actually become connected. Rather than expensively over-provisioning their systems, the administrator may wish to determine a specific level of service. This equates to a probability that, at times of greatest demand, the caller will receive a busy tone, because UM has reached its limit of concurrent calls.

Traffic analysis calculations typically specify both the busy hour occupancy (e.g. 14%) and the probability (P) of finding all "ports" busy.  A value of P = 0.01 means that a caller trying to reach UM in the busiest hour of the day will, on average, have a 1% probability of getting a busy tone instead. Higher values of P therefore correspond to lower levels of service.

Sample Calculations

To illustrate the sort of results that are predicted, Figure 1 shows the results computed for the number of user supported, under various conditions, as a function of the maximum number of concurrent calls allowed. These calculations assume that calls to UM are not queued; either they are answered as soon as possible after they are offered, or the caller receives a "busy" indication and must hang up and retry. This corresponds to the behavior of the majority of PBXs.

Two basic kinds of system are illustrated: one with "light" usage (upper pair of curves), and one with "heavy" usage (lower pair of curves). The pairing of the curves shows that the effect of variations of service level (P = 0.01; P = 0.05) is fairly minor compared to variations in call traffic.

Figure 1. Sample Calculations (small systems)

Clearly, UM can support a user population that is considerably bigger than the number of concurrent calls it can handle. This is easy to understand; users (or callers trying to reach them) don't spend all their time on the phone.

Figure 1 was calculated according to the following assumptions:

In "light" usage, each user receives a handful of voice and fax messages per day, and does not log in over the phone. The assumption is that they use a mail client (Outlook or OWA) to access these messages. Play-on-phone is not included, so voice messages are assumed to be played back with local multimedia.

In the scenario where users are using the system as "experts", they log in several times a day (to check messages, calendar etc.) and receive more call-answered messages, too. This approximates fairly heavy system use, and the number of users supported is correspondingly less.

Naturally, there are scenarios that fall between these curves, and some that even represent lighter or heavier usage.  There is no allowance here for Automated Attendants, which also compete for resources.

Figure 2. Sample Calculations (Larger Systems)

Figure 2 shows the same calculations, extended to larger numbers of concurrent calls. The two "heavy" usage curves are very close together; the higher quality of service (P = 0.01) is the lower of the curves.

At this scale, the number of supported users is approximately proportional to the maximum number of concurrent calls. The non-linear portion of the curves (which was visible in Figure 1) is confined to the smallest systems.

The key statistic is the average fraction of the day (busy hour) which each user (or caller, trying to reach a user) spends interacting with UM over the phone. It does not matter how this time is spent (e.g. user listening to e-mail, system receiving a call-answered fax for the user...), just how much time is spent.

Each UM Server should support a maximum of 60 - 100 concurrent calls. (More precise details will be available by the time that Exchange Server 2007 is released). For large systems, the calculations above suggest that the number of UM-enabled users supported per UM server is of the order of 3000 (heavy usage) to 10000 (light usage).

Caveat

The calculations shown are only intended to illustrate plausible patterns of usage. Each customer will be slightly different, and establishing the average patterns of usage should be a part of any effort to scope the required extent of UM deployment. Additionally, customers may wish to provide one or more "redundant" UM servers to increase overall system availability.

- Michael Wilson

This might have gone unnoticed - but we have two Exchange Server 2007 transport architecture diagrams available for your viewing pleasure:

Exchange2007 Edge Transport Role Architecture

Exchange2007 Hub Transport Role Architecture

You can grab them both on this page.

- The Exchange Team

Now that Beta 2 of Exchange Server 2007 is available for public download and preview, I thought I would present a blogcast about one of my favorite features: Cluster Continuous Replication, or CCR for short.  CCR is a high availability feature of Exchange 2007 that combines the asynchronous log shipping and replay features built into Exchange 2007 with the failover and management features provided by the Microsoft Cluster service. CCR is a solution that can be deployed within a single data center or between two data centers, with no single point of failure.

To demonstrate how to deploy CCR, I have created a 7-part blogcast that takes you through the process.  The blogcast video parts are as follows; please click on video thumbnails below to see the videos:

1. Introduction to CCR

2. Creating the directory and file share for the file share witness

3. Forming a failover cluster with a Majority Node Set (MNS) quorum

4. Configuring the MNS quorum to use the file share witness

5. Installing the active clustered mailbox server role

6. Installing the passive clustered mailbox server role

7. Verifying cluster status, failover, and manageability

These blogcast videos are intended to be watched in full-screen resolution (at least 1024 x 768), and in numbered order. To save time and reduce video size, some of the demos in this blogcast have been compressed or edited without affecting the quality or the results of the demos.

In addition, I ran batch files to accomplish the steps in some of the demos. A couple of the demos involve multiple commands, so to minimize the chance of errors and typos, and to save time, I performed some of the steps using batch files.

A few notes about the blogcast:

-      In Part 3 of the blogcast, I mention that there are some expected errors that I encounter during the formation of the cluster. In the demo, these are actually warnings, not errors. The warnings being encountered refer to the lack of shared storage in the cluster. These warnings can be safely ignored because CCR does not require, or use, shared storage. Some of the warnings being encountered also refer to additional networks and local storage that is present on each node. These extra resources are present because I use these systems for a variety of different demos. Rather than remove them, I leave them disabled. When the New Cluster Wizard analyzes the systems to determine their readiness as a cluster, it finds these disabled resources and issues warnings about them.  It is these types of warnings that can be safely ignored. When you form your own failover cluster, be sure to fully investigate all warnings and errors that appear, and resolve them if necessary.

-      In Part 4 of the blogcast, once the MNS quorum has been configured to use the file share witness, and once the default cluster group has been taken offline and online, the file share witness will be used. Below is a screen shot displaying the contents of the file share witness directory and its sub-directory on the demo system (\\E2K7\MNS_FSQ_EXCLUS). As you can see, there is very little data in the directory. The load on the file share is very light. The presence of the recently created directory (the long GUID with the $ at the end of it) is evidence of the file share witness at work. Once activated, the MNS quorum with file share witness creates a single file in the directory. In order to prevent split brain syndrome, the current MNS resource owner (the node that currently owns the Cluster Group) acquires an exclusive lock on that file when the other node is down or otherwise unavailable. Only the owner of the exclusive lock may survive when nodes lose communication with each other. The current MNS resource owner will also write membership data into that file. When a node starts and forms the cluster, it will use that membership data to determine whether it has the latest cluster state information and can form the cluster without causing split brain syndrome.

Figure 1 - File Share Witness Directory on Hub Transport Server

-      In Part 5 of the blogcast, I mention that the cluster needs a "special, unique IP address." I meant to say it needs a "static, unique IP address." In order for a failover cluster to be supported, it must have at least two network interface cards (NICs) in each node. One NIC is typically dedicated to the private network traffic (e.g., cluster heartbeat traffic), and the other NIC is used for both public network traffic (e.g., client, server, and administrator interaction with the clustered mailbox server and the cluster) and private network traffic (only if the dedicated private network fails). When forming the failover cluster, be sure to follow the instructions in the Exchange Server 2007 product documentation:

-Exchange 2007 Product Documentation (Online/Web) - http://go.microsoft.com/fwlink/?LinkId=69434

- Exchange 2007 Product Documentation (Offline/CHM) - http://go.microsoft.com/fwlink/?LinkId=69162

-      In Parts 5 and 6 of the blogcast, the clustered mailbox server is installed into the cluster (first the active node, then the passive node). Be aware that any pre-requisite checks that fail when installing the clustered mailbox server are not re-checked on the passive. It is very important that you ensure that the passive node meets all pre-requisites, too.

If you now need a refresher of the LCR (Local Continuous Replication) - please see my earlier video on the subject here.

Of course we welcome your feedback on CCR, the documentation for CCR, and this blogcast. Thanks for reading/watching!

-Scott Schnoll