* But Were Afraid to Ask

In Part 1 and Part 2 of this series we looked at the fundamentals of Exchange backups using VSS, and the flow of an active DAG database backup.

In Part 3 we break down how a passive DAG database copy undergoes a full backup. The Exchange Writer responsible for passive copy backups doesn't run in the Information Store Service, but rather as part of the MS Exchange Replication Service. Among other functions, this service coordinates the backup process between the passive copy node and the active copy server. Similar to the backup of an active database described in Part 2, this post describes the backup of a passive database copy of DB1, hosted on server ADA-MBX1. The active mounted database copy is on ADA-MBX2, and again, a non-persistent copy-on-writer (COW) snapshot is utilized by the backup solution:

(please click thumbnails for full size version of graphics in this post)

The first steps to back up a passive database copy are about the same as for an active one. The backup application gets the metadata for DB1 from the Exchange Writer, but again, the writer is running in the MS Exchange Replication Service. A new writer instance GUID is generated which will persist throughout the job, as with an active database backup.

Event 2021 indicates that the backup application, or VSS requestor, has engaged the Exchange Writer. It will appear numerous times throughout the backup as different components are read from metadata, such as log and database file locations.

Events 2110 and 2023 indicate that the backup application has requested a particular set of components to back up, and the backup type.

The replication service for the passive copy’s server signals the active copy server that a backup is in progress. Events 910 and 210 on the active copy server, as well as 960 on the passive copy server, signify two things: First, they establish which server backing up a passive copy of the database; Second, the STORE service on the active copy server has marked the database with “backup in progress” in memory and acknowledges that the surrogate backup will proceed. Once this occurs it is not possible to backup the database again until either the current surrogate backup completes, or the “backup in progress” status is otherwise cleared.

Events 2025 and 2027 are generated when the replication writer prevents the replication service from writing logs copied from the active copy server to the local disk. Replay of logs also stops, thereby keeping the contents of the database files unchanged. At this point writes of data for the database getting backed up are “frozen”. VSS can now create the snapshots in shadow storage for each disk specified in the metadata.

VSS creates snapshots of disks D: and E:. Once these complete it signals the Exchange Writer, which in turns allows the replication service to resume log copy and replay. Events 2029 and 2035 are generated when the “thaw” is completed and normal disk writes are allowed to continue.

Once the snapshots are created the backup application can copy blocks of data through VSS, which transfers blocks of data from shadow storage if they’ve been preserved due to a change, or from the actual disk volume if they haven’t. The replication service writer waits for the signal that the transfer of data is complete. This flow of data is represented by the purple arrows, which in this case indicates data getting copied out of the snapshots in storage, through I/O of the Exchange server, and on to the backup server.

When the files necessary for backing up DB1 are safely copied to backup media, the backup application signals VSS that the job is complete. VSS in turn signals the replication writer, and Exchange generates events 963 and 2046 on the passive copy server. The replication service then signals the Information Store service on the active copy server that the job is done, and that log truncation can proceed if all necessary conditions are met. The active copy node generates events 913 and 213 signaling that the surrogate backup is done, and that the database header will be updated with the date and time of the backup.

Events 2033 and 2037 signal the end of the backup. The active copy node flushes and rolls the current transaction log containing database header updates. That log is then shipped and made eligible for replay according to schedule so that the passive database copy is marked with the new header information at the earliest available time. Log truncation also proceeds if possible. In this case the snapshots are destroyed, and normal operations continue.

For more on the subject of this series here are some more great references:

Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636(WS.10).aspx

Exchange VSS Writers
http://msdn.microsoft.com/en-us/library/bb204080.aspx

Overview of Processing a Backup Under VSS
http://msdn.microsoft.com/en-us/library/aa384589(VS.85).aspx

Backup Sequence Diagrams
http://msdn.microsoft.com/en-us/library/aa579076(v=exchg.140)

Troubleshooting the Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ff597980(EXCHG.80).aspx

Jesse Tedoff

Last week, we announced The New Exchange. Today, we are excited to share its new, refreshed management experience.

For folks familiar with Exchange 2010, there are 3 ways to manage Exchange: the Exchange Management Console (EMC), the Exchange Control Panel (ECP), and the Exchange Management Shell (EMS).

As far as the GUI-based experience is concerned, customers are faced with an incongruous choice between EMC and ECP. While most of the management surface is exposed via EMC, some newer features such as Auditing, eDiscovery, RBAC management, Group naming policy, ActiveSync Quarantined Device management, etc., are only available in ECP. Since these features are applicable to both on-premises as well as online deployments, administrators are forced to learn multiple tools and juggle between them. Specifically for the MMC-based EMC, customers also have to bear IT overhead with respect to updates, patches and so on.

Wouldn’t it be pure bliss if you, the Exchange administrator (expert or novice), had just ONE seamless, integrated way to manage all of Exchange, be it on-premises, online, or even both?

Introducing the Exchange Administration Center (EAC)

With The New Exchange, we are proud to announce a brand new experience for the Exchange administrator: the Exchange Administration Center (EAC)! The EAC brings a completely refreshed, seamless, integrated and unified web-based experience.

(please click on thumbnails to see full size)

Figure 1: Introducing the new Exchange Administration Center (EAC).

EAC adopts some of the key tenets of the Windows 8 style. EAC is clean, light and open. While sporting a simplified look, rest assured that there is no sacrifice on functionality. Usability and visual design tests have driven best-fit functionality exposure. Frequently used elements are readily visible; everything else is available but just a little tucked away to reduce visual clutter. Significant attention has also been given to the Information Architecture model, ensuring that features are easily located across Exchange’s vast administrative surface (for instance, you won’t find oddities such as ActiveSync under Phone/Voice anymore). While designing EAC, we have constantly kept both the seasoned and the novice Exchange administrator in mind, and we believe that EAC scales well for both. Finally, the visual consistency across Office 2013, Windows 8 and Windows Phone is simply refreshing.

A quick tour

Let’s take a quick, whirlwind tour of the new EAC. Subsequent blogs will dig deeper into various key features.

To launch EAC, simply point your favorite browser to your new Exchange 2013 server. As soon as you login, the first thing you will notice is the immediate page load response – a stark difference from Exchange 2010’s EMC! Plus with EAC now relying on local PowerShell, MMC client requirements and annoying startup and WinRM issues are a thing of the past. (Note: The ToolBox still uses MMC).

EAC adopts a simple visual layout as described below:

Figure 2: Visual layout of EAC.

1. Hybrid navigation

This serves to rapidly navigate between on-premises and Office 365 Exchange deployments for customers that are running a Hybrid environment. With SSO in place, managing your complex, hybrid environment is a cinch – all it takes is a mouse-click to switch between your environments. You get the same, full-fidelity EAC experience across your entire deployment.

2. Notifications

Notifications are new in EAC. The infrastructure offers online (visual) as well as offline (email) notifications for any feature that is integrated with it. You no longer need to refresh the UI to be aware of updates. The infrastructure will notify you periodically as appropriate. Currently, the following features are plugged into the notification infrastructure, with more to come soon:

• Import and Export of PST
• Certificate expiration
• Mailbox migration

Figure 3: A closer look at Notifications in EAC.

Every Notification clearly identifies status, and offers contextual links to enable you to quickly navigate and take action as needed.

3. Me tile and Help

The Me tile indicates who’s currently logged in. It also offers an entry point for the Help Desk administrator to login on behalf of another user to troubleshoot his/her settings. The Help link here is the primary Help content entry point. Help, of course, is available throughout EAC, and is context-sensitive.

4. Feature panes

EAC employs an efficient Information Architecture model to surface Exchange’s administrative functions in an effective and meaningful manner. The model aims to collect related administrative features in a best-fit manner into each Feature pane or category. Currently, the Feature panes exposed are:

• Recipients – this covers all recipient management such as user, linked, room, equipment, shared mailboxes, distribution, security and dynamic groups, and mail user and contacts. The center also exposes a Migration entry point and dashboard to monitor all ongoing mailbox migrations in one place
• Permissions – this covers RBAC management functionality in addition to policies such as OWA policies
• Compliance Management – this covers various Compliance and eDiscovery related features such as In-place Discovery & Hold, Auditing, Data Loss Prevention (DLP), Retention Policies and Tags, and Journaling
• Organization – this covers Federation, Sharing, Apps (as described in the recent OWA blog article), and Address Lists
• Protection – this covers Anti-Malware/Anti-Spam
• Mail Flow – this covers Transport Rules, Delivery Reports, Accepted Domains, Email Address Policies, Receive and Send Connectors
• Mobile – this covers Mobile Device Access control and Policies
• Public Folders – this covers Public Folders and Public Folder Mailboxes
• Unified Messaging – this covers all UM administrative functionality such as Dial Plans, Policies, Gateways, etc.
• Servers – this covers Server configuration, High Availability (Databases, DAGs and DAG Networks), Virtual Directories and Certificates
• Hybrid – this covers Hybrid Setup (based on HCW) and Configuration

Note that EAC is fully RBAC-aware. This means that if a certain Feature pane is not applicable or unavailable due to underlying RBAC permissions, EAC will respect the same and not show the respective Feature panes. Additionally, EAC fully supports multiple forest topologies.

A quick glance at the above list should put both the seasoned and the budding Exchange administrator at ease. If you are coming from Exchange 2010, EAC offers the combined feature set of both EMC and ECP, and much more. For the novice Exchange administrator, by incorporating an effective Information Architecture, ensuring key data points/actions are easily available, and reducing visual clutter, we believe that EAC will be equally attractive.

5. Tabs

Tabs represent individual features in a given Feature pane. Each Tab goes deep to expose administrative functionality for a given feature.

Tabs are also RBAC-aware, and only show up depending on your permissions.

6. List view

This represents the core working area of EAC. While the List view may appear visually light, trust us when we say it is functionally rich. The List view has received extra attention to ensure that it performs well in large scale environments. Specifically for Recipient management, EAC’s list view offers asynchronous, background loading of large data sets, paging controls, and ensures that it does not impact your overall experience. The first page of data loads instantly, while the rest is being retrieved in the background. Also available on certain list views is the ability to export data to CSV format, and customizing the views by adding/removing columns. Bulk editing of objects is also available. Finally, with integrated Search experiences, the list view offers a quick, efficient way to work with large datasets.

Figure 4: EAC's new Search experience offers hints.

Figure 5: EAC's Bulk edit experience.

7. Details pane

The Details pane goes hand-in-hand with EAC’s list view. It serves as a context-sensitive work-area surfacing frequently viewed attributes and actions, with just one mouse-click. For example, to enable Archiving for a user, all you need to do is select that user, and click on the Enable link under “Archive” in the Details pane. Without the Details pane, you would need to bring up the user’s property page, navigate to the correct section, and then find the Archiving bit – cumbersome.

Figure 6: Configure Archiving and other common attributes for your users with just one click.

Interoperability

We realize that customers typically have complex, mixed version deployments, spanning multiple Exchange product versions. In line with our vision of a seamless, integrated and unified administrative experience, we have raised the bar on InterOp administration. EAC offers a much better and broader coverage across the board particularly around viewing/modifying lower-version Exchange objects. A subsequent article will dig deeper into this topic.

Accessibility

We have made great strides in making EAC accessible. We have ensured that EAC offers mouse-free, full-keyboard access across all of EAC. For keyboard access specifically, we have provided shortcut keys to work with navigation, forms and controls. Like the new OWA and other Office Web Apps, we also offer a navigation shortcut (CTRL+F6) to quickly navigate across EAC. We have tuned EAC to provide the best High-Contrast experience possible. Additionally, we are proud to say that we have adopted the Accessible Rich Internet Application (ARIA) industry standard to provide a great screen-reader experience for EAC, across Win8 Narrator and JAWS.

Platform support

We are aware that every user has his/her own favorite browser/OS combination, and we have worked hard to ensure that EAC works best across a broad set of popular platform combinations. We are happy to say that EAC works great on IE8, IE9, IE10, FireFox 13+ (Windows, Mac, Linux), Safari 5+ (Mac), and Chrome 20+ (Windows and Mac).

Additional reading

You can find EAC documentation here, and the EAC FAQ here.

Try EAC!

EAC is now available in the latest Exchange 2013 Preview download bits as well as via the Office 365 Customer Preview offering. We will be blogging more to drill-down on certain features. In the meantime, do try the new EAC, and give us your feedback!

The Exchange Manageability Team

Following our last article, introducing the new Exchange Administration Center (EAC), we follow up on how the new EAC makes it really easy to manage multi-forest Exchange deployments.

As described in Deploy Exchange 2010 in a Cross-Forest Topology, Exchange Server 2010 can be deployed in a cross-forest or resource forest topology. For the purpose of this article, we will employ the same approach to deploy a resource forest topology with The New Exchange.

First, let’s setup a resource forest environment as shown below, with a one-way forest trust setup so that Forest B trusts Forest A.

Figure 1: Layout of a resource-forest Exchange topology

Forest A is the account-forest, where all user accounts are provisioned. Forest A does not have any Exchange servers installed. Forest B is the resource forest – with Exchange Server 2013 installed and with linked mailboxes for each of Forest A’s user accounts. Forest B has no user accounts provisioned.

In a lab environment, we have a user, John Doe, setup in Forest A. We now want John Doe to be an Exchange administrator. To do this, we need to ensure that he has the appropriate Role-Based Access Control (RBAC) privileges in place in the Exchange resource forest. Since we are dealing with a multi-forest environment here, there are two ways of configuring RBAC, and we will try both:

1. Using linked mailboxes
2. Using linked role groups

You may already have users setup in an account forest. Configuring these users as linked mailboxes establishes their presence in the Exchange resource forest. By adding these linked mailboxes to existing RBAC role groups, the associated users thus effectively become Exchange administrators.

Using linked mailboxes

In the figure below, John Doe’s user account is setup in the accounts forest. Using EAC, an Exchange administrator can then create a linked mailbox for him, as shown below.

Figure 2: John Doe has been setup as a linked mailbox.

John’s mailbox can then be added to any of the built-in RBAC administrative role groups, thus making him an Exchange administrator. In the screenshot below, John has been made a member of the built-in Organization Management role group.

Figure 3: John Doe has been added as a member of the Organization Management role group.

Now, let’s try logging into EAC as John himself. John should now have Exchange administrative privileges, and that is what we see below.

Figure 4: Logging into EAC as John Doe, configured as a linked mailbox, and as a member of the Organization Management role group.

Using linked role groups

Linked role groups are essentially role groups, but linked via a Universal Security Group (USG) across a forest boundary. Thus members of this USG effectively become members of the linked role groups. This means that if John Doe is a member of such a USG, he automatically gets all RBAC permissions in an Exchange resource forest via the linked role groups. Linked role groups thus make it possible for a small set of USGs in one account forest to manage complex, multiple Exchange forest topologies.

To demonstrate the above, we will do the following:

1. In the account forest, using Active Directory Users and Computers (ADUC) management tool, we will create a USG called AdminSG. AdminSG will represent a group of Exchange administrators. We will then make John Doe a member of AdminSG
2. In the resource forest, we will setup a single linked role group, based on the built-in role group “Organization Management”, mapped to AdminSG, using the following Exchange Management Shell calls:

$accountForestCredential = Get-Credential

$OrgMgmt = Get-RoleGroup "Organization Management"

New-RoleGroup "Organization Management - Linked" -LinkedForeignGroup "AdminSG" -LinkedDomainController bjex062.extest.microsoft.com -LinkedCredential $accountForestCredential -Roles $OrgMgmt.Roles

Get-ManagementRoleAssignment -RoleAssignee "Organization Management - Linked" -Role My* | Remove-ManagementRoleAssignment

Get-ManagementRole | New-ManagementRoleAssignment -SecurityGroup "Organization Management - Linked" -Delegating

With the above steps, John Doe now has all RBAC privileges in the Exchange resource forest even though his user account is in the account forest.

We will now attempt to login to EAC as John Doe. We launch EAC from any desktop, and point it to a CAS server in the resource forest, and we are logged in. John has standard RBAC privileges as defined in the Organization Management RBAC role group and is able to manage Exchange in the resource forest accordingly.

Figure 5: Logging into EAC as John Doe, via the linked Organization Management role group.

Try EAC!

As you can see, EAC makes it a snap to manage multi-forest Exchange deployments. You don’t need to remote into dedicated management machines to manage a specific Exchange forest, nor do you need to create special administrative accounts in every Exchange resource forest. You can do all this right from your own desktop with EAC, with your existing user credentials!

EAC is available in the latest Exchange 2013 Preview download bits as well as via the Office 365 Customer Preview offering. We will continue to write more about EAC in the upcoming weeks. In the meantime, do try the new EAC, and give us your feedback!

The Exchange Manageability Team

The changes in the updated Exchange 2010 Monitoring Management Pack include:

• Fixes to Alerts – at times two events were logged for the same event.
• Ensure Correct Values are read.
• Log the event on local server where the TS is running.

Here is a location of the updated Management Pack: http://www.microsoft.com/en-us/download/details.aspx?id=692 (short: http://aka.ms/ex2010mp)

Note: When you upgrade from the previous Management Pack and you have a Language Pack installed there is no need to update the Language Pack. If you want to update the Language Pack you need to uninstall the previous Language Pack and install the new one.

Thanks,

Exchange Team

A question that has come up several times in recent months is: How do I create RBAC roles that present only very limited ActiveSync management functionality?

Before we dive into the answer let us do a quick review of what RBAC (Role Based Access Control) is.

Prior to Exchange 2010 permissions were defined through tools like DSACLS and ADSIEdit. This let you specify what objects a user or group could touch and what they could do to the object as a whole. If a user needed write access to one specific property of an object, but not the other properties, there was no easy way to handle this. RBAC does not define permissions on the object; instead it defines permissions on the PowerShell cmdlets that can modify the object. PowerShell cmdlets get added to a role and a user or group is assigned to the role. If the cmdlet and parameters you need are part of a role you participate in, then you will be able to run the cmdlet.

In the Exchange Management Shell you can run (get-excommand).count to see how many Exchange cmdlets you currently have access to. In the Exchange Control Panel (ECP) and the Exchange Management Console the cmdlets you have access to determine what options are displayed. Therefore if a window in either GUI requires you have specific PowerShell cmdlets in your role, but you do not have them one of two results is possible:

• The window will not be displayed (in fact options that lead to it are unlikely to be offered)
• The window will display, but all content will be disabled (this is typical if you have the relevant Get- cmdlets, but lack one or more of Set, New, Add, etc.)

For more detail around RBAC, please start with the following:

• RBAC and the Triangle of Power http://blogs.technet.com/b/exchange/archive/2009/11/16/3408825.aspx
• Understanding Role Based Access Control http://technet.microsoft.com/en-us/library/dd298183.aspx

Exchange 2010 SP2 contains 71 RBAC roles. However, none of them offer limited subsets of ActiveSync commands that can be assigned to help desk staff. To create such roles you have to tackle them yourself. If your helpdesk works with PowerShell this is relatively straightforward because you can create a role that has only the PowerShell cmdlet and parameters they require. If the users operate exclusively through the ECP this process is more complex, because the user must be able to navigate to the point where the operation is conducted.

In this example the customer needed helpdesk staff to be able to wipe ActiveSync devices through the Exchange Control Panel. The problem was that only members of Organization Management were able to navigate to the proper window in the ECP and carry out a device wipe. Adding the HelpDesk users to the Organization Management role group was out of the question – it simply has too many rights.

The Administrator tried creating an RBAC role that contained only the Clear-ActiveSyncDevice cmdlet. The problem was that the new role did not allow them to access the functionality through the ECP. The ECP did not allow the users to navigate to the place where the “Wipe Device” button is displayed because the button is nested a few levels down. The user needs to be able to list the users in the Organization, see their Phone and Voice properties and be able to open the dialogs along the way. A role that contains only the Clear-ActiveSyncDevice cmdlet does not include the other cmdlets that are required by these other steps in the ECP. What we have to do from here is figure out what we have to add to this role so we can navigate to the window and click the “Wipe Device” button.

The first step in this process is to look at what roles the Organization Management role group is comprised of. To do this we run:

[PS] C:\>$FormatEnumerationLimit=999
[PS] C:\>get-rolegroup "organization management" | fl roles

Roles : {Active Directory Permissions, Address Lists, ApplicationImpersonation, Audit Logs, Cmdlet Extension Agents, Database Availability Groups, Database Copies, Databases, Disaster Recovery, Distribution Groups, Edge Subscriptions, E-Mail Address Policies, Exchange Connectors, Exchange Server Certificates, Exchange Servers, Exchange Virtual Directories, Federated Sharing, Information Rights Management, Journaling, Legal Hold, Mail Enabled Public Folders, Mail Recipient Creation, Mail Recipients, Mail Tips, Mailbox Import Export, Mailbox Search, Message Tracking, Migration, Monitoring, Move Mailboxes, Organization Client Access, Organization Configuration, Organization Transport Settings, POP3 And IMAP4 Protocols, Public Folder Replication, Public Folders, Receive Connectors, Recipient Policies, Remote and Accepted Domains, Retention Management, Role Management, Security Group Creation and Membership, Send Connectors, Support Diagnostics, Transport Agents, Transport Hygiene, Transport Queues, Transport Rules, UM Mailboxes, UM Prompts, UnScoped Role Management, Unified Messaging, User Options, View-Only Audit Logs, View-Only Configuration, View-Only Recipients, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, RetentionPolicies, MyTextMessaging, MyVoiceMail, MyMailboxDelegation}

From here we need to discard roles that are not going to be directly related to wiping a device. Some of the roles like “Remote and Accepted Domains” are obviously not going to contain related cmdlets. For the potentially interesting Roles our next step is to find out what they contain. To do that we run a cmdlet like this one:

[PS] C:\storage>Get-ManagementRoleEntry "Mail Recipients\*"

Name Role Parameters
---- ---- ----------
Write-AdminAuditLog Mail Recipients {Comment, Confirm, Debug, DomainController, ErrorAction, Er...
Update-Recipient Mail Recipients {Confirm, Credential, Debug, DomainController, ErrorAction,...
Test-MAPIConnectivity Mail Recipients {Archive, Confirm, Debug, ErrorAction, ErrorVariable, Ident...
Set-User Mail Recipients {AssistantName, CertificateSubject, City, Company, Confirm,...

I have cut the output short here and included only a few lines as a demonstration (the actual cmdlet produces 96 results).

From here the next step is to create new child roles of the roles that we believe are useful for our work. Here is an example:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe

The role we just created is a child of Mail Recipients, thus it has all the permissions of its parent. Why not use the Mail Recipients role itself? As we progress I intend to remove pieces from this role so that we can achieve the lowest level of permissions possible. Never modify the built-in roles like Mail Recipients because it will break functionality. Another point to raise: a child of a role can only be assigned the functionality of its parent; it cannot be given any rights or access to functionality that is not already included in the parent.

Once we have created our role we need to create a Role Group. This will make it easier to assign the role to users in the future. For our testing we are using an account called WipeTest. Once testing is complete, replace WipeTest with the account(s) or group(s) desired.

New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles "StrictlyRecipActiveSyncDeviceWipe " -members WipeTest

WipeTest can log into OWA and access the ECP. We find that we can navigate most of the way to the option we want in the ECP, but not all the way. This indicates an additional role is required.

If you look in the Exchange directory (by default c:\Program Files\Microsoft\Exchange) you will find the following path “ClientAccess\ecp\PhoneVoice”. Looking through the files in here will give you some clues as to what you might want to add next. The Web.Config file has numerous mentions of OrganizationConfig, but that isn’t specific enough. We can look through the folder to see if any of the files mention specific cmdlets we might be able to use and that are not in the role we have already defined. One that stands out is Set-CasMailbox (it is in QuarantinedDevices.ASCX). We then checked on where that cmdlet resides:

[PS] C:\>Get-ManagementRoleEntry "*\set-casmailbox" | fl name,role,parameters

Name : Set-CASMailbox
Role : Mail Recipients
Parameters : {ActiveSyncDebugLogging, ActiveSyncEnabled, ActiveSyncMailboxPolicy, Confirm, Debug, DisplayName, DomainController, ECPEnabled, EmailAddresses, ErrorAction, ErrorVariable, EwsAllowEntourage, EwsAllowList, EwsAllowMacOutlook, EwsAllowOutlook, EwsApplicationAccessPolicy, EwsBlockList, EwsEnabled, HasActiveSyncDevicePartnership, Identity, IgnoreDefaultScope, ImapEnabled, ImapEnableExactRFC822Size, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, MAPIBlockOutlookNonCachedMode, MAPIBlockOutlookRpcHttp, MAPIBlockOutlookVersions, MAPIEnabled, Name, OutBuffer, OutVariable, OWAEnabled, OwaMailboxPolicy, PopEnabled, PopEnableExactRFC822Size, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, PrimarySmtpAddress, SamAccountName, ShowGalAsDefaultView, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : Organization Client Access
Parameters : {ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs, Confirm, Debug, DomainController, ErrorAction, ErrorVariable, Identity, OutBuffer, OutVariable, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : User Options
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : MyBaseOptions
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

It is interesting to note the parameter differences. We can exclude MyBaseOptions and UserOptions because their parameters would not help us wipe a device. We have already tried a child role of Mail Recipients and that role did not work. That leaves “Organization Client Access” as a role we could try using. You will notice it has access to the ActiveSyncAllowedDeviceIDs and ActiveSyncBlockedDeviceIDs parameters and they are not present in the Mail Recipients role.

Since we have seen Set-CasMailbox listed in the files we can try creating a new child role of “Organization Client Access” and strip out everything except Set-CasMailbox.

new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

Now we add this new role to the Role Group we created earlier:

New-ManagementRoleAssignment -Name "OCA Child ActiveSyncDevice Wipe" -SecurityGroup "OnlyActiveSyncDeviceWipe" -Role OrgClientAccessWipeDeviceOnly

Now when WipeTest tries to wipe the device they can access the button in the ECP. One problem remains: StrictlyRecipActiveSyncDeviceWipe (a child of “Mail Recipients”) still has too many rights. From here we remove most of the cmdlets from StrictlyRecipActiveSyncDeviceWipe using the following cmdlet:

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

The next stage involves adding cmdlets back in to the role one at a time until we can navigate to the proper location in the ECP and conduct a device wipe. The routine is simple: add a cmdlet, try the operation. If it fails log out of OWA, add another cmdlet and try again. When we get it to work we can either stop or go back and remove individual cmdlets to try and achieve a minimum level of permissions. Below are some examples of the cmdlets we can use.

To add a cmdlet back in we need to do this:

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe

/Aside

If you wanted to put back multiple cmdlets you can use the syntax from the example below:

Get-ManagementRoleEntry "Mail Recipients\*" | where{$_.name -like "get-m*"} | add-ManagementRoleEntry -role StrictlyRecipActiveSyncDeviceWipe

In this blog I only want to insert the cmdlets one at a time, but I included this for illustration.

/End Aside

If we want to remove an individual cmdlet from the role we can use this:

Remove-ManagementRoleEntry "StrictlyRecipActiveSyncDeviceWipe\Get-Mailbox"

(When the “Are You Sure?” prompt appears, select Yes or Yes to All)

In this blog I have included many of the details regarding how I journeyed to the final set of cmdlets. I have left out most of the tedious trial and error, but hopefully included enough detail you can go through this process yourself.

Below I have pasted in a summary of all the cmdlets for those that want to see everything together in a single, concise presentation:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe
new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

(When the “Are you sure?" prompt is presented, select A)

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

(When the “Are you sure?” prompt is presented, select A)

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-user" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-recipient" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-casmailbox" -role StrictlyRecipActiveSyncDeviceWipe
New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles StrictlyRecipActiveSyncDeviceWipe,OrgClientAccessWipeDeviceOnly -members WipeTest

Once these cmdlets are run the WipeTest user (or the user or group you specify) will be able to open OWA, navigate to the ECP and open each of the dialogs needed to reach the point where they can wipe a device.

Thanks to Matt Byrd and Brad Hughes as contributors as I was writing this post.

Chris Pollitt

A brief history of hybrid management

The release of Exchange Server 2010 brought with it a revolutionary new Cloud based service which we all know today as Exchange Online for Office 365. In the early days of the Cloud lots of time and energy was devoted to rapid migration of user and organizational data with some focus on the deployment and support of coexistence between an on-premises Exchange enterprise deployment with a web-based tenant. However, for larger organizations (LORGs) the strong feedback was that in addition to data migration efficiency there is a great need to richly support a longer state of on-premises and Cloud coexistence. The LORGs have spoken and they’ve asked for a full-fidelity, no-compromises management experience for mailboxes based on-premises and in the Cloud.

Exchange Server 2010 was the first to deliver an on-premises plus Exchange Online cross-premises coexistence solution by extending the existing functionality provided by the Exchange Management Console (EMC). EMC is a Windows MMC based client originally geared toward managing large scale deployments of enterprise servers which later evolved into the de facto Exchange Server console that we refer to today simply as “hybrid.” EMC facilitated efficient data migration to the Cloud (Office 365), provided cross-premises recipient management including bulk editing and facilitated the management of most organizational level policies and objects.

EMC is typically used on individual x64 servers hosting Exchange Server roles or separately on workstations via the “Management tools only” installation. It’s a Windows only management tool which means it depends upon local services like WinRM to communicate with remote servers via the PowerShell protocol.

Figure 1: Hybrid Management with Exchange Server 2010

For hybrid management, EMC provides admins the ability to add a second “tree” to the console pane in order to view all recipients, perform mailbox migrations and manage organizational objects related to the Exchange Online tenant. A purely Exchange Online only deployment does not need to apply EMC for management, instead the simplified “Exchange Control Panel” (ECP) console is used which was also new in Exchange Server 2010.

So, what is hybrid?

Hybrid should not be imagined as a unique offering of an Exchange server itself, but rather as a state of coexistence which implies an on-premises server is interacting in cooperation with an Internet-based service. The concept of hybrid is not unique to the Exchange product line and may also be found across the wider family of Microsoft Office servers such as SharePoint and Lync.

In the case of Exchange hybrid, typically it implies a set of mailboxes and policies are distributed across on-premises and Office 365 to act as one “virtual” organization. In previous blog entries on hybrid setup and deployment, you learned that from the perspective of the two premises this state of coexistence is viewed as an internal deployment e.g. certificates are added automatically during cross-premises mail flow from Office 365 tenants to on-premises recipients resulting in the delivered mail being trusted as having originated from within the organization itself although actually arriving via the Internet using dedicated hybrid mail connectors.

There are many possibilities and permutations of how to organize recipients across on-premises and the Office 365 service to suit the needs of your organization. For example, one organization may plan to move 100% of their on-premises recipients to the tenant within two years, another will opt to add all their resource room mailboxes to their Office 365 tenant immediately while yet another chooses to use their online tenant to securely host their online archive mailboxes. The point is we’re delivering flexibility with hybrid designed to meet the needs of your business.

Introducing hybrid management for the new Exchange

This blog post picks up where “Cloud on your terms – Part I” left off by focusing primarily on the “steady state” of hybrid management particularly around the most common scenarios.

For the purposes of this post we’ll assume these pre-requisites have already been satisfied:

• At least one Exchange Server 2013 Client Access Server (CAS15) and Mailbox Server (MBX15) role has been installed. One of each type separately or both residing on a single server e.g. in an interoperability environment featuring a previous edition of Exchange Server.
• The Office 365 tenant version must be 15.0.000.0 or greater to configure a hybrid deployment with Exchange Server 2013. Consult the Office 365 site for latest details on licensing and pricing plans.
• You’ve enabled coexistence via the Office 365 admin portal and performed all other pre-requisite steps as noted including proving coexistence domain ownership.
• You have access to the “tenant administrator” Microsoft Account credentials which are necessary to access the Office 365 tenant.
• All on-premises dependencies are in place e.g. Active Directory Synchronization installed.
• The Hybrid Configuration wizard has been run successfully. This may have included upgrading your previous Hybrid Configuration settings if you were already using hybrid with Exchange 2010 and Office 365.
• You are not using the built-in “administrator” recipient account. Read on for details on why this isn’t supported for hybrid management.

Figure 2: Hybrid Configuration wizard for the new Exchange as reviewed in a previous posting from Ben Appleby

The new Exchange Administration Center hybrid console

To start things off here’s an annotated guide to the new hybrid management console via Exchange Administrator Center (EAC) for the new Exchange:

A) “ENTERPRISE” and “OFFICE 365” pivots – use these to toggle between your on-premises deployment and your online Office 365 tenant

B) A single consolidated central list where all your notifications will appear regardless of where they originated or which pivot you’re currently using e.g. for tracking mailbox migrations from on-premises to Office 365.

C) A single list view containing all recipients from both premises

D) “Details pane” for remote (Office 365) hosted mailboxes

E) Mailbox migration entry point via navigation tab

What’s new in hybrid management for Exchange

The philosophy of hybrid for the new Exchange is dead simple: to provide you, the administrator, with a single familiar console that you can use from nearly anywhere to manage your all-up cross-premises organization.

Here’s a short list of what’s new:

1) We’re taking advantage of having the new full featured browser-based console for Exchange administrators, which means lower maintenance costs required to keep hybrid “Management Tools” installations up-to-date. Updating just your Exchange Server 2013 Mailbox servers will keep all your EAC admins up-to-date.

2) Depending upon the security configuration of the ECP (the protocol name for EAC) IIS virtual directory on the Mailbox servers you can choose to allow both external and internal administrator access or exclusively internal for domain joined machines.

3) From one browser tab you can control of all your recipients and organizational objects (e.g. address lists and policies).

4) A single consolidated set of Exchange Notifications across all premises.

5) Support for Single Sign-On via ADFS 2.0 – there will be future topics presented soon devoted to deploying and managing Single Sign On. More information on preparing to use Single Sign-On is available on Office 365.

Figure 4: ADFS Single Sign-On module for Hybrid mode

6) Manage “Another User …” cross-premises – to perform a help-desk scenario such as setting the out-of-office message on behalf of another user on vacation simply use the “Another user …” option next to your Display Name in the upper right hand corner of the console to view a complete list of recipients across all premises.

Figure 5: Managing "Another user  ..." merged Recipients view

Start using hybrid management mode for Exchange Server 2013

If you’ve already run the Hybrid Configuration wizard (HCW) or the Update-HybridConfiguration cmdlet directly in PowerShell then you are already using EAC’s hybrid mode. In fact, from the “Hybrid” tab in EAC once you click “enable” you’ll be asked for your Microsoft Account credentials and after your tenant is found you’ll be sent right back to EAC but this time running in hybrid mode.

Later on, there’s nothing special you need to do to enter hybrid mode after running the HCW successfully. This is because in addition to enabling key scenarios like mail flow and data sharing (aka free/busy) services cross-premises the wizard creates artifacts on-premises that when present will automatically enable hybrid mode for EAC. Specifically, Update-HybridConfiguration (via HCW) will create a special Remote-Domain object which, when EAC detects a –TargetDeliveryDomain (TDD) property, will start EAC hybrid mode automatically.

One of the biggest difference you’ll notice when using hybrid mode is that when you click the “Office 365” tab it will prompt you to sign into your online tenant via either your Microsoft Account or ADFS credentials. Note that for performance reasons EAC caches whether to use hybrid mode to avoid checking at every logon (the cache state is automatically refreshed every 30 minutes). If you’ve manually created a Remote Domain with a TDD and immediately need to start using hybrid mode you should restart IIS on your Exchange Server 2013 Mailbox servers.

Figure 6: Hybrid Configuration wizard entry point

Managing hybrid in an on-premises interoperability deployment

There are few fine points to consider when managing Hybrid in an on-premises interoperability environment where Exchange 2010 and/or Exchange 2007 servers exist.

In an interoperability deployment, be aware that there’s added functionality you should use with the URI you’re using to access your deployment when logging on if your admin mailbox isn’t on the new Exchange. These URI keys will not be added by default for you in most cases, but stay tuned for more information on future releases which may feature pre-built links. We highly recommend bookmarking URIs with any needed key/value pairings for easy reference.

Reminder that the use of the built-in “administrator” account in Exchange Server should not be used with hybrid management:

Managing your recipients in hybrid mode

A complete list of all recipients is available in the “ENTERPRISE” pivot under the “mailboxes” tab. There are few items you should be aware of when creating and managing new recipients in hybrid mode.

The simple rule to follow when provisioning or modifying any recipient with hybrid is to always use the on-premises “ENTERPRISE” side. This is due to mostly one-way synchronization nature of MSO Directory Synchronization services and ensures that both on-premises and the tenant have the same copies of all recipient Active Directory details.

Figure 7: On-premises mailboxes noted as Mail Users in an Office 365 tenant

Provisioning new mailboxes in Office 365

To provision a new Office 365 mailbox in hybrid mode begin in the on-premises “mailbox” tab then select the “Office 365” mailbox type in the dropdown list from the new icon. Creating a new mailbox in your tenant may impact your available client licenses – view available licenses and plans from the Office 365 portal using your Microsoft Account credentials.

Figure 8: Creating an Office 365 mailbox

You’ll notice that on the “Office 365” service side there is no option to create a mailbox from EAC in hybrid mode. This ensures that all new mailboxes are provisioned from the on-premises side for complete recipient copies. It may be possible for you to directly provision a new Office 365 mailbox from the Office 365 Portal directly but this should not be used in Hybrid deployments since this mailbox will not be “back-synced” from Office 365 to on-premises and mail flow problems may occur.

Modifying recipients is also not recommend or permitted in hybrid mode from the “Office 365” side as this would result in the recipient being out-of-date on one side of the cross-premises deployment. In fact, this operation is blocked by Role-Based Access Control (RBAC) runtime validation rules to prevent divergence of copies (see the error message below).

Figure 9: Edit to recipient in service side blocked to avoid divergence

Much more to come soon!

We hope that you’re as excited as we are about the new hybrid mode for the Exchange Administration Center! Look for more articles covering topics such as Migration, Single Sign-On via ADFS, and debugging for hybrid soon.

Warren Johnson

You may have seen the introduction to the new Exchange Administration Center (EAC). The EAC is a unified Web-based portal for both on-premises and online Exchange deployments. Managing high availability (HA) is one of the key scenarios for on-premises customers, and the EAC delivers a brand new experience of managing HA. With EAC, the HA management tools are put together with a new modern look and feel.

Managing Exchange HA involves different operations like database switchovers, server switchovers, adding database copies, reseeding, etc. In previous versions of Exchange, there were UI gaps in the management consoles that required you to use both the console and the shell for some management tasks. For example, configuring lagged database copies. In previous versions of Exchange, you had to create a lagged database copy using the shell. In Exchange 2013, you can do this using EAC.

When you use the EAC to manage an on-premises environment, you will see a feature pane called “Servers.” This is where the Mailbox server-related HA features are managed. An example of this is shown below in Figure 1.

Figure 1. Where to Manage HA with the EAC

In this feature area, you will see 5 tabs (servers, databases, database availability groups, virtual directories, and certificates). The first 3 tabs are used to manage mailbox server-related HA features.

Database Availability Group creation and configuration

Let’s start by setting up a new DAG. As shown in the figure below, you can quickly create a DAG using the EAC.

Figure 2: new Database Availability Group

Then you can add Mailbox servers to the DAG, as shown in Figure 3.

Figure 3: managing DAG membership

Database and database copies management

Now it’s time for you to switch to database management to configure mailbox databases and deploy database copies on DAG members.

Continuing from where we left off, we switch to the databases tab. As you can see, there is an option called “Add database copy”, as shown in the figure below.

Figure 4: add mailbox database copies

All database copies are shown in the database details pane, as shown in Figure 5.

Figure 5: database copies in details pane

By drilling down to the mailbox database details pane, you can see the status of the selected database and its copies. You can also see important information like copy queue length and content index state. For the passive copies, you can do different operations like suspend and activate based on their current status.

After you have created database copies for a database, you can easily switch to the other databases from the main database list view to create copies of them. As you see, admins can manage database and database copies in one view without switching to another UI. Very handy and straightforward!

Server Switchovers

As mentioned before, besides managing HA at the database level, you can also perform switchovers at the server level. The EAC provides a more comprehensive way of managing servers.

For example, for a variety of reasons, you may need to take some a DAG member offline. The first step in doing this will always be to perform a server switchover; that is, to move all of the active copies currently hosted on that server to other DAG members, as shown below.

Figure 6: Server Switchover

As with Exchange 2010, when performing a switchover, you can specify the switchover target or perform a targetless switchover, as shown below Figure 7.

Figure 7: Two choices for Server Switchover

Conclusion

The handy and improved UI brings you a brand new experience in managing HA in the EAC. You don’t need to toggle between console and shell anymore. And more importantly, you can easily access it from anywhere.

Go and try it out, we are looking forward to hearing from you!

Bin Sun

OAB History

Offline Address Books, fondly referred to as OABs, are a critical component in Exchange infrastructure for a long time now. An OAB is used by Microsoft Outlook clients in Cached Exchange Mode for address book lookups when offline. OABs are also critical in reducing the workload on Exchange servers as cached mode Outlook clients will always query the local OAB first.

The OAB has evolved over Exchange releases. The last major overhaul of OAB architecture was in Exchange Server 2007, where we introduced web-distribution of OAB along with CAS server role taking major responsibility of distributing the OAB. But the OAB generation process itself hasn't changed much.

Until now.

With the change in the server role architecture introduced in Exchange Server 2013, we have also changed the way OABs are generated and distributed to clients. Let’s explore the new OAB in Exchange 2013 by comparing it to its predecessors.

Changes in OAB generation

Which Server will generate the OAB?

In all previous Exchange releases, OAB generation was bound to a specific Exchange server by the Server property. When you install the first Exchange mailbox server, setup designates it as the OAB generation server. You can create new OABs as needed. When creating a new OAB, the OAB generation server has to be specified.

OAB in Exchange Server 2010:

Get-OfflineAddressBook "Default Offline Address Book" | fl name,server
 
Name : Default Offline Address Book
Server : MBX1

The disadvantage with this approach was that only one server was configured for OAB generation, and it was a single point of failure. If this server was unavailable for a long period, the OAB generation was affected.

In Exchange 2013, the OAB is generated by each Exchange 2013 Mailbox server(s) that hosts a special type of arbitration mailbox, called organization mailbox. OAB generation is not bound by the Server parameter anymore.

OAB in Exchange Server 2013:

Get-OfflineAddressBook "Default Offline Address Book (Ex2012)" | fl name,server
 
Name : Default Offline Address Book (Ex2012)
Server :

The unbinding of OAB from a specific server allows the same OAB to be generated by multiple Mailbox servers. This new architecture provides greater resiliency in OAB generation.

Which component will generate the OAB?

The Microsoft Exchange System Attendant service was the workhorse responsible for OAB generation in previous Exchange versions. The OAB generation was a scheduled process, i.e. OAB generation would start at the scheduled time configured on the OAB property, irrespective of the work load on the server.

In Exchange 2013, the OABGeneratorAssistant, a mailbox assistant running under the Microsoft Exchange Mailbox Assistants service, generates the OAB. Like most other mailbox assitants, the OABGEnerationAssistant is a throttled process – it runs or pauses according to the workload on the server.

Where are the OAB files stored?

In previous Exchange versions, the OAB generated by the Mailbox server was located in the %ExchangeInstallPath%\ExchangeOAB folder. The folder was shared so the CAS could retrieve the OAB files for distribution to Outlook clients.

In Exchange 2013, the OAB files are generated and stored in the Organization Mailbox first and later copied to the %ExchangeInstallPath%\ClientAccess\OAB\ folder.

Changes in OAB distribution

Exchange 2007 and 2010 supported two methods of OAB distribution: web distribution and Public Folder distribution. Exchange 2013 supports only the web distribution method, so let’s explore the changes in web-distribution method.

The Exchange 2007/2010 CAS pulled the OAB files generated on the respective Mailbox server and stored them locally. The Microsoft Exchange File Distribution Service on the CAS role did the task of pulling OAB files.

This was the flow OAB download from client side:

1. Outlook receives OAB URL from Autodiscover and reaches a CAS server.
2. The CAS authenticates the user and serves OAB files from local disk.

Couple of disadvantage with this method:

1. The OAB download fails if the CAS doesn't have the OAB files locally.
2. If the File Distribution Service on CAS isn't working, clients will receive stale OAB files or, in other words will not receive the updates.

In Exchange 2013, OAB files are not stored locally on the CAS. CAS 2013 proxies all OAB download requests to the appropriate Exchange 2013 Mailbox server. With this change in the architecture, the Microsoft Exchange File Distribution Service is removed from the CAS role.

In Exchange 2013, this is the flow of OAB download:

1. Outlook receives OAB URL from Autodiscover and reaches designated CAS 2013 through OAB URL.

The CAS server performs the following actions:

1. Performs initial authentication for OAB.
2. Queries Active Directory and determines the closest Organization Mailbox for the requesting user.

3. Queries Active Directory again to determine the mailbox database hosting the Organization Mailbox.

4. Queries the Active Manager to determine the mailbox server where the mailbox database is active (mounted).
5. Proxies the request to the Mailbox server identified in step 4.
6. Retrieves OAB files and passes them to the client.

This new workflow overcomes the disadvantages of legacy OAB download workflow.

The Organization Mailbox

The Organization Mailbox is a new type of arbitration mailbox introduced with Exchange 2013. The arbitration mailbox with persisted capability OrganizationCapabilityOABGen is referred to as Organization Mailbox. It plays a crucial role in OAB generation, storage and distribution.

Each Exchange Server 2013 mailbox role hosting an Organization Mailbox will generate all Exchange 2013 OAB’s defined in the environment. The OAB is generated in the Organization Mailbox first and later copied to the disk.

Use the following command to identify the Organization mailbox:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}

Example:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}
 
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
SystemMailbox{bb558c35... SystemMailbox{bb5... mbx1 Unlimited

Storing the OAB files in the Organization Mailbox makes the OAB files more resilient.

Putting it together: A real-life scenario:

The following scenario puts together the critical points we learned so far:

1. MBX1 and MBX2 are Exchange 2013 Mailbox servers and member of a DAG. CAS1 is an Exchange 2013 CAS.
2. The organization mailbox is present on mailbox database DB1. DB1 has copies on MBX1 and MBX2.
3. DB1 is currently active on MBX1.
4. The Microsoft Exchange Mailbox Assistants service on MBX1 will generate the OAB.
5. The OAB will be first generated in the organization mailbox and later copied to disk of MBX1. At this point, MBX2 is not playing any role in OAB generation.
6. An Outlook client tries to download OAB, and reaches CAS1 through OAB URL.
7. CAS1 queries Active Manager and finds out database hosting organization mailbox (DB1) is active on MBX1.
8. CAS1 proxies the OAB download request to MBX1 and serves the files back to the client.
9. At this point, MBX1 goes down due to power failure and DB1 is activated on the server MBX2.
10. CAS1 receives another request for OAB download, queries the Active Manager again and this time proxies the request to MBX2, as DB1 is now active on MBX2.
11. MBX2 extracts OAB files present in the organization mailbox to the disk, to ensure latest files are served to the client.
12. MBX1 comes back online, but DB1 remains active on MBX2.
13. At next OAB generation work cycle, the Microsoft Exchange Mailbox Assistants service on MBX2 will generate the OAB.

The next article in this series will talk about how to manage the new OAB in Exchange 2013.

Bhalchandra Atre

Many organizations have chosen to configure a hybrid deployment with Exchange Online to take advantage of different features such as rich mailbox moves and cross-premises calendar free/busy sharing. This includes Exchange 2003, Exchange 2007 and Exchange 2010 organizations that require a long-term hybrid configuration with Exchange Online and organizations that are using a hybrid deployment as a stepping stone to migrating fully to Exchange Online. So, at what point should these organizations decide to get rid of their on-premises Exchange servers used for the hybrid deployment? What if they have moved all of the on-premises mailboxes to Exchange Online? Is there a benefit to keeping on-premises Exchange servers? While it may seem like a no-brainer, the decision to get rid of the on-premises Exchange servers is not simple and definitely not trivial.

Mailbox Management

Organizations that have configured a hybrid deployment for mailbox management and hybrid feature support have also configured Office 365 Active Directory synchronization (DirSync) for user and identity management. For organizations intending on keeping DirSync in place and continuing to manage user accounts from the on-premises organization, we recommend not removing the last Exchange 2010 server from the on-premises organization. If the last Exchange server is removed, you cannot make changes to the mailbox object in Exchange Online because the source of authority is defined as on-premises. The source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a hybrid deployment. If you needed to edit most mailbox settings, you would have to be sure the Active Directory schema was extended on-premises and use unsupported tools such as Active Directory Service Interfaces Editor (ADSI Edit) for common administrative tasks. For example, adding a proxy address or putting a mailbox on litigation hold when there isn’t an Exchange Management Console (EMC) or Exchange Management Shell (Shell) on-premises becomes difficult and these simple (and other more complex) tasks cannot be done in a supported way.

Note: A hybrid deployment is not required in order to manage Exchange objects from an on-premises organization. You can effectively manage Exchange objects with an on-premises Exchange server even if you do not have an organization relationship, Federation Trust, and third-party certificate in place. This Exchange server gives you a supported method for creating and managing your Exchange recipient objects. It is recommended to use Exchange Server 2010 for management tasks since this will give you the option to create objects such as remote mailboxes with the New-RemoteMailbox cmdlet. The server role needed is at least a Client Access Server (CAS) role, for management tools to work properly.

Online Organizations without On-Premises Exchange Servers

Some Exchange Online organizations may have removed all Exchange servers from their on-premises organization and have felt the user management pain mentioned above first hand. Each situation is unique, but in many cases an Exchange 2010 server can simply be added back to the organization to simplify the management process. These organizations will need to ensure that a mail-enabled user is in place for all Exchange Online mailboxes in order to properly configure the mailboxes. Assuming DirSync is still deployed in the on-premises organization, duplicate object issues shouldn’t be a problem.

Managing Users from the On-Premises Organization when Source of Authority is Online

There are some organizations that have created an Office 365 service tenant and started to use Exchange Online only to realize they want to consolidate the user management tasks. There are also some organizations that came from hosted environments or migrated from Business Productivity Online Services (BPOS) where they did not manage their users from an on-premises organization. Now that they are in Office 365 and using Exchange Online, they want to simplify the user management process. In either case, if you have DirSync deployed and you are using Exchange Online, you should have an on-premises Exchange server for user management purposes.

The process for changing the source of authority after the users are created in Office 365 would be to use the DirSync “soft match” process outlined here. This will allow organizations to manage the user account and Exchange Online mailboxes from the on-premises organization. Organizations need to verify that there was a mail-enabled user in the on-premises directory for the corresponding Exchange Online mailboxes. Organizations that haven’t had an Exchange server deployed previously will need to install an Exchange 2010 server. Office 365 for enterprises customers can obtain an Exchange Server 2010 license at no charge by contacting customer support. This license has limitations and doesn’t support hosting on-premises mailboxes.

Removing the HybridConfiguration Object created by the Hybrid Configuration Wizard

When a hybrid deployment is created using the Hybrid Configuration Wizard, the wizard creates the HybridConfiguration Active Directory object in the on-premises organization. The HybridConfiguration object is created when the New-HybridConfiguration cmdlet is called by the Hybrid Configuration Wizard. The object stores the hybrid configuration information so that the Update-HybridConfiguration cmdlet can read the settings stored in the object and use them to provision the hybrid configuration settings.

Removing the HybridConfiguration object isn’t supported in Exchange Server 2010. There isn’t a cmdlet that will remove the HybridConfiguration object and the object can reside in Active Directory without adverse effects as long as the Hybrid Configuration Wizard isn’t run again.

However, removing the HybridConfiguration object is supported in Exchange Server 2013. The new Remove-HybridConfiguration cmdlet will remove the HybridConfiguration object from the configuration container, however it will not disable or remove any existing hybrid deployment configuration settings.

Although many people want to remove the HybridConfiguration object as part of their Exchange decommissioning plan, it isn’t critical and is optional.

Removing a Hybrid Deployment

The proper way to remove a hybrid deployment is to disable it manually. The following actions should be performed to remove the objects created and configured by the Hybrid Configuration Wizard:

1. Re-point your organization’s MX record to the Office 365 service if it is pointing to the on-premises organization. If you are removing Exchange and don’t point the MX record to Office 365, inbound Internet mail flow won’t function.

2. Using the Shell in the on-premises organization, run the following commands:

Remove-OrganizationRelationship –Identity “On Premises to Exchange Online Organization Relationship”
Remove-FederationTrust –Identity “Microsoft Federation Gateway”
Remove-SendConnector “Outbound to Office 365”

3. Using EMC, you can also remove the <your organization domain>.mail.onmicrosoft.com domain that was added as part of the email address policy for your organization.

4. OPTIONAL - Remove the remote domains created by the Hybrid Configuration wizard in the Exchange Online organization. From the EMC, select the Hub Transport in the Exchange Online forest node and remove all remote domains starting with “Hybrid Domain” shown below:

5. Remove the organization relationship from the Exchange Online organization with the following command. You must use Remote PowerShell to connect to Exchange Online connected to Exchange Online. For detailed steps, see Connect Windows PowerShell

Remove-OrganizationRelationship –Identity “Exchange Online to On Premises Organization Relationship”

6. OPTIONAL - Disable the Inbound and Outbound Forefront Online Protection for Exchange (FOPE) connectors created by the Hybrid Configuration Wizard. These connectors can be disabled using the FOPE Administration Console and the release option shown below:

Note: Removing or modifying objects with ADSIEDIT isn’t supported.

Conclusion

Most of the time the reason for most organizations that have configured a hybrid deployment, removing the last Exchange server from the on-premises environment will have adverse effects. In most cases, we recommend that you leave at least one Exchange 2010 Server on-premises for mailbox management unless you are getting rid of the on-premises messaging and identity management dependencies all together.

Timothy Heeney

In Exchange Online and Exchange Server 2013, you can use In-Place Hold to preserve mailbox content for litigation or investigations. Many organizations also need to preserve mailbox data for users who are no longer in the organization.

In on-premises Exchange deployments, this has typically been done by disabling the Active Directory user account and performing actions such as removing it from distribution groups, preventing inbound/outbound email to and from the mailbox (including setting delivery restrictions and configuring message size limits), hiding the mailbox from the Global Address List (GAL), and also setting an account expiration date on the user account in Active Direcory. Licensing costs are not a concern in this scenario, because you do not need a Client Access License (CAL) for a mailbox that’s no longer active.

In Exchange Online, admins remove mailboxes for departed users. However, once you remove a mailbox, it can no longer be included in eDiscovery searches (using Multi-Mailbox Search in the previous version). Additionally, 30 days after you remove a mailbox, it is permanently deleted from Exchange Online and can no longer be recovered. Multi-Mailbox Search requires that the mailbox be active, which means an Exchange Online or Office 365 plan is required for the mailbox for as long as you want to preserve data for eDiscovery.

Note: You can preserve mailbox data offline by exporting it to a PST file using Microsoft Outlook and then remove the mailbox. However, if you need to perform an eDiscovery search, you would need to inject it back to an Exchange Online mailbox.

Inactive Mailboxes

In the new Exchange Online, we’ve introduced the concept of inactive mailboxes to handle departed users. When a user leaves the organization and you need to retain their mailbox data for some time to facilitate eDiscovery (or meet retention or business requirements), you can place the mailbox on In-Place Hold before removing it. This preserves the mailbox, but prevents it from sending/receiving messages, hides it from users so it's no longer visible in the GAL and other recipient lists. You can add inactive mailboxes to In-Place eDiscovery searches. Inactive mailboxes do not require an Exchange Online or Office 365 plan.

When your eDiscovery, retention or other business requirements are met and you no longer need to preserve the mailbox content, you can remove the mailbox from In-Place Hold. After you remove hold, the normal mailbox removal behavior of Exchange Online will resume for the mailbox - if the mailbox was removed more than 30 days ago, it will be permanently deleted. If it was removed less than 30 days ago, it will be permanently deleted after 30 days of removal.

For more details, see Managing Inactive Mailboxes (short url: aka.ms/inactivembx) in Exchange Online documentation.

Inactive mailboxes are available in March 2013 in the E3, E4, A3, A4, G and Exchange Online P2 plans.

Bharat Suneja

In Exchange 2010, when a database availability group (DAG) member needs service, it can be placed into maintenance mode. Exchange 2010 includes scripts the StartDagServerMaintenance.ps1 and StopDagServerMaintenace.ps1 scripts to place/remove a DAG member from maintenance mode. For a summary of what these scripts do, see this post.

Within a DAG, it is not uncommon to have one or more databases or servers blocked from automatic activation by the system. Some customers configure entire servers to be blocked from activation, some block individual copies, and some do a combination of both, based on their business requirements. Administrators using the maintenance mode scripts will find their configured activation blocks reset to the unblocked. This behavior is not a problem with the scripts; in fact, the scripts are working as designed.

Here is an example of a database copy that has had activation suspended:

[PS] C:\>Get-MailboxDatabaseCopyStatus DAG-DB0\MBX-2 | fl name,activationSuspended

Name                             : DAG-DB0\MBX-2
ActivationSuspended              : True

Here is an example of a server that has activation blocked:

[PS] C:\>Get-MailboxServer MBX-2 | fl name,databasecopyautoactivationpolicy

Name                             : MBX-2
DatabaseCopyAutoActivationPolicy : Blocked

When the administrator executes the stopDagServerMaintenance.ps1 script, these states are reset back to their defaults. Here is an example of the states post StopDagServerMaintenance.ps1:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-MailboxDatabaseCopyStatus DAG-DB0\MBX-2 | fl name,activationSuspended

Name                             : DAG-DB0\MBX-2
ActivationSuspended              : False

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-MailboxServer MBX-2 | fl name,databasecopyautoactivationpolicy

Name                             : MBX-2
DatabaseCopyAutoActivationPolicy : Unrestricted

Although the maintenance scripts behavior is by design, it can lead to undesirable scenarios, such as lagged database copies being activated. Of course, to eliminate these issues, an administrator can record database and server settings before and after maintenance and reconfigure any reset settings as needed.

To help with this, here is a sample script I created that records database and server activation settings into a CSV file which can then be used with the maintenance scripts to adjust the states automatically.

What the script does

When you run the script, it creates two CSV files (on the server you run it on) along with a transcript that contains the results of the command executed. The first CSV file contains all database copies assigned to the server and their activation suspension status. Here's an example:

#TYPE Selected.Microsoft.Exchange.Management.SystemConfigurationTasks.DatabaseCopyStatusEntry
"Name","ActivationSuspended"
"DAG-DB0\DAG-3","True"
"DAG-DB1\DAG-3","True"

The second CSV file contains the database copy auto activation policy of the server. For example:

#TYPE Selected.Microsoft.Exchange.Data.Directory.Management.MailboxServer
"Name","DatabaseCopyAutoActivationPolicy"
"DAG-3","Blocked"

Using maintenanceWrapper.ps1 to start and stop maintenance

Because this scipt is unsigned, you'll need to relax the execution policy on the server to allow for unsigned scripts.

IMPORTANT: Allowing unsigned PowerShell scripts to execute is a security risk. For details, see Running Windows PowerShell Scripts. If this option does not meet your organization's security policy, you can sign the script (requires a code-signing certificate).

This command sets the execution policy on a server to allow unsigned PowerShell scripts to execute:

Set-ExecutionPolicy UNSIGNED

You can use the maintenanceWrapper.ps1 script to start and stop maintenance procedure on a DAG member.

1. Use this command to start the maintenance procedure:

   maintenanceWrapper.ps1 –server <SERVERNAME> –action START

   The command creates the CSV files containing the original database states and then invokes the StartDagServerMaintenance.ps1 script to place the DAG member in maintenance mode.

2. After maintenance is completed, you can stop the maintenance procedure using this command:

   maintenanceWrapper.ps1 –server <SERVERNAME> –action STOP

   The command calls the StopDagServerMaintenance.ps1 script to remove the DAG member from maintenance mode and then resets the database and server activation states from the states recorded in the CSV file.

Give the script a try and see if it makes maintenance mode for activation-blocked servers and databases easier for you. I hope you find this useful, and I welcome any and all feedback.

*Special thanks to Scott Schnoll and Abram Jackson for reviewing this content and David Spooner for validating the script.

Tim McMichael

Prior to Exchange 2007, there were two primary methods of implementing automated resource scheduling – Direct Booking and the AutoAccept Agent(a store event sink released as a web download for Exchange 2003). In Exchange 2007, we changed how automated resource scheduling is implemented. The AutoAccept Agent is no longer supported, and the Direct Booking method, technically an Outlook function, has been replaced with server-side calendar booking function called the Resource Booking Attendant.

Note There are various terms associated with this new Resource Booking function, such as: Calendar Processing, Automatic Resource Booking, Calendar Attendant Processing, Automated Processing and Resource Booking Assistant. We will be using the “Resource Booking Attendant” nomenclature for this article.

While the Direct Booking method for resource scheduling can indeed work on Exchange Server 2007/2010/2013, we strongly recommend that you disable Direct Booking for resource mailboxes and use the Resource Booking Attendant instead. Specifically, we are referring to the “AutoAccept” Automated Processing feature of the Resource Booking Attendant, which can be enabled for a mailbox after it has been migrated to Exchange 2007 or later and upgraded to a Resource Mailbox.

This conversion process to resource mailboxes utilizing the Resource Booking Attendant is sometimes an honest oversight or even deliberately ignored when migrating away from Exchange 2003 due to Direct Booking’s ability to continue to work with newer versions of Exchange, even Exchange Online. This will often result in resource mailboxes (or even user mailboxes!) with Direct Booking functionality remaining in place long after Exchange 2003 is ancient history in the environment.

Why not just leave Direct Booking enabled?

There are issues that can arise from leaving Direct Booking enabled, from simple administrative burden scenarios all the way to major calendaring issues. Additionally, Resource Booking Attendant offers advantages over Direct Booking functionality:

1. Direct Booking capabilities, technically an Outlook function, has been deprecated from the product as of Outlook 2013. It was already on the deprecation list in Outlook 2010 and required a registry modification to reintroduce the functionality.
2. Direct Booking and Resource Booking Attendant are conflicting technologies, and if simultaneously enabled, unexpected behavior in calendar processing and item consistency can occur.
3. Outlook Web App (as well as any non-MAPI clients, like Exchange ActiveSync (EAS) devices) cannot use Direct Booking for automated resource scheduling. This is especially relevant for Outlook Web App-only environments where the users do not have Microsoft Outlook as a mail client.
4. The Resource Booking Attendant AutoAccept functionality is a server-side solution, eliminating the need for client-side logic in order to automatically process meeting requests.

How do I check which mailboxes have Direct Booking Enabled?

How does one validate if Direct Booking settings are enabled on mailboxes in the organization, especially if mailboxes had previously been hosted on Exchange 2003?

Figure 1: Checking Direct Booking settings in Microsoft Outlook 2010

Unfortunately, the manual steps involve assigning permissions to all mailboxes, creating MAPI profiles for each mailbox, logging into each mailbox, checking Tools> Options> Calendar> Resource Scheduling, note which of the three Direct Booking checkboxes are checked, click OK/Cancel a few times, log out of mailbox. Whew! That can be a major undertaking even for a small to midsize company that has more than a handful of mailboxes! Having staff perform this type of activity manually can be a costly and tedious endeavor. Once you have discovered which mailboxes have the Direct Booking settings enabled, you would then have to repeat this entire process to disable these settings unless you removed them at the time of discovery.

Having an automated method to discover, track, and even disable Direct Booking settings would be nice right?

Look no further, we have the solution for you!

Using Exchange Web Services (EWS) and PowerShell, we can automate the discovery of Direct Booking settings that are enabled, track the results, and even disable them! We wrote Remove-DirectBooking.ps1, a sample script, to do exactly that and even more to aid in automating this manual effort.

After you've downloaded it, rename the file and remove the .txt extension.

IMPORTANT  The previously uploaded script had the last line truncated to Stop-Tran (instead of Stop-Transcript). We've uploaded an updated version to TechNet Gallery. If you downloaded the previous version of the script, please download the updated version. Alternatively, you can open the previously downloaded version in Notepad or other text editor and correct the last line to Stop-Transcript.

Let’s break down the major tasks the PowerShell script does:

1. Uses EWS Application Impersonation to tap into a mailbox (or set of mailboxes) and read the three MAPI properties where the Direct Booking settings are stored. It does this by accessing the localfreebusy item sitting in the NON_IPM_SUBTREE\FreeBusy Data folder, which resides in the root of the Information Store in the mailbox. The three MAPI properties and their equivalent Outlook settings the script looks at are:

   • 0x686d Automatically accept meeting requests and remove canceled meetings
   • 0x686f Automatically decline meeting requests that conflict with an existing appointment or meeting
   • 0x686e Automatically decline recurring meeting requests

   These three properties contain Boolean values mirroring the Resource Scheduling checkboxes found in Outlook (see Figure 1 above).

2. For mailboxes where Direct Booking settings were detected, it checks for conflicts by determining if the mailbox also has Resource Booking Attendant enabled with AutomateProcessing set to AutoAccept.
3. Optionally, disables any enabled Direct Booking settings encountered.

   Note It is important to understand that by default the script runs in a read-only mode. Additional command line switches are available to run the script to disable Direct Booking settings.

4. Writes a detailed runtime processing log to console and log file.
5. Creates a simple output text file containing a list of mailboxes that can be later leveraged as an input file to feed the script for disabling the Direct Booking functionality.
6. Creates a CSV file containing statistics of the list of mailboxes processed with detailed information, such as what was discovered, any errors encountered, and optionally what was disabled. This is useful for performing analysis in the discovery phase and can also be used as another source to create an input file to feed into the script for disabling the Direct Booking functionality.

Example Scenarios

Here are a couple of example scenarios that illustrate how to use the script to discover and remove enabled Direct Booking settings.

Scenario 1

You've recently migrated from Exchange 2003 to Exchange 2010 and would like to disable Direct Booking for your company’s conference room mailboxes as well as any user mailboxes that may have Direct Booking settings enabled. The administrator’s logged in account has Application Impersonation rights and the View-Only RecipientsRBACrole assigned.

1. On a machine that has the Exchange management tools & the Exchange Web Services API 1.2 or greater installed, open the Exchange Management Shell, navigate to the folder containing the script, and run the script using the following syntax:

   .\Remove-DirectBooking.ps1 –identity * -UseDefaultCredentials

2. The script will process all mailboxes in the organization with detailed logging sent to the shell on the console. Note, depending the number of mailboxes in the org, this may take some time to complete
3. When the script completes, open the Remove-DirectBooking_<timestamp>.txtfile in Notepad, which will contain list of mailboxes that have Direct Booking enabled:

   
   Figure 2: Output file containing list of mailboxes with Direct Booking enabled

4. After reviewing the list, rerun the script with the InputFile parameter and the RemoveDirectBookingswitch:

   .\Remove-DirectBooking.ps1 –InputFile ‘.\Remove-DirectBooking_<timestamp>.txt’ –UseDefaultCredentials -RemoveDirectBooking

5. The script will process all the mailboxes listed in the input file with detailed logging sent to the shell on the console. Because you specified the RemoveDirectBooking switch, it does not run in read-only mode and disables all currently enabled Direct Booking settings encountered.
6. When the script completes, you can check the status of the removal operation by checking the Remove-DirectBooking_<timestamp>.csv file. A column called Direct Booking Removed? will record if the removal was successful. You can also check the runtime processing log file RemoveDirectBooking_<timestamp>.logas well.

   
   Figure 3: Reviewing runtime log file in Excel (see larger screeshot))

Note The Direct Booking Removed? column now shows Yes where applicable, but the three Direct Booking settings columns still show their various values as “Yes”; this is because we record those three values pre-removal. If you were to run the script again in read-only mode against the same input file, those columns would reflect a value of N/A since there would no longer be any Direct Booking settings enabled. The Resource Room?, AutoAccept Enabled?, and Conflict Detected all have a value of N/A regardless because they are not relevant when disabling the Direct Booking settings.

Scenario 2

You're an administrator who's new to an organization. You know that they migrated from Exchange 2003 to Exchange 2007 in the distant past and are currently in the process of implementing Exchange 2013, having already migrated some users to Exchange 2013. You have no idea what resources mailboxes or even user mailboxes may be using Direct Booking and would like to discover who has what Direct Booking settings enabled. You would then like to selectively choose which mailboxes to pilot for Direct Booking removal before taking action on the majority of found mailboxes.

Here's how you would accomplish this using the Remove-DirectBooking.ps1 script:

1. Obtain a service account that has Application Impersonation rights for all mailboxes in the org.
2. Ensure service account has at least Exchange View-Only Administrator role (2007) and at least have an RBAC Role Assignment of View Only Recipients (2010/2013).
3. On a machine that has the Exchange management tools & the Exchange Web Services API 1.2 or greater installed, preferably an Exchange 2013 server, open the Exchange Management Shell, navigate to the folder containing the script, and run the script using the following syntax:

   .\Remove-DirectBooking.ps1 –Identity *

4. The script will prompt you for the domain credentials of the account you wish to use because no credentials were specified. Enter the service account’s credentials.
5. The script will process all mailboxes in the organization with detailed logging sent to the shell on the console. Note, depending the number of mailboxes in the org, this may take some time to complete.
6. When the script completes, open the Remove-DirectBooking_<timestamp>.csvin Excel, which will looks something like:

   
   Figure 4: Reviewing the Remove-DirectBooking_<timestamp>.csv in Excel (see larger screeshot))

7. Filter or sort the table by the Direct Booking Enabled? column. This will provide a list that can be scrutinized to determine which mailboxes are to be piloted with Direct Booking removal, such as those that have conflicts with already having the Resource Booking Attendant’s Automated Processing set to AutoAccept (which you can also filter on using the AutoAccept Enabled? column).
8. Once the list has been reviewed and the targeted mailboxes isolated, simply copy their email addresses into a text file (one address per line), save the text file, and use it as the input source for the running the script to disable the Direct Booking settings:

   .\Remove-DirectBooking.ps1 –InputFile ‘.\’ -RemoveDirectBooking

9. As before, the script will prompt you for the domain credentials of the account you wish to use. Enter the service account’s credentials.
10. The script will process all the mailboxes listed in the input file with detailed logging sent to the shell on the console. It will disable all enabled Direct Booking settings encountered.
11. Use the same validation steps at the end of the previous example to verify the removal was successful.

Script Options and Caveats

Please see the script’s help section (via “get-help .\remove-DirectBooking.ps1 -full”) for full information on all the available parameters. Here are some additional options that may be useful in certain scenarios:

1. EWSURL switch parameter By default, the script will attempt to retrieve the EWS URL for each mailbox via AutoDiscover. This is preferred, especially in complex multi-datacenter or hybrid Exchange Online/On-premises environments where different EWS URLs may be in play for any given mailbox depending on where it resides in the org. However, there may be times where one would want to supply an EWS URL manually, such as when AutoDiscover is having “issues”, or the response time for AutoDiscover requests is introducing delays in overall script execution (think very large quantity of number of mailbox identities to churn through) and the EWS URL is the same across the org, etc. In these situations, one can use the EWSURL parameter to feed the script a static EWS URL.
2. UseDefaultCredentials If the current user is the service account or perhaps simply has both the Impersonation and the necessary Exchange Admin rights per the script’s requirements and they don’t wish to be prompted to type in a credential (another great example is scheduling the script to run as a job for instance), you can use the UseDefaultCredentials to run the script under that security context.
3. RemoveDirectBooking By default, the script runs in read-only mode. In order to make changes and disable Direct Booking settings on the mailbox, you mus specify the RemoveDirectBooking switch.

The script does have several prerequisites and caveats to ensure proper operation and meaningful results:

1. Application Impersonation rights and minimum Exchange Admin rights must be used
   • For Exchange 2007, see Configuring Exchange Impersonation (Exchange Web Services)
   • For Exchange 2010/2013, see Configuring Exchange Impersonation (uses RBAC)
2. Exchange Web Services Managed API 1.2 or later must be installed on the machine running the script
3. Exchange management tools must be installed on the machine running the script
4. Script must be executed from within the Exchange Management Shell
5. The Shell session must have the appropriate execution policy to allow the script to be executed (by default, you can't execute unsigned scripts).
6. AutoDiscover must be configured correctly (unless the EWS URL is entered manually)
7. Exchange 2003-based mailboxes cannot be targeted due to lack of EWS capabilities
8. In an Exchange 2010/2013 environment that also has Exchange 2007 mailboxes present, the script should be executed from a machine running Exchange 2010/2013 management tools due to changes in the cmdlets in those versions

Summary

The discovery and removal of Direct Booking settings can be a tedious and costly process to perform manually, but you can avoid and automate it using current functions and features via PowerShell and EWS in Microsoft Exchange Server 2007, 2010, & 2013. With careful use, the Remove-DirectBooking.ps1 script can be a valuable tool to aid Exchange administrators in maintaining automated resource scheduling capabilities in their Microsoft Exchange environments.

Your feedback and comments are welcome.

Thank you to Brian Day and Nino Bilic for their guidance in content review, and to our customers (you know who you are) for piloting the script.

Seth Brandes& Dan Smith

A question that is often asked of Support in regard to legacy Public Folders is whether they're replicating and how much progress they're making.  The most common scenario arises when the administrator is adding a new Public Folder database to the organization and replicating a large amount of data to it.  What commonly happens is that the administrator calls Support and says:

The database on the old server is 300GB, but the new database is only 150GB!  How can I tell what still needs to be replicated?  Is it still progressing??

You can raise diagnostic logging for public folders, but reading the events to see which folders are replicating is tedious.  Most administrators want a more detailed way of estimating the progress of replication than comparing file sizes.  They also want to avoid checking all the individual replication events.

There are a number of ways to monitor replication progress so that one can make an educated guess as to how long a particular environment will take to complete an operation.  In this post, I'm going to provide a detailed example of one approach to estimating the progress of replication by comparing item counts between different public folder stores.

Getting Public Folder item counts

To get the item counts in an Exchange 2003 Public folder database you can use PFDAVAdmin.  The process is outlined in this previous EHLO blog post.  For what we're doing below, you'll need the DisplayName, Folderpath and the total number of items in the folder. The rest of the fields aren't necessary.

To get the item counts on an Exchange 2007 server, use (remember there is only one Pub per server):

Get-PublicFolderStatistics -Server <servername> | Export-Csv c:\file1.txt

To get the item counts on an Exchange 2010 server, you use:

Get-PublicFolderStatistics -Server <servername> -ResultSize unlimited | Export-Csv c:\file1.txt

Comparing item counts

There are some very important caveats to this whole procedure.  The things you need to watch out for are:

• We're only checking item counts.  If you delete 10 items and add 10 items between executions of the statistics data, gathering this type of query will not reveal whether they have replicated.  Therefore, having the same number on both sides is not necessarily an assurance that the folders are in sync. 
• If you're comparing folders that contain recurring meetings, the item counts can be different on Exchange 2007 and older because of the way WebDAV interacts with those items.
• I've seen many administrators try to compare the size of one Public Folder database to the size of another.  Such an approach to checking on replication does not take into account space for deleted items, overhead and unused space.  Checking item counts is more reliable than simply comparing item sizes
• The two databases might be at very different stages of processing replication messages.  It is unlikely that both pubs will present the same numbers of items if the folders are continuously active.  Even if the folders are seeing relatively low activity levels, it's not uncommon for the item count to be off by one or two items because the replication cycle (which defaults to every 15 minutes) simply hasn’t gotten to the latest post
• If you really want to know if two replicas are in sync, try to remove one.  If Exchange lets you remove the instance, you know Exchange believes the folders are in sync.  If Exchange cannot confirm the folders are in sync, it'll keep the instance until it can complete the backfill from it.  In most cases, the administrators I have spoken with are not in a position where they can use this approach.

For the actual comparison you can use any number of products.  For this blog I have chosen Microsoft Access for demonstrating the process of comparing the CSV files from the different servers.  To keep things simple I am going to use the Access database.  There are some limitations to my approach:

• Access databases have a maximum file size of 2GB. If your public folder infrastructure is particularly large (i.e.  your CSV files are over 500MB) you may have to switch to using Microsoft SQL.
• I am not going to compare public folders with a Folder path greater than 254 characters because the Jet database engine that ships with Access cannot join memo fields in a query.  Working around the join limitation by splitting the path across multiple text fields is beyond the scope of this blog.
• I am going to look at folders that exist in both CSV files.   If the instance has not been created and its data exported into the CSV file the folder will not be listed.

An outline of the process is:

1. Export the item counts from the two servers you wish to compare
2. Import the resulting text files
3. Clean up the data for the final query
4. Run a query to list the item counts for all folders that are in Both files and the difference in the item counts between the originally imported files

Assumptions for the steps below:

• You have exported the public folder statistics with the PowerShell commands presented above
• You have fields named FolderPath, ItemCount and Name in the CSV file

If your file is different than expected you will have to modify the steps as you go along

Here are the steps for conducting the comparison:

1. Create a new blank Microsoft Access database in a location that has more than double the size of your CSV files available as free space.

2. By default, the Export-Csv cmdlet includes the .NET type information in the first line of the CSV output. Because this line will interfere with the import, we'll need to remove it.  Open each CSV file in notepad (this can take a while for larger files) and remove the line highlighted below.  In this example the line starting with “AdminDisplayName” would become the topmost line of the file.  Once the top line is deleted close and save the file.

Figure 1

TIP You can avoid this step by including the -NoTypeInformation switch when using the Export-CSV cmdlet, which filters out the .NET object type information from the CSV output. For details, see Using the Export-Csv cmdlet on TechNet. (Thanks to #MSExchange MVP @SteveGoodman for the tip!)

3. Import the CSV file to a new table:

• Click on the External Data tab as highlighted in Figure 2
• Browse to the CSV file and select it (or type in its path and name directly)
• Make sure the “Import the source data into a new table in the current database’ option is selected
• Click OK

Figure 2

4. In the wizard that starts specify the file is delimited as shown and then click Next.

Figure 3

5. Tell the wizard that the text qualifier is the double quote (character 34 in ASCII), the delimiter is the comma and that the “First Row Contains Field Names” as shown in Figure 4.

Note:  It is possible that you will receive a warning when you click “First Row Contains Field Names”.  If any of the field names violate the rules for a field name Access will display a warning.  Don’t panic.  Access will replace the non-conforming names with ones it considers appropriate (typically Field1, Field2, etc.).  You can change the names if you wish on the Advanced screen.

Figure 4

6. Switch to Advanced view (click the Advanced button highlighted in Figure 4) so that we can change the data type of the FolderPath field.  In Access 2010 and older the data type needs to be changed from Text to Memo.  In Access 2013 it needs to be changed from Short Text to Long Text.  While we are in this window you have the option to exclude columns that are not needed by placing a checkmark in the box from the skip column.  In this blog we are only going to use the FolderPath, name and the item count.  You can also exclude fields earlier in the process by specifying what fields will be exported when you do the export-csv.  The following screenshots show the Advanced properties window.

Figure 5a: Access 2010 and older

Figure 5b: Access 2013

Note:  If you think you will be doing this frequently you can use the Save As button to save your settings.  The settings will be saved inside the Access database and can then be selected during future imports by clicking on the Specs button.

7. Click OK on the Advanced dialog and then click Finish in the wizard.

8. When prompted to save the Import steps click Close.  If you think you will be repeating this process in the future feel free to explore saving the import steps.

9. Access will import the data into a table.  By default the table will have the same name as the source CSV file.  The files used in creating this blog were called 2007PF_120301 and 2010 PF_120301.  If there are any import errors they will be saved in a separate table.  Take a moment to examine what they are.  The most common is that a field got truncated.  If that field is the folderpath it will affect the comparisons later.  If there are other problems you will have to troubleshoot what is wrong with the highlighted lines (typically there should be no import errors as long as the FolderPath is set as a Memo field).

10. Go back to Step 2 to import the second file that will be used in the comparison. 

11. Now a query must be run to determine if any folderpath exceeds 255 characters.  Fields longer than 255 characters cannot be used for a join in an Access query.  If we have values that exceed 255 characters in this field we will need to exclude them from the comparison.  Additional work to split a long path across multiple fields can be done, but that is being left as an exercise for any Access savvy readers. 

12. To get started select the options highlighted in Yellow in Figure 6:

Figure 6

13. Highlight the table where we want to check the length of the folderpath field as shown in Figure 7.  Once you have selected the table click Add and then Close:

Figure 7

14. Switch to SQL view as shown in Figure 8:

Figure 8

15. Replace the default select statement with one that looks like this (please make sure you substitute your own table name for the one that I have Bolded in the example):

SELECT Len([FolderPath]) AS Expr1, [2007PF_120301].FolderPath
FROM 2007PF_120301
WHERE (((Len([FolderPath]))>254));

Note:  Be sure the semi-colon is the last character in the statement.

16. Run the query using the red “!” as shown in Figure 9: 

Figure 9

Figure 10

17. If the result is a single empty row (as shown in Figure 10) then skip down to step 19.  If the result is at least one row then go back to SQL view (as shown in Figure 8) and change the statement to look like this one (as before please make sure 2007PF_120301 is replaced with the table name actually being used in your database):

SELECT [2007PF_120301].FolderPath, [2007PF_120301].ItemCount,
[2007PF_120301].Name, [2007PF_120301].Identity INTO 2007PF_120301_trimmed
FROM 2007PF_120301
WHERE (((Len([FolderPath]))<255));

18. You will get a prompt like the one in Figure 11 when you run the query.  Select Yes:

Figure 11

19. After it is done repeat steps 11-18 for the other CSV file that was imported to be part of the comparison.  If you have done steps 11-18 for both files you will be comparing then advance to step 20.

20. Originally the FolderPath was imported as a memo field (Long Text if using Access 2013).  However we cannot join memo fields in a query.  We need to convert them to a text field with a length of 255. 

If you got a result greater than zero rows in step 16 this step and the subsequent steps will all be carried out on the table specified in the INTO clause of the SQL statement (in this blog that table is named 2007PF_120301_trimmed). 

If you were able to skip steps 17 and 18 this step and the subsequent steps will be carried out on the table you imported (2007PF_120301 in this example).

Open the table in Design view by right-clicking on it and selecting Design View as shown in Figure 12.  If you select the wrong tables for the subsequent steps you will get a lot of unwanted duplicates in your final comparison output.

Figure 12

21. Change the folderpath from Memo to Text as shown in Figure 13.  If you are using Access 2013 change it from Long Text to Short Text.

Figure13

22. With the FolderPath field highlighted look to the lower part of the Design window where the properties of the currently selected field are displayed.  Change the field size of folderpath to 255 characters as shown in Figure 14.

Figure 14

23. Save the table and close its design view.  You will be prompted as shown in Figure 15.  Don’t panic.  All the folderpaths should be shorter than the 255 characters specified in the properties of the table.  The dialog is just a standard warning from Access.  No data should be truncated (the earlier queries should have seen to that).  Say Yes and repeat steps 20-23 for the other table being used in this comparison.  If you make a mistake here remember that you will still have your original CSV files and can always fix the mistake by removing the tables and redoing the import.

Figure 15

24. We have been on a bit of a journey to make sure we prepared the tables.  Now for the comparison.  Create a new query (as shown in Figure 6) and highlight both tables that have had the FolderPath shortened to 255 characters as shown in Figure 16.  Once they are highlight click Add and then close.

Figure 16

25. Drag Folderpath from the table that is the source of your replication to Folderpath on the other database.  The result will look like Figure 17.

Figure 17

26.   In the top half of the Query Design window we have the tables with their fields listed.  In the bottom half we have the query grid.  You can make fields appear in the grid in 3 ways:

• Switch the SQL view and add them to the Select statement
• Double-click the field in the top half of the window
• Drag the field from the top half of the window to the grid
• Click in the Field line of the grid and a drop down will appear that you can use to select the fields
• Type the field name you want on the Field in the grid

For this step we need to add:

• One copy of the folderpath field from one table (doesn’t matter which one)
• The ItemCount field from each table

27.   Go to an empty column in the grid.  We need to enter the text that will tells us the difference between the two item counts.  Type the following text into the column (be sure to use the table names from your own database and not my example): 

Expr1:  Abs([2007PF_120301_trimmed].[itemcount]-[2010pf_120301_trimmed].[itemcount])

Note:  After steps 25-27 the final result should look like  Figure 18.  The equivalent SQL looks like this:

SELECT [2007PF_120301_trimmed].FolderPath, [2007PF_120301_trimmed].ItemCount, [2010PF_120301_trimmed].ItemCount, Abs([2007PF_120301_TRIMMED].[ItemCount]-[2010PF_120301_TRIMMED].[ItemCount]) AS Expr1
FROM 2007PF_120301_trimmed INNER JOIN 2010PF_120301_trimmed ON [2007PF_120301_trimmed].FolderPath = [2010PF_120301_trimmed].FolderPath;

Figure 18

28. Run the query using the red “!” shown in Figure 9.  The results will show you all the folders that exist in BOTH public folder databases, the itemscount in each database and the difference between them.  I like the difference reported as a positive number, but you might prefer to remove the absolute value function.

There is more that can be done with this.  You can use Access to run a Find Unmatched query to find all items from one table that are not in the other table (thus locating folders that have an instance in one database, but not the other).  You can experiment with different Join types in the query and you can deal with Folderpaths longer than a single text field can accommodate.  These and any other additional functionality you desire are left as an exercise for the reader to tackle.  I hope this provides you with a process that can be used to compare the item counts between two Public Folder stores (just remember the caveats at the top of the article).

Thanks To Bill Long for reviewing my caveats and Oscar Goco for reviewing my steps with Access.

Chris Pollitt

Organizations often need to share availability (aka Free/Busy) information with other Exchange organizations. Depending on the version of Exchange Server you're on, there are different ways to do this. Let's take a look at three common scenarios and go through the exact steps required in order to achieve sharing of availability information between two on-premises Exchange organizations.

Scenarios:

1. Scenario 1: Both organizations running Exchange 2010 SP1
2. Scenario 2: One (or both) organizations running a mix of both Exchange 2007 and Exchange 2010 SP1
3. Scenario 3: One (or both) organizations running a mix of Exchange 2003, Exchange 2007 and Exchange 2010 SP1

This summary table outlines the requirements in order to facilitate Availability lookups between two organizations:

*refer to “Option A” and Option B” which are discussed later in this post

Scenario 1: Both organizations are running Exchange 2010 Sp1

This is the simplest scenario. Users in both organizations are on Exchange 2010, both organizations can use Federated Delegation and do not require any additional steps.

1. Both organizations must first set up a Federation Trust. The steps to create a Federation trust are documented in Create a Federation Trust. The Federation Trust should be in place and working for both organizations before the organization relationship is set up.
2. Register the DNS TXT records for the federated domain namespace and all other domains you wish to add to the federation trust. The account namespace (this is the federated delegation organization identifier or OrgID) identifies your organization to the Microsoft Federation Gateway. You must use a domain other than your primary SMTP domain (used to receive inbound email) for the account namespace, as documented in Configure Federated Delegation. The current recommendation is to use exchangedelegation.domain.com as the account namespace.
3. Ensure that the autodiscover web service is configured and working for your domain namespace. Although it's possible to manually configure the organization relationship, we recommended that you use autodiscover.
4. Create an organization relationship with the remote organization. The steps to create an organization relationship are documented in Create an Organization Relationship.

Note: Directory synchronization is not required in order to do cross-org availability in Exchange 2010 SP1, except if you have users on Outlook 2007/2003. However, if you choose to configure directory synchronization, it'll not impact the ability to perform availability lookups.

Scenario 2: One or both organizations are running Exchange 2010 SP1 and Exchange 2007

Steps 1-4 in this scenario are the same as Scenario 1. However, with Exchange 2007 in the mix, directory synchronization is requiredbetween the two organizations. You must also create an availability address space for the remote organization. This allows Exchange 2007 users in both organizations to benefit from Exchange 2010's support for federation.

5. For Exchange 2007 to query availability cross org, directory synchronization must be performed for all users for which Free/Busy needs to be shared. This can be performed either manually (create Exchange contacts or Mail-enabled users one at a time), or via an automated process (MIIS, ILM, FIM, other 3rd party dirsync tool, etc.).

   Dirsync is required in this case because Exchange 2007 requires (and expects) a local object when the availability request is performed. If no local Exchange object is present, the availability request will fail.

6. Create a new availability address space for the remote organization that directs availability request from 2007 users to the 2010 Sp1 server. The syntax for creating the availability address space is included below.

   Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl https://Exchange2010SP1CAS.InternalDomain.com/ews/exchange.asmx -ForestName Fabrikam.com -UseServiceAccount $True

   With this setting, when an Exchange 2007 user requests availability information for a user from the remote org, the request will be proxied through the Exchange 2010 Sp1 server, which then will utilize the Federation Trust and Organization Relationship to send the availability request to the remote forest availability endpoint.

   
   Figure 1: Exchange 2007 user requests availability for a user in remote organization
   1. Step 1. Exchange 2007 user requests availability from user in Org B. Exchange 2007 proxies the request to the Exchange 2010 SP1 server.
   2. Step 2 and 3. Exchange 2010 detects it is for a remote org, and detects there's an Organization Relationship. Exchange then validates the Federation Trust.
   3. Step 4. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   4. Step 5. The Availability service in Org B generates a respond and sends back to the Exchange 2010 SP1 CAS server in Org A.
   5. Step 6. The availability response is returned to Exchange 2007, which then returns the response to the client.

Scenario 3: One or both organizations are running Exchange 2003, Exchange 2007 and Exchange 2010 SP1

Steps 1-4 in this scenario are the same as Scenario 1. Steps 5-6 in this scenario are the same as Scenario 2. Additionally, since you have Exchange 2003 in the topology, you must choose one of the two options described below in Option A and Option B.

With either option, there are considerations that must be made. Please reference the known issues section at the end of this post to better understand these considerations. With both options, it's assumed that you have performed all previous steps outlined in Scenario 1 and Scenario 2.

Option A:

1. Ensure that there is an Exchange 2010 Sp1 Mailbox server that hosts a Public Folder database.
2. Move ALL replicas of Free/Busy public folders to the Exchange 2010 Sp1 Public Folder server, and remove ALL replicas from either 2003 or 2007. This will allow Exchange 2010 SP1 to respond to all Public Folder free/busy requests.

   As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query, and route the request to the Availability service, which will then process the request as outlined in previous scenarios

3. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the targetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This is done via the Exchange Management Shell by running this command:

   Set-organizationrelationship –identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

   Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. This can be obtained by running Get-WebServicesVirtualDirectory –server 2010cas.contoso.com | fl name, *url*

   
   Figure 2: Exchange 2003 user requests availability information for user in remote org (Option A)
   1. Step 1. Exchange 2003 user requests availability from user in Org B. Since the mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDN attribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines the Administrative Group in which the object was created and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).

      For example, Joe User's LegacyExchangeDN is LegacyExchangeDN=/o=First Organization/ou=Exchange 2003 Admin Group/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou=Exchange 2003 Admin Group is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder.

   2. Step 2. The Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides.
   3. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox server intercepts the Free/Busy request and routes it to the Availability service.
   4. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust.
   5. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   6. Step 7. The Availability service in Org B generates a response and sends it back to the Exchange 2010 SP1 CAS server in Org A.
   7. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.

Option B

1. Ensure that there's an Exchange 2010 SP1 Mailbox server that hosts a Public Folder database.
2. If not already present, create the Free/Busy system folder called External (FYDIBOHF25SPDLT) and ensure that the only replica of this Free/Busy Folder is on the Exchange 2010 SP1 server.

   Note:This External free busy folder will only be created on a new Exchange 2010 SP1 install when the option to create the public folders is selected during setup. The option is only presented if it's the first server installed in the organization. If a public folder database was not created during setup, you'll need to manually create this folder. The process to create this External folder is simple.

   1. Connect to the on-premise Exchange 2010 SP1 Public Folder server (this has to be done from the Public Folder server)
   2. Open Windows PowerShell
   3. Type " Add-PsSnapin Microsoft.Exchange.Management.Powershell.Setup"
   4. Then Type " Install-FreeBusyFolder"

   This will create the new Schedule Plus free busy folder called "External (FYDIBOHF25SPDLT)".

3. Modify the LegacyExchangeDN on all mail-enabled objects that reference the remote organization and change the OU value to External (FYDIBOHF25SPDLT). As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query and route the request to the Availability service, which will then process the request as outlined in previous scenarios.
4. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the TargetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This command populates the TargetSharingEPRproperty:

   Set-OrganizationRelationship –Identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

   Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. You can obtain it by running Get-WebServicesVirtualDirectory –Server 2010cas.contoso.com | fl Name, *url*

Figure 3: Exchange 2003 user requests availability information for user in remote org (Option B)

1. Step 1. Exchange 2003 user requests availability from user in Org B. Since the requesting client mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDNattribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines which Administrative Group the object was created in, and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).

   For example: LegacyExchangeDN=/o=First Organization/ou= External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou= External (FYDIBOHF25SPDLT)/is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder.

2. Step 2. Since the mail-enabled user has had the legacyExchangeDN modified, and the only replica of the External free/busy folder is on Exchange 2010, the Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides.
3. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox role intercepts the Free/Busy request and routes it to Availability.
4. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust.
5. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
6. Step 7. The response is generated by the Availability service in Org B and sent back to the Exchange 2010 SP1 CAS server in Org A.
7. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.

Known Issues/Concerns

Issue #1 - OWA 2003

When Exchange 2003 users use OWA to schedule a meeting, they will look at “Availability” tab in the form, which will request free/busy from public folders via DAV. A free/busy request for DAV looks like this:

http://ExchangeServer/public/?Cmd=freebusy&
start=2009-10-28T00:00:00-07:00&
end=2009-10-29T00:00:00-07:00&
interval=30&
mbxguid=ea14502f-44cc-41ae-9f1d-df519a16ad20&
u=SMTP:mary@Contoso&
u=SMTP:joe@Contoso.com

Note: The above text is actually a single line string, it was broken down into multiple lines for easy reading.

DAV can only retrieve free/busy for users in the local public folder database. When OWA loads pages and scripts in the browser, it passes the URL to the public folder corresponding to the user mailbox. If the is no local replica for the folder corresponding to the first user provided in u= entry in the URL, DAV will do HTTP redirect (status 302) for the entire request to a public server that has that replica. Note this implementation assumes that free/busy for all other users provided in the request can also be found in the same server. The implication is that free/busy folders for different administrative groups must have replicas in all public folder databases. In our case, some or all free/busy folders will only have replicas on Exchange 2010, however Exchange 2010 does not support the DAV protocol, so OWA redirects to 2010 will simply fail.

With Option A, this will cause ALL OWA Free/Busy requests (both internal and external) to fail, as the Exchange 2003 server will not have replicas of any Free/Busy public folders.

With Option B, if the free/busy request is for a local mailbox user, the request will succeed. If the request is for a user from the remote org, the request will fail.

Issue #2 - Internal Free/Busy for Exchange 2003

Option A for Exchange 2003 requires that the only replicas for all free/busy folders must reside on Exchange 2010 SP1 servers. In environments where Exchange 2003 Public Folder databases are located in multiple physical sites, if Exchange 2010 Sp1 Public Folder databases are not located in the same physical sites, this may lead to issues with excessive latency and possible performance issues as internal free/busy queries may have to traverse WAN links.

Issue #3 - Queries for Exchange 2007 users cross-org fail

By default, Exchange 2007 allows availability queries for 42 days of information. Exchange 2010 bumped up that limit to 62 days. When Exchange 2010 performs the request for a user on Exchange 2007 in the remote organization, the request may fail because Exchange 2010 is requesting 62 days of information, which exceeds the default limit of 42 imposed by Exchange 2007.

To address this issue, you can adjust the maximumQueryIntervalDays value in the EWS web.config (located in the \Program Files\Microsoft\Exchange Server\ClientAccess\ExchWeb\ews\ folder) on the Exchange 2007 servers. Add the value under the AppSettings section.

This example configures the availability service on Exchange 2007 server to provide availability information for 62 days.

<appSettings>
    <add key="maximumQueryIntervalDays" value="62" />
</appSettings>

Note: The maximumQueryIntervalDays value is not present by default. If this value is not present, Exchange uses the default interval of 42 days.

After you do this, you will want to do an IISReset on the Exchange 2007 CAS servers to make sure the new setting takes effect, as this value is only read on startup.

Issue #4 - Queries for Exchange 2003 users cross-org fail

By default, an Exchange 2010 CAS performing a cross-org free/busy lookup will query the autodiscover service for the user you're attempting to view Free/Busy for. If the target user is an Exchange 2003 user, autodiscover will fail because Exchange 2003 users are not autodiscover-enabled. This issue is scheduled to be fixed in Exchange 2010 SP1 Update Rollup 4. To work around this issue, manually set the targetSharingEPR on the Organization Relationship for the remote organization with Exchange 2003.

Example:

Set-OrganizationRelationship –identity -targetSharingEPR https://mail.contoso.com/ews/exchange.asmx/WSSecurity

Update: The issue has been fixed in Exchange 2010 SP1 Update Rollup 4. See KB 2506820. The free/busy information does not display of a user whose mailbox is located on an Exchange Server 2003 server.

An additional issue with queries for remote Exchange 2003 users is that the remote organization will return the Free/Busy response in the format of a MergedOnly string. Exchange 2010 cannot convert this string to store the result in public folders, so no information is returned to the Outlook client.  A fix is available for this issue. See KB 2567863 Free/Busy information may not be returned when a Cross-Org query is performed from a legacy Exchange user.

Issue #5 - Federating with another Organization that has both on-premises and cloud users

If you federate with another organization that subscribes to a cloud service such as Office 365 or BPOS, availability lookups for remote users that have been moved to the cloud will fail. The reason is that your organization relationship is with the on-premises Organization. That on-premises org has a completely separate Organization Relationship with O365/BPOS. When an availability call is made from a separate org via an Organization Relationship, it'll be made to the on-premises org, where a mail-enabled user or contact will be found. There's no functionality to proxy the availability call through the Organization Relationship from the on-premises Org to the cloud, so this call will fail.

Ben Winzenz

You may have noticed a change in the behavior of the Safe Senders list within Outlook starting in Exchange 2010. Users can no longer add accepted domains to Outlook’s Safe Senders list.

This was done as an anti-spam deterrent as we have all seen cases where Joe The Spammer spoofs the mail from your own domain. Adding your own domain to the Safe Senders list would bypass all Outlook client-side anti-spam checks, dumping that message from the Nigerian prince (spoofed using your own domain) into your users’ Inboxes. Not so good unless you were really waiting for that business opportunity.

A valid SPF record and our anti-spam agents (specifically the SenderID agent) would go a long way to block these types of spam. However, many customers out there have not exactly jumped on the SPF bandwagon.

You can learn more about SenderID filtering in Sender ID and Understanding Sender ID. Use the Sender ID Framework SPF Record Wizard to create an SPF record for your domain.

With Exchange 2010, you CAN still add individual email addresses from your own accepted domains to the Safe Senders list - you just can’t add the entire domain, as shown in the screenshot above.

What happens if you DO decide to add the whole domain?

If you try to do this for a user via the Shell, you will get the very helpful error below:

We tell you exactly why we are throwing an error.

How about when a user does this via Outlook? First, Outlook lets the user add a domain.

However after a few minutes the entry will magically disappear.

Allowing app servers to send as your own domain

Many customers have various applications that submit mail anonymously to Exchange where the messages come from email addresses from your accepted domains.

Some of you have apps submitting from so many accepted domain addresses that it wouldn’t be feasible (let alone fun) attempting to add all of these addresses individually to the safe senders list in Outlook to ensure these messages do not end up in junk mail.

Now that we can’t add the whole domain, what are our options?

• We know that adding all the addresses manually is an available albeit painful option
• A second option is to disable Outlook’s client side filtering (yeah... not a good idea, so do not seriously consider it. Spam checks out the window!)
• A third and best option is to install the anti-spam agents on your relay hub(s) and add the IPs of your app servers to the IP Allow list of the connection filtering agent as documented here.

When the sending SMTP host’s IP address is on the IP Allow List in Exchange, it bypasses all anti-spam checks (except sender/recipient filtering) and the Content Filter agent stamps an SCL of -1 on the message which Outlook will honor.

X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-Antispam-Report: IPOnAllowList
X-MS-Exchange-Organization-SCL: -1

So, go ahead and run the Install-AntispamAgents.ps1 from the Scripts folder on your Hub Transport server, and then add IP addresses or subnets of our application servers to the IP Allow List.

If using the Shell, use this command to add an IP address to the IP Allow List:

Add-IPAllowListEntry –IPAddress 192.168.10.120

What Not To Do: Using Externally Secured Authentication

Now I know what you’re thinking: Why don’t we just add Externally Secured Authentication as an authentication type on a Receive Connector, scope the connector’s remote IP range to the sending application servers and call it a day?

Well, not so fast... you see, while Externally Secured gives the sending IP the ms-Exch-Bypass-Anti-Spam extended right, this only circumvents the Exchange Anti-Spam checks, not Outlook’s. And it is Outlook that’s moving the message into junk mail in this case.

Also note that Externally Secured does not stamp any SCL X-headers on the message as an SCL of -1 would’ve bypassed Outlook’s checks. The only header this authentication type creates is the one below:

X-MS-Exchange-Organization-AuthAs: Internal

If you're still confused about Exchange and Outlook anti-spam checks, take a look at Exchange anti-spam myths revealed.

Big thanks to Tak Chow for tech reviewing this post.

Tom Kern

Last year when we released Exchange 2010 SP1, we posted about the change expired password feature in Outlook Web App and how you can enable it by creating the ChangeExpiredPasswordEnabled registry entry. See So you want to change your expired passwords in OWA... for details.

Since then you've sent us many requests for supporting the use of User Principal Name (UPN) format in the same feature. Previously only domain\username format was supported when entering domain credentials.

We passed on that feedback to Exchange PMs and we're glad to let you know that the support for UPN credentials is now available in Exchange 2010 SP1 RU3-V3, which was released recently.

Note: At the time of this writing, Update Rollup 4 is the latest rollup available for Exchange 2010 SP1.

References:

• Configuring the Change Password Feature in Outlook Web App
• 2464564 - You cannot change the password of a UPN formatted user name in OWA when you enable Exchange Server 2010 SP1 Password Reset Tool

M. Amir Haque

A user is out of office for some reason – on vacation, sick, on a sabbatical or extended leave of absence, or traveling to a remote location on business, and forgets to set an automatic reply, also known as an Out Of Office message or OOF in Exchange/Outlook lingo. As an Exchange administrator, you get an email from the user’s manager asking you to configure an OOF for the user.

In previous versions of Exchange, you would need to access the user’s mailbox to be able to do this. Out of Office messages are stored in the Non-IPM tree of a user’s mailbox along with other metadata. Without access to the mailbox, you can’t modify data in it. Two ways for an admin to access a mailbox:

1. Grant yourself Full Access mailbox permission to the user’s mailbox.
2. Change the user’s password and log in as user.

It is safe to say that either of these options is potentially dangerous. The first option grants the administrator access to all of the data in the user’s mailbox. The second option grants the administrator access to all of the data that the user account can access within your company and locks the user out of his own user account (as the user in question no longer knows the account password).

In Exchange 2010, you can configure auto-reply options for your users without using either of the above options. You must be a member of a role group that has either the Mail Recipients or User Options management roles.

Configure auto-reply options using the Exchange Control Panel

To configure an auto-reply using the ECP:

1. From Mail>Options, select Another User (default My Organization).
   
   Figure 1: Select Another User

2. Select the user you want to configure the auto-reply for

3. In the new window, ensure the user's name is displayed in the alert message, and then click Tell people you’re on vacation
   
   Figure 2: When managing another user in the ECP, an alert near the top of the page displays the name of the user you're managing

4. From the Automatic Replies tab, configure the auto-reply options for the user (see screenshot).

In Exchange 2007, we introduced the ability to create different Out of Office messages for external and internal recipients. You can also disable or enable Out of Office messages on a per-user basis and on a per-remote domain basis in Remote Domain settings. For details, see previous post Exchange Server 2007 Out of Office (OOF).

Configure auto-reply options using the Shell

This command schedules internal and external auto-replies from 9/8/2011 to 9/15/2011:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Scheduled –StartTime “9/8/2011” –EndTime “9/15/2011” –ExternalMessage “External OOF message here” –InternalMessage “Internal OOF message here”

To configure auto-replies to be sent until they're disabled (i.e. without a schedule), set the AutoReplyState parameter to Enabled and do not specify the StarTime and EndTime parameters. For detailed syntax and parameter descriptions, see Set-MailboxAutoReplyConfiguration.

This command retrieves auto-reply settings for a mailbox.

Get-MailboxAutoReplyConfiguration bsuneja@e14labs.com

This command disables auto-reply configured for a mailbox:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null

Bharat Suneja

Update 10/21/11: There is now a fix for this issue. Please go here to learn how to get it.

We wanted to write a blog post about an issue that some of you have reported to us, and has been discussed at some length in Exchange Forums also.

After you install Internet Explorer 9 on a computer that has Exchange 2010 or Exchange 2007 management tools installed, you might run into a situation where closing the Exchange Management Console (EMC) results in the following error:

You must close all dialog boxes before you can close Exchange Management Console

This might happen even if there are no property pages left opened that you can see. Please note here that not all of our customers who installed IE9 on a computer with Exchange management tools (server or workstation) have run into this problem.

Are there any workarounds?

As it stands right now, we are not aware of a reliable workaround for this problem. Terminating the EMC using the Task Manager (or possibly a command or script) does not have adverse effects on management tools functionality, but is clearly a non-optimal solution.

What are we doing to address this?

The EMC is implemented as a Microsoft Management Console snap-in. We are working closely with both MMC and Internet Explorer teams to find a solution to this problem. Due to the complex nature of several products involved and the interoperability between them, identifying the root cause was not simple; things are still in process and we do not have a firm solution or a date to share with you yet. We do, however, want to say that we are very aware of this issue and several teams are collaborating and working to get this addressed. Once more details are available, we will be sure to share them here.

Nino Bilic

Update 12/13/2011: Please note that starting with today, you do not need to call Microsoft Support to get the fix to resolve this issue. All that is required now is installation of December 13, 2011 IE security update, KB 2618444. The below blog post has been updated accordingly.

We are happy to report that a fix for the Exchange Management Console (EMC) issues when Internet Explorer 9 is installed is now available. To be specific, we have talked about this in a previous blog post:

Exchange 2007 or 2010 EMC might fail to close with "You must close all dialog boxes before you can close Exchange Management Console"

How does this fix need to be applied?

In order to install the fix, a released version of IE9 needs to be installed on the machine first. Then:

• MS11-099: Cumulative Security Update for Internet Explorer: December 13, 2011 needs to be installed. This fix is available publicly for everyone to download. The fix that resolves the incompatibility has been rolled into this security update.

The KB article talking about all this has also been updated: KB 2624899 FIX: You cannot close the EMC window on a computer that has Internet Explorer 9 installed

Finally, I would like to thank the Internet Explorer team for working with us on this interoperability issue and producing this hotfix.

Nino Bilic

Since its release in 2009, the interest in Exchange 2010 has been fantastic. While working with customers to educate them and prep them for moving to Exchange 2010, we've uncovered some common misconceptions. One trend has to do with misconceptions around the Client Access Server array object, or CAS array object for short. Technical Writer and frequent blogger Scott Schnoll suggested I put pen to paper… err… keys to keyboard (?) when I was commenting on this trend on an internal Microsoft distribution group, so here we are with this post.

I’m not going to go into all of the technical aspects of a CAS array object in this post. That's already been covered wonderfully by Nagesh Magadev in a prior post: Exploring Exchange 2010 RPC Client Access service.

The following list is a collection of truths many customers are not aware of when it comes to the CAS array object which I'll try to demystify. Part 1 will discuss the first three items and l'll cover the last three items in part 2.

1. A CAS array object does not load balance your traffic
2. A CAS array object does not service Autodiscover, OWA, ECP, EWS, IMAP, POP, or SMTP
3. A CAS array object's fqdndoes not need to be part of your SSL certificate
4. A CAS array object should not be resolvable via DNS by external clients
5. A CAS array object should not be configured or changed after creating Exchange 2010 mailbox databases and moving mailboxes into the databases
6. A CAS array object should be configured even if you only have one CAS or a single multi-role server.

Everyone confused? Nice. Let’s try to fix that as best we can by going through each of these one at a time. You'll see some server names throughout this article so why don’t I show you what I’m working with in my lab first?

OK, let's dig in!

1. A CAS array object does not load balance your traffic

A CAS array object performs no load balancing. It's an Active Directory object used to automate some functions within Exchange and that's all. Exchange 2010 documentation says all over the place that it's recommended to use load balancers (LB) to load balance CAS traffic. So what do I mean by saying the CAS array object performs no load balancing?

What you're actually doing with a load balancer is balancing traffic across a pool of CAS or perhaps you could call it an array of CAS - but not the CAS array object itself. The difference is subtle yet distinct; perhaps we didn’t make the names distinct enough to help prevent the confusion in the first place.

The primary reason, and perhaps the only reason, a CAS array object exists is to automatically populate the RpcClientAccessServer attribute of any new Exchange 2010 mailbox database created in the same Active Directory site (as the CAS array object).

The RpcClientAccessServer attribute is used to tell Outlook clients during the profile creation process what server name should be in the profile. That’s pretty much it folks, there's no more magic going on here and once you've created your CAS array object it's simply an object in Active Directory and there's zero load balancing going on at this point in time.

The rest is up to you at this point. It's up to you to:

• Create an ‘A’ record in DNS that'll allow the client machine to resolve the hostname to an IP address. This IP address will most likely be the virtual IP (VIP) of the LB reachable only by internal clients. This VIP is where Outlook or any other MAPI/RPC capable application will then connect to gain access to Exchange 2010 mailbox resources.
• Configure your load balancing solution to pass traffic to the pool of CAS servers by way of the VIP.

The CAS themselves have no idea there is any load balancing happening.

You may also be confused by what can be seen after creating a CAS array object using the New-ClientAccessArray cmdlet or viewing a pre-existing CAS array object using the Get-ClientAccessArray cmdlet.

Here I'm creating a new CAS array object in my lab with the Name CASArray-A, the FQDN of outlook.lab.local, and in the Active Directory site very aptly named Site-A.

Figure 1: Creating a Client Access array

First of all my FQDN and Name fields don’t match because the Name is a display name - it's purely cosmetic. It's whatever you want to name it so you know what that CAS array object is being used for. The FQDN is the record you must then create in DNS or else clients will never be able to resolve it to an IP address to connect to. At this point, I’ll remind you that there can be only one CAS array object per Active Directory site.

So why is the Members property populated with two CAS immediately after creation? Didn’t I tell you there's no load balancing going on at this point? It looks kind of like I lied to you doesn’t it?

To be honest, the Members property is a touch misleading. If you didn’t read up on the steps to create a CAS array object you may think you’re done at this stage. You created your CAS array object and you can see two CAS have automatically joined the array. By this time you may be off for a celebratory drink or going down cube-town hallway to steal some cookies from this guy. Not quite yet my friend!

Due to the fact that we associated the CAS array object to Active Directory site Site-A, the cmdlet simply goes and finds all Client Access servers registered as residing in Site-A and then lists them in the Members column. I like to tell customers to think of this column as the Potential Members column or as my colleague Kamal Abburi, another PFE here at Microsoft, suggests it's the Site CAS Members column. You can add these Client Access servers as nodes in your load balancing solution because they all reside in the same Active Directory site. But until the load balancer is configured we have no load balancing.

How did the cmdlets know what site the CAS are in? Well, I’m glad you asked because we get to break out everybody’s best friend AdsiEdit.msc and dig down into the Configuration partition of Active Directory to find the magic beans.

Figure 2: The msExchServerSite attribute of an Exchange 2010 server contains the Active Directory site the server resides in

Each Exchange server has an msExchServerSite attribute that contains the Active Directory site they currently reside in. In case you're wondering, yes it's dynamically updated if you move an Exchange server to a new site and the Microsoft Exchange Active Directory Topology service has a chance to run and update a few things. But the AutoDiscoverSiteScope attribute (Part of Get/Set-ClientAccessServer) will not be dynamically updated and you may have funky Autodiscover results until this is fixed – depending on your site, server, and client layout.

2. A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP, SMTP, or POP

Let’s go back for a moment to what a CAS array object actually does. It populates the RpcClientAccessServer attribute of an Exchange 2010 mailbox database, which is then used to tell Outlook where it needs to connect when using RPC (over TCP). For Outlook Anywhere (HTTPS) clients, it indicates where the traffic that leaves the RPC-over-HTTP proxy needs to connect on the client’s behalf in order to reach their mailbox.

So what services does the Outlook client attempt to connect to when using RPC (over TCP)?

First Outlook connects to the CAS array object on TCP/135 to communicate with the RPC Endpoint Mapper in order to discover the TCP ports the following two services are listening on.

1. Microsoft Exchange RPC Client Access (aka MSExchangeRPC)
2. Microsoft Exchange Address Book (aka MSExchangeAB)

That’s it for RPC (over TCP) mode!

Outlook Anywhere (aka RPC over HTTP) clients connect to the RPC-over-HTTP proxy component on TCP/443 on a CAS by resolving the Outlook Anywhere external hostname, or what the Outlook profile calls the proxy server.

Interesting geeky side note for anyone interested, Outlook automagically and quietly adds /rpc/rpcproxy.dll to the server name specified, as that’s really what it needs to connect to, but if we asked people to type these names in, like we used to back in Outlook 2003 days, can you imagine how many would have missed it, or got it wrong?)

Figure 3: Specifying the RPC Proxy URL in Outlook 2003

Traffic is routed out of the RPC-over-HTTP proxy to the appropriate MAPI/RPC endpoint using a list of hard-coded, rather than dynamically assigned TCP ports, those being TCP 6001, TCP 6002, and TCP 6004. The Outlook Anywhere external hostname is purposefully not the same FQDN as the CAS array object and I’ll explain why later on.

A client may also make HTTPS connections to services such as Autodiscover, OAB downloads, EWS, POP, or IMAP, but these services are defined by entirely different methods such as virtual directory URLs or the AutoDiscoverServiceInternalUri value. None of these additional services are serviced by the CAS array object as none of them are using RPC, although it’s likely to be the same server they are connecting to. The CAS array object’s FQDN may share the same VIP as the other service’s URLs, but we strongly recommend the CAS array object FQDN not be the same as the other services’ URLs if split DNS is in use. More on that last recommendation later.

3. A CAS array object's FQDN does not need to be part of your SSL certificate name list

This is a very common misconception usually spawned due to the item directly above. SSL certificates in the realm of this article are only utilized when we want to do something like establish an SSL-protected HTTP session. Because RPC (over TCP) is not an HTTP session, it's not going to be protected with SSL and therefore, we don't need the CAS array object's FQDN to be included on the subject name list of the SSL certificate. Let's take a look at it.

Below is Outlook 2010 in MAPI/RPC mode connected to an Exchange 2010 CAS array object.

Figure 4: Outlook 2010 RPC (over TCP) connections to Exchange 2010 CAS

We can see it has made one directory and two mail connections. In the netstat output (overlayed above the screenshot) we see the machine has made one endpoint mapper connection (TCP 135) to the CAS array object as well as connections to TCP 59531 and TCP 59532 which represent the statically assigned TCP ports for the MSExchangRPC and MSExchangeAB services respectively in this lab.

From the server side we can see the services listening using the command netstat –n –b.

Figure 5: Services Outlook needs to connect to when using RPC (over TCP)

As expected, it shows that none of the services are being contacted over HTTP (to TCP 443). This is why you don't need the CAS array object FQDN on the SSL certificate.

Thinking you need the CAS array FQDN on the SSL certificate can sometimes be confused by the way Outlook displays connections while in HTTPS mode as seen below.

Figure 6:Outlook Anywhere connections

This time we see Outlook 2010 has made two mail connections and a Public Folder connection when the screen shot was taken and we can also see we are using HTTPS. From within Outlook it looks as if we are connected to outlook.lab.local and E2K10-MLT-01.lab.local, which we are sort of, but utilizing netstat once again we see we are actually connected to the RPC-over-HTTP proxy located at webmail.lab.local on TCP/443 (HTTPS). Outlook will always display what server is eventually connected to for data by itself or via RPC-over-HTTP proxy. If you're wondering why we see 6 connections via netstat instead of three, it's because HTTP is a half-duplex protocol and we therefore establish an RPC_DATA_IN and an RPC_DATA_OUT channel for each connection seen inside Outlook.

You may also be thinking, “Wait! Outlook 2007 and 2010 encrypt RPC sessions by default! We have to have the name on the cert!” Wrong-O my friends because the encryption setting you see below utilizes RPC encryption and has nothing to do with SSL. The communication is still happening over RPC and not over HTTPS.

Figure 7: When connecting using RPC (over TCP), Outlook uses RPC encryption

Simple isn’t it! If a CAS array object met a Certification Authority and the CA said: “Hey man you really need me! C’mon I’ll sell you a swanky wildcard cert on the cheap!” the CAS array object would simply reply “Honey badger don’t care!” and probably use the CA to crack open a pistachio. Now that's of course if you followed our recommendation to use a different FQDN for the CAS array object than you’re using for the other service FQDN(s). Yes, I’m getting to why…

I hope Part 1 of this article has been helpful to you so far in making sense of some common misunderstood issues with CAS array objects, and hope that you’ll tune in for Part 2 at a later time where we'll cover the remaining three common misconceptions about CAS array objects.

Brian Day
Premier Field Engineer, Messaging

Continue to Demystifying the CAS Array Object - Part 2.