We’re happy to announce the latest updates to the Exchange Server 2013 Deployment Assistant!

We’ve updated the Deployment Assistant to include the following new scenarios:

• Upgrading from a mixed Exchange 2007/Exchange 2010 deployment to Exchange 2013
• Configuring an Exchange 2013-based hybrid deployment for Exchange 2010 organizations

These new scenarios provide step-by-step guidance about how to upgrade your mixed Exchange 2007/Exchange 2010 organization to benefit from the improvements and new features of Exchange 2013. Additionally, Exchange 2010 organizations can now configure a hybrid deployment with Office 365 using Exchange 2013 if you would like to leverage the newest improvements to the Hybrid Configuration Wizard.

And, we’re working on even more future improvements to the Deployment Assistant! We’ve listened to your feedback for improving both the Exchange 2013 and Exchange 2010 Deployment Assistants and we’re combining both of these tools into a single deployment resource. All the on-premises and hybrid deployment scenarios for Exchange 2010 in the Exchange Server 2010 Deployment Assistant will soon be incorporated into the Exchange Server 2013 Deployment Assistant. The new and improved “Exchange Server Deployment Assistant” will soon be a one-stop shop for deploying multiple versions of Exchange. Keep checking back here for an announcement to learn when this is available!

In case you're not familiar with it, the Exchange Server 2013 Deployment Assistant is a web-based tool that helps you deploy Exchange 2013 in your on-premises organization, configure a hybrid deployment between your on-premises organization and Office 365, or migrate to Office 365. Supported on most major browsers, the tool asks you a small set of simple questions and then, based on your answers, creates a customized checklist with instructions to deploy or configure Exchange 2013. Instead of trying to find what you need in the Exchange library, the Deployment Assistant gives you exactly the right information you need to complete your task.

And until we’ve finished our upcoming updates for the Deployment Assistants, if you still need to deploy Exchange 2010, or are interested in configuring an Exchange 2010-based hybrid deployment with Office 365, you can continue to access the Exchange Server 2010 Deployment Assistant.

Do you have a deployment success story about the Deployment Assistant? Do you have suggestions on how to improve the tool? We would love your feedback and comments! Feel free to leave a comment here, or send an email to edafdbk@microsoft.com directly or via the Feedback link located in the header of every page of the Deployment Assistant.

Happy deploying!

The Exchange Server Deployment Assistant Team

At TechEd North America 2013, we announced that we had begun testing and validation of a new configuration for a database availability group (DAG) that would enable automatic site resilience when two datacenters were used in concert with a witness server that was deployed in a Windows Azure IaaS environment.

During the validation phase of our testing, it became clear that the Windows Azure infrastructure did not support the necessary underlying network components to allow us to configure a supported solution. As a result, we are not yet able to support the use of Azure for a DAG’s witness server.

Background Information

The goal was to derive a supported configuration for Azure subscribers that already had at least two datacenters of their own.  Two of the on-premises datacenters would house the Exchange DAG members, and the witness server would be deployed as an Azure file server VM, which would be located in a third datacenter (the Azure cloud).

In order to configure a DAG and its witness across three datacenters, you must meet the following requirements:

• You need two well-connected datacenters, in which Exchange is deployed
• You need a third location that is connected via the network to the other two datacenters
• The third location needs to be isolated from network failures that affect the other two datacenters

Unfortunately, Azure does not provide the necessary infrastructure to provide us with a third location with the appropriate network connectivity.

Azure Networks

Today, Azure provides support for two types of networks:

1. A single site-to-site VPN – a network that connects two locations
2. One or more point-to-site VPNs – a network that connects a single VPN client to a location

To have a server deployed in Azure act as a witness server for the DAG, you would require two site-to-site VPN connections (one connecting each Exchange datacenter to the Azure infrastructure). This is not possible today, as Azure supports only a single site-to-site VPN connection per Azure network. Without a second site-to-site VPN connection for the other datacenter, only one datacenter can have persistent network connectivity with the Azure servers.

A point-to-site VPN cannot be used in the second datacenter for a variety of reasons:

• A point-to-site connection is designed to be a client VPN connection that connects a single host to the Azure cloud service
• Point-to-site VPN connections have timeouts and will automatically disconnect after a certain period of time
• Point-to-site VPN connections do not automatically reconnect and require administrative intervention

Witness Server Placement Considerations

The placement of a DAG’s witness server will depend on your business requirements and the options available to your organization. Exchange 2013 includes support for new DAG configuration options that are not recommended or not possible in previous versions of Exchange. These options include using a third location, such as a third datacenter or a branch office.

The following table lists general witness server placement recommendations for different deployment scenarios.

When a DAG has been deployed across two datacenters, a new configuration option in Exchange 2013 is to use a third location for hosting the witness server. If your organization has a third location with a network infrastructure that is isolated from network failures that affect the two datacenters in which your DAG is deployed, then you can deploy the DAG’s witness server in that third location, thereby configuring your DAG with the ability automatically failover databases to the other datacenter in response to a datacenter-level failure event.

For more information on the witness server and witness server placement, see Managing Database Availability Groups.

Moving Forward From Here

Unfortunately, without the required networking infrastructure in the Azure service, a DAG cannot be deployed on-premises using a witness server in the Azure cloud.  The Exchange Product Group has made a formal feature request from the Azure team for multiple site-to-site VPN support. If that feature is introduced by the Azure team, then testing and validation of the Azure witness will reconvene with the hope of producing a supportable solution. In the meantime, Azure is not supported for use as a DAG witness.

Scott Schnoll

Exchange Server 2013 introduces a new feature called Managed Availability, which is a built-in monitoring system with self-recovery capabilities.

If you’re not familiar with Managed Availability, it’s a good idea to read these posts:

• Lessons from the Datacenter: Managed Availability
• What Did Managed Availability Just Do To This Service?

As described in the above posts, Managed Availability performs continuous probing to detect possible problems with Exchange components or their dependencies, and it performs recovery actions to make sure the end user experience is not impacted due to a problem with any of these components.

However, there may be scenarios where the out-of-box settings may not be suitable for your environment. This blog post guides you on how to examine the default settings and modify them to suit your environment.

Managed Availability Components

Let’s start by finding out which health sets are on an Exchange server:

Get-HealthReport -Identity Exch2

This produces the output similar to the following:

Next, use Get-MonitoringItemIdentity to list out the probes, monitors, and responders related to a health set. For example, the following command lists the probes, monitors, and responders included in the FrontendTransport health set:

Get-MonitoringItemIdentity -Identity FrontendTransport -Server exch1 | ft name,itemtype –AutoSize

This produces output similar to the following:

You might notice multiple probes with same name for some components. That’s because Managed Availability creates a probe for each resource. In following example, you can see that OutlookRpcSelfTestProbe is created multiple times (one for each mailbox database present on the server).

Use Get-MonitoringItemIdentity to list the monitoring Item Identities along with the resource for which they are created:

Get-MonitoringItemIdentity -Identity Outlook.Protocol -Server exch1 | ft name,itemtype,targetresource –AutoSize

Customize Managed Availability

Managed Availability components (probes, monitors and responders) can be customized by creating an override.

There are two types of override: local override and global override. As their names imply, a local override is available only on the server where it is created, and a global override is used to deploy an override across multiple servers.

Either override can be created for a specific duration or for a specific version of servers.

Local Overrides

Local overrides are managed with the *-ServerMonitoringOverride set of cmdlets. Local overrides are stored under following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\

The Microsoft Exchange Health Management service reads this registry path every 10 minutes and loads configuration changes. Alternatively, you can restart the service to make the change effective immediately.

You would usually create a local override to:

• Customize a managed availability component that is server-specific and not available globally; or
• Customize a managed availability component on a specific server.

Global Overrides

Global overrides are managed with the *-GlobalMonitoringOverride set of cmdlets. Global overrides are stored in the following container in Active Directory:

CN=Overrides,CN=Monitoring Settings,CN=FM,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com

Get Configuration Details

The configuration details of most of probes, monitors, and responders are stored in the respective crimson channel event log for each monitoring item identity, you would examine these first before deciding to change.

In this example, we will explore properties of a probe named “OnPremisesInboundProxy”, which is part of the FrontendTransport Health Set. The following script lists detail of the OnPremisesInboundProxy probe:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy"}

You can also use Event Viewer to get the details of probe definition. The configuration details most of the Probes are stores in the ProbeDefinition channel:

1. Open Event Viewer, and then expand Applications and Services Logs\Microsoft\Exchange\ActiveMonitoring\ProbeDefinition.
2. Click on Find, and then enter OnPremisesInboundProxy.
3. The General tab does not show much detail, so click on the Details tab, it has the configuration details specific to this probe. Alternatively, you can copy the event details as text and paste it into Notepad or your favorite editor to see the details.

Override Scenarios

Let’s look at couple real-life scenarios and apply our learning so far to customize managed availability to our liking, starting with local overrides.

Creating a Local Override

In this example, an administrator has customized one of the Inbound Receive connectors by removing the binding of loopback IP address. Later, they discover that the FrontEndTransport health set is unhealthy. On further digging, they determine that the OnPremisesInboundProxy probe is failing.

To figure out why the probe is failing, you can first list the configuration details of OnPremisesInboundProxy probe.

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy"}

Name : OnPremisesInboundProxy

ExtensionAttributes : <ExtensionAttributes><WorkContext><SmtpServer>127.0.0.1</SmtpServer><Port>25</Port><HeloDomain>InboundProxyProbe</HeloDomain><MailFrom Username="inboundproxy@contoso.com"/><MailTo Select="All" Username="HealthMailboxdd618748368a4935b278e884fb41fd8a@FM.com"/><Data AddAttributions="false">X-Exchange-Probe-Drop-Message:FrontEnd-CAT-250 Subject:Inbound proxy probe</Data><ExpectedConnectionLostPoint>None</ExpectedConnectionLostPoint></WorkContext></ExtensionAttributes>

The ExtentionAttributes property above shows that the probe is using 127.0.0.1 for connecting to port 25. As that is the loopback address, the administrator needs to change the SMTP server in ExtentionAttributes property to enable the probe to succeed.

You use following command to create a local override, and change the SMTP server to the hostname instead of loopback IP address.

Add-ServerMonitoringOverride -Server ServerName -Identity FrontEndTransport\OnPremisesInboundProxy -ItemType Probe -PropertyName ExtensionAttributes -PropertyValue '<ExtensionAttributes><WorkContext><SmtpServer>Exch1.contoso.com</SmtpServer><Port>25</Port><HeloDomain>InboundProxyProbe</HeloDomain><MailFrom Username="inboundproxy@contoso.com" /><MailTo Select="All" Username="HealthMailboxdd618748368a4935b278e884fb41fd8a@FM.com" /><Data AddAttributions="false">X-Exchange-Probe-Drop-Message:FrontEnd-CAT-250Subject:Inbound proxy probe</Data><ExpectedConnectionLostPoint>None</ExpectedConnectionLostPoint></WorkContext></ExtensionAttributes>' -Duration 45.00:00:00

The probe will be created on the specified server in following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\Probe

You can use following command to verify if the probe is effective:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy"}

Creating a Global Override

In this example, the organization has an EWS application that is keeping the EWS app pools busy for complex queries. The administrator discovers that the EWS App pool is recycled during long running queries, and that the EWSProxyTestProbe probe is failing.

To find out the details of EWSProxyTestProbe, run the following:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "EWSProxyTestProbe"}

Next, change the timeout interval for EWSProxyTestProbe to 25 seconds on all servers running Exchange Server 2013 RTM CU2:

1. Use following command to get version information for Exchange 2013 RTM CU2 servers:
   

   Get-ExchangeServer | ft name,admindisplayversion

2. Use following command to create a new global override:
   

   Add-GlobalMonitoringOverride -Identity "EWS.Proxy\EWSProxyTestProbe" -ItemType Probe -PropertyName TimeoutSeconds -PropertyValue 25 –ApplyVersion “15.0.712.24”

Override Durations

Either of above mentioned overrides can be created for a specific Duration or for a specific Version of Exchange servers. The override created with Duration parameter will be effective only for the period mentioned. And maximum duration that can be specified is 60 days. For example, an override created with Duration 45.00:00:00 will be effective for 45 days since the time of creation.

The Version specific override will be effective as long as the Exchange server version matches the value specified. For example, an override created for Exchange 2013 CU1, with version “15.0.620.29” will be effective until the Exchange server version changes. The override will be ineffective if the Exchange server is upgraded to different version of Cumulative Update or Service Pack.

Hence, if you need an override in effect for longer period, create the override using ApplyVersion parameter.

Removing an Override

Finally, this last example shows how to remove the local override that was created for the OnPremisesInbounxProxy probe.

Remove-ServerMonitoringOverride -Server ServerName -Identity FrontEndTransport\OnPremisesInboundProxy -ItemType Probe -PropertyName ExtensionAttributes

Conclusion

Managed Availability performs gradual recovery actions to automatically recover from failure scenarios. The overrides help you customize the configuration of the Managed Availability components to suite to your environment. The steps mentioned in the document can be used to customize Monitors & Probes as required.

Special thanks to Abram Jackson, Scott Schnoll, Ben Winzenz, and Nino Bilic for reviewing this post.

Bhalchandra Atre

Update 8/14/13: Due to an issue with the Exchange 2013 Security Update installation process, the Exchange 2013 updates have been removed from the Download Center. For more information, please see Exchange 2013 Security Update MS13-061 Status Update.

Today, Exchange Servicing released several updates for the Exchange product line to the Download Center:

• Update Rollup 11 for Exchange Server 2007 SP3
• Update Rollup 7 for Exchange Server 2010 SP2
• Update Rollup 2 for Exchange Server 2010 SP3
• Exchange Server 2013 RTM CU1 MSRC Security bulletin MS13-061
• Exchange Server 2013 RTM CU2 MSRC Security bulletin MS13-061

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

Exchange 2007 Rollups

The Exchange 2007 SP3 RU11 update contains two fixes in addition to the changes for MS13-061. For more details, including a list of fixes included in this update, see KB 2873746 and the MS13-061 security bulletin. We would like to specifically call out the following fixes which are included in this release:

• 2688667 W3wp.exe consumes excessive CPU resources on Exchange Client Access servers when users open recurring calendar items in mailboxes by using OWA or EWS
• 2852663 The last public folder database on Exchange 2007 cannot be removed after migrating to Exchange 2013 

Exchange 2010 Rollups

The Exchange 2010 SP2 RU7 update contains the changes for MS13-061.  For more details, see the MS13-061 security bulletin.

The Exchange 2010 SP3 RU2 update contains fixes for a number of customer-reported and internally found issues, as well as, the changes for MS13-061. For more details, including a list of fixes included in this update, see KB 2866475 and the MS13-061 security bulletin. We would like to specifically call out the following fixes which are included in this release:

• 2861118 W3wp.exe process for the MSExchangeSyncAppPool application pool crashes in an Exchange Server 2010 SP2 or SP3 environment
• 2851419 Slow performance in some databases after Exchange Server 2010 is running continuously for at least 23 days
• 2859596 Event ID 4999 when you use a disclaimer transport rule in an environment that has Update Rollup 1 for Exchange Server 2010 SP3 installed
• 2873477 All messages are stamped by MRM if a deletion tag in a retention policy is configured in an Exchange Server 2010 environment
• 2860037 iOS devices cannot synchronize mailboxes in an Exchange Server 2010 environment
• 2854564 Messaging Records Management 2.0 policy can't be applied in an Exchange Server 2010 environment

Exchange Server 2013

MS13-061 is the first security update released for Exchange Server 2013 utilizing the new servicing model.  MS13-061 is available as a security update for:

• Security Update for Exchange Server 2013 RTM CU1
• Security Update for Exchange Server 2013 RTM CU2

Important: If you have previously deployed CU2, you must ensure you are running build 712.24 in order to apply the security update. For more information about build 712.24, please see Now Available: Updated Release of Exchange 2013 RTM CU2.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Late last night we became aware of an issue with MS13-061 security update for Exchange Server 2013. Specifically, after the installation of the security update, the Content Index for mailbox databases shows as Failed and the Microsoft Exchange Search Host Controller service is renamed.

For those that have already installed the MS13-061 security update for Exchange Server 2013, we already have KB 2879739 that provides the steps on how to resolve this issue. However, due to this issue and that it affects all Mailbox server installations, we have decided to pull the MS13-061 security update temporarily.

Note: This issue does not occur in Exchange 2010 or Exchange 2007. You can proceed with testing and deploying Exchange 2007 SP3 RU11, Exchange 2010 SP2 RU7, and Exchange 2010 SP3 RU2.

Recommendation

If you have already installed MS13-061 security update on your Exchange 2013 servers, we recommend following the steps in KB 2879739 to resolve the issue.

If you have not installed MS13-061 security update on your Exchange 2013 servers, we recommend not proceeding with the update at this time. To mitigate the security vulnerability, we recommend following the workaround steps identified within the Vulnerability Information – Oracle Outside in Contains Multiple Exploitable Vulnerabilities section within the MS13-061 Security Bulletin.

Question/Answers

Q: What is the impact of this security vulnerability?

A: Please see the information contained within the MS13-061 Security Bulletin.

Q: I am about to upgrade from CU1 to CU2, will I be affected?

A: No, this issue does not occur when upgrading to a cumulative update. This issue only occurs when patching a .msi installation via a .msp file.

Q: Why does this issue occur with installing a .msp file?

A: During the Exchange 2013 installation (.msi installation), the service is created, the Data Folder Location registry key is created and during a post configuration step, the registry key is populated with data and the service name is rebranded. During the .msp installation, these settings are reverted back to their original installation values prior to the post-configuration step.

Q: If I follow the steps identified in the workaround, will I have issues in the future?

A: Following the steps identified in KB 2879739 will resolve the issue and not cause any future problems.

Q: What happens if I uninstall the security update?

A: You will need to follow the steps identified in KB 2879739, otherwise your search infrastructure will be broken.

Q: Why didn’t you recall the update rollups for Exchange 2010 and Exchange 2007?

A: Both Exchange 2010 and Exchange 2007 utilize a different indexing architecture and, as a result, are not impacted.

Q: How was this issue not detected in Exchange Online if Exchange Online is always receiving fixes before on-premises customers?

A: Exchange Online does not deploy .msp patches into the environment; instead, Exchange Online deploys new full builds of the product (cumulative updates, if you will) on a regular release cadence. As a result, Exchange Online was not impacted by this issue.

Q: How was this issue not detected in your on-premises deployments?

A: Unfortunately, this security update did not get deployed into our dogfood environment prior to release.

Q: You have told us time and time again that you were going to improve your testing procedures, and yet each time you have to tell us that you missed something. When will it end?

A: We will work very hard to regain your trust and confidence. With that said, we have recently made the decision to delay the release of Exchange 2013 RTM CU3 by several weeks to ensure that we have enough run time testing within our dogfood environment. Also, we will ensure that all patches are deployed in our dogfood environment prior to release going forward.

We will continue to make improvements in our release cadence and testing methodologies over time to ferret out these issues. These changes may mean that our once a quarter release cadence for Exchange 2013 may change.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

In Microsoft Exchange 2013, Public Folders were re-engineered using mailbox infrastructure to take advantage of the existing high availability and storage technologies of the mailbox database. Public folder architecture uses specially designed mailboxes to store both the public folder hierarchy and the content. This also means that there’s no longer a public folder database. High availability for the public folder mailboxes is provided by a database availability group (DAG). To learn more about the general architecture about the public folders please visit the blog post: Public folders in the new Office.

We are currently seeing that customers have started using and taking the advantage of the new public folders feature in Microsoft Exchange 2013. Since the public folders have been re-designed, it becomes very important to plan for recovery of deleted data as well.

This blog post we will be exploring various recovery scenarios that can occur with public folders in Microsoft Exchange 2013.

Recovering items deleted from public folders

• With the public folder now being in a mailbox, we will follow the method for recovering the deleted items as we have been following earlier for recovering items from Dumpster with “regular” mailboxes
• Recover deleted items for public folders is enabled by default from Outlook 2007 onwards, which is the minimum client required for Microsoft Exchange 2013.
• Items or content deleted go directly to the Dumpster where they are retained as per the retention settings set on the public folder or the default settings are inherited.

To understand this let’s take an example:

A user who deletes the content from a specific folder will see the following message:

To then recover that data, user just needs to click on the Recover Deleted Items option in Outlook which will pop up a new window and will list the items to be recovered. From there, use the usual selection and Recover Selected Items functionality.

How to recover items which are past retention period?

If you need to recover the items from a public folder where deleted items have passed the retention period the only option is to restore from the last full good backup for the database which hosts the associated public folder content mailbox. This behavior is similar to the recovery of contents in normal mailboxes.

You will have to restore the database files to a RecoveryDatabase. Once the restore is complete you will have to use the below command to complete the recovery.

New-MailboxRestoreRequest –SourceDatabase “Name of Recovery database” –SourceStoreMailbox “mailbox containing affected public folder” –TargetMailbox “mailbox to which data is recovered” –AllowLegacyDNMismatch –IncludeFolders “name of affected folder”

The missing data will be recovered to the affected public folder.

Note: Make sure that the Microsoft Exchange 2013 Server is updated with Cumulative Update 2 (Ref: Exchange 2013 RTM CU2 (712.22) Issue - Public Folder Permissions Loss after PF Mailbox Move)

Using Outlook to recover deleted public folders

Outlook Clients make the job of recovering deleted public folders easy. The following things are necessary for the successful recovery of public folders:

• The user recovering the public folder should have the Owner permissions on the public folder being recovered.
• Public folder should be within the deleted items retention period.
• If the folder being recovered is a root folder, the user should also have owner permissions at the Root level.
• If the recovered public folder is a Child folder of another folder, the user should also have the Owner permissions on the Parent folder.

Moving further let’s consider a scenario where you need to recover a root public folder which was deleted.Let’s say the permissions need to be granted to the user who wants to recover the root public folder.

In Exchange Admin Center (EAC) assign the permissions to the relevant user who wants to recover the public folder and click on save button and exit out.

Once the Root permissions have been assigned to the required user, the user can recover the public folder using the regular Outlook recover Deleted Items functionality. Once the folder is recovered, remove the permissions for the user that you added at the root level, if so desired.

A few things to note:

• When public folders are recovered using Outlook client, you will need to rename them to their original name once they are recovered.
• Any root public folder which is recovered using Outlook will be restored to the Primary Public Folder mailbox. If you you need to move the Public folder to the original secondary mailbox, you can do so using the command:

New-PublicFolderMoveRequest -Folders \<Folder name> -TargetMailbox "Target mailbox name"

For more information visit: New-PublicFolderMoveRequest

If the root public folders also had the Child folders which were recovered, you might need to also move the child public folder to the Secondary mailbox explicitly. Moving the root public folder to another mailbox will not change the content mailbox for the respective child folders. In order to move the branch of public folders to respective content mailboxes use a script named .\Move-PublicFolderBranch.PS1

Things to note:

• It might be easier to use Exchange Management Shell preferably in scenarios where you need to recover the deleted Child public folders or deleted parent public folder which also has the child folders (see below)
• Any Root public folder which is deleted and recovered using the Outlook client should have their original permissions retained. If the root public folder recovered also had child public folders, then the permissions of child folders will be replaced and inherited from the parent public folder.

Using Exchange Management Shell to recover deleted public folders

While recovering public folders using Outlook is one of recovery options, we still have Exchange Management Shell which will help us in recovery scenarios and can make the job easier. Let’s say you need to restore a public folder to the root path or you are not the owner of the public folder which was deleted and you need to recover it.

You run the command:

Get-PublicFolder –Identity “\NON_IPM_SUBTREE” –Recurse | FL >C:\pf2.txt

Once the command is run it will create a text file. You need to open it and find the affected public folder path.

Let’s say I have a folder named “Test-3” which is deleted. I will search for the required folder in the text file:

Now open the Exchange Management Shell and run the following command, to recover the folder:

Set-PublicFolder –Identity “\NON_IPM_SUBTREE\DUMPSTER_ROOT\<GUID>\Test-3” –Path “\” –Verbose

That is all! You can now open Outlook and access the public folder which you just recovered. The contents along with the permissions will be restored.

You can use the same process to also restore any deleted child public folder or entire branch of public folders which are deleted. Simply restore the Root folder and all of its content (including any child folders) will be restored with it.

Note: It’s not necessary to restore the Child public folder to its own Parent folder. It can also be restored to the root public folder hierarchy by specifying the desired path.

How to recover folders which are past deleted items retention period?

Recovering public folders within retention period is very easy, but recovering public folders which have been deleted from dumpster is more challenging. You need to restore a last full good backup for the affected public folder.

Similarly to recovering items past retention period, once you restore the database to a Recovery database you need to run a Shell command to restore the contents to the affected public folder.

There are certain pre-requisites for this recovery method:

• For recovery of any public folder mailbox data, we should have “target” folders created in the target mailbox. In other words, the data that you are trying to recover will not create the folder structure automatically (at this time)
• Make sure that the Microsoft Exchange 2013 Server is updated with Cumulative Update 2 to avoid any permissions issues as discussed in the blog post (Exchange 2013 RTM CU2 (712.22) Issue - Public Folder Permissions Loss after PF Mailbox Move)

Let’s walk through a scenario to understand this more clearly.

You have a folder named June Reports which has expired and cannot be recovered from deleted items, and therefore needs to be recovered from backup

In order to recover the deleted June Reports folder from the restored database, we need to have a folder with a name of “June Reports” in the target public folder mailbox to which the data is being restored. This is a limitation of the restore process at this time.

So, to walk through specific steps:

We need to recover a root public folder named JuneReports. I have last full good backup with me which has the required data. Restore the database to a Recovery Database. Once the database has been restored you will have to perform the following steps:

Create a new public folder with name “June Reports” in a public folder content mailbox if it does not exists. If it exists, then you can skip this step.

New-PublicFolder –Mailbox “Content Mailbox name” –name “June Reports”

Next you will run the command:

New-MailboxRestoreRequest –SourceDatabase “Name of Recovery database” –SourceStoreMailbox “recovered mailbox containing affected public folder” –TargetMailbox “target mailbox to which data is recovered” –AllowLegacyDNMismatch –IncludeFolders “name of affected folder”

After that completes, you can run the below command to check if the command was successfully in restoring the contents:

Get-MailboxrestoreRequest | Where { $_.Status –eq “Completed” }

To confirm the restore is completed, run the command Get-MailboxRestoreRequestStatistics and check the value of ItemsTransferred

Now, in Outlook the affected folder should have all restored items:

You should see the recovered items along with the new items in the folder.

For more information check:

• New-MailboxRestoreRequest
• Get-MailboxRestoreRequestStatistics

Conclusion

In the above blog post I tried to shed some light on how to recover the contents from public folders when they are deleted and have also discussed the scenarios where we need to recover the entire public folder. I plan to continue posting other public folder recovery scenarios in additional blog posts.

I would like to Thank Ben Winzenz, Bill Long, Charlotte Raymundo, Nino Bilic and Bhalchandra Atre for their help in reviewing this blog post!

Siddhesh Dalvi

It’s no secret that the amount of email we receive increases every day. For messages that we care about, most of us take some action (read, reply, file, etc.) and then put them away. But from time to time we need to refer back to some of those messages. A convenient and fast way to dig up messages is to search for them. You enter a keyword or the name of the person who sent the message and Exchange returns the results for that query. But when the part of the message you’re looking for is buried within a long conversation, it’s a hassle to find the specific section you’re looking for.

Outlook Web App has been highlighting search term hits to easily identify where a search term is located within a long conversation. We’ve recently made three improvements to the Outlook Web App hit highlighting feature. These include:

1. Auto-expanding conversation items that have hits in them.
2. Auto-scrolling to the first search hit.
3. Adding hit navigation within a conversation.

Auto-expanding conversation items with hits

When you search for a term and select a conversation from the results list, Outlook Web App opens all the items that have search hits within that conversation and collapses all that don’t contain the term, so users can concentrate on the items related to their query.

For example, the following screenshot shows a conversation with 15 items (3 unread) as it’s displayed in Inbox (before a search):

When you search for the keyword “73”, Outlook Web App automatically scrolls to the first occurrence (explained below), expands all the items that contain “73”, and collapses all the item parts that don’t contain the search term. If you want to see the content of items that don’t contain the term, you can still expand them by clicking that item. You don’t have to open each item part just to see if the word you’re searching for is there. Distraction-free search results FTW!

Auto-scrolling to the first search hit

Whenever you search for a term and select a conversation from the results list, Outlook Web App will move the scroll position of the reading pane so that the first item part that includes the search term is in view.

The following screenshot shows the same conversation displaying the results of a search for the words “low car”. Notice that the reading pane (the right-most panel in the Outlook Web App window) has auto-scrolled to reveal the first occurrence of the term “low car”. This way, you don’t have scroll up or down a long conversation just to see where the highlights are.

Added hit navigation within a conversation

The last improvement is the one we’re most proud of and we think will help users save quite a bit of time when searching. We’ve taken a useful cue from the “find in document/page” feature of word processors and browsers to implement hit navigationinside a conversation. This lets you jump quickly between search hits using a control built into the reading pane. You can see the control at the bottom right of the reading pane during your search.

Here are the components of the hit navigation control:

• The search term is highlighted with an orange background to match the currently highlighted instance of the term in the reading pane.
• Buttons with arrow icons let you move to up and down to the previous or next instance of the search term.
• Numbers show the total number of visible hits for the search term and the position of the currently highlighted one relative to the others.

You can move between the search hits by clicking the previous and next buttons. The reading pane will move to the next or previous search hit depending on the button that’s clicked. The following screenshot shows what Outlook Web App user interface might look like when you search for the word “knob” and then use the new hit navigation to go to the fifth instance of the term “knob” within that conversation (by clicking nextfour times). As you can see, the currently highlighted term is distinguished from the all the other highlights using a different background color (yellow vs. orange). The navigation buttons work in a circular way, which means that when you’re at the tenth, clicking next will take you back to the first item.

We’ve been rolling out these features to Office365 users and our Enterprise customers can get them by applying Exchange 2013 CU2.

Kutlay Topatan

On August 14th, we announced the removal of the MS13-061 Security Update for Exchange Server 2013 due to an issue where the patch changed settings for the search infrastructure, placing the content index for all databases into a failed state.  As of today, we have released updated security updates for both Exchange 2013 RTM CU1 and Exchange 2013 RTM CU2.

Download links for MS13-061:

• Exchange 2013 RTM CU1 Security Update
• Exchange 2013 RTM CU2 Security Update

As always, we recommend you test updates in a lab environment that closely mirrors your production environment prior to deploying in your production environment.

Questions & Answers

Q: What was changed in these patches?

A: The registry settings for the search infrastructure outlined in KB 2879739 are preserved during patch installation.

Q: Was this patch tested in your on-premises environment prior to release?

A: Yes, we tested this in our Exchange Dogfood environment prior to release and validated that the search settings were retained upon installation.

Q: What happens if I uninstall the security update (or any other interim update I receive from Microsoft for Exchange 2013)?

A: You will need to follow the steps identified in KB 2879739, otherwise your search infrastructure will be broken. 

Q: Wait, I thought you fixed that issue; why do I have to follow KB 2879739 if I uninstall?

A: This has to do with the way the search infrastructure is installed during the Cumulative Update.  Unfortunately, this issue cannot be corrected via a patch file; we have to address it in a cumulative update.  We are planning to address this in CU3.

Q: If I uninstall a patch and then install a new patch, do I still have to follow the steps in KB 2879739?

A: Yes.

Q: Will I need to follow KB 2879739 every time I install a patch?

A: No; the installation of a new patch without uninstalling the previous patch will not introduce this behavior.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

As customers are upgraded or sign up for the latest version of Office 365 for business, they may notice some changes in their recipient and organization management experience. For instance, we now allow the Organization and Hybrid Migration management experience to be initiated from the Exchange Administration Center (EAC) in Exchange Online. This allows you as the administrator to take advantage of many of the enhancements that were added to the migration and organization management experience. The good news is you can do this without having to upgrade your on-premises Exchange 2010 Hybrid server to Exchange 2013.

Hybrid Mailbox Moves

In hybrid deployments with Exchange Online, you should consider using the EAC to perform your hybrid mailbox moves. Some of the main features that have been added or enhanced are listed in Mailbox Moves in Exchange 2013:

• Ability to move multiple mailboxes in large batches
• Email notification during move with reporting
• Automatic retry and automatic prioritization of moves
• Option for manual move request finalization, which allows you to review your move before you complete it
• Periodic incremental syncs to update migration changes

The other benefit to using the EAC in Exchange Online - it's a web-based tool, and you have access to the latest enhancements as they are made available in Exchange Online. The Migration team is continually working to improve the migration experience and resolve issues that we may face along the way.

The Exchange Management Console (EMC) in Exchange 2010 SP3 is still a supported tool for performing hybrid mailbox moves. However, you'd be missing out on the enhancements that were built into the EAC and you could potentially run into some of the limitations that exist in the EMC when connecting to the new service.

Previous EMC move mailbox experience

Most customers with a hybrid deployment are currently running Exchange 2010 in their on-premises environment. Many customers are accustomed to performing their mailbox moves from the EMC on-premises. If there was an issue initiating the move, the customer would be notified with an error message such as the following:

Figure 1: A generic error when performing a remote mailbox move using the Exchange Management Console in Exchange 2010 SP3

This would let the administrator know that they needed to start investigating the moves. In many cases, when you get a generic error (such as the error above) or if you wanted to get a more verbose error message you would use PowerShell to connect to Exchange Online and initiate the move, as shown in the following steps:

1. Connect to Exchange Online Using Remote PowerShell

2. Initiate the move request:

   $OnPremAdmin=Get-Credential

   When prompted, enter the on-premises administrator credentials.

   New-MoveRequest -Remote -RemoteHostName mail.contoso.com -RemoteCredential $OnPremAdmin -TargetDeliveryDomain “Contoso.mail.onmicrosoft.com”

Current EMC move mailbox experience

With the latest version of Office 365, if you were to use the EMC on-premises to initiate a mailbox move and there was an issue, you would not get ANY errors. Meaning you may think the move was submitted successfully even if it was never submitted to the Mailbox Replication Service (MRS). This could mean no move logs, no moves in the queue, and no record that a move was even attempted! Although using the EMC to move mailboxes to Exchange Online is (still) supported, all of the move features are not available in the EMC. You should really use the EAC in the cloud to get the best and most reliable administration experience for your mailbox moves.

Moving mailboxes to Exchange Online using the EAC

Here's a quick walkthrough of how to move a mailbox from Exchange 2013/2010/2007/2003 in a hybrid environment with the new service.

This is assuming you've successfully completed hybrid configuration and your on-premises Exchange organization happily coexists with your cloud-based Exchange organization. You can use the Microsoft Exchange Server Deployment Assistant (EDA), our web-based tool, to get step-by-step instrucions for configuring a hybrid environment.

1. Log into https://portal.MicrosoftOnline.com with your tenant administrator credentials

2. In the top ribbon, click Admin and then select Exchange

3. Click Migration> click + and then select the appropriate move mailbox option. In this example, we're moving a mailbox to the cloud so we select Migrate to Exchange Online.

4. On the Select a migration type page, select Remote move migration as the migration type for a hybrid mailbox move

5. On the Select the users page, select the mailboxes you want to move to the cloud.

6. On the Enter on-premises account credentials page, provide your on-premises administrator credentials in the domain\user format.

7. On the Confirm the migration endpoint page, ensure that the on-premises endpoint shown is the CAS with MRS Proxy enabled.

   Note This will be the same endpoint regardless of wehther you're moving a mailbox to the cloud (onboard request) or moving a mailbox from the cloud to your on-premises Exchange organization (offboard request).

8. Enter a name for the migration batch and initiate the move.

EMC Changes

In Exchange 2010, the EMC has three sections: 1) Organization Configuration 2) Server Configuration and 3) Recipient Configuration. These sections will be visible to administrators as long as they have permissions, via RBAC, to the objects that are in that container.

Before the Service upgrade, if a customer was in a hybrid deployment and connected their Exchange 2010 SP2 EMC to Office 365, they'd see two sections (Organization Configuration and Recipient Configuration in their cloud organization. The Tenant Administrator would not see server configuration settings because they have no control or view into the Server Configuration settings.

Figure 2: Exchange 2010 SP2 EMC connected to Exchange Online before the service uprade

After the service upgrade, the customers will actually see only one container in the cloud organization in Exchange 2010 SP3 EMC - Recipient Configuration. We removed the Organization Configuration container because we don't support (or test) allowing an Exchange 2010 EMC to control or change organizational settings in a newer version of Exchange. To prevent issues, we've completely removed that container from the view in EMC. Configuration changes to the tenant’s Exchange organizational settings in Exchange Online should be accomplished by connecting to the EAC in Exchange Online.

Figure 3: Exchange 2010 SP3 EMC connected to Exchange Online after the service uprade

Timothy Heeney

Ignite Summits are unique and special events for IT Pros delivered by the Exchange team. We share our knowledge and experience deploying and managing the new Office products and services and hear from you on what you love and what you’d like to see. Ignite content is designed and delivered by product experts from across Microsoft (Engineers, Technical Writers, Product Managers & Consultants). In October and November, we will be hosting the following Ignite events.

Register to attend an Ignite Summit.

These 3 day events provide you the opportunity to meet and discuss with Microsoft’s product experts a wide variety of topics from Office, Office 365, SharePoint, Exchange, Project, Yammer and developer content – over 70 sessions covered. Specifically, for Exchange, the sessions will dig deep into the Exchange Server 2013 features and provide expert guidance to plan and deploy these features in your own environment. These session will be delivered by Exchange experts like Scott Schnoll, Brian Day, Andrew Ehrensing, and Robert Gillies just to name a few. The Ignite Exchange track agenda will cover the following topics.

These events are a significant investment in our time and resources, but we are pleased to continue our policy of not charging for these unique training opportunities. However we will impose a no-show fee of $600 (USD) if you register, but do not cancel your registration before the summit. Accommodations for this summit are not included, however we have arranged discounted rooms at the event venues on a first come first serve basis. More details are posted on our registration site (http://aka.ms/A2or7u). Of course, if you can’t make it to one of our events, you can join us on our weekly webcasts or see other upcoming technical events and learning resources at http://ignite.office.com.

Having problems with mail delivery can be a very frustrating experience whether you’re the affected end user or the administrator responsible for ensuring that your end users are able to send and receive mail without issue. Unfortunately, issues with mail flow are not uncommon and will likely occur at some point in time whether your users’ mailboxes are hosted in Office 365, on-premise, or a combination of both.

In an effort to help you resolve these issues we have released the Mail Flow Guided Walkthrough (GWT) for troubleshooting problems sending and receiving mail or when mail is delayed in the following scenarios:

• The sender’s mailbox is hosted on Office 365 and the recipient’s mailbox is outside your organization.
• The sender’s mailbox is outside your organization and the recipient’s mailbox is hosted in Office 365.
• The sender’s and recipient’s mailboxes are both located in Office 365.
• The sender’s mailbox is hosted in Office 365 and the recipient’s mailbox is located on an on-premise Exchange server and both users are in the same organization.
• The sender’s mailbox is hosted on an on-premise Exchange server and the recipient’s mailbox is hosted in Office 365 and both users are in the same organization.

The goal of this walkthrough is to assist you in resolving these issues in a timely manner by focusing on the scoping and steps used to isolate and resolve problems.

I’d like to thank everyone who contributed to the development of this troubleshooter with special recognition going to the following folks: Tom Kern, Nitin Shukla, Sainath Vijayaraghavan, Jim Martin, Bruce Wilson, Stephen Gilbert, Scott Landry, Charlotte Raymundo, Mary Browning, Star Li, Chen Jiang, Victor Zhang.

Joe Turick

We are making it easier to move your existing public folders to Exchange Online modern Public Folders. We are introducing 2 improvements to make this migration easier – first we have increased the size of public folder mailboxes from 25 GB to 50 GB – increasing the standard storage size for modern Public Folders in Exchange Online to approximately 2.5 TB. We are also making it possible for Exchange Server 2003 customers to utilize an Exchange Server 2010 Hybrid to enable Public Folder migration to Exchange Online. These updates help remove challenges in migrating your existing public folders to Exchange Online. Let’s have a look at the benefits and impacts of these changes.

Increasing Exchange Online Public Folder Mailbox Size

The larger public folder mailbox size provides you the ability to store a larger amount of data in modern public folders. Each tenant provides 50 public folder mailboxes now with a 50 GB quota – thus Exchange Online provides approximately 2.5 terabytes of public folder data in the cloud. This removes challenges we have seen in some migrations where the total volume of data exceeded the prior 1.25 TB limit.

The increase in mailbox size does not increase the size of a single public folder. We continue to recommend that you limit the size of any single public folder to 15 GB prior to migration. This recommendation is two-fold – it provides the best service experience and it avoids situations where public folder splits are required at migration. This limit is truly for a single folder – it does not include child folders for the calculation of a folder size. You should review the size of your current public folders prior to migration and reduce the size by deleting or separating large single public folders to ensure the best public folder experience in the service.

As the service is enhanced with changes, you should remember you still have control as the service administrator. You retain the control to reduce the public folder mailbox quota – however you are prevented from configuring quotas values larger than 50 GB in the service.

In the Exchange Online public folder mailbox quota is managed for you – the system monitors and automatically triggers public folder splits to best utilize use public folder mailboxes in the service. Splits are managed by the service and are transparent to users and service administrators. The end result of a split process is to keep all public folder mailboxes within the service limits.

Migrating Exchange Server 2003 Public Folders

This change helps customers migrating from Exchange Server 2003 to Exchange Online – as we have previously noted you can’t directly migrate Exchange Server 2003 Public Folders to Exchange Online. Now you can obtain and use the Exchange Server 2010 SP3 Hybrid to host your existing public folders on the hybrid server for purposes of migration. This migration to Exchange Online requires you move your existing public folder replicas to the hybrid server so there are no replicas left on Exchange 2003. We make multiple hybrid server keys available to you to retain public folder high availability on-premises during your co-existence phase. The scope of use for the Exchange 2010 Hybrid server in this case is limited to temporarily hosting on-premises Exchange Public Folders, solely for the purpose of migrating such Public Folders to Exchange Online. You can request a hybrid server key from Office 365 support.

What’s Next for Public Folders

We are working to provide additional control in the provisioning of public folders. In the future we will extend the New-PublicFolder command to specify an existing or new public folder mailbox, thus enabling admins to control the destination of public folders and avoid situations where a split process is required soon after migration. This is extremely useful when performing PST based public folder migrations.

Learn More About Public Folders

For complete details about Public Folder migration read the TechNet Article for Public Folders in Exchange Online.

Special thanks to the entire Public Folder Feature Crew and Brian Day for contributing to and validating this data.

Brian Shiers

We’re happy to announce that we’ve added some tests to Microsoft Remote Connectivity Analyzer (RCA), to help you test your mail flow configuration. These tests are intended for customers who use the Exchange Online Protection service to perform spam and malware filtering before sending email messages to your email servers. You can run these tests when setting up the service, or whenever you want to verify that your mail flow is set up correctly.

The Verify MX Record and Outbound Connector Test, shown in the image below, verifies that the MX record for your domain points to EOP, so that mail is routed to EOP for filtering before it reaches your mailboxes. This test also verifies that you have an Outbound on-premises connector configured to deliver email to your on-premises environment.

Figure 1: Verify MX Record and Outbound Connector Test

The Verify Service Delivery Test verifies delivery from the service to your on-premises environment by testing the connection between the service and your IP addresses or fully qualified domain names (FQDNs) defined in your Outbound on-premises connector.

For more information about how to run these tests, see Test Mail Flow With the Remote Connectivity Analyzer.

We welcome any feedback; please send comments to the following email address: exrcafb@microsoft.com.

Exchange Online Protection (EOP) Team

The Office Sustained Engineering team has an important update about a potential issue with Outlook 2013 after installing the September 2013 Update. For details about the issue and how to fix affected installations, see Outlook 2013 Folder Pane Disappears After Installing September 2013 Public Update on the Office Sustained Engineering blog.

Exchange Team

Introduction

In Exchange 2013 we introduced the concept of “Server Component States”. Server Component State provides granular control over the state of the components that make up an Exchange Server from the point of view of the environment it is running in. This is useful when you want to take an Exchange 2013 Server out of operation partially or completely for a limited time, but still need the Exchange services on the server to be up and running.

One example of such a situation is when “Managed Availability” (MA) comes to the conclusion that a specific server is not healthy in some respects and therefore should be bypassed temporarily until the bottleneck has been identified and removed. MA does so by utilizing so-called “Offline Responders”. They are explained in some detail in Lessons from the Datacenter: Managed Availability. Their counterpart are “Online Responders”, which bring the server back online when it is determined as being healthy again.

Another example is when a server is being updated, for example with a new CU.

In both situations, the server cannot be taken offline completely, but it also should not be considered as a fully operational member of its Exchange organization as well.

The primary purpose of Managed Availability is, to make the life of Exchange Administrators easier so that they usually do not have to bother themselves with the details. However, in other situations, a certain level of knowledge about the basic concepts behind “Server Component States” might prove to be useful.

Verify the current State of the Server Components

A first overview over the current State of all Server Components can be displayed in the Exchange PowerShell with the Get-ServerComponentState –Identity <ServerID> cmdlet:

You see, that the Server Components listed here do not map 1:1 to Exchange Services or processes running on the server. Instead, they provide an abstraction-layer and display “Components” which together make up the interfaces an Exchange Server provides to its environment. The majority of the components have a name like “*Proxy”. They are specific for the CAS Role, while other components like “HubTransport” and “UMCallRouter” are part of the Mailbox server role and “Monitoring” and “RecoveryActionsEnabled” belong to both roles.

In addition to the single components which can be managed individually, there’s also a component called “ServerWideOffline”, which is used to manage the state of all components together, with the exception of “Monitoring” and “RecoveryActionsEnabled”. For this purpose, “ServerWideOffline” overrides individual settings for all other components. It doesn’t touch “Monitoring” and “RecoveryActionsEnabled” because these two components need to stay active in order to keep MA going. Without them, no “OnlineResponder” could bring “ServerWideOffline” back to “Active” automatically.

About States and Requesters

Usually, Server Components are in one of two States: “Active” or “Inactive”. A third state, called “Draining”, is only relevant for the Components “FrontendTransport” and “HubTransport”.

Whenever the state of a component is supposed to be changed, it has to be done by a “Requester”. For example, the parameter –Requester is mandatory when you run the cmdlet Set-ServerComponentState:

There are altogether five “Requesters” defined:

• HealthAPI
• Maintenance
• Sidelined
• Functional
• Deployment

Requesters are labels - you can choose any of them when running Set-ServerComponentState. But each Requester is treated and stored individually (more on this in the next section) and you should select the Requester that best matches your intention. For example, when you need to set “ServerWideOffline” to “Inactive” for maintenance purposes, it makes no sense to use “HealthAPI” as Requester. You might get what you want that way in terms of functionality; but such a choice will make troubleshooting unnecessarily complicated in case something does not work as expected, and you might get into a conflict with MA. Whenever MA triggers an OfflineResponder or an OnlineResponder it uses “HealthAPI” as Requester; therefore it is a good idea to consider “HealthAPI” as reserved for use by MA.

Interaction between States and Requesters

As stated above, each Requester is handled and stored individually. There’s no relationship or hierarchy amongst them. However, in case of a conflict between two or more Requesters, “Inactive” has a higher priority than “Active”.

Here’s a practical example:

Imagine that “ServerWideOffline” has been set to “Inactive” by two different Requesters, say “Functional” and “Maintenance”:

Then, you set back “ServerWideOffline” to “Active” with one of the two Requesters

As a Result, “ServerWideOffline” and all dependent Components still remain in the state “Inactive”:

In order to set them back to “Active” again, Set-ServerComponentState … -State Active needs to be executed with the second Requester as well.

Obviously, administrators will rarely configure such combinations purposefully. However, we have seen them happening as the result of a mix of processes running in the background and manual configuration.

Where is the data stored and how can it be retrieved?

Information about “Server Components”, “Requesters” and “States” is stored in two different places: Active Directory and the server’s Registry. Storage in the Active Directory facilitates running Set-ServerComponentState against a remote server.

In order to determine precedence in case of a divergence between the two places, a timestamp is used. The newer setting is considered as the intended one.

In Active Directory, the settings are stored in the “msExchComponentStates” attribute of the Exchange Server object in the Configuration-namespace:

In the Registry, the settings are stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates:

You can use the Get-ServerComponentState cmdlet from the Shell to retrieve these settings:

<variable>.LocalStates displays the settings in the local Registry and <variable>.RemoteStates displays the settings in the Active Directory.

Peculiarities of “FrontendTransport” and “HubTransport” Components

Most Exchange Server components pick up changes in their Component State “on the fly”. However, this is not the case for the two Components “FrontendTransport” (mapped to the “Microsoft Exchange Frontend Transport” service on CAS Servers) and “HubTransport” (mapped to “Microsoft Exchange Transport” on Mailbox Servers). They pick up changes upon their next restart only.
This can cause confusion about their actual state. For example, they might be displayed as “Inactive” in Get-ServerComponentState but functionally still be active since they haven’t been restarted since their state has changed.

In order to alert the Administrator about such an inconsistency they write warnings into the Application Event Log. These warnings (7011 for MSExchangeTransport and 7012 for MSExchangeFrontEndTransport) inform the Administrator about the current and the expected state:

MA has Responders which take care of such inconsistencies and resolve them after a while by a forced crash and restart of the affected services. These Responders have the name “FrontendTransport.ServiceInconsistentState.Restart.Responder” and “HubTransport.ServiceInconsistentState.Restart.Responder”. They can be identified in the Microsoft.Exchange.ActiveMonitoring/ResponderDefinition crimson channel using the methodology described in What Did Managed Availability Just Do To This Service? blog post.

In Exchange 2013 CU2 and CU3 they are only triggered once per day for standalone Mailbox Servers and up to four times per day for DAG members. This might change in future versions, though.

After the inconsistencies have been cleared, Events 7009 from Source “MSExchangeTransport” (or “MSExchangeFrontendTransport”) and Category “Components” are logged, which show the current state:

When the state of one or both of these components is set to “Inactive”, each attempt to connect to the SMTP service on the server (on TCP port 25) triggers the response “421 4.3.2 Service not active” (for the FrontendTransport component) and “451 4.7.0 Temporary Server error” (for the HubTransport component) and corresponding entries are written to the respective SmtpReceive Protocol Logs.

As mentioned in KB 2866822 , messages sent from internal stay in the Outbox or Drafts folder and “Service not active” entries are logged in the “Connect*”-Logs in the “Submission”-Folder underneath “TransportRoles\Logs\Mailbox\Connectivity\” when “HubTransport” is set to “Inactive”.

A problem with failing updates to CU2

While an Exchange 2013 Server is updated with CU2, the setup- sets “Monitoring”, “RecoveryActionsEnabled” and “ServerWideOffline” to Inactive using the Requester “Functional” at the beginning, as can be seen in the “ExchangeSetup”-Logfile:

However, when the update exits prematurely because it encounters an unrecoverable error-condition, it does not restore the original state. Even when the Administrator restarts all stopped Exchange services or reboots the server, the Exchange components still remain in the Inactive state.

In order to recover from this situation, you must either find the root cause for the error and remove it so that the setup completes successfully, or manually set the ServerComponentStates back to Active with the Requester “Functional”.

This issue might be fixed in future CUs and SPs.

When should you change Server Component States manually?

Perhaps the two most important scenarios where manual changes of Server Component States come into play are:

1. Planned server maintenance
2. Temporary isolation of some server components, so that they are not targets for proxy requests from other CAS servers any more.

Server component states and planned maintenance of DAG members

Scenario 1 is described for DAG-members in some detail in Managing Database Availability Groups on TechNet. However, in practice, it can prove to be trickier than expected, depending on the details of the planned maintenance measure.

The article does not mention that “FrontendTransport” and “HubTransport” have to be restarted, before a change in their Component State becomes effective at all. Without a restart, you continue to receive warning events 7011 and 7012 in the Application Event Log, but the state of the components remains the same as before, until eventually MA detects the inconsistency and force restarts the services.

Also, the problem with the prematurely exiting CU setups mentioned above in the section “Practical Experiences” cannot be resolved by following the recommendations in the article to the dot, because Setup uses the Requester “Functional”, while the article talks about the Requester “Maintenance”.

Special thanks to Bhalchandra Atre, Stephen Gilbert for their contributions as well as Abram Jackson and Bharat Suneja for their review.

Helmut Krüger

We wanted to let you know that we have released a Beta version of Microsoft Office 365 Best Practices Analyzer for Exchange Server 2013. You can download the bits and read more about the release here. While this Beta has been available for a little while, we have been updating the build once a month with more improvements.

A couple of notes on this release:

• This is a Beta (pre-release) release; we plan to make changes to the tool look and feel, as well as add many additional rules to the tool.
• In order to download the tool, you will need an Office 365 tenant or Azure Active Directory user id. This is because in the future, we plan to include some value-add features that will enable you to store some information in our service (for example, we could enable the running history of BPA reports etc.) Note though that even though login to Azure Active Directory is required to download the tool, you do not need to have an Office 365 tenant to use it. This release can be used by customers who have:
  • Exchange Server 2013 on-premises only
  • Exchange Server 2013 hybrid configuration
  • Office 365 customers who leverage Exchange Online exclusively
• For versions of Exchange earlier than Exchange 2013, please use the already released version of BPA.

We’d like to hear your feedback on this release. You are welcome to post comments here, but if you have specific BPA feedback, we’d like to get an email from you so we can get all the details we might need.

Nino Bilic

Update 11/14/13: We believe that we have resolved all of the related issues; if you still see problems with Remote Connectivity Analyzer, please send us feedback.

We’re having some technical issues with the Remote Connectivity Analyzer site, which is causing occasional errors when running tests.  Although we continue to monitor, please send us feedback using the tool if you're impacted.  While we can’t respond to each inquiry, this helps us measure the impact.  Sorry for the inconvenience; we're working hard to mitigate it! 

For status updates, you can follow us on Twitter @ExRCA

RCA Team

We’ve listened to your feedback for improving the on-premises and hybrid Exchange Server deployment experience, and we’re happy to announce the release of the new, consolidated Deployment Assistant!

The Exchange Server Deployment Assistant now combines all the on-premises and hybrid deployment scenarios from both the Exchange 2013 Deployment Assistant and the Exchange 2010 Deployment Assistant into a single tool. We’ve eliminated the need for the installation of Silverlight and provide guidance for all Exchange Server deployments in a true one-stop shop experience. We’ve also kept the same, convenient question-and-answer format to create a customized, step-by-step checklist with instructions to deploy Exchange 2013 or Exchange 2010.

Starting your Exchange deployment is familiar and convenient, no matter whether you’re deploying Exchange 2013 or Exchange 2010. Just select the one of the three basic deployment tracks: On-premises, Hybrid, or Cloud Only to get started, as shown in Figure 1.

Figure 1: The Exchange Server Deployment Assistant home page

After selecting your basic deployment track, you’ll be able to choose from either an Exchange 2013-based or Exchange 2010-based path for either on-premises or hybrid deployment scenarios. If you selected the Cloud Only scenario, the deployment path is the same for both Exchange 2013 and Exchange 2010 organizations and you’re on your way to getting started with an Exchange Online-only deployment.

Figure 2: Choose either the Exchange 2013 or Exchange 2010 deployment path

After you’ve chosen either the Exchange 2013 or Exchange 2010 deployment path (see Figure 2), you’ll answer a few questions about your deployment needs and you’re off to the races with your customized deployment checklist! For example, see Figure 3, which shows a checklist for an on-premises Exchange 2013 deployment.

Figure 3: Exchange 2013 on-premises deployment path

And, here’s some more good news! If you’ve bookmarked links to the Exchange 2013 and Exchange 2010 Deployment Assistants, there’s no action required to go to the new tool when using your bookmarks. You’ll be automatically redirected to the new tool when using the URL for the previous version of the Deployment Assistant.

We hope you enjoy the convenience of having all the Exchange 2013 and Exchange 2010 deployment scenario guidance in a single tool. We’d love your feedback and comments! Please feel free to leave a comment here, or send an email to edafdbk@microsoft.com directly or via the 'Feedback' link located in the header of every page of the Deployment Assistant.

Happy deploying!

The Deployment Assistant Team

One of best troubleshooting tools for Exchange ActiveSync (EAS) is mailbox logging. This logging allows us to see the incoming request sent by the device and the outgoing response from the Exchange server. Exchange ActiveSync Mailbox Logging provides the steps for enabling ActiveSync mailbox logging and breaks down the components of the log. Here we're going to use one of these logs to analyze how a mobile device running an EAS client (for e.g. a Windows Phone) initializes a profile with Exchange and a few standard commands.

Provision

A device must be provisioned before it can synchronize with Exchange. The device sends the Provision command with the device settings contained within the request. The server response includes the security settings based on the ActiveSync mailbox policy associated with the mailbox. It is important to note now that there are two status codes for most ActiveSync requests. The HttpStatus code only provides the IIS response to the request, and a 200 response does not mean the request was successful. The second status code is for the ActiveSync command and varies depending on the command sent by the device. A status code of 1 is most commonly a success.

The following example shows the request and response from a Provision command:

The device sends another Provision command to complete the provisioning process.This request includes the policy key from the previous response. The following example shows the second Provision command sending the PolicyKey.

For more detailed analysis of EAS provisioning process & Policies, see Provisioning, Policies, Remote Wipe, and ABQ in Exchange ActiveSync on The Exchange Dev Blog.

FolderSync

Once the device is provisioned, it will send a FolderSync command to obtain the folder hierarchy of the mailbox. If you capture this FolderSync request in the ActiveSync mailbox log, you will have the folder name that correlates to the CollectionId values in future ActiveSync requests. Alternatively, see ActiveSync - Mapping a Collection ID to a Mailbox Folder to determine which folder the CollectionId represents. The following example shows the response from a FolderSync request:

Sync

After the EAS client has obtained the folder hierarchy of the mailbox from Exchange, it can begin to populate folders on the device . Windows Phone leverages a hangingSync request to retrieve data from these folder. We should however expect the first Sync request by this device to have an immediate response with new items for one or more folders. It is also important to notice the SyncKey sent by the device in this first request is 0. This is because the folders (have just been created on the device and) currently have no synchronization state. The response for each Sync request will include a new SyncKey value that the subsequent Sync request should send. The following example shows the request and response for a Sync command:

We will typically either see no status code or a status code of 1 in the response for a Sync request. Any other status code would require further investigation by reviewing the protocol document. A status code of 1 represents a successful Sync request and no status code simply means there were no changes within the heartbeat interval for the request.

Typically you will see items being added to the device in the Sync response. You can see detailed information including the sender and subject if verbose logging has been enabled on the CAS servers. The following example shows a response sending a new item to the Inbox:

ItemOperations

There are several uses for the ItemOperations command and one of the most common requests is for downloading an attachment onto the device. The request will contain the FileReference value for the attachment which can be seen in the Sync response if available. The following examples show two responses for the ItemOperations command. We can see the first response is a success and the server sending the attachment. However the second response throws an exception and has a different status code. Lookup this status code in the protocol documentfor more information on the exception.

Were you able to determine the issue? The exception within the ActiveSync mailbox log for this example does provide enough detail to know the attachment was too large. It is very important to know how to use the protocol document to look up status codes for the various ActiveSync commands.

Calendaring

Now that we have covered the most common command that will be found in the ActiveSync mailbox log (that is the Sync command), it is now time to dig a little bit deeper. One of the most common issues with ActiveSync devices is calendaring. Most ActiveSync users rely on their mobile device to have accurate calendar information so they do not miss an appointment. Calendar items can be added to a mailbox as either an appointment created by the mailbox or a meeting request sent by either the mailbox owner or another organizer.

We are going to review the life of an appointment as we find it within the ActiveSync mailbox log. This appointment will start as a meeting request sent by an organizer within the organization. The following example shows a Sync response where this appointment is first added to the device:

Here we can see the appointment has a unique ServerId value for this item on the device. We also know that the appointment is currently showing a status of tentative in the BusyStatus. This is the standard placeholder that Exchange creates in the calendar when a new meeting request is received. The following example shows the corresponding meeting request:

The complex part of this process begins when the user responds to the appointment on the device. This response results in several requests which include MeetingResponse, SendMail, MoveItems, and Sync commands. We are going to cover each of these steps to see how the commands impact the items on the device and within the mailbox.

The MeetingResponse command is in the first ActiveSync command sent by the device to accept, decline, or tentatively accept the meeting. This request does not sent the response to the organizer. The request includes the meeting request item within the Inbox the response is for while the response from the Exchange server also includes the appointment item. The following examples show the request and response for a MeetingResponse command:

The SendMail command is the response message sent back to the organizer. The following is an example of the request for a SendMail command:

The MoveItems command is sent by the device to move the meeting request item from the Inbox to the Deleted Items folder. The following example shows the request for a MoveItem command:

The Sync command is sent by the device to update the calendar item on the mailbox. This Sync request is sending a Change for the appointment to update this status from Tentative to Busy. The following example shows the request sending a change for the BusyStatus:

You may also notice another Sync command sent by the device and that the response includes an Add for the Sent Items folder. Here we are getting the meeting acceptance message from the Sent Items and adding in onto the device.

Meeting Updates

All that we just covered was the original meeting request being received by the device. That is the origin of the appointment for our example. Next we need to look at how this appointment changes as time moves forward. The next evolution in this appointment’s life is a when the organizer sends an update for a single instance of the series.

A change to a recurring appointment is called an exception and that is exactly what we will see in the ActiveSync mailbox log. The first part of the response shows us that we have a Change for an item and further down within that response we will see the exceptions. The following example shows our appointment receiving a change and the exception includes a new start time:

Wait. Our appointment has not stopped experiencing life changes. The organizer has decided to cancel an instance of this recurring appointment. The following example once again shows a change for our appointment but this time the exceptions have grown. This example was done intentionally so we can see how difficult it becomes to read these logs when an appointment has a large number of exceptions.

The good news is these exceptions are sent in the order in which they were made, so the last exception is the most recent. In our example above, the last exception shows this instance of the meeting has been canceled.

The focus has intentionally been on the Calendar item and its changes. However we cannot forget that with each change to the appointment the user also gets an updated meeting request. This means we will also see a Sync request that includes a response adding the meeting request to the Inbox. The following example shows the response adding the updated meeting request:

Just like the original meeting request for the series, the user has the ability to accept and decline the changes from the device. If you do not remember the process, don’t hesitate to jump back and take a second look. That is exactly what this article is intended to show.

SendMail

The last topic we are going to cover is sending a message from a Windows Phone device. There are two commands that we may see from an ActiveSync device when a user is sending a message. The Search command will be sent when a user types text into the To field and perform a search against the Global Address List. The following examples show a request and response for a Search command:

Then the device will send a SendMail command when the user hits the Send icon. Unless an error is encountered during this request there should be an empty response from the Exchange server. The following example shows a request for the SendMail command:

Conclusion

At this point you should have some understanding of how Exchange ActiveSync functions and what to look for in the ActiveSync mailbox log. Here are a few reminders:

• Whenever the device initiates a new item or change, the request from the device will contain this data. Whenever the change is made on the mailbox, the response from the Exchange server will contain the data.
• Windows Phone uses a hanging Sync command to wait for changes on the mailbox. This request contains a heartbeat interval which determines how long the server should wait before sending a response. A success will return a status code of 1 indicating there are changes. If there are no changes, then no status code is returned.
• An updated meeting contains all of the exceptions for that appointment and the last exception is the most recent.
• Accepting a meeting request on an EAS device is a complex process with multiple steps. It is recommended that you review this process if many users use their devices to accept meetings.
• Current versions of Exchange require a minimum search length of four characters before Exchange will perform the query.
• The SendMail command does not return a status code unless an error is encountered.

Jim Martin (EXCHANGE)

Update 11/5/2013: added a section on firewall rules to try.

Overview

When designing a site resilient Exchange Server solution, one of the required planning tasks is to determine how many transaction logs are generated on an hourly basis. This helps figure out how much bandwidth will be required when replicating database copies between sites, and what the effects will be of adding additional database copies to the solution. If designing an Exchange solution using the Exchange Server Role Requirements Calculator, the percent of logs generated per hour is an optional input field.

Previously, the most common method of collecting this data involved taking captures of the files in each log directory on a scheduled basis (using dir, Get-ChildItem, or CollectLogs.vbs). Although the log number could be extracted by looking at the names of the log files, there was a lot of manual work involved in figuring out the highest the log generation from each capture, and getting rid of duplicate entries. Once cleaned up, the data still had to be analyzed manually using a spreadsheet or a calculator. Trying to gather data across multiple servers and databases further complicated matters.

To improve upon this situation, I decided to write an all-in-one script that could collect transaction log statistics, and analyze them after collection. The script is called GetTransactionLogStats.ps1. It has two modes: Gather and Analyze. Gather mode is designed to be run on an hourly basis, on the top of the hour. When run, it will take a single set of snapshots of the current log generation number for all configured databases. These snapshots will be sent, along with the time the snapshots were taken, to an output file, LogStats.csv. Each subsequent time the script is run in Gather mode, another set of snapshots will be appended to the file. Analyze mode is used to process the snapshots that were taken in Gather mode, and should be run after a sufficient amount of snapshots have been collected (at least 2 weeks of data is recommended). When run, it compares the log generation number in each snapshot to the previous snapshot to determine how many logs were created during that period.

Script Features

Less Data to Collect

Instead of looking at the files within log directories, the script uses Perfmon to get the current log file generation number for a specific database or storage group. This number, along with the time it was obtained, is the only information kept in the output log file, LogStats.csv. The performance counters that are used are as follows:

Exchange 2013:

MSExchangeIS HA Active Database\Current Log Generation Number

Exchange 2007/2010:

MSExchange Database ==> Instances\Log File Current Generation

Note: The counter used for Exchange 2013 only contains the active databases on that server. The counter used for Exchange 2007/2010 contains all databases on that server, including passive copies. To only get data from active databases on an Exchange 2007/2010 server, make sure to manually specify the databases for that server in the TargetServers.txt file.

Multi Server/Database Support

The script takes a simple input file, TargetServers.txt, where each line in the file specifies the server, or server and databases to process. If you want to get statistics for all databases on a server, only the server name is necessary. If you want to only get a subset of databases on a server (for instance if you wanted to omit secondary copies on an Exchange 2007 and 2010 server), then you can specify the server name, followed by each database you want to process.

Built In Analysis Capability

The script has the ability to analyze the output log file, LogStats.csv, which was created when run in Gather mode. It does a number of common calculations for you, but also leaves the original data in case any other calculations need to be done. Output from running in Analyze mode is sent to multiple .CSV files, where one file is created for each database, and one more file is created containing the average statistics for all analyzed databases. The following columns are added to the CSV files:

• Hour: The hour that log stats are being gathered for. Can be between 0 – 23.
• TotalLogsCreated: The total number of logs created during that hour for all days present in LogStats.csv.
• TotalSampleIntervalSeconds: The total number of seconds between each valid pair of samples for that hour. Because the script gathers Perfmon data over the network, the sample interval may not always be exactly one hour.
• NumberOfSamples: The number of times that the log generation was sampled for the given hour.
• AverageSample: The average number of logs generated for that hour, regardless of sample interval size. Formula: TotalLogsCreated / NumberOfSamples.
• PercentDailyUsage: The percent of a full days’ worth of logs that the AverageSample value for that hour accounts for. Formula: (AverageSample / AverageNumberOfLogsPer24Hours) * 100.
• AverageSamplePer60Minutes: Similar to AverageSample, but adjusts the value like each sample was taken exactly 60 minutes apart. Formula: (TotalLogsCreated / TotalSampleIntervalSeconds) * 3600 * 24.
• PercentDailyUsagePer60Minutes: Similar to PercentDailyUsage, but adjusts the value like each sample was taken exactly 60 minutes apart. (AverageSamplePer60Minutes / AverageNumberOfLogsPer24Hours) * 100.

Parameters

The script has the following parameters:

• -Gather: Switch specifying we want to capture current log generations. If this switch is omitted, the -Analyze switch must be used.
• -Analyze: Switch specifying we want to analyze already captured data. If this switch is omitted, the -Gather switch must be used.
• -ResetStats: Switch indicating that the output file, LogStats.csv, should be cleared and reset. Only works if combined with –Gather.
• -WorkingDirectory: The directory containing TargetServers.txt and LogStats.csv. If omitted, the working directory will be the current working directory of PowerShell (not necessarily the directory the script is in).
• -LogDirectoryOut: The directory to send the output log files from running in Analyze mode to. If omitted, logs will be sent to WorkingDirectory.
• -MaxSampleIntervalVariance: The maximum number of minutes that the duration between two samples can vary from 60. If we are past this amount, the sample will be discarded. Defaults to a value of 10.
• -MaxMinutesPastTheHour: How many minutes past the top of the hour a sample can be taken. Samples past this amount will be discarded. Defaults to a value of 15.
• -MonitoringExchange2013: Whether there are Exchange 2013 servers configured in TargetServers.txt. Defaults to $true. If there are no 2013 servers being monitored, set this to $false to increase performance.

Usage

Run the script in Gather mode, taking a single snapshot of the current log generation of all configured databases:

PS C:\> .\GetTransactionLogStats.ps1 -Gather

Run the script in Gather mode, and indicates that no Exchange 2013 servers are configured in TargetServers.txt:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -MonitoringExchange2013 $false

Run the script in Gather mode, and changes the directory where TargetServers.txt is located, and where LogStats.csv will be written to:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -WorkingDirectory "C:\GetTransactionLogStats" -ResetStats

Run the script in Analyze mode:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze

Run the script in Analyze mode, sending the output files for the analysis to a different directory. Specifies that only sample durations between 55-65 minutes are valid, and that each sample can be taken a maximum of 10 minutes past the hour before being discarded:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze -LogDirectoryOut "C:\GetTransactionLogStats\LogsOut" -MaxSampleIntervalVariance 5 -MaxMinutesPastTheHour 10

Example TargetServers.txt

The following example shows what the TargetServers.txt input file should look like. For the server1 and server3 lines, no databases are specified, which means that all databases on the server will be sampled. For the server2 and server4 lines, we will only sample the specified databases on those servers. Note that no quotes are necessary for databases with spaces in their names.

Output File After Running in Gather Mode

When run in Gather mode, the log generation snapshots that are taken are sent to LogStats.csv. The following shows what this file looks like:

Output File After Running in Analyze Mode

The following shows the analysis for a single database after running the script in Analyze mode:

Notes

By default, the Windows Firewall on an Exchange 2013 server running on Windows Server 2012 does not allow remote Perfmon access. I suspect this is also the case with Exchange 2013 running on Windows Server 2008 R2, but haven’t tested. If either of the below errors are logged, you may need to open the Windows Firewall on these servers to allow access from the computer running the script.

ERROR: Failed to read perfmon counter from server SERVERNAME

ERROR: Failed to get perfmon counters from server SERVERNAME

Update:

After noticing that multiple people were having issues getting this to work through the Windows Firewall, I tried enabling different combinations of built in firewall rules until I could figure out which ones were required. I only tested on an Exchange 2013 server running on Windows Server 2012, but this should apply to other Windows versions as well. The rules I had to enable were:

File and Printer Sharing (NB-Datagram-In)
File and Printer Sharing (NB-Name-In)
File and Printer Sharing (NB-Session-In)

Mike Hendrickson