Today, we have released an updated version of the Exchange 2013 Server Role Requirements Calculator that addresses several issues found since its initial release.  You can view what changes have been made, or download the update directly.

In addition, we are releasing an updated version of the Exchange 2010 Server Role Requirements Calculator as well. You can view what changes have been made, or download the update directly.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

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

Today the Exchange CXP team released Update Rollup 1 for Exchange Server 2010 SP3 to the Download Center.

Note: Some of the following KB articles may not be available at the time of publishing this post.

This update contains fixes for a number of customer-reported and internally found issues. For more details, including a list of fixes included in this update, see KB 2803727. We would like to specifically call out the following fixes which are included in this release:

• 2561346 Mailbox storage limit error when a delegate uses the manager's mailbox to send an email message in an Exchange Server 2010 environment
• 2756460 You cannot open a mailbox that is located in a different site by using Outlook Anywhere in an Exchange Server 2010 environment
• 2802569 Mailbox synchronization fails on an Exchange ActiveSync device in an Exchange Server 2010 environment
• 2814847 Rapid growth in transaction logs, CPU use, and memory consumption in Exchange Server 2010 when a user syncs a mailbox by using an iOS 6.1 or 6.1.1-based device
• 2822208 Unable to soft delete some messages after installing Exchange 2010 SP2 RU6 or SP3

For DST changes, see Daylight Saving Time Help and Support Center (microsoft.com/time).

Exchange Team

Since the initial release of Log Parser Studio (LPS) there have been over 30,000 downloads and thousands of customers use the tool on a daily basis. In Exchange support many of our engineers use the tool to solve real world issues every day and in turn share with our customers, empowering them to solve the same issues themselves moving forward. LPS is still an active work in progress; based on both engineer and customer feedback many improvements have been made with multiple features added during the last year. Below is a short list of new features:

Improved import/export functionality

For those who create their own queries this is a real time-saver. We can now import from multiple XML files simultaneously only choosing the queries we wish to import from multiple query libraries or XML files.

Search Query Results

The existing feature allowing searching of queries in the library is now context aware meaning if you have a completed query in the query window, the search option searches that query. If you are in the library it searches the library and so on. This allows drilling down into existing query results without having to run a new query if all you want to do is narrow down existing result sets.

Input/Output Format Support

All LP 2.2 Input and Output formats contain preliminary support in LPS. Each format has its own property window containing all known LP 2.2 settings which can be modified to your liking.

Exchange Extensible Logging Support

Custom parser support was added for most all Exchange logs. These are covered by the EEL and EELX log formats included in LPS which cover Exchange logs from Exchange 2003 through Exchange 2013.

Query Logging

I can't tell you how many times myself or another engineer spent lots of time creating the perfect query for a particular issue we were troubleshooting, forgetting to save the query in the heat of the moment and losing all that work. No longer! We now have the capability to log every query that is executed to a text file (Query.log). What makes this so valuable is if you ran it, you can retrieve it.

Queries

There are now over 170 queries in the library including new sample queries for Exchange 2013.

PowerShell Export

You can now export any query as a standalone PowerShell script. The only requirement of course is that Log Parser 2.2 is installed on the machine you run it on but LPS is not required. There are some limitations but you can essentially use LPS as a query editor/test bed for PowerShell scripts that run Log Parser queries for you!

Query Cancellation

The ability to submit a request to cancel a running query has been added which will allow you to cancel a running query in many cases.

Keyboard Shortcuts

There are now 23 Keyboard shortcuts. Be sure to check these out as they will save you lots of time. To display the short cuts use CTRL+K or Help > Keyboard Shortcuts.

There are literally hundreds of improvements and features; far too many to list here so be sure and check out our blog series with existing and upcoming tutorials, deep dives and more. If you are installing LPS for the first time you'll surely want to review the getting started series:

• Getting started with Log Parser Studio
• Getting started with Log Parser Studio, part 2
• Getting started with Log Parser Studio, part 3

If you are already familiar with LPS and are installing this latest version, you'll want to check out the upgrade blog post here:

• Log Parser Studio: upgrading from v1 to v2

Additional LPS articles can be found here:

http://blogs.technet.com/b/karywa/

LPS doesn't require an install so just extract to the folder of your choice and run LPS.EXE. If you have the previous version of LPS and you have added your own custom queries to the library, be sure to export those queries as a backup before running the newest version. See the "Upgrading to LPS V2" blog post above when upgrading.

Kary Wall

Exchange 2010 includes a feature called Datacenter Activation Coordination (DAC) mode that is designed to prevent split brain at the database level during switchback procedures that are being performed after a datacenter switchover has occurred. One of the side benefits of enabling DAC mode is that it enables you to use the built-in recovery cmdlets to perform the datacenter switchover and switchback.

In the real world, there are several different factors that determine what commands to run and when to run them. For example:

• Are Exchange Servers available in the primary datacenter?
• Is network connectivity available between the primary and remote datacenter?
• Is Exchange deployed in a topology with a single Active Directory site or multiple sites?

The answers to these questions determine not only the specific commands to run but also where the commands should be run.

In addition, administrators need to understand what the desired outcomes of those commands are. For example:

• How do I verify that stop-databaseavailability group was successful?
• How do I verify that restore-databaseavailabilitygroup performed the correct steps?
• When is it appropriate to run start-databaseavailailitygroup?

Each of these requires a different set of verification steps before proceeding.

And of course as with any process there are those occasional expected errors.

With this in mind, I want to introduce the Datacenter Switchover Tool, a kiosk-based PowerPoint application that allows administrators to work through the flow of questions to determine:

• What commands to run and where to run them
• How to verify the commands completed successfully.
• How to walk through a Datacenter Switchover from the Mailbox server / database availability group perspective.

To use the tool, simply download it and open it in PowerPoint. Make sure use only the buttons that are available on the screen. The tool will walk you through the correct questions, in the correct order, and provide feedback on the commands to execute and their verification.

The location of the tool is here: http://gallery.technet.microsoft.com/Exchange-2010-Datacenter-09a81fc6

Note: We have now also published the Exchange Server 2010 DAG Switchover GWT (Guided Walkthrough). You can use that as an additional resource to help you get through the switchover process.

Enjoy!

Tim McMichael

One of the great benefits to running one of the world’s largest Exchange deployments is that we at Microsoft get to see all the things that our customers face on a daily basis. With the recent release of iOS6, we have noticed a marked increase in support calls due to meetings having the owner of the meeting changed (sometimes called “meeting hijacking”). Most instances reported to us to date involve users with delegates who first open a meeting request in Outlook and then act on that same meeting in iOS.

Meeting issues are a large part of the challenges that we know some organizations see with 3^rd party devices (here is our list). Unfortunately the recent iOS update has exacerbated one of these issues. We wanted to let you know about this issue as well as let you know that we have discussed this issue with Apple. We are also looking at ways that we can continue to harden the Exchange infrastructure to protect our servers and service from poorly performing clients.

In the meantime we wanted to offer a few mitigation options:

• Tell users not to take action on calendars on iOS We're not seeing this particular issue if users don't take action on their calendar items (for example, accept, delete or change meetings).

• Switch iOS users to POP3/IMAP4 Another option is to switch users over to POP/IMAP connections. This will remove calendar and contacts functionality while allowing users to still use email (though the email may shift to pull from push while using these protocols).

• 3^rd party clients/OWA Moving impacted users over to another email client that is not causing these issue for your organization may help alleviate the pain here. There are a number of other client options (OWA being one of them of course). Numerous clients are available in mobile application stores. We don’t recommend any particular client.

• Block delegates Many of the issues we are seeing involve delegates. An admin can take the less drastic step of using the Allow/Block/Quarantine list to block only users who are delegates, or have a delegate, to minimize the impact here.

• Block iOS 6 devices Exchange server comes with the Allow/Block/Quarantine functionality that enables admins to block any device or user.

• Tell users not to upgrade to iOS 6 or to downgrade their devices – This solution may work as a temporary fix until Apple provides a fix but many users may have already made the decision to update.

• Wait We do not have any information on the timeline of a fix from Apple but if this timeline is short, this may be the easiest course of action. Please contact Apple about any potential fix or timeline for its delivery.

• Our support team has also published a KB article on this issue that you can read here. And we will update this post when a fix is available or we have additional information.

Adam Glick
Sr. Technical Product Manager

In previous posts, we have discussed certificate based authentication (CBA) for Outlook Web App, and Greg Taylor has covered publishing Outlook Web App and Exchange ActiveSync (EAS) with certificate based authentication using ForeFront TMG in this whitepaper. Certificate based authentication for OWA only can also be accomplished using ForeFront Unified Access Gateway.

In this post, we will discuss how to configure CBA for EAS for Exchange 2010 in deployments without TMG or UAG.

To recap some of the common questions administrators and IT decision-makers have regarding CBA:

What is certificate based authentication?
CBA uses a user certificate to authenticate the user/client (in this case, to access EAS). The certificate is used in place of the user entering credentials into their device.

What certificate based authentication is not:
By itself, CBA is not two-factor authentication. Two-factor authentication is authentication based on something you have plus something you know. CBA is only based on something you have.

However, when combined with an Exchange ActiveSync policy that requires a device PIN, it could be considered two-factor authentication.

Why would I want certificate based authentication?
By deploying certificate based authentication, administrators gain more control over who can use EAS. If users are required to obtain a certificate for EAS access, and the administrator controls certificate issuance, access control is assured.

Another advantage: Because we're not using the password for authentication, password changes don't impact device access. There will be no interruption in service for EAS users when the they change their password.

Things to remember:
There will be added administration overhead. You will either need to stand up your own internal Public Key Infrastructure (PKI) using Active Directory Certificate Services (AD CS, formerly Windows Server Certificate Services) or a 3rd-party PKI solution, or you will have to purchase certificates for your EAS users from a public certification authority (CA). This will not be a one-time added overhead. Certificates expire, and when a user’s certificate expires, they will need a new one, requiring either time invested in getting the user a new certificate, or budget invested in purchasing one.

Prerequisites:

You need access to a CA for client certificates. This can be a public CA solution, individual certificates from a vendor, or an Active Directory Certificate Services solution. Regardless, the following requirements must be met:

• The user certificate must be issued for client authentication. The default User template from an AD CS server will work in this scenario.
• The User Principal Name (UPN) for each user account must match the Subject Name field in the user's certificate.
• All servers must trust the entire CAtrust chain. This chain includes the root CA certificate and any intermediate CA certificates. These certificates should be installed on all servers that may require them, to include (but not limited to) ISA/TMG/UAG server(s) and the Client Access Server (CAS).
• The root CA certificate must be in the Trusted Root Certification Authorities store, and any intermediate CA certificates in the intermediate store on all of these systems. The root CA certificate, and intermediate CA certificates must also be installed on the EAS device.
• The user’s certificate must be associated with the user’s account in Active Directory

Client Access Server Configuration

To configure the Client Access server to enforce CBA:

1. Verify if Certificate Mapping Authentication is installed on the server.

1. Right click on Computer in the start menu and choose Manage.
2. Expand Roles and click on Web Server (IIS)
3. Scroll down to the Role Services section. Under the Security section you should see Client Certificate Mapping Authentication installed.

• If you don't see Client Certificate Mapping Authentication installed, click add Role Services> (scroll) Security and select Client Certificate Mapping Authentication and then click Install.

• Reboot your server.

  2. Enable Active Directory Client Certificate Authentication for the server root in IIS.

  1. Start IIS Manager
  2. Click on the Server Name.
  3. Double click Authenticationin the middle pane.

  4. Right click on Active Directory Client Certificate Authentication and select Enable
     

  5. When this is complete, restart the IIS Admin service from the Services console (or use Restart-Service IISAdmin"from the Shell).

     Important: IISreset does not pick up the changes properly. You must restart this service.

  3. Require Client Certificates in Exchange management console.

  1. In the Exchange Management Console, expand Server Configuration and then select the Client Access server you want to configure
  2. On the Exchange ActiveSync tab, right click on the Microsoft-Server-ActiveSync directory and choose Properties.
  3. On the Authenticationtab:
     1. Clear the Basic authentication (password is sent in clear text) checkbox
     2. Select Require client certificates

  4. Modify the ActiveSync XML configuration file to allow Client Certificate Mapping Authentication.

  1. In IIS manager open the configuration editor under the Microsoft-Server-ActiveSync directory.
     

  2. Browse the option for clientCertificateMappingAuth and set the value to True

  Once this is configured, all that's left to do is client configuration.

  Client Configuration

  You'll need to get the user’s certificate to the device. This will be accomplished in different ways for different devices. Some possibilities include:

  • Make the Trusted Root Certification Authority (Root CA) certificate available on a web site or other means of distribution.
  • Make the user’s certificate, including the private key, available on a website or other means of distribution.

    Caution: Use appropriate security measures to ensure that only the user who owns the certificate is able to access it from the device.

  • If the device supports external storage, you can place the certificate on a memory card or other external storage device and install it from the card.
  • Some devices have a certificate manager available for a host operating system. You can plug the device into your computer, run the certificate manager and install the certificate.

  Once the certificate is on the device, the user can configure the Exchange ActiveSync client (usually a mail app) on the device. When configuring EAS for the first time, users will be required to enter their credentials. When the device communicates with the Client Access Server for the first time, users will be prompted to select their certificate. After this is configured, if users check the account properties, they'll see a message similar to the following:

  Microsoft Exchange uses certificates to authenticate users when they log on. (A user name and password is not required.)

  Exchange Server 2003 Mailbox Coexistence

  This is an added step that requires some simple changes, and must be performed whether TMG is used to access Exchange 2010 or not. Use the following steps to enable this for access to Exchange 2003 mailboxes.

  1. Apply the hotfix from the following article (or one that has a later version of EXADMIN.DLL) to the Exchange 2003 servers where the mailboxes are homed.

     937031 Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server

  2. The article instructs you to run a command to configure IIS to support both Kerberos and NTLM. You must run the command the command prompt using CSCRIPT, as shown below:

     1. Click Start> Run> type cmd and press Enter.
     2. Type cd \Windows\System32\AdminScripts and press Enter.
     3. Type the following command and press enter:

        cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "Negotiate,NTLM"

  3. On the Exchange 2003 mailbox server, launch Exchange System Manager and follow these steps:

     1. Expand the Administrative Group that contains the Exchange 2003 server.
     2. Expand Servers> expand <server name>> Protocols > HTTPExchange Virtual Server
     3. Right click the Microsoft-Server-ActiveSync virtual directory and select Properties
     4. On the Access tab, click Authentication and ensure that only Integrated Windows Authentication checkbox is checked.

  4. Use the following steps to configure the Exchange 2010 to Exchange 2003 communication for Kerberos Constrained Delegation (KCD).

     1. Open Active Directory Users and Computers on the CAS
     2. Right click the CAS computer account > Properties
     3. In the Delegation tab, select Trust this computer for delegation to specified services only
     4. Select Use any authentication protocol option and then click Add
     5. In the Add Services window, click Users or Computers and enter the name of the Exchange 2003 server that the CAS is delegating to
     6. Click OK
     7. A list of Service Principal Names (SPN) will be displayed for your server.
     8. Select the appropriate HTTP SPN for the Exchange 2003 server. You'll need to add the correct SPN, HTTP/serverFQDN

        Note: You may need to add the SPN as per Setspn Overview

  5. Thanks to:
     DJ Ball for his previous work in documenting certificate based authentication for Outlook Web App (see How to Configure Certificate Based Authentication for OWA - Part I and How to Configure Certificate Based Authentication for OWA - Part II
     Mattias Lundgren, for starting the documentation process on certificate based authentication for EAS.
     DJ Ball and Will Duff for reviewing this document.
     Henning Peterson and Craig Robicheaux for reviewing this document.
     Greg Taylor for technical review.

     Jeff Miller

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

Today the Exchange CXP team released the following update rollups to the Download Center. All three releases cover Security Bulletin MS12-080. Because this is a security release, the updates will also be available on Microsoft Update.

• Update Rollup 5-v2 for Exchange Server 2010 Service Pack 2
• Update Rollup 8 for Exchange Server 2010 Service Pack 1
• Update Rollup 9 for Exchange Server 2007 Service Pack 3

Update Rollup 5-v2 for Exchange Server 2010 SP2

This update contains a number of customer reported and internally found issues. For a list of updates included in this rollup, see KB 2785908 Description of Update Rollup 5 version 2 for Exchange Server 2010 Service Pack 2. We would like to specifically call out the following fixes which are included in this release:

Note: Some of the following KB articles may not be available at the time of publishing this post.

• 2748766 Retention policy information does not show "expiration suspended" in Outlook Web App when the mailbox is set to retention hold in an Exchange Server 2010 environment
• 2712595 Microsoft Exchange RPC Client Access service crashes when you run the New-MailboxExportRequest cmdlet in an Exchange Server 2010 environment
• 2750847 An Exchange Server 2010 user unexpectedly uses a public folder server that is located far away or on a slow network

For DST Changes: http://www.microsoft.com/time

Exchange Team

Recently, Windows Update began offering the Windows Management Framework 3.0 as an Optional update. This includes all forms of update distribution, such as Microsoft Update, WSUS, System Center Configuration Manager and other mechanisms. The key bit here is that the Windows Management Framework 3.0 includes PowerShell 3.0.

Windows Management Framework 3.0 is being distributed as KB2506146 and KB2506143 (which one is offered depends on which server version you are running - Windows Server 2008 SP2 or Windows Server 2008 R2 SP1).

What does that mean to you?

Windows Management Framework 3.0 (specifically PowerShell 3.0) is not yet supported on any version of Exchange except Exchange Server 2013, which requires it. If you install Windows Management Framework 3.0 on a server running Exchange 2007 or Exchange 2010, you will encounter problems, such as Exchange update rollups that will not install, or the Exchange Management Shell may not run properly.

We have seen Exchange update rollups not installing with the following symptoms:

• If rollup is installed through Microsoft Update, the installation might error with error code 80070643
• If rollup is installed from a download, the error displayed is Setup ended prematurely because of an error.
• In both cases, Event ID 1024 may be logged in the Application event log with the error error code “1603”. For example, if you try to install update roll 5 for Exchange 2010 SP2, you may see the following description in event ID 1024:

  Product: Microsoft Exchange Server - Update 'Update Rollup 5-v2 for Exchange Server 2010 Service Pack 2 (KB2785908) 14.2.328.10' could not be installed. Error code 1603. Windows Installer can create logs to help troubleshoot issues with installing software packages. Use the following link for instructions on turning on logging support: http://go.microsoft.com/fwlink/?LinkId=23127

Our guidance at this time is that Windows Management Framework 3.0 should not be deployed on servers running Exchange 2007 or Exchange 2010, or on workstations with the Exchange Management Tools for either version installed. If you have already deployed this update, it should be removed. Once you remove the update, functionality should be restored.

Ben Winzenz

Exchange 2010 had many new enhancements and improvements over prior versions of Exchange. One really cool feature was the introduction of the Calendar Repair Assistant (CRA). The CRA is a mailbox assistant that is configurable through the Exchange Management Shell and runs within the MS Exchange Mailbox Assistants service. Its intended purpose is to help maintain consistency of calendar meetings between an organizer and the attendees by comparing the meeting copies of the organizer and the attendees. Why did the Exchange Product Group build this really awesome component into Exchange 2010? I’m glad you asked. I want to take you on a journey back to…The Good Ole Days!

The Good Ole Days

In the “Good Ole Days” (or even as recently as last week), the Exchange support team logged numerous calls and cases on calendar meeting issues for prior versions of Exchange. Because of the flexibility allowed in terms of what end users can do with meetings in their calendars, meetings can become inconsistent across organizers and attendees calendars. These issues would range from inconsistent meeting times between organizers and attendees to meetings being “unknowingly” deleted from a user’s calendar. We saw cases where meetings would show up in Outlook but not a mobile device or vice versa. Sometimes meetings would be duplicated on a calendar or would lose their organizer. Delegates would reportedly make a change to a meeting but it wouldn’t show up on the mailbox owner’s mobile device. The list goes on. The troubleshooting of these issues, though normally pretty straight forward can be tedious and time consuming. I went ahead and included a troubleshooting reference guide for you below not only to point out how we would troubleshoot and identify these problems, but also just in case you’ve stumbled onto this blog and you’re experiencing something similar!

Exchange calendar troubleshooting reference

Getting to the most recent service pack and update of your Outlook client and Exchange Server is very important as doing that might actually address your reported problems. Depending on the type of issue you are experiencing, there are several different ways to troubleshoot. If you are trying to determine why a meeting keeps changing or is moved to the deleted items folder, etc. MFCMapi is a good tool to use. You can launch MFCMapi and connect to the mailbox profile of the user that is reporting the issue. Find the calendar item that you are looking for and save out the properties of that item to a text file. Search for the PR_LAST_MODIFIER_NAME, PR_LAST MODIFIED_DATE, PR_SENDER_EMAIL, and PR_SENT_REPRESENTING_NAME. These properties will paint a pretty good picture for you. Often times we’ve seen that the last user to modify the item is either a service account for a MAPI/CDO device, a delegate, or the mailbox owner themselves.

Another great tool you can use to see what is happening to a meeting is Exchange Trace or “Trace Control” which can be found in the Exchange Troubleshooting Assistant in Exchange 2007 and 2010. You can setup your trace, check all of the boxes under “Trace Types” and then on the “Components to Trace” you will select “Store” with the following “Trace Tags”: tagCalendarChange, tagCalendarDelete, tagMtgMessageChange, tagMtgMessageDelete. You can then setup a mailbox filter for the mailbox in question and kick off the trace. At this point you will need to reproduce the issue (or wait until it reproduces). Once it does stop the trace. You’ll need to get with Microsoft support at this point to convert and analyze the trace for you.

One of my colleagues over on the Outlook team, Randy Topken, created a great tool called CalCheck. It performs a wide variety of tests and is very helpful in troubleshooting Calendar issues. I won’t go through all of them as he has published everything you need to know here: CalCheck - The Outlook Calendar Checking Tool.

There are many other issues that we have encountered, but this is a glimpse of the most common types of issues we have seen (and actually continue to see) and how we go about troubleshooting those problems. Hopefully this gives you a little insight as to why we were so excited to see the Calendar Repair Assistant in Exchange 2010. I’ve included some additional links to assist you in troubleshooting calendar below:

• Working with support to troubleshoot the Outlook calendar in an Exchange environment
• How to troubleshoot calendar issues in Microsoft Outlook, Microsoft Exchange Server 2007, and Microsoft Exchange Server 2010
• How to troubleshoot missing and duplicate appointments in Outlook
• Troubleshooting Free/Busy Information for Outlook 2007

CRA RTM

Now let’s get to the heart of this article, THE CRA! The CRA was built to detect and correct calendar inconsistencies like I described above between a meeting organizer and attendees. The CRA must be configured through the Exchange Management Shell in order to run, as it is not enabled by default. Once enabled, the CRA will run against all mailboxes on the server you have configured it for. You can disable it for specific mailboxes by using the Set-Mailbox cmdlet and setting the CalendarRepairDisabled to True. In the RTM release of Exchange 2010, the CRA was a time-based assistant that was configured to run on a specified schedule and could not be throttled to adjust for server resource utilization. CRA made decisions only by comparing an organizer’s copy of a meeting with the attendee’s copy of the meeting. CRA uses the organizer’s meeting copy as the master and assumes it is the correct copy. It then checks attendee response status and assumes that the attendee’s response status is correct and updates the tracking information for the organizer. The problem was that CRA had no idea of how the inconsistencies occurred, meaning it didn’t take into account client intent i.e an attendee intentionally changes a meeting start time or location on their own calendar. One of the biggest issues we saw with this lack of client intent checking in RTM was if an attendee deleted a meeting from their calendar but did not send an update to the organizer, the CRA would recreate the meeting in the attendees calendar and would continue to do so until the attendee sent a response to the organizer (this has been corrected in SP1). When the CRA detects an inconsistency on a calendar, it issues a special meeting message called a Repair Update Message. The message is processed by the Calendar Attendant and then the message is placed in the user’s Deleted Items folder. Any repairs made are recorded in the CRA log (see Troubleshooting CRA below).

CRA SP1 and later

Exchange 2010 SP1 saw some pretty cool changes to the CRA. As mentioned earlier, in the RTM version CRA was time based and ran on a specified schedule. In SP1 and later this changed to a throttle based assistant to help prevent it from impacting server resources or end user experience. You can enable CRA with the Set-MailboxServer cmdlet. You will need to set the CalendarRepairWorkCycle and the CalendarRepairWorkCycleCheckpoint. The work cycle is the time span allocated for CRA to scan and process all mailboxes on the server i.e. if this is set to seven days, that means every mailbox on the server will be processed once every seven days. The throttling assistant calculates the slowest pace at which mailboxes can be processed by dividing the total number of mailboxes by the work cycle. There is also a built in mechanism to monitor certain resources like store and throttle the processing back if the load starts to rise. The checkpoint is the period of time in which the list of mailboxes in the CRA’s queue is refreshed during the existing work cycle, adding new mailboxes, moved mailboxes and mailboxes that have not processed yet into its queue. For example, the following command will set the CRA to check all mailboxes on the server once every seven days and refresh its work queue every day with the list of calendars that still need to process repairs within that seven day period:

Set-MailboxServer –Identity MBXSRV1 –CalendarRepairWorkCycle 7.00:00:00 –CalendarRepairWorkCycleCheckPoint 1.00:00:00

You can verify the settings for calendar repair options that are set for all mailbox servers by running the following in Exchange Management Shell:

Get-MailboxServer | fl name,*calendar*

Another great change in SP1 was the introduction of “client intent”. The CRA can now distinguish intentional versus unintentional inconsistencies between a meeting organizer and attendees. When the CRA is running against an attendee calendar, it will validate a meeting item against the organizer’s copy. If it is running against the organizer, it will validate the item against all attendees. The CRA will correct inconsistencies, but only for mailboxes on the server for which it is running. It reads from other Exchange 2010 mailbox servers, but each server enabled for calendar repair will have its own instance of the CRA running that is responsible for the mailboxes on that server. When the CRA finds an inconsistency, it goes about determining client intent by using snapshots of calendar items that are stored in something called the Calendar Version Store (CVS) and calendar metadata. Before a calendar item is changed, the Exchange 2010 copy on write functionality takes a snapshot of the calendar item and stores it along with additional metadata (like the source or the application that initiated the change) in the root of the Recoverable Items folder for a default 120 days before being purged. The Calendar Version Store maintains a historical record of these calendar item snapshots that are in the Recoverable Items folder. Client intent metadata is added to a calendar item as a named property: Name id = 0x0015 (dispidClientIntent), Named Prop GUID = 11000E07-B51B-40D6-AF21-CAA85EDAB1D0. Any non-zero Hex value represents an intentional change. Before a specific change is made to a calendar item, the snapshot is taken which preserves the existing metadata as well. When the CRA is determining client intent, it queries the Calendar Version Store. During the initial query, a special dynamic search folder is created called CalendarVersionStore in the root of the non-IPM subtree with a search scope of the IPM subtree and the Recoverable Items folder and criteria of all calendar items and meeting messages. Once this search folder is populated with the requested stored versions of a particular item from the Calendar Version Store, the CRA will go about determining client intent. It must first determine the target version of the particular item. It does this in one of two ways. The first method the CRA uses to determine the target version for client intent is when the resulting change, and not the state prior to the change, is important, ie an item is deleted. The Calendar Version store is sorted with the most recent item on top and then queried backwards. The oldest version found that is in the target state is used as the target version and it is the one whose client intent metadata is validated. Let’s say that item A is deleted and there are 4 snapshots of item A in the CVS. We will call them A4-A1. First A4 is queried and we see that it matches the target deleted state. Then A3 is queried and (for hypothetical purposes) we see it is also in the target deleted state. Then A2 is queried and the CRA determines that this snapshot is not in the target deleted state. Now the CRA will go back to A3 and review the metadata on it for client intent. Any non-zero entry on this item indicates an intentional change. The second method the CRA uses to determine the target version for client intent is when how an item transitioned into a certain state is important, ie the time or location on an attendee copy is different from the organizer’s copy. The main difference of this method is that it looks at the chain of snapshots from initial state to target state. If any snapshot in the chain does not show client intent, then the whole change is considered unintentional. Let’s say that the CRA finds that a meeting attendee for meeting B has a different time listed than the organizer. There are 5 snapshots of B in the attendees CVS, B5-B1. The CRA searches backwards (B5-B4-B3-B2-B1) and finds that B2 is the last snapshot with the same time as the organizer. It will then look at the metadata on B3-B5. If any of these have a zero entry, the entire chain is considered unintentional and will be corrected. All of the items in this chain must have a non-zero metadata client intent property value set for CRA to read this as an intentional change. In 2010 SP1, when the CRA detects an unintentional inconsistency it uses the same process (Repair Update Message) as it did in 2010 RTM. When the CRA detects an intentional location or time inconsistency, no repair action is taken on the calendar item. If there is an intentional missing organizer or attendee item, the CRA uses a special inquiry message to repair the item on the opposite calendar. For instance, if a meeting organizer deletes a meeting but doesn’t send out a cancellation, the meeting will still exist on the attendee’s calendar. The CRA will send a special inquiry message that is processed by the calendar attendant and trigger a normal meeting cancellation on the attendee’s calendar. For more information on CRA conflict detection and resolution logic see the “Conflict Detection and Resolution” section here: Understanding Calendar Repair

Caveats

• CRA does not run against resource mailboxes.
• If the meeting organizer does not enable the “Request a response to this invitation” in OWA or “Request Responses” option in Outlook, calendar repair will not take place on that meeting.
• If you set calendar repair to disabled for a specific mailbox, calendar repair will not take place for that mailbox. You can verify this with get-mailbox | ft name,CalendarRepairDisabled . If it’s set to true, then calendar repair is disabled.
• If you disable the Calendar Version Store for a specific mailbox, then client intent cannot be determined. You can verify this get-mailbox | ft name,CalendarVersionStoreDisabled . If it’s set to true, then the Calendar Version Store is disabled.
• The CRA only check calendar items for mailboxes that have the calendar attendant enabled (it is by default). This allows the Repair Update Message to be processed. See Set-CalendarProcessing.
• The primary clients that write client intent metadata are OWA 2010 SP1 and Outlook 2010. Client intent for clients utilizing EWS or EAS may be limited. See Client Application Experience.
• CRA will not change the meeting organizer, if it has been improperly changed.

Troubleshooting CRA

Troubleshooting calendar issues in 2010 can be approached in the same way as listed in the earlier troubleshooting section. There are some additional things you can look at when trying to see if the CRA processed a repair to a meeting and why. The first is the CRA log. It is stored on the mailbox server that it is running on and is located in <ExchangeInstallPath>\Logging\Calendar Repair Assistant and is in the format of CRA<date>yyyymmdd-<sequence>.<user>.log. Locate the CRA logs for specific users and then review them for any repairs that the CRA made. get-CalendarDiagnosticLog can be used to search the Calendar Version Store for a particular user and a particular item. Then you can use MFCMapi as outlined above to search the properties of the item and determine if there was positive client intent.

Conclusion

Hopefully I’ve shed a little light on the importance of the Calendar Repair Assistant. It is a critical component and has, in my opinion, reduced the number of cases in Exchange 2010 than what we saw for calendar issues in prior versions of Exchange. Troubleshooting, while you can still use the same techniques used in legacy versions of Exchange, has been simplified with the CalCheck, Calendar Repair Log, and using the Get-CalendarDiagnosticLog to pull calendar items from the Calendar Version Store for analysis on client intent cases.

Additional resources

• Understanding Calendar Repair
• Configure Calendar Repair Assistant Settings
• Managing Calendars
• Set-MailboxServer
• Set-Mailbox
• Changes to Recoverable Items Versioning in Exchange 2010 SP2 RU3

I wanted to thank Mike Manjunath, Rob Whaley and Jonathan Runyon for their review of this blog post.

Charles Lewis

Earlier last year, we announced that Exchange 2010 Service Pack 3 would be coming in the first half of 2013. Later, we updated the timeframe to Q1 2013. Today, we're pleased to announce the availability of Exchange Server 2010 Service Pack 3, which is ready to download.

Service Pack 3 is a fully slipstreamed version of Exchange 2010. The following new features and capabilities are included within SP3:

• Coexistence with Exchange 2013:Customers who want to introduce Exchange Server 2013 into their existing Exchange 2010 infrastructure will need the coexistence changes shipping in SP3.

  NOTE: Exchange 2010 SP3 allows Exchange 2010 servers to coexist with Exchange 2013 CU1, which is also scheduled to be released in Q1 2013. Customers can test and validate this update in a representative lab environment prior to rolling out in their production environments as an important coexistence preparatory step before introducing Exchange Server 2013 CU1.

• Support for Windows Server 2012: With SP3, you can install and deploy Exchange Server 2010 on computers that are running Windows Server 2012.
• Support for Internet Explorer 10: With SP3, you can use IE10 to connect to Exchange 2010.
• Customer Requested Fixes: All fixes contained within update rollups released before SP3 will also be contained within SP3. Details of our regular Exchange 2010 release rhythm can be found in Exchange 2010 Servicing.

In addition to the customer reported issues resolved in previous rollups, this service pack also resolves the issues that are described in the following Microsoft Knowledge Base (KB) articles:

Note: Some of the following KB articles may not be available at the time of publishing this post.

2552121 You cannot synchronize a mailbox by using an Exchange ActiveSync device in an Exchange Server 2010 environment

2729444 Mailboxes are quarantined after you install the Exchange Server 2010 SP2 version of the Exchange Server 2010 Management Pack

2778100 Long delay in receiving email messages by using Outlook in an Exchange Server 2010 environment

2779351 SCOM alert when the Test-PowerShellConnectivity cmdlet is executed in an Exchange Server 2010 organization

2784569 Slow performance when you search a GAL by using an EAS device in an Exchange Server 2010 environment

2796950 Microsoft.Exchange.Monitoring.exe process consumes excessive CPU resources when a SCOM server monitors Exchange Server 2010 Client Access servers

2800133 W3wp.exe process consumes excessive CPU and memory resources on an Exchange Client Access server after you apply Update Rollup 5 version 2 for Exchange Server 2010 SP2

2800346 Outlook freezes and high network load occurs when you apply retention policies to a mailbox in a mixed Exchange Server 2010 SP2 environment

2810617 Can't install Exchange Server 2010 SP3 when you define a Windows PowerShell script execution policy in Group Policy

2787500 Declined meeting request is added back to your calendar after a delegate opens the request by using Outlook 2010

2797529 Email message delivery is delayed on a Blackberry mobile device after you install Update Rollup 4 for Exchange Server 2010 SP2

2800080 ErrorServerBusy response code when you synchronize an EWS-based application to a mailbox in an Exchange Server 2010 environment

For more details, see Description of Exchange Server 2010 SP3.

Exchange Team

Today the Exchange CXP team released the following update rollups to the Download Center. All three releases cover Security Bulletin MS13-012 (KB 2809279). Because this is a security release, the updates will also be available on Microsoft Update.

Update Rollup 6 for Exchange Server 2010 Service Pack 2

Update Rollup 10 for Exchange Server 2007 Service Pack 3

Update Rollup 6 for Exchange Server 2010 SP2:

This update contains a number of customer reported and internally found issues. In particular we would like to specifically call out the following fixes which are included in this release:

Note: Some of the following KB articles may not be available at the time of publishing this post.

2489941 The "legacyExchangeDN" value is shown in the "From" field instead of the "Simple Display Name" in an email message in an Exchange Server 2010 environment

2779387 Duplicated email messages are displayed in the Sent Items folder in a EWS-based application that accesses an Exchange Server 2010 Mailbox server

2751581 OAB generation fails with event IDs 9126, 9330, and either 9338 or 9339 in an Exchange Server 2010 environment

2784081 Store.exe process crashes if you add certain registry keys to an Exchange Server 2010 Mailbox server

Update Rollup 10 for Exchange Server 2007 SP3:

This update contains a number of customer reported and internally found issues. In particular we would like to specifically call out the following fixes which are included in this release:

2783779 A hidden user is still displayed in the Organization information of Address Book in OWA in an Exchange Server 2007 environment

Note: Exchange 2007 SP3 RU10 allows Exchange 2007 servers to coexist with Exchange 2013 CU1, which is also scheduled to be released in Q1 2013. Customers can test and validate this update in a representative lab environment prior to rolling out in their production environments as an important coexistence preparatory step before introducing Exchange Server 2013 CU1.

For DST Changes: http://www.microsoft.com/time

Exchange Team

Ahoy, Exchange Ninjas! It’s time to buckle up and go PST hunting again with the new PST Capture 2.0!

Earlier this week, we released a brand new version of the free PST Capture tool that allows you to hunt down PST files on client computers across your network. After it finds PST files on users’ computers, the tool consolidates the PST files to a central location, and then easily injects PST data to primary or archive mailboxes on your on-premises Exchange Servers or Exchange Online.

What’s new in PST Capture 2.0?

PST Capture 2.0 includes the following improvements:

• Support for Microsoft Exchange Server 2013
• Updated profile generation code to use Outlook Anywhere (RPC over HTTP).
• Fixed Exchange Online import failure issue when PST Capture is not installed on an Exchange server.
• Removed User Interface limit of 1,000 users when performing an import to Exchange Online.
• General performance improvements

Download PST Capture 2.0 from the Download Center (aka.ms/getpstcapture), check out the PST Capture documentation (aka.ms/pstcapture) and then go get those PSTs!

Exchange Team

We're happy to announce that the Exchange Server 2010 Deployment Assistant (ExDeploy) now includes updates for supporting hybrid deployments with Exchange 2010 Service Pack 3 (SP3) organizations and the latest release of Office 365.

Important information to know about the SP3 update for the Exchange 2010 hybrid deployment scenarios:

• Updated information is available only in English at this time. Support in additional languages will follow shortly.
• We’ve removed the qualifying question about existing Forefront Online Protection for Exchange for on-premises organizations. Forefront Online Protection for Exchange (FOPE), now known as Exchange Online Protection (EOP), is no longer a limiting factor in hybrid transport routing options. Organizations no longer need to request that their existing EOP service be merged with the EOP service provided with the Microsoft Office 365 tenant. The EOP services are merged automatically and do not require any additional configuration.
• We’ve also removed the limitations on configuring centralized mail transport in the Manage Hybrid Configuration wizard. Centralized mail transport in hybrid deployments can be configured regardless of existing EOP service configuration.
• If you have previously configured a hybrid deployment using ExDeploy and Exchange 2010 SP2, you’ll need to take a few basic administrative actions as part of updating your hybrid deployment for the latest release of Office 365. See Understanding Upgrading Office 365 Tenants for Exchange 2010-based Hybrid Deployments for more details.

We’d also like to remind everyone that we’ve released the Exchange Server 2013 Deployment Assistant for those organizations that want to take advantage of the features of a new Exchange 2013 installation and for Exchange 2010 and Exchange 2007 organizations that are interested in the benefits of an Exchange 2013-based hybrid deployment. See Now Available: Exchange Server 2013 Deployment Assistant.

Exchange 2010-based hybrid deployments offer Exchange 2010, Exchange 2007 and Exchange 2003 organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. It provides the seamless look and feel of a single Exchange organization between an on-premises organization and an Exchange Online organization in Office 365. In addition, hybrid deployments can serve as an intermediate step to moving completely to a cloud-based Exchange Online organization. This approach is different than the simple Exchange migration (“cutover migration”) and staged Exchange migration options currently offered by Office 365 outlined in E-Mail Migration Overview.

About the Exchange Server Deployment Assistant

The Exchange Server Deployment Assistant (ExDeploy) is a web-based tool that helps you upgrade to Exchange 2010 on-premises, configure a hybrid deployment between an on-premises and Exchange Online organization or migrate to Exchange Online.

Figure 1:The Exchange Deployment Assistant generates customized instructions to help you upgrade to Exchange 2010 on-premises or in the cloud

It asks you a small set of simple questions, and then based on your answers, it provides a checklist with instructions to deploy or configure Exchange 2010 that are customized to your environment. These environments include:

• Stand-alone on-premises Exchange installations and upgrades
• Hybrid deployment configurations and
• Cloud-only Exchange deployment scenarios.

Besides getting the checklist online, you can also print instructions for individual tasks and download a PDF file of your complete configuration checklist.

Your feedback is very important for the continued improvement of this tool. We would love your feedback on this new scenario and any other area of the Deployment Assistant. Feel free to either post comments on this blog post, provide feedback in the Office 365 community Exchange Online migration and hybrid deployment forum, or send an email to edafdbk@microsoft.com via the Feedback link located in the header of every page of the Deployment Assistant.

Exchange Deployment Assistant Team

Back in November 2012, we announced our MCA Beta client. We have been very busy working to improve the testing options that are available from the MCA client. Here’s what we’ve built for the 1.0 release:

Microsoft Connectivity Analyzer Tool 1.0

We are excited to announce the 1.0 release of the Microsoft Connectivity Analyzer.  This tool is a companion to the Microsoft Remote Connectivity Analyzer web site.  The MCA tool provides administrators and end users with the ability to run connectivity diagnostics for five common connectivity symptoms directly from their local computer.  Users can test their own connectivity, and save results in an HTML format that administrators will recognize from viewing results on the RCA website. 

Install the MCA 1.0 tool here:https://testconnectivity.microsoft.com/?tabid=client

Watch the Introduction Video:

The MCA tool offers five test symptoms:

• “I can’t log on with Office Outlook”– This test is equivalent to the Exchange RCA test for “Outlook Anywhere (RPC over HTTP)”. There is an option to run the SSO test provided on the parameters page.
• “I can’t send or receive email on my mobile device”.   – This test is equivalent to the Exchange RCA test for Exchange ActiveSync.
• ***New MCA Test*** “I can’t log on to Lync on my mobile device or the Lync Windows Store App”– This test checks for the Domain Name Server (DNS) records for your on-premise domain to ensure they are configured correctly for supporting Mobile Lync clients. Also it connects to the Autodiscover web service and makes sure that the authentication, certificate, web service for Mobility is correctly set up
• ***New MCA Test*** “I can’t send or receive email from Outlook (Office 365 only)”– This test checks Inbound/Outbound SMTP mail flow and also includes Domain Name Server validation checks for O365 customers.
• ***New MCA Test*** “I can’t view free/busy information of another user”– This test verifies that an Office 365 mailbox can access the free/busy information of an on-premises mailbox, and vice versa (one direction per test run).

Microsoft Lync Connectivity Analyzer Tool:  You will also notice the Lync Connectivity Analyzer Tool on the client page.  We are working on combining MCA with MLCA in the near future but wanted to make both these great tools available to customers now to improve our client diagnostics options. To learn more about MLCA – go HERE

Feedback: Send all feedback to the MCA Feedback alias.  Please let us know what you think of the tool and whether this will be helpful in troubleshooting connectivity scenarios. Also feel free to provide feedback on additional tests you would like to see added in the future.

Microsoft Remote Connectivity Analyzer 2.1

We are excited to announce the 2.1 release of the Microsoft Remote Connectivity Analyzer web site.  The tool provides administrators and end users with the ability to run connectivity diagnostics for our servers to test common issues with Exchange, Lync and Office 365.  We have added new Office 365 Domain Name Server tests, enhanced existing tests, and improved the overall site experience.

Check out the updates to the website here:https://testconnectivity.microsoft.com

Here are the highlights of the 2.1 RCA release:

Version 2.1 (March 2013)

• Added support for localized language support for 60 languages
• Updated version of the downloadable Microsoft Connectivity Analyzer v1.0 Tool for troubleshooting connectivity from the local machine
• Added Microsoft Lync Connectivity Analyzer downloadable tool for troubleshooting Lync issues from the local machine
• Added Office 365 General Tests section
• Added Office 365 Exchange Domain Name Server (DNS) Connectivity Test

Enjoy!

Thanks.

Brian Feck on behalf of the entire MCA/RCA team.
Follow the team on Twitter - @ExRCA

I'm a support enginer in CSS. I was working with a customer who reported a mail loop error for a specific domain like contoso.com. This error was only observed in large emails.  Yeah that’s really mysterious until you figure out that the mail loop is due to size restriction on the Send connector.  I thought this was curious enough to share.

Understanding the configuration and root cause of the issue:

I initially thought that this might have been the outcome of the Edge server being configured to use an external DNS server (a DNS server that resolves external hosts). Usually, when the Edge Tranport server is configured to use an external DNS, it resolves the domain name to the public IP addresses (generally pointing to itself, the exernal firewall, or the service provider) instead of a Hub Transport server in the Active Diectory site, causing a mail loop.

On reproducing the issue, I found out that the Edge Transport server was not configured to use an external DNS server. The environment I set up to reproduce the issue looked like the diagra below:

Here's what happens in this scenario: When the Edge Transport server receives a 20 MB email from an Internet sender, it accepts it. The Edge Transport server has two connectors that match the address space - one for the address space contoso.com to the Active Directory site and one for the address space *. When making the routing decision based on all available connectors, the one from the Edge to Hub is not considered because of the size restriction (it has 10 MB size limit). The best match is the * connector from Edge to the Internet (Please go over the connector selection algorithm documented in Understanding Message Routing) which has a message size limit of 30 MB.

End result: The message is routed back to the Internet causing the message loop between the Internet and the Edge Server.

Based on whether the Send connector to the Internet is configured to use DNS or a Smart Host to deliver oubound mail, we will get one of the following NDRs:

If using DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##

If using a Smart Host:

5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#

The Solution

This behavior is by design and can be easily rectified by modifying the message size limit on the connector. Based on your requirement, you can choose either of the following options:

• Set the MaxMessageSize parameter on the Receive Connector (which receives inbound mail from the Internet) to 10MB, so messages from the Interent are restricted to 10 MB.
• Set the MaxMessageSize on the Send connector from Edge to HUB to 30MB, which will allow you to receive 30 MB messages from external senders.

Mystery solved! Thanks to Arindam Thokder and Scott Landry, who helped me with getting this ready for the blog!

Suresh Kumar (XCON)

As a Microsoft Premier Field Engineer (PFE), I assist companies with Lotus Notes and GroupWise migrations to Exchange/Outlook environments and have found that different applications act differently. One of the common questions is: Can Outlook/Exchange send canned responses from a common mailbox? The answer is yes, but it is done a little differently than other products.

While everyone here is familiar with the different tools and process in this article, I usually find that the ‘leap of faith’ to put them together in this combination is not always made. So here we go, easy steps put together to create an end result worthy of solving a situation that may apply to your environment.

The first question is, in the Exchange/Outlook realm, is it possible to have a common response from a single mailbox (sometimes referred to as a ‘repository’) from multiple people? Yes it is possible in Outlook, but several steps have to be setup for this to occur correctly and consistently.

Let’s say you have an ‘IT Helpdesk’ mailbox, that acts like a repository and you have several people accessing this resource throughout the day. The first step is to remind ourselves where ‘signatures’ are stored in Outlook. Most peoples’ first thought is within the Outlook profile. That’s not correct. The signatures are actually stored as .htm files on a user’s local machine:

By default on Vista\Windows 7\8:

C:\Users\%UserName%\AppData\Roaming\Microsoft\Signatures

By default on Windows XP:

C:\Documents and settings\%UserName%\Application Data\Microsoft\Signatures

Why do I mention %UserName%? That is the wild card entry for the Alias or AD User Account name of whoever is logged onto the computer. You’ll see later that we reference this again.

Another question is, ‘What can you do with an HTML file?’ And of course the better question is, ‘What CAN’T you do with an HTML file?’ The beauty of having these files on the computer is that we can act upon them at any time and Outlook will use the current file. In fact, even with Outlook open, you could add a new file in this location and it will show up in the available signature list, which is one of the more dynamic options available in Outlook. Within this HTML file, you could put all kinds of interesting mechanisms: hyperlinks, formatted text, images, marching ant text, blinking text, all of the cool and possibly annoying functions that a web page allows us to accomplish.

The next step we have to do is to be able to get common files to end users’ desktops. This is accomplished by a simple GPO (Group Policy Object) via AD (Active Directory). Hence, if a file needs to be copied to a desktop, a simple call to a UNC path that acts upon a logon process can get the file to the proper location. Something like:

xCopy \\ServerName\Share\*.* C:\Users\%UserName%\AppData\Roaming\Microsoft\Signatures

This will copy all files in this share location to whoever has the GPO applied to and get it to their desktop every time they log onto any machine they have access to. This also ensures consistency of implementing updated files and ease of deploying new machines. For those of you that thought the signature files were in the Outlook profile, you can now see that you can have signatures setup for an end user before they ever launch Outlook on a newly provisioned client machine. Pretty cool stuff.

You can also set permissions on the network folder share to only allow say a manager to edit the files inside the folder. This would allow only the proper people to have access that impacts many other users. Example, around December the files could mention holiday specific information like: “Thank you for the contact, our staff is cycling through holiday time off and your request may take a little longer than usual to get to.” Or at the beginning of the year: “Welcome to the New Year, we are excited about deploying our new products this year.” Whatever the message is, it can easily be updated and controlled from a central location and be deployed to the proper end users that send out the common responses.

Figure 1: Setting share permissions on a folder share.

The next problem we run into is when someone ‘reads’ a message in Outlook, it is marked as ‘read’. Now other mail products allow you to read a message and have it not be marked as read. We don’t do that in Outlook/Exchange. Once a message is read by anyone, you have to go back and mark it as ‘unread’. A training of end users is the only answer here. There are no Outlook settings available to set to change this behavior.

Figure 2: Right click a message and select ‘Mark as Unread’ or on the Ribbon, select Unread/Read option.

We’re almost done. The last few steps are back on the client machines. After you’ve trained your end users to simply apply the appropriate signature file and select the correct mailbox account to send from, you have one more training step. You have to inform them of which ‘sent items’ folder to send from. Yep, there’s another issue here, but one that can also be easily resolved.

Figure 3: Selecting specific signature and which mailbox account to send from.

By default, when sending a message from within Outlook, the message is recorded from the ‘sent item’ folder of the user sending the item. This is not the ideal behavior when we have a common resource mailbox that others have to view sent items from people who are also acting as a single voice from the identical repository location. This is accomplished by a registry edit on the client side. So once again we go back to our friend AD and edit a GPO for consistency. Remember that all registry settings can be edited via GPO’s. Depending on the version of AD you’re on, you may have to use a logon file that calls to a .reg file, or for 2008 and above DC’s, use GPO Preferences to achieve the same process.

There is no universal fix; each user who can ‘Send As’ another mailbox must perform one of the following on their computer, or deploy using a patch management solution, like System Center Configuration Manager (SCCM) and/or GPO’s.

Outlook 2003 (KB317865 and KB953804)

Install the office2003-KB953803-GLB.exe hotfix (http://support.microsoft.com/kb/953803). There is no reboot required; but, Outlook has to be closed.

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Preferences

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type DelegateSentItemsStyle, and then press ENTER.

5. Right-click DelegateSentItemsStyle, and then click Modify.

6. In the Value data box, type 1, and then click OK.

7. Exit Registry Editor.

Outlook 2007 (KB972148 and KB970944)

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type DelegateSentItemsStyle, and then press ENTER.

5. Right-click DelegateSentItemsStyle, and then click Modify.

6. In the Value data box, type 1, and then click OK.

7. Exit Registry Editor.

Outlook 2010 (KB2181579)

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type DelegateSentItemsStyle, and then press ENTER.

5. Right-click DelegateSentItemsStyle, and then click Modify.

6. In the Value data box, type 1, and then click OK.

7. Exit Registry Editor.

Outlook 2013

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Preferences

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type DelegateSentItemsStyle, and then press ENTER.

5. Right-click DelegateSentItemsStyle, and then click Modify.

6. In the Value data box, type 1, and then click OK.

7. Exit Registry Editor.

The other alternative is to have the sender manually move the sent message to the Sent Items folder of the user named as the sender in the email.

Important: After you set the DelegateSentItemsStyle registry value to 1, the functionality is only available when the Microsoft Exchange account is set to Use Cached Exchange Mode. The DelegateSentItemsStyle registry value will not work consistently on an Exchange account that is configured in Online mode.

Figure 4: Creating a GPO, using ‘preferences’, to set which ‘sent items’ folder is allowed to be selected.

So there you have it. Sending a consistent response, from a commonly shared mailbox, using signature files, Outlook client regedit, GPO’s, and a UNC share. Now go out and improve your commonly used shared resource mailboxes and present a stronger corporate image at the same time. Thank you and happy improvements.

Mike O'Neill

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

A short while ago, we posted an article on how to Use Exchange Web Services and PowerShell to Discover and Remove Direct Booking Settings. We received a lot of constructive feedback with some noting that users can experience an issue when enabling the Resource Booking Attendant on mailboxes that were cleansed of their direct booking settings via the sample script we provided. Specifically, the following error can be encountered when the organizer is scheduling a regular non-recurring meeting against the resource mailbox:

“…declined your meeting because it is recurring. You must book each meeting separately with this resource.”

We have updated the script to account for this scenario to prevent and correct this from occurring and we have also updated the article to reflect the changes as well.

In a nutshell, the issue is encountered when we have a divergence of what settings are enabled/disabled between the Schedule+ Free/Busy System (Public) Folder item representing the user’s mailbox and the user’s local mailbox free/busy item. Outlook’s Direct Booking process actually queries the Schedule+ item’s Direct Booking settings when attempting to perform Direct Booking functionality. The Schedule+ folder tree normally contains an item that contains a synced set of Direct Booking settings of that which is stored in the user’s localfreebusy mailbox item. The issue is encountered when the settings between the Schedule+ item and the local mailbox item do not match.

Normally, Outlook triggers a sync of the local mailbox item to the Schedule+ item via deliberate native MAPI code. However, in our case we are using EWS in the sample script, and that syncing trigger does not natively exist. We therefore updated the script to find the Schedule+ item and ensure its settings are congruent with the local item’s settings. The logic for this is actually a bit complicated for two main reasons:

1. No Schedule+ item exists in the organization – There are valid scenarios where the Schedule+ item may not exist, such as the mailbox was never opened with Outlook and the Direct Booking settings were enabled via another means, such as MFCMAPI and so on.
2. Co-existent versions of Exchange - EWS is rather particular on how public folder and public folder item bindings can occur. EWS by design will not allow a cross-version public folder (or item) bind operation. Period. This means a session, for example on a mailbox on Exchange 2010 would not be able to bind to a public folder or its items on Exchange 2007, there would need to be a replica of the folder on Exchange 2010 for the bind operation to be successful. Further, continuing our example, even if the there is a replica on Exchange 2010, the bind operation would still fail if the user’s mailbox database’s “default public folder database” is set to a non-2010 public folder database (i.e. an Exchange 2007 database). The EWS session would kick back an error stating: ‘There are no public folder servers available’

With these guidelines in mind, we approached the script update to maximize the congruency potential between the local mailbox item and the public folder item. We only disable the direct booking settings in the local mailbox item if one of the following criteria is met regarding the Schedule+ item:

• We can successfully bind to the user’s Schedule+ item
  • There is a replica we can touch with the EWS session, and we found the item representing the user and we can therefore safely keep congruency between the local and the Schedule+ items.
• There is no replica present that would potentially contain an item representing the user
  • There is no replica in the org (any version of exchange) that would contain an item for the user so there is no potential for getting into an incongruent state between the local and the Schedule+ items.
• There is a replica of the Schedule+ folder on the same version of Exchange that the EWS session is connected to, AND the default public folder database of the user is likewise on the same version of Exchange.
  • We could not find a Schedule+ item for the user (if we did, we would have satisfied condition 1 above), but not because there was no replica containing the item (if we did, we would have satisfied condition 2 above), and not because we could not bind to the folder via the EWS limitations we outlined above. We can therefore state that congruency between the local and the Schedule+ items are not at risk and there is no Schedule+ item representing the user.

It should be noted that we will always take action to disable the Direct Booking settings from the Schedule+ item even if the local mailbox item does not have its Direct Booking settings enabled – this keeps us true to our “congruency” logic.

In closing, please remember that the script is a sample and does not cover every possible scenario out there – we made this update because the aforementioned issue reported is central to having the script produce the desired outcome of fully disabling Direct Booking. We are thankful for and welcome your continued feedback!

Dan Smith & Seth Brandes
Exchange PFEs