This is the official blog of the Exchange Server Product Group. All content here is considered authoritative and supported by Microsoft, unless otherwise specified.
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
Just over a year ago on March 8, 2013 the first version of OffCAT was released. In the 12 months that followed, the OffCAT team released a new version (v1.1), published numerous rule file updates that included over 260 new detection rules and over 250 bug fixes/feature improvement. And now with over 100,000 customer downloads under our belts, we have released the very latest version (v1.2).
There are many new features, diagnostic rules, and fixes in OffCAT v1.2, and we hope you will quickly install v1.2 to see what has been added.
Symptoms-based issue report
To improve the usability of the report containing the list of detected issues, the default report view is now arranged by symptom. Every issue that could be detected by OffCAT was tagged with 1 or more symptoms so you can quickly find relevant issues.
If you want to just see the symptoms closest to those reported by your customer, click the Filter control to enable/disable the symptoms you want shown in the report.
To quickly turn off the filter, click the ‘undo’ Filter control.
Link to open the CalCheck.log file
If there are issues found by CalCheck during a scan, the scan report will contain an ‘Open CalCheck log’ link if the CalCheck.log file is found in the %Temp% folder. This will allow you to quickly review additional details on problem meetings found only in the CalCheck.log file.
Office Alerts
At the bottom of the Scan page is a new space dedicated to important news items all customers should see. This will help keep customer informed about updates, breaking news, support lifecycles, etc.
These alerts function just like issues shown in the OffCAT report – click on an alert to see an expanded description and a link to an article that provides more details.
KMS client activation toolbox
The Scan page also includes a ‘KMS client activation’ link that will take you to a new section of OffCAT that provides a large array of tools for troubleshooting KMS client activation issues.
This link takes you to the new KMS Client screen where you can solve just about every known KMS activation problem.
Why run Ospp.vbs when you can get the same information, and more, using the convenient UI provided by OffCAT.
Export to .zip
If you are reviewing OffCAT scans from other users you will probably want them to use this new export option as their OffCAT results may contain errors or warnings for issues found by CalCheck. These errors and warnings refer you to the CalCheck.log file and you will have this log file only if the user exported their OffCAT report using the .zip option.
Drag and drop support for importing scans
Don’t bother clicking ‘Import scan’ and then browsing for the .xml file you want to review, just drag and drop it onto the ‘View or Import Scan’s screen to see the report in seconds. We think this will be a time-saver for people that import scans on a regular basis.
Improved scan management
To help you keep a large list of scans manageable, the ‘View or Import Scan’s screen has added several new features: searchable scan list, one-click delete, and multi-select controls (to improve scan deletion).
If you have a large list of scans on the View or Import Scans page, search for them using the search box to the left of the magnifying glass icon.
Hover over any scan in the list on the View or Import Scans screen and then click the red ‘X’ on the far right to delete the scan with one click.
In earlier versions of OffCAT your options for deleting scans were either one-by-one or ‘Delete all’. In OffCAT v1.2 you can select one or more scans in the list using the control to the left of each scan and then click ‘Delete selection’ to delete the selected items.
Updated list of resources for Office 365 users
Click the Office 365 Resources link in the left panel to see the updated list of most useful resources for troubleshooting Office 365 issues.
For complete details on all the new features, please check out the updated ReadMe file that is in the \Microsoft OffCAT folder or on the Download site.
As in earlier versions of OffCAT, there are two ways to install v1.2 from the Microsoft Download site.
Most people install OffCAT using the OffCAT.msi file from the Microsoft Download site. If you installed OffCAT v1.0 or v1.1 this way, here is the quickest way to install OffCAT v1.2:
1. Start your currently installed version of OffCAT. 2. When you see the following prompt (assuming you have ‘Check for updates on startup’ enabled), select the ‘Update the tool in place’ option. If you do not see this prompt, click OffCAT Updates in the left panel of OffCAT and then click ‘Check for updates now’. The OffCAT.msi file from the Microsoft Download site will be downloaded and launched, ready for you to complete the installation. The setup process for OffCAT v1.2 automatically removes earlier versions of OffCAT, so there’s no need to remove OffCAT before updating to v1.2. 3. Then, after the update is finished, launch OffCAT from the shortcut on the Start menu/screen.
1. Start your currently installed version of OffCAT.
2. When you see the following prompt (assuming you have ‘Check for updates on startup’ enabled), select the ‘Update the tool in place’ option.
If you do not see this prompt, click OffCAT Updates in the left panel of OffCAT and then click ‘Check for updates now’.
The OffCAT.msi file from the Microsoft Download site will be downloaded and launched, ready for you to complete the installation.
The setup process for OffCAT v1.2 automatically removes earlier versions of OffCAT, so there’s no need to remove OffCAT before updating to v1.2.
3. Then, after the update is finished, launch OffCAT from the shortcut on the Start menu/screen.
If you ‘installed’ an earlier version of OffCAT by extracting the files included in the .zip file download, you can use the following steps to get OffCAT v1.2 onto your computer.
1. Locate and delete the folder containing the OffCAT files extracted from the earlier version .zip file. 2. Go to the OffCAT download page and then select OffCAT.zip when prompted to select your download file(s). 3. Extract the files from OffCAT.zip into a new folder. 4. Launch OffCAT v1.2 using OffCAT.exe in this new folder.
1. Locate and delete the folder containing the OffCAT files extracted from the earlier version .zip file.
2. Go to the OffCAT download page and then select OffCAT.zip when prompted to select your download file(s).
3. Extract the files from OffCAT.zip into a new folder.
4. Launch OffCAT v1.2 using OffCAT.exe in this new folder.
If you do not want users to manually run OffCAT you still to have the option to scan their computers by running the command-line version of OffCAT (OffCATcmd.exe).
All of the command-line switches for OffCATcmd.exe are fully documented (with examples) in the ReadMe_OffCATv1.2.docx file.
OffCAT v1.2 continues support for group policy management over the features most people want to control in a company setting. If you are already using the group policy template from OffCAT v1.1, you do not need to make any changes. However, if you are using the group policy template from OffCAT v1.0 or you are not currently using OffCAT polices, please download OffCATv12.adm from the OffCAT page on the Microsoft Download Center.
All of the policies available for OffCAT are fully documented in the ReadMe_OffCATv1.2.docx file.
The Microsoft Download site also provides a download for a complete user's guide on OffCAT tool. It is highly recommended you read this document before installing and using the OffCAT tool:
OffCAT ReadMe (ReadMe_OffCATv1.2.docx)
Note: You do not have to download the ReadMe from the Download site as it is included in the OffCAT.msi installation and the OffCAT.zip file. However, if you want to read the documentation before installing OffCAT, then you can download it.
Greg Mansius
Let’s say you are in process of removing the last copy of a mailbox database or uninstalling an Exchange server and run into the following error message:
“This mailbox database contains one or more mailboxes…”
You check again and again but can’t find a mailbox on the server being uninstalled or the database you are deleting, but the error continues haunting you!!
Sounds familiar? Ran into this before? Read on!
Let’s take the example of DB2, a database present on an Exchange Server 2013 that I am trying to remove and am getting the error:
As suggested by the error message, I verified for the presence of all sorts of possible mailboxes one can create, namely normal user mailboxes, arbitration mailboxes, public folder mailboxes and archive mailboxes.
Checking for regular mailboxes reveals nothing:
Checking for Archive mailboxes reveals nothing:
Checking for public folder mailboxes reveals, you guessed it, nothing:
Finally, checking for Arbitration mailboxes gives similar results:
Still, the removing mailbox database continues failing with same error. What to do? Do I need a flamethrower?
If you are using Exchange 2013, you can use the Remove-MailboxDatabase as it indicates the DN of the user that still has mailbox on the database, but only when -Verbose parameter is specified. Like so:
If you do not have Exchange Server 2013, don’t despair…
Another possibility is that the database you’re trying to remove is an Archive Database for a mailbox residing on a different mailbox database.
The following command helps you list mailboxes using a specific database as Archive Database:
Get-Mailbox | where {$_.ArchiveDatabase -eq "<databaseName>"}
Here’s the output from my example:
Aha! Mystery solved! So, I just moved the archive mailbox to another database:
…And the database could now be removed after the move was complete.
We realize that the experience here is not ideal and the relevant team is aware. In the meantime, hope this helps some of you.
Bhalchandra Atre
This article is part 3 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning.
Over the last several months, we have routinely fielded questions on how various clients connect to the infrastructure once Exchange 2013 is deployed. Our goal with this article is to articulate the various connectivity scenarios you may encounter in your designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2007 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2013.
Figure 1: Exchange 2007 & Exchange 2010 Multi-Site Architecture
As you can see from the above diagram, this environment contains three Active Directory sites:
To understand the client connectivity before we instantiate Exchange 2013 into the environment, let’s look at the four users.
The Autodiscover namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2010 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2010 infrastructure and retrieve configuration settings based on their mailbox’s location. The Autodiscover service on Exchange 2010 can process Autodiscover requests for both Exchange 2007 and Exchange 2010 mailboxes.
For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.
For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will connect to the Exchange 2010 RPC Client Access array endpoint (assuming one exists). Keep in mind the importance of configuring the RPC Client Access array endpoint correctly, as documented in Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations.
For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox.
For more information, see the article Upgrading Outlook Web App to Exchange 2010.
For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010.
Exchange 2013 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. As a result, Outlook Anywhere has been enabled on all Client Access servers within the infrastructure and the mail.contoso.com and autodiscover.contoso.com namespaces have been moved to resolve to Exchange 2013 Client Access server infrastructure.
Figure 2: Exchange 2013 Coexistence with Exchange 2007 & Exchange 2010 in a Multi-Site Architecture
To understand the client connectivity now that Exchange 2013 exists in the environment, let’s look at the four users.
The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2013 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2013 infrastructure and depending on the mailbox version, different behaviors occur:
For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint.
For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will still connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox.
When you have an Exchange 2013 mailbox you are using Outlook Anywhere, both within the corporate network and outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 mailboxes.
In Exchange 2007/2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013, you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the Exchange 2013 System Requirements for more information). Outlook will process the ExHTTP in order – internal first and external second.
The default Exchange 2013 internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.
In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the Exchange Deployment Assistant. Specifically, you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method.
The Exchange 2013 Client Access server’s RPC proxy component sees the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (legacy CAS or Exchange 2013 Mailbox server).
For Outlook Web App, the user experience will depend on the mailbox version and where the mailbox is located.
For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2013 no longer supports the 451 redirect response – Exchange 2013 will always proxy ActiveSync requests.
Coexistence with Exchange Web Services is rather simple.
Offline Address Book
Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.
It’s important to understand that when CAS2013 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value.But how does CAS2013 choose which legacy Client Access server to proxy the connection?
When a CAS2013 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, CAS2013 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping (yes, even Exchange 2007 servers are targeted with that user string). CAS2013 expects a response - a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, CAS2013 immediately retries to determine if the error was a transient error. If this second attempt fails, CAS2013 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), CAS2013 will attempt to determine the health state of the down CAS to determine if it is available.
The IIS log on a legacy Client Access server will contain the ping events. For example:
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 302 0 0 277 170 02014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 309 177 152014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 245 170 02014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 301 0 0 213 169 1712014-03-11 14:00:01 W3SVC1 DF-C14-02 157.54.7.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 293 194 312014-03-11 14:00:04 W3SVC1 DF-C14-02 157.54.7.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 261 170 171
If for some reason, you would like to ensure a particular CAS2010 is never considered a proxy endpoint (or want to remove it for maintenance activities), you can do so by executing the following cmdlet on Exchange 2010 (note that this feature does not exist on Exchange 2007):
Set-ClientAccessServer <server> -IsOutofService $True
All this discussion about HTTP-based clients is great, but what about POP and IMAP clients? Like the HTTP-based client counterparts, IMAP and POP clients are also proxied from the Exchange 2013 Client Access server to a target server (whether that be an Exchange 2013 Mailbox server or a legacy Client Access server). However, there is one key difference, there is no health-checking on the target IMAP/POP services.
When the Exchange 2013 Client Access server receives a POP or IMAP request, it will authenticate the user and perform a service discovery.
CAS2013 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, CAS2013 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, CAS2013 will try to locate a plaintext proxy target first, SSL next, TLS lastly.
Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2013 when coexisting with either Exchange 2007 or Exchange 2010. Please let us know if you have any questions.
Ross Smith IV Principal Program Manager Office 365 Customer Experience
Microsoft Exchange Server 2003 entered the market on September 28, 2003 and continued the great messaging and collaboration experience that Microsoft Exchange Server had provided in previous releases. As we approach April 8, 2014, we want to inform users of Microsoft Exchange Server 2003 of the opportunities you have as we near the end of support for that version of Exchange.
We have been told by a variety of customers that some of the top concerns of businesses today involve data security, compliance, eDiscovery, mobile devices use / bring-your-own-device, and IT management. While Exchange 2003 was a leader in messaging space, its decade old capabilities may not meet the needs of a modern business. Exchange Online or Microsoft Exchange Server 2013 provide an updated, modern solution that address these top concerns and provide additional capabilities to meet your business needs. In comparing versions of Exchange Server, you will quickly see all of the benefits of moving to the current version of the platform.
The process to move from Exchange 2003 to Exchange 2013 on-premises is a two-step migration. There is no native, direct migration path from Exchange Server 2003 to Exchange 2013 on premises; it must be done in stages. For an Exchange Online migration, you can use the Migration dashboard in the Exchange Admin Center (EAC) to migrate mailboxes and mail content from an on-premises messaging system (including Exchange 2003) to Exchange Online and your Office 365 organization. You can migrate mailboxes and mailbox data from Exchange 2013, Exchange 2010, Exchange 2007 and Exchange 2003, or migrate mailbox data from an IMAP messaging system.
The migration plan should address immediate needs but should also focus directly on the future of your messaging platform. Please use the information and resources below to help you make a decision that meets all of your needs.
Exchange Server Deployment Assistant: http://technet.microsoft.com/en-us/library/ee681665(v=exchg.141).aspx
Exchange 2003 - Planning Roadmap for Upgrade and Coexistencehttp://technet.microsoft.com/en-us/library/aa998186(v=exchg.141).aspx
*Many other migration references linked from this topic*
Depending on your choices in the Exchange Server Deployment Assistant you may elect to migrate to Exchange 2013 on-premises via Exchange 2010, or you may elect to migrate directly to our Office 365 hosted Exchange environment. The references linked at the end of this post provide more information on specific migration scenarios and coexistence with both Exchange 2010 and Exchange 2013.
Coexistence of Exchange 2013 and earlier versions of Exchange Server:
Exchange 2007
At this time, supported with the following versions of Exchange:
Minimum Update Rollup 13 for Exchange 2007 Service Pack 3 (SP3) on all Exchange 2007 servers in the organization, including Edge Transport servers.
The latest Cumulative Update or Service Pack for Exchange 2013 on all Exchange 2013 servers in the organization.
Exchange 2010
Exchange 2010 SP3 and latest Update Rollup on all Exchange 2010 servers in the organization, including Edge Transport servers.
Mixed Exchange 2010 and Exchange 2007 organization
Minimum Update Rollup 13 for Exchange 2007 SP3 on all Exchange 2007 servers in the organization, including Edge Transport servers..
Hybrid deployments can be configured for on-premises Exchange 2007-based organizations or later. For Exchange 2007 and Exchange 2010 organizations, at least one Exchange 2013 Client Access and one Exchange 2013 Mailbox server must be installed in the on-premises organization to run the Hybrid Configuration wizard and support Exchange 2013-based hybrid deployment functionality. We recommend combining the Exchange 2013 Client Access and Mailbox server roles on a single server when configuring hybrid deployments with Exchange 2007 and Exchange 2010 environments. All on-premises Exchange 2013 servers must have installed the latest CU or Service Pack (whichever is newer) for Exchange 2013 to support hybrid functionality with Office 365.
For a complete listing of Exchange Server and Office 365 for enterprises tenant hybrid deployment compatibility, see the requirements listed in the following table for Exchange 2013-based and Exchange 2010-based hybrid deployments.
Notes:
1 - Blocked in Exchange 2013 setup2 - Tenant upgrade notification provided in Exchange Management Console 3 - Requires at least one on-premises Exchange 2010 SP2 server4 - Requires at least one on-premises Exchange 2010 SP3 server5 - Requires at least one on-premises Exchange 2013 CU1 or greater (recommended) server
An Office 365 for enterprises tenant and administrator account and user licenses must be available on the tenant service to configure a hybrid deployment. The Office 365 tenant version must be 15.0.000.0 or greater to configure a hybrid deployment with Exchange 2013. Additionally, your Office 365 tenant status must not be transitioning between service versions. For a complete summary, see the preceding table. To verify your Office 365 tenant version and status, see Verify Office 365 tenant version and status here.
For Microsoft Premier customers who are interested in a more hands-on assisted approach, Microsoft has a workshop offering (EMRA – Exchange Migration Readiness Assessment). We know that your company relies on Microsoft for reliable and secure business communication and collaboration. To ensure your users experience optimal levels of performance and availability during the migration period, Microsoft Services has created the Migrations Readiness Assessments.
Customized for your business, the Exchange Migration Readiness Assessment will provide an in-depth analysis of Active Directory and current Exchange environment for focus on readiness for a transition Exchange Server 2010 deployment.
A final report will be provided summarizing the key findings as well as key metrics collected from the environment, capturing the state of the current environment and its overall deployment readiness.
Focused on your IT needs, the Exchange Server 2010 Migration Readiness Assessments make up a 4 day on-site engagement that prepares both your data center and IT staff for a successful migration. We created the assessment to meet your specific needs focusing on the following areas:
Microsoft Services delivers a comprehensive assessment of your current environment in preparation for a smooth migration. Exchange Server 2010 Migrations Readiness Assessment significantly reduces your exposure to costly mistakes and delays that can impact your end users’ experience with Microsoft Exchange Server 2010.
For more information about consulting and support offerings from Microsoft, contact your Microsoft Services representative or visit www.microsoft.com/services.
Understanding Upgrade to Exchange 2010http://technet.microsoft.com/en-us/library/aa998604(v=exchg.141).aspx
Understanding Upgrade from Exchange 2003 to Exchange 2010http://technet.microsoft.com/en-us/library/ff805040(v=exchg.141).aspx
Understanding Upgrade from Exchange 2003 and Exchange 2007 to Exchange 2010http://technet.microsoft.com/en-us/library/ff805036(v=exchg.141).aspx
Checklist: Upgrading from Exchange 2003 and Exchange 2007http://technet.microsoft.com/en-us/library/ff805038(v=exchg.141).aspx
Upgrading Exchange Server 2003 to Exchange Server 2007http://technet.microsoft.com/en-us/library/hh757966.aspx
Common Mistakes When Upgrading Exchange 2000/2003 To a Exchange 2007http://support.microsoft.com/kb/555854
Upgrading Exchange ActiveSync to Exchange 2010http://blogs.technet.com/b/exchange/archive/2009/12/08/upgrading-exchange-activesync-to-exchange-2010.aspx
MCS team blog: Prepare client side environment to Upgrade from Exchange 2003/2007 to Exchange 2010 http://blogs.technet.com/b/meamcs/archive/2010/12/19/prepare-client-side-environment-to-upgrade-from-exchange-2003-to-exchange-2010.aspx
Upgrade from Exchange 2003 Mailboxhttp://technet.microsoft.com/en-us/library/dd638113(v=exchg.141).aspx
How to Remove the Last Legacy Exchange Server from an Organizationhttp://technet.microsoft.com/en-us/library/bb288905.aspx
How to remove the first Exchange Server 2003 computer from the administrative grouphttp://support.microsoft.com/kb/822931
For SBS customers: Guided Walk-Through of How to Remove the Last Legacy Exchange Server from an Organization in a SBS 2003 to SBS 2011 Migrationhttp://social.technet.microsoft.com/wiki/contents/articles/2263.remove-the-last-legacy-exchange-server.aspx
How to Uninstall Exchange Server 2003http://technet.microsoft.com/en-us/library/bb125110(v=EXCHG.65).aspx
How to migrate mailbox data by using the Exchange Admin Center in Office 365http://support.microsoft.com/kb/2798131/en-gb
Outlook.com Help | How to perform an Exchange 2003 cutover migration to the Office 365 Cloudhttp://help.outlook.com/en-us/140/ms.exch.ecp.emailmigrationwizardexchangelearnmore.aspx
Outlook.com Help | How to perform an Exchange 2003 staged migration to the Office 365 Cloudhttp://help.outlook.com/en-us/140/ff959224.aspx
Microsoft Product support lifecycle information by product familyhttp://support.microsoft.com/lifecycle/default.aspx?LN=en-us&c2=730&x=15&y=9
For all of the YouTube fans, there are numerous Exchange MVP and community contributors who have published hundreds of videos with guided walk-through for Exchange 2003 migration scenarios which may be helpful to review: http://www.youtube.com/results?search_query=exchange+2003+migration+to+exchange+2010&sm=3
Chris Lineback, Ed GrantPremier Field Engineers
Whether you’re using the Exchange Server Role Requirements Calculator by Ross Smith IV or the Exchange Client Network Bandwidth Calculatorby Neil Johnson, you’ll need to provide statistics about your log file usage to determine bandwidth requirements.
Whenever I’ve done that previously, I’d pipe the directory content to a text file and then start working on it in Excel. That is quite tedious and laborious work, and to be honest; very few people would probably do it for more than one or two log sets if at all.
Then why not automate it? If it’s a question of finding files and a bit of string handling, PowerShell should be able to do it for you… And sure enough, writing the first lines of code in a Seattle hotel, the project started taking form.
The script, GetLogFileUsage.ps1, is controlled by command line inputs, if no arguments are given, the help screen will display:
By default the script will grab log files from the last 24 hours but can be set to use a specific date using the “-Date” parameter. You need to make sure that transaction log files have not been truncated by a backup in the set time window. Needless to say, this will not work with circular logging.
You can specify a single database using the “-Database <db name>” parameter, a specific server by using the “-Server <server name>” parameter, or simply just all servers in the Organization by using “-Server All”.
Important: To support the database and server parameters, the script must run in the Exchange Management Shell.
If you’re unable to run the script in EMS or you’re collecting statistics from legacy Exchange or even a non-Exchange server, you can use a path file to input servers and paths to the script. The format of the file is:
Using the path file as input will provide support for any transaction log based database, not just Exchange. So feel free to mess around with it, I’d be happy to hear how many third party products that are supported.
To use the default file “.\paths.txt”, just add the parameter “-File” or use it in combination with “-PathFile <file name>” to specify a file of your choice.
If you want to use another CSV file delimiter than semicolon, specify it on the command line using the “-Delimiter” parameter, or change it in the script if you want it to be permanent.
Depending on how many databases or servers you’ve selected, the script will run for a while until it shows the output displayed in the following screen:
This serves only as a means for you to check if the numbers look right. The “Percent” column is automatically placed in your clipboard for you to paste into Notepad (first line is blank so you need to remove it before pasting into Excel).
The pasted numbers will look like this in the Exchange Server Role Requirements Calculator (you have to select site resilient deployment to enter numbers into these cells):
And this is how it looks when used in the Exchange Client Network Bandwidth Calculator (found on the bottom far right of the “Client Mix” worksheet):
As an added bonus, a CSV file with all your log drive statistics is created for you to see if a better distribution of log files is needed to even out load on the drives.
I hope you will find this script useful and time saving when working with the calculators. Feedback and comments for improvement are more than welcome.
Karsten Palmvig Principal Consultant, MCS Denmark
This article is part 2 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning.
Unlike previous versions of Exchange, Exchange 2013 no longer requires session affinity at the load balancing layer.
To understand this statement better, and see how this impacts your designs, we need to look at how CAS2013 functions. From a protocol perspective, the following will happen:
Step 5 is the fundamental change that enables the removal of session affinity at the load balancer. For a given protocol session, CAS now maintains a 1:1 relationship with the Mailbox server hosting the user’s data. In the event that the active database copy is moved to a different Mailbox server, CAS closes the sessions to the previous server and establishes sessions to the new server. This means that all sessions, regardless of their origination point (i.e., CAS members in the load balanced array), end up at the same place, the Mailbox server hosting the active database copy.This is vastly different from previous releases – in Exchange 2010, if all requests from a specific client did not go to the same endpoint, the user experience was negatively affected.
The protocol used in step 6 depends on the protocol used to connect to CAS. If the client leverages the HTTP protocol, then the protocol used between the Client Access server and Mailbox server is HTTP (secured via SSL using a self-signed certificate). If the protocol leveraged by the client is IMAP or POP, then the protocol used between the Client Access server and Mailbox server is IMAP or POP.
Telephony requests are unique, however. Instead of proxying the request at step 6, CAS will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging components on the Mailbox server.
Figure 1: Exchange 2013 Client Access Protocol Architecture
However, there is a concern with this architectural change. Since session affinity is not used by the load balancer, this means that the load balancer has no knowledge of the target URL or request content. All the load balancer uses is layer 4 information, the IP address and the protocol/port (TCP 443):
Figure 2: Layer 4 Load Balancing
The load balancer can use a variety of means to select the target server from the load balanced pool, such as, round-robin (each inbound connection goes to the next target server in the circular list) or least-connection (load balancer sends each new connection to the server that has the fewest established connections at that time).
Unfortunately, this lack of knowledge around target URL (or the content of the request), introduces complexities around health probes.
Exchange 2013 includes a built-in monitoring solution, known as Managed Availability. Managed Availability includes an offline responder. When the offline responder is invoked, the affected protocol (or server) is removed from service. To ensure that load balancers do not route traffic to a Client Access server that Managed Availability has marked as offline, load balancer health probes must be configured to check <virtualdirectory>/healthcheck.htm (e.g., https://mail.contoso.com/owa/healthcheck.htm). Note that healthcheck.htm does not actually exist within the virtual directories; it is generated in-memory based on the component state of the protocol in question.
If the load balancer health probe receives a 200 status response, then the protocol is up; if the load balancer receives a different status code, then Managed Availability has marked that protocol instance down on the Client Access server. As a result, the load balancer should also consider that end point down and remove the Client Access server from the applicable load balancing pool.
Administrators can also manually take a protocol offline for maintenance, thereby removing it from the applicable load balancing pool. For example, to take the OWA proxy protocol on a Client Access server out of rotation, you would execute the following command:
Set-ServerComponentState <Client Access Server> -Component OwaProxy –Requestor Maintenance –State Inactive
For more information on server component states, see the article Server Component States in Exchange 2013.
If the load balancer did not utilize the healthcheck.htm in its health probe, then the load balancer would have no knowledge of Managed Availability’s removal of (or adding back) a server from the applicable load balancing pool. The end result is that the load balancer would have one view of the world, while Managed Availability would have another view of the world. In this situation, the load balancer could direct requests to a Client Access server that Managed Availability has marked down, which would result in a negative (or broken) user experience. This is why the recommendation exists to utilize healthcheck.htm in the load balancing health probes.
Now that we understand how health checks are performed, let’s look at four scenarios:
In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is operating at layer 4 and is not maintaining session affinity. The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; however, because this is a layer 4 solution, the load balancer is configured to check the health of only a single virtual directory (as it cannot distinguish OWA requests from RPC requests). Administrators will have to choose which virtual directory they want to target for the health probe; you will want to choose a virtual directory that is heavily used. For example, if the majority of your users utilize OWA, then targeting the OWA virtual directory in the health probe is appropriate.
Figure 3: Single Namespace with No Session Affinity
As long as the OWA health probe response is healthy, the load balancer will keep the target CAS in the load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for all requests associated with that particular namespace. In other words, in this example, health from the perspective of the load balancer, is per-server, not per-protocol, for the given namespace. This means that if the health probe fails, all client requests will have to be directed to another server, regardless of protocol.
Figure 4: Single Namespace with No Session Affinity - Health Probe Failure
In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is configured to utilize layer 7, meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; in this case, a health probe is configured on each virtual directory.
As long as the OWA health probe response is healthy, the load balancer will keep the target CAS in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.
Figure 5: Single Namespace with Layer 7 (No Session Affinity) - Health Probe Failure
In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is configured to maintain session affinity (layer 7), meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; in this case, the health probe is configured on each virtual directory.
Figure 6: Single Namespace with Session Affinity - Health Probe Failure
This scenario combines the best of both worlds – provides per-protocol health checking, while not requiring complex load balancing logic.
In this scenario, a unique namespace is deployed for each HTTP protocol client; for example:
Figure 7: Multiple Namespaces with No Session Affinity
The load balancer is configured to not maintain session affinity (layer 4). The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; in this case, the health probes are effectively configured to target the health of each virtual directory, as each virtual directory is defined with a unique namespace, and while the load balancer still has no idea what the URL is being accessed, the result is as if it does know.
Figure 8: Multiple Namespaces with No Session Affinity - Health Probe Failure
The downside to this approach is that it introduces additional namespaces, additional VIPs (one per namespace), and increases the number of names added as subject alternative names on the certificate, which can be costly depending on your certificate provider. But, this does not introduce extra complexity to the end user – the only URL the user needs to know is the OWA URL. ActiveSync, Outlook, and Exchange Web Services clients will utilize Autodiscover to determine the correct URL.
The following table identifies the benefits and concerns with each approach:
Exchange 2013 introduces significant flexibility in your namespace and load balancing architecture. With load balancing, the decision ultimately comes down to balancing functionality vs. simplicity. The simplest solution lacks session affinity management and per-protocol health checking, but provides the capability to deploy a single namespace. At the other end of the spectrum, you can utilize session affinity management, per-protocol health checking with a single namespace, but at the cost of increased complexity. Or you could balance the functionality and simplicity spectrums, and deploy a load balancing solution that doesn’t leverage session affinity, but provides per-protocol health checking at the expense of requiring a unique namespace per protocol.
A while back we promised an article on namespace planning and load balancing principles with Exchange 2013. We’re finally going to fulfill that promise as a series of articles. The articles will span several topics, including namespace planning, load balancing, client connectivity coexistence, and certificate planning. As the title suggests, this first article will cover namespace planning principles.
If you are like the vast majority of our customers, you already have some version(s) of Exchange deployed in your environment. Depending on the version, you may have different namespace requirements today.
In Exchange 2007 environments, at a minimum, you had two namespace scenarios:
In addition, if you deployed in a multi-datacenter environment, you most likely had additional protocol-based namespaces for each region.
Like Exchange 2007, Exchange 2010 leverages the Autodiscover service for enabling client profile changes, so that namespace exists.
For customers that upgraded from Exchange 2007 (or Exchange 2003), a new namespace requirement was introduced for coexistence – the legacy namespace, legacy.contoso.com. Though it is important to note that the legacy namespace can be called anything you choose, alderaan.contoso.com for example.
Exchange 2010 introduced additional namespace requirements, which resulted in additional complexity around namespace planning, especially for site resilient solutions:
Out of these nine namespaces, seven of them were required on certificates. The RPC Client Access namespaces were not required on the certificate because they were accessed via RPC connectivity and not via an Internet-based protocol, like HTTP.
One of the benefits of the Exchange 2013 architecture is that the namespace model can be simplified, when compared to Exchange 2010.
An example of how it can be simplified can be seen when thinking about a site resilience scenario. If you have two datacenters participating in a site resilient architecture, by replacing the Exchange 2010 infrastructure with Exchange 2013, five namespaces could potentially be removed:
There’s two reasons for this.
First, Exchange 2013 no longer leverages an RPC Client Access namespace. This is due to the architectural changes within the product - for a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. In other words, the RPC Client Access service is no longer decoupled from the store, like it was in Exchange 2010.
Second, as mentioned, CAS2013 proxies requests to the Mailbox server hosting the active database copy. This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2013 does not require the client namespaces to move with the DAG during an activation event – a CAS2013 in one Active Directory site can proxy a session to a Mailbox server that is located in another Active Directory site. This means that unique namespaces are no longer required for each datacenter (mail.contoso.com and mail2.contoso.com); instead, only a single namespace is needed for the datacenter pair – mail.contoso.com. This also means failback namespaces are also not required during DAG activation scenarios, so mailpri.contoso.com and mailsec.contoso.com are removed.
Depending on your architecture and infrastructure you have two choices:
It’s also worth mentioning that these choices are also tied to the DAG architecture.
In an unbound model, you have a single DAG deployed across the datacenter pair. This DAG has Mailbox servers in each datacenter – typically all Mailbox servers are active and host active database copies, however you could deploy all active copies in a single datacenter. Mailboxes for both datacenters are dispersed across the mailbox databases within this DAG. In this model, clients can connect to both datacenters in the event there is a WAN failure – neither datacenter’s connectivity is a boundary, hence the term unbound. It does not guarantee, however, the connectivity provides users an equal experience; meaning one connection may provide a better user experience because it has lower latency or more bandwidth.
In an unbound model, a single namespace is preferred because either datacenter can service the user request. This means that from a load balancing perspective, the CAS infrastructure in both datacenters participate in handling traffic, as seen in the following diagram:
Figure 1: Single Namespace used across Site Resilient Datacenter Pair (Unbound Model)
As a result, for a given datacenter, the expectation is that 50% of the traffic will be proxied from the other datacenter.
As its name implies, in a bound model, users are associated (or bound) to a specific datacenter. In other words, there is preference to have the users operate out of one datacenter during normal operations and only have the users operate out of the second datacenter during failure events. There is also a possibility that users do not have equal connectivity to both datacenters. Typically, in a bound model, there are two DAGs deployed in the datacenter pair. Each DAG contains a set of mailbox databases for a particular datacenter; by controlling where the databases are mounted, you control connectivity.
In a bound model, multiple namespaces are preferred, two per datacenter (primary and failback namespaces), to prevent clients trying to connect to the datacenter where they may have no connectivity. Switchover to the other datacenter is a controlled event.
Figure 2: Multiple Namespaces used across Site Resilient Datacenter Pair (bound Model)
Other namespaces are still required. Exchange 2013 takes advantage of the Autodiscover service for client profile manipulation; so the autodiscover.contoso.com namespace remains in place.
If you are planning to upgrade from Exchange 2007, a legacy namespace is required for connectivity. The legacy namespace provides connectivity for OWA, is the namespace returned in Autodiscover responses (e.g., Exchange Web Services URL), and provides access to Exchange 2007 mailboxes that exist in non-Internet facing Active Directory sites.
Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces. A split-brain DNS infrastructure enables different IP addresses to be returned for a given namespace based on where the client resides – if the client is within the internal network, the IP address of the internal load balancer is returned; if the client is external, the IP address of the external gateway/firewall is returned.
This approach simplifies the end-user experience – users only have to know a single namespace (e.g., mail.contoso.com) to access their data, regardless of where they are connecting. A split-brain DNS infrastructure, also simplifies the configuration of Client Access server virtual directories, as the InternalURL and ExternalURL values within the environment can be the same value.
In the event that you do not deploy a split-brain DNS (also known as split-DNS) infrastructure, Exchange 2013 has introduced one improvement in this area – Outlook Anywhere now supports separate internal and external namespaces.
The concept of regional namespaces has existed since OWA debuted in 1997 (can you believe OWA is almost 17 years old!?!). A regional namespace is a way for clients to connect to the Client Access endpoint that is closest to the Mailbox servers hosting the data.
Use of a regional namespace does not necessarily mean you are restricted to a bound model, either. This is because depending on your infrastructure and network capabilities, you may choose to have a dedicated namespace for each datacenter pair. For example, your company may have a set of datacenters in North America and in Europe, and due to a desire to reduce cross-region network traffic, you deploy a dedicated namespace for each region (notice that within a region, the unbound model is used):
Figure 3: Regional Namespaces
Exchange 2013 introduces significant flexibility in your namespace architecture, enabling deployment of a single unified namespace for a site resilient datacenter pair (or worldwide), or deployment of multiple namespaces. As we delve into the intricacies surrounding load balancing principles, client connectivity, and certificate planning, you will understand (hopefully) how to choose the best namespace model.
Exchange Server 2013 Service Pack 1 (SP1) is now available for download! Please make sure to read the release notesbefore installing SP1. The final build number for Exchange Server 2013 SP1 is 15.00.0847.032.
SP1 has already been deployed to thousands of production mailboxes in customer environments via the Exchange Server Technology Adoption Program (TAP). In addition to including fixes, SP1 provides enhancements to improve the Exchange 2013 experience. These include enhancements in security and compliance, architecture and administration, and user experiences. These key enhancements are introduced below.
Note: Some of the documentation referenced may not be fully available at the time of publishing of this post.
SP1 provides enhancements improving security and compliance capabilities in Exchange Server 2013. This includes improvements in the Data Loss Prevention (DLP) feature and the return of S/MIME encryption for Outlook Web App users.
These improvements help Exchange meet our customer requirements and stay in step with the latest platforms.
We know the user experience is crucial to running a great messaging platform. SP1 provides continued enhancements to help your users work smarter.
As with all cumulative updates (CUs), SP1 is a full build of Exchange, and the deployment of SP1 is just like the deployment of a cumulative update.
Prior to or concurrent with upgrading or deploying SP1 onto a server, you must update Active Directory. These are the required actions to perform prior to installing SP1 on a server.
1. Exchange 2013 SP1 includes schema changes. Therefore, you will need to execute the following command to apply the schema changes. setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms 2. Exchange 2013 SP1 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute the following command. setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
1. Exchange 2013 SP1 includes schema changes. Therefore, you will need to execute the following command to apply the schema changes.
setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
2. Exchange 2013 SP1 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute the following command.
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Once the above preparatory steps are completed, you can install SP1 on your servers. Of course, as always, if you don’t separately perform the above steps, they will be performed by Setup when you install your first Exchange 2013 SP1 server. If this is your first Exchange 2013 server deployment, you will need to deploy both Client Access Server and Mailbox Server roles in your organization.
If you already deployed Exchange 2013 RTM code and want to upgrade to SP1, you will run the following command from a command line. setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms Alternatively you can start the installation through the GUI installer.
If you already deployed Exchange 2013 RTM code and want to upgrade to SP1, you will run the following command from a command line.
setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms
Alternatively you can start the installation through the GUI installer.
Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., SP1) or the prior (e.g., CU3) Cumulative Update release.
Note: We have learned some customers using 3rd party or custom transport agents may experience issues after installation of SP1. If you experience installation issues consult KB 2938053 to resolve this issue with transport agents.
Our next update for Exchange 2013 will be released as Exchange 2013 Cumulative Update 5. This CU release will continue the Exchange Server 2013 release process.
If you want to learn more about Exchange Server 2013 SP1 and have the opportunity to ask questions to the Exchange team in person, come join us at the Microsoft Exchange Conference.
Brian ShiersTechnical Product Manager, Exchange
The Exchange team is announcing the availability of the following updates:
Exchange Server 2010 Service Pack 3 Update Rollup 5 resolves customer reported issues and includes previously released security bulletins for Exchange Server 2010 Service Pack 3. A complete list of the issues resolved in this rollup is available in KB2917508.
Exchange Server 2007 Service Pack 3 Update Rollup 13 provides recent DST changes and adds the ability to publish a 2007 Edge Server from Exchange Server 2013. Update Rollup 13 also contains all previously released security bulletins and fixes and updates for Exchange Server 2007 Service Pack 3. More information on this rollup is available in KB2917522.
Neither release is classified as a security release but customers are encouraged to deploy these updates to their environment once proper validation has been completed.
Note: KB articles may not be fully available at the time of publishing of this post.
The Exchange Team
With Exchange 2013, we released a new data loss prevention (DLP)capability based on deep content analysis that helps you identify, monitor, and protect sensitive information. We’re continually looking to expand our DLP capabilities, and today we’re bringing two new ones to you—Document Fingerprinting and Policy Tips in Outlook Web App (OWA). Both are being rolled out for Office 365 users right now, and they’ll be part of the Exchange Server 2013 SP1 release for our on-premises users (please stay tuned for more information on SP1).
Watch this short video that explains what DLP has to offer today and how the new capabilities can help your organization be more compliant.
Let’s look at these two new capabilities in more detail.
Document Fingerprinting enables you to match documents that are derived from the same template. This can be useful for organizations that frequently use standard forms or templates, for example:
To understand how this works, let’s take a look at a scenario.
Contoso Pharma is a pharmaceutical company with a research division. Employees in the research division collaborate with their peers across the company to create new products and services, and file patents to protect their intellectual property. The law firm used by the company for patent filing uses a standard template for patent applications.
Say you’re an administrator at Contoso Pharma. You can use Document Fingerprinting to define a customized sensitive information type called “Patents.” To do so, you use the new administrative interface in the Exchange Admin Center (EAC) to create a new document fingerprint. Select the file you want to fingerprint, and then select the standard template that employees use for that file, in this case, patent applications.
You create document fingerprints in the EAC by selecting the file and then the sensitive information type.
This creates a template of that kind of document, which is used to detect other documents that are derived from the template.
When you fingerprint a document, a template of that kind of document is created (1) that is then used to detect documents (2) created with it.
Continuing with our Contoso Pharma scenario, once the patent template is fingerprinted, you (as an administrator) can use the existing Exchange Transport Rules and DLP infrastructure to create a rule to detect email with sensitive information of type “Patents” and define any of the supported actions in DLP. For example, you could block emails with patent documents attached from being sent externally. If Contoso Pharma uses an outside counsel for filing patents, you can allow users to send the email with an override option from Policy Tips! (See the introduction to Policy Tips in OWA section below.)
Although the scenario above refers to patents, you can easily imagine document fingerprinting being used to detect sensitive information in many other circumstances, like a hospital fingerprinting custom forms that contain personal health information, or a tax processing agency fingerprinting the 1040 EZ or W2 forms in the U.S.A.
Document fingerprinting is just one method organizations can use to detect sensitive content. Here’s a quick guide to the different methods of detecting sensitive content and the uses of each:
Policy tips are designed to notify users in your organization when they are sending sensitive information over email. Policy Tips are similar to MailTips, and you can use them in Outlook in several different ways to help your users avoid sending sensitive information in email. For example, you can use Policy Tips to:
With this new release in the Office 365 service and Exchange Server 2013 SP1, all the rich capabilities of Policy Tips previously available in Outlook 2013 will now also be available across the OWA interfaces.
As an administrator, you have the flexibility to set these different ways of using policy tips based on your business requirements. For example, you could set up a policy to only send a notification if an email contains one or two social security numbers, but block the mail from being sent and require a business justification if an email has a spreadsheet attached that contains more than 50 social security numbers.
As of Exchange 2013 SP1, OWA and OWA for Devices will both have Policy Tips support. The experience is in line with the experience in Outlook 2013, where users see a Policy Tip based on the DLP rules set by their administrator. If you already have a DLP policy with Policy Tips turned on, they will automatically apply in OWA. That means administrators do not need to create new configurations or turn switches on for this feature to work in OWA.
When you include sensitive information in an email message, a DLP Policy Tip notifies you before you send the message.
Policy Tips in OWA also show the user what sensitive content was detected in an email; in Outlook, it also allows the user to report back to the administrator if they think the email content is not sensitive. This empowers users that are closest to the data to provide feedback on the efficacy of detecting sensitive content.
A callout displays the sensitive content that was detected in the email and allows the user to report a mistake in the detection.
Administrators can also block emails that contain a large number of sensitive content (for example, an Excel attachment with more than 50 credit card numbers). Just as in Outlook 2013, the attachment with the sensitive content is highlighted so the user can easily identify it. Depending on the organization’s policy, users can be empowered to override the policy—with the option of requiring them to include a business justification—and send the email.
Policy Tips can be set up to block users from sending a large amount of sensitive content; attachments with sensitive content are highlighted for the user.
These experiences are also replicated on all mobile devices, from Windows Phone to iOS and Android devices.
Policy Tips can be set up on the Mobile devices to educate users
Different kinds of Policy Tips can be triggered based on conditions, like the amount of sensitive data in an email. No new configuration is required to do this, if DLP in Outlook has already been enabled.
Policy Tips in Outlook 2013 are turned on when an administrator creates a rule with a action to notify the end user with a policy tip, or configures a DLP policy with such a rule. In Exchange 2013 these rules are applied on both the server and the client (that is, Outlook 2013). These same rules now get applied in exactly the same manner in OWA as well. This means that Exchange, Outlook, and OWA all share these configurations:
Different kinds of Policy Tips options can be triggered based on conditions, such as the one above where we notify the user about sensitive information but allow them to send the message.
You can defining sensitive content for Outlook and OWA when you configure a transport rule.
Custom Policy Tip configurations, like compliance URLs or customized notification texts, are applied uniformly in Outlook, OWA, and OWA for Devices.
DLP planning and implementation are crucial for most organizations, because they impact the organization as a whole and all the users who work with sensitive data. Protecting sensitive information without decreasing users’ productivity is a key principle of DLP in Office 365, and Policy Tips and Document Fingerprinting can help you do just that. We hope adding these capabilities to our DLP arsenal will help make DLP management easier for your users. Stay tuned for more news about our work in compliance.
Shobhit Sahay
Update 3/18/2014: The fix for this issue has been released and is a part of March 11 2014 update for Outlook 2013. Please see the following KB article: http://support.microsoft.com/kb/2863911.
We wanted to make certain that Exchange admins are aware of an Outlook issue which may impact your plans to move to Exchange Server 2013. As discussed in KB:2934750, Outlook 2013 customers who deployed client updates released in November and December of last year may experience a profile migration error post mailbox migration. When this occurs, it might not be possible to use normal Profile Repair options to restore connectivity. Older versions of Outlook, including Outlook 2013 without the November and December updates will function normally. An Outlook update which resolves this issue is nearing completion and being worked with priority to be released as soon as possible. The Exchange team is working closely with the Outlook team to verify the fix.
Exchange 2013 debuted last year with the ability to configure a Hierarchical Address Book (HAB) for on premises deployments.
As many of our customers are migrating and evaluating the cloud, a consistent user experience between online and on premises deployments is not just a requirement, but an expectation. As such, we are really excited to announce the availability of HAB to Office 365 users, worldwide!
Now, a tenant administrator for Office 365 is able to configure a HAB using the same commands one would in an on premises deployment.
For more information on how to configure and use a HAB, please refer to Hierarchical Address Books: Exchange 2013 Help.
We are moving some of our user mailboxes to Office 365 while keeping some in our on premises infrastructure. Are the users able to see the same HAB?
No, we are working to resolve a possible issue of the HAB being out of sync in this hybrid deployment case. A solution will be available in the near future.
Can Outlook Web App (OWA) users use the HAB?
No, browsing the HAB is available for Outlook 2010/2013 only at this time.
Paul Lo
We are excited to announce that the Exchange On-Premises TAP Program is accepting nominations!
The purpose of this post is to provide you with the opportunity to nominate your company for the Exchange On-Premises Technology Adoption Program (TAP) Program. Joining the Exchange On-Premises TAP Program provides companies with a number of advantages, such as providing input and feedback for future releases, developing a close relationship with the Exchange Product Team; receiving pre-release information about Exchange, and more.
The Exchange On-Premises TAP Program is designed to validate the next version of Exchange Server by having customers test deployments of pre-release builds of Exchange in their own production environment. This gives participants the opportunity to provide feedback to the Exchange product development team. Customers in the TAP Program are provided free support from Microsoft Customer Services and Support (CSS) for issues encountered with Exchange. Additional information on the TAP Program is discussed in this blog entry from a number of years ago, which is still quite relevant today: http://msexchangeteam.com/archive/2004/12/29/343848.aspx
What's in it for TAP Program customers?
What do I have to commit to in order to participate in the Exchange TAP Program?
What makes a good TAP Program candidate?
If you feel your Company fits what we are looking for, you can nominate yourself by filling out this form:
On-premises TAP Program self-nomination form
Note: This form is located on an Office 365 site and is for our business customers to self-nominate for inclusion in future Office pre-release programs. If you are a Microsoft representative and would like to nominate a customer you are working with, please contact us directly and we will provide appropriate guidance.
All nominations, internal and external, are reviewed and screened prior to acceptance into a program. No customers are allowed access to any pre-release downloads or information until all legal paperwork is properly executed. Nomination does not mean acceptance… not all nominees will be chosen for a program.
Thank you!
David EspinozaSenior Program Manager, Customer Experience Team
Over the last year, as more customers have gone down the path of Hybrid Migration, we have seen more questions and forum posts on the subject. When looking at the reasons for this, it seemed clear that customers are in need of some additional guidance on how and when to perform troubleshooting steps if something goes wrong.
Currently there's a wide array of troubleshooting documentation out there in the form of blog posts, KBAs and videos. Unfamiliarity with the moving parts involved in a hybrid migration can make troubleshooting tricky.
To help you with troubleshooting, we have released a new guided walkthrough (GWT) for Hybrid Mailbox moves. This link will soon be surfaced in various KB articles as well as the support ticket creation process.
The intent of this GWT is to take a tenant administrator step-by-step though the common troubleshooting tasks to solve their hybrid mailbox move issues and allow the customer to continue their deployment. We took the most common migration failure scenarios and put them into this easy to follow guide.
http://aka.ms/HybridMigrationGWT
The Hybrid Migration Troubleshooter is a tool that will continue to evolve over time. If you see any issues with the troubleshooter or think there are situations that should be added or improved, please let us know at MigrationGWT@microsoft.com.
A special thanks to all that contributed to the creation of the GWT: Kevyn Pietsch, Nagesh Mahadev, Richard Roddy, Jeff Miller, Timothy Heeney. And to the writers and KE team for assisting with collaboration and coordination efforts: Charlotte Raymundo, Dee Dee Woodward, Sharon Shen.
More GWTs for Cutover, Staged, and IMAP migration coming very soon… stay tuned!
Timothy Heeney
Perry Clarke is back to geek out with you through his blog and the Geek out with Perry video series.
In this edition, Perry is joined by a new co-host, Julia White to discuss what it looks like to run a secure service in Exchange Online. The discussion covers the investments in the data center as well as customer control features available in the service to help customers manage risks. Read the blog and check out the video to hear the full conversation.
If you want to geek out with Perry and the Exchange team join them at MEC 2014 in Austin, TX. Go to iammec.com to learn more about the event and register today.
Brian Shiers Technical Product Manager, Exchange
Update 3/5/2014: Added a note about anonymous comment moderation.
It’s been a while since we posted something related to intent and operation of this blog. Since our first post in 2004, we have worked hard to give you the latest news and upcoming details about various versions of Exchange that were “new” and “in-market” at the time. Yup, some of us have been with the blog from day one.
First and foremost, this blog is the official blog of the Exchange Product Group (the “Exchange Team”). This is the same team of program managers, developers, testers, and other engineers at Microsoft that build Exchange for both on-premises releases and for Exchange Online/Office 365. In many respects, one could think of this scenario as us creating one product and then shipping different product SKUs. While this is a bit of an oversimplification, think of it as a single code base that gets shipped to different customers in different ways. We went into some detail around explaining how this process works in our Servicing Exchange 2013 post(one of the crucial points being that the speed of innovation/engineering).
Please note that this post is not about the benefits or challenges of choosing one approach to deploying Exchange over the other. Suffice it to say that there are many different considerations organizations go through when deciding what the right approach is for them. We understand this diversity is here to stay, hence our recent post about The Road Ahead.
As always, we listen to and consider all customer feedback. It’s clear from the comments from readers of this blog that some of you feel that we are trying to deliberately push more Service-related content, with the ultimate motive being “to get everyone to Exchange Online.” And you’ve said that you want more “Exchange Team” and fewer “Office 365 Team” blog posts.
Since from engineering viewpoint, there is no difference, we plan to continue sharing engineering advancements with you about it all on this blog. Restricting this blog to on-premises content simply does not make sense, given the diversity of our customer base (on-premises, Exchange Online, hybrid mode, etc.).
Thus, in response to your feedback, we've created an On premises tag for all posts that are related to on-premises subjects, allowing you to readily view only on-premises content. Please know that if you only follow on-premises content, you might miss out on early views of product features delivered to Exchange Online first, and include those features in future on-premises releases or updates as appropriate (Rajesh’s post Development cadence in a cloud world reflects this). We believe this approach is the best way to provide a single location for all things Exchange while providing you the choice to select the types of content you feel is appropriate to your current situation. To be really clear: if a specific post applies to both on-premises as well as Exchange Online, it would be tagged as both.
For a while now, we've been considering turning off anonymous comments. It has become a bit of a necessity to go through comments posted over a typical weekend and clean off the inevitable (and creative!) comment spam. While already making tweaks to the blog, we've decided we will turn off anonymous commenting on March 1st. That will give you a bit of time to register with TechNet and keep giving us feedback, and will give us a way to keep the blog comments free of those “special offers” much easier.
Note: We have turned on anonymous comment moderation starting today (3/5/14). If you're not signed in, you will still see the comment form but comments will go into the moderation queue automatically. We do not plan to actively monitor this queue. Please register, and let us know if any issues!
We commit to keep sharing relevant content with all of you, no matter which combination of our products you are using (and even if you’re not using them <g>).
Nino Bilic
Many users rely on their smartphones and other mobile devices to access their email and calendar using Exchange ActiveSync (EAS). Any issues with mobile device access and EAS are noticed and reported immediately and a solution is expected just as quickly.
To assist you in troubleshooting EAS issues in your organization, we just released the Exchange ActiveSync Guided Walkthrough (GWT). You can use this walkthrough for troubleshooting some common EAS issues such as:
Here's what it looks like:
Figure 1: The Exchange ActiveSync Guided Walkthrough
The goal for this walkthrough is to help you scope & resolve issues on your own by providing troubleshooting steps that can be used to address most common EAS issues. The tool also helps in log collection, analysis and taking appropriate steps to address common EAS issues.
Special thanks to Sharon Shen, Sainath Vijayaraghavan, Miguel Ortiz, and Matt Bromberger for their contributions in developing this troubleshooting tool.
Jim Martin
Message trace enables administrators to trace email messages as they pass through Exchange Online or Exchange Online Protection (EOP) service. It helps you determine whether a message was received, rejected, deferred, or delivered by the service.
You’ve told us that you need to be able to trace messages older than the current period of one week. We’re excited to announce that we’re increasing the look back period for message trace in Exchange Online to 90 days!
The existing functionality of looking up messages for the last week will persist and those results will be viewable immediately. When you search for messages older than a week, the request will be submitted as an extended message trace request. After the request has been processed, the trace results will be delivered to you in a CSV file by email. An example of an extended message trace request is shown below.
We’re already rolling out this feature. Look for more details later this month.
This feature applies to Exchange Online and Exchange Online Protection services. On-premises customers have the capability to manage and search message tracking logs in Exchange Server.
Want to know more about this topic? Join the Exchange engineering team and MVPs at MEC 2014 for a chance to get your questions answered. Register today at IAMMEC.com.
Vandana Kumbla Senior Program Manager
Just 8 ½ weeks until the Microsoft Exchange Conference 2014 kicks off in Austin, Texas!
We’re putting the finishing touches on sessions, speakers, content, parties, and all of those wonderful and quirky touches that make MEC different from any other conference. If you haven’t registered yet, now is the time, because hotels are filling up fast and your chance to win rock star treatment ends on Feb 10. Here are the key things to know about MEC 2014:
When March 31st to April 2nd
Where Austin, Texas, the live music capital of the world.
Who A diverse group of folks who all share a passion for Exchange. We’ll have an all-star lineup of executive speakers, joined by planeloads of people from the Exchange engineering team, plus MVPs, partners, and customers from across the globe.
What We have 100 unique sessions planned, including new formats like Experts Unplugged sessions where you can hear experts give unscripted answers to your toughest questions, and a Future Look @ session series where upcoming Exchange features will be disclosed in detail for the first time.
Why Whether you are a MEC veteran or a first-timer, it’s the best possible way to take your Exchange skills, knowledge, and connections to the next level. Want more details? Check out www.iammec.com or watch some of the MEC 2012 keynote to get a taste of the type of experience you can only get at MEC. After you register, be sure to join the conversation on Twitter by following @MEConf and using the #iammec hashtag.
We’ll see you in Austin!
The Directory Based Edge Blocking (DBEB) feature in Exchange Online Protection (EOP) lets you reject messages for invalid recipients at the service network perimeter. DBEB lets admins add mail-enabled recipients to Azure Active Directory and block all messages sent to email addresses that aren’t present in Azure Active Directory.
If a message is sent to a valid email address present in Azure Active Directory, the message continues through the rest of the service filtering layers (anti-malware, anti-spam, transport rules). If the address is not present, the service blocks the message before filtering occurs, and a non-delivery report (NDR) is sent to the sender informing them that their message was not delivered.
Admins can manage the DBEB feature through configuration of the domain type in the Exchange admin center (EAC). The EAC exposes two domain types:
There are three ways for you to purchase Exchange Online Protection (EOP). In most ways they are the same, but there are some differences. How new features are deployed is one of the differences.
You now have the ability to change your domain type in the EAC. Once the feature has been fully deployed the messages for invalid recipients will start being rejected for domains that have been configured as Authoritative.
The default domain type for a new domain in EOP Standalone is Internal relay. This domain type allows your email messages to route through EOP and have all the rules and filtering applied to them for all recipients for each of your domains.
In order to enable DBEB you need to change your domain type to Authoritative after configuring directory synchronization and ensuring that all of your mail enabled objects are present. This changes the behavior of the service so that it rejects all messages at the network perimeter to any recipient for your domain that is not present in Windows Azure Active Directory. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.
You have always had the ability to change your domain type in the EAC. This means that you may already have synchronized your users and configured your domains as Authoritative in order for recipient blocking to occur within EOP. The difference for you is more subtle.
Currently, messages for invalid recipients enter the filtering network and are being rejected during the same process which processes your Transport Rules. With the introduction of DBEB, messages will now be blocked ahead of the Transport Rules in the messaging pipeline.
You’ll know that the deployment is complete for your organization when you see an increase in your SMTP blocked message count in the received spam report. A reporting update is coming soon that will separate the DBEB specific blocks from the other SMTP blocks, so if you have the updated report before DBEB finished deployment, you’ll see the message count in the DBEB section of the received spam report.
In FOPE Directory Based Edge Blocking (DBEB) allows you to upload a list of legitimate SMTP addresses to the service and take action based on those addresses. The only action that’s being introduced for DBEB in EOP is the equivalent of “Reject”.
We’ll migrate all enabled users that are present in the FOPE Administration Center to Office 365 as part of your transition from FOPE to EOP. This will ensure that your current list of FOPE users is present in the Windows Azure Active Directory when you’re upgraded. We strongly recommend that if you have any clean-up to do for the users currently in FOPE, you should do so prior to your upgrade. We also recommend that you configure directory synchronization with Office 365 before updating your MX record to point to EOP. The directory synchronization has built in logic to match up any existing user objects in Office 365 with their on-premises directory objects, based on properties like SMTP proxy address. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.
For each domain within your organization, the User List Source and Directory-Based Edge Blocking mode will determine the domain type used for your upgrade. If your User List Source in FOPE is configured to use Admin Center or Directory Synchronization Tool and your DBEB mode is set to Reject, your domain will be added to EOP and configured as Authoritative. All other User List Source + DBEB mode combinations will be added as Internal relay, so if you want to enable DBEB you’ll need to change this to Authoritative after your transition is complete.
Wendy Wilkes Senior Program Manager Office 365 Customer Experience
Recently, we have seen some questions about what the Update-DatabaseSchema cmdlet in Exchange 2013 is about. So I thought I would share some additional information on the subject.
The Update-DatabaseSchema cmdlet is a part of the infrastructure that we’ve built into Exchange 2013 to safely upgrade database schema in a DAG deployment. Unlike previous releases, a database schema upgrade in Exchange 2013 can only occur after all DAG members are upgraded to a version of software that supports the schema version and there is control over when the schema upgrade occurs (setting RequestedDatabaseSchemaVersion to a value higher than CurrentSchemaVersion up to the MaximumSupportableDatabaseSchemaVersion supported by all members of DAG). The RequestedDatabaseSchemaVersion of a database cannot be incremented to a value higher than the minimum of MaximumSupportableDatabaseSchemaVersion supported by any DAG member. This design prevents issues like those encountered during upgrade Exchange 2010 DAG members to post-RTM service packs and automatically upgrading database schema version when mounting database on an upgraded server (no longer able to mount on a server that has not yet been upgraded).
The initial database schema version will be based on the server version(s) deployed in the DAG. The Exchange 2013 RTM database schema version is 0.121 and can be displayed using get-MailboxDatabase or get-MailboxDatabaseCopyStatus in CU2 and later. MaximumSupportableDatabaseSchemaVersion has incremented in each CU release, so databases created with server versions after RTM may be created with a schema version higher than 0.121. Prior to CU3, the Update-DatabaseSchema cmdlet could be used to manually set RequestedDatabaseSchemaVersion value higher than CurrentSchemaVersion (version at database creation). In CU3, setup (during build-to-build upgrade) was modified to automatically request upgrade of database schema version on existing databases to MaximumSupportableDatabaseSchemaVersion (0.126) for databases created with a lower schema version. By design, the attempt to set RequestedDatabaseSchemaVersion to 0.126 only succeeds when the last member of DAG is upgraded to CU3. All database schema upgrades are serial and are performed at mount time after a RequestedDatabaseSchemaVersion value is set, so an upgrade from 0.121 (RTM) to 0.126 (CU3) will involve 5 distinct schema upgrades (transactions).
It should be noted that database schema upgrades only involve global tables in a database. There is also a schema associated with tables associated with each mailbox and a mailbox schema upgrade can modify any table associated with a mailbox. After a database schema upgrade is performed during database mount, corresponding mailbox schema upgrades can be performed on subsequent logon to a mailbox. The schema version of a mailbox can be displayed using get-MailboxStatistics and will match the database schema version after first logon occurs after database schema upgrade completes.
We internally have the ability to control the MaximumSupportedDatabaseSchemaVersion for each target environment (test, dogfood, production service, on-premises) where an Exchange Server can be deployed explicitly and only increment the value supported in an environment in a given build after we have built high confidence with that change. We progressively built high confidence in the safety of performing a schema upgrade in our test, dogfood and Exchange Online environments and completed in-place database schema upgrades in Exchange Online prior to shipping CU3. It was this validation in our production service that led to the decision to enable this automated upgrade for our on-premises customers so that they could begin to reap the benefits enabled by these schema changes. This same validation will be performed for any schema upgrades included with future CU/SP releases.
You might ask yourself at this point: what are those benefits? Since the release of Exchange 2013, we have used database schema upgrades to help tweak performance on the database level, and envision that we will continue to do so in the future. Another thing to note is that we will not be automatically incrementing the version at every release (a cumulative update or a service pack) but will change the schema only when there is a specific benefit to be had.
The following shows the cmdlets that can be used to display the schema versions supported by servers hosting each database copy, the schema version of each database, and schema version of each mailbox.
[PS] D:\data\scripts>$identity = "forest noll"[PS] D:\data\scripts>$m = get-mailbox $identity [PS] D:\data\scripts>Get-MailboxDatabaseCopyStatus $m.database | FL Identity,status,*schema*
Identity : D12 MBX Store 18\15M31Status : MountedMinimumSupportedDatabaseSchemaVersion : 0.121MaximumSupportedDatabaseSchemaVersion : 0.126RequestedDatabaseSchemaVersion :
Identity : D12 MBX Store 18\D15M41Status : HealthyMinimumSupportedDatabaseSchemaVersion : 0.121MaximumSupportedDatabaseSchemaVersion : 0.126RequestedDatabaseSchemaVersion :
Identity : D12 MBX Store 18\15M30Status : HealthyMinimumSupportedDatabaseSchemaVersion : 0.121MaximumSupportedDatabaseSchemaVersion : 0.126RequestedDatabaseSchemaVersion :
Identity : D12 MBX Store 18\D15M40Status : ServiceDownMinimumSupportedDatabaseSchemaVersion :MaximumSupportedDatabaseSchemaVersion :RequestedDatabaseSchemaVersion :
[PS] D:\data\scripts>Get-MailboxDatabase $m.database -status | FL *schema* CurrentSchemaVersion : 0.126RequestedSchemaVersion : 0.126
[PS] D:\data\scripts>Get-MailboxStatistics $m | FL *schema* CurrentSchemaVersion : 0.126
Hopefully this helps understanding what this is for!
Todd Luttinen
Exchange and Outlook have, for years, been great collaboration platforms, where our customers could share information easily with others. One of the things that came to light when a lot of our customers adopted Office 365, is that many often have trouble matching their business needs to actual features in the product (stuff they would see in user interfaces and need to configure). In a purely on-premises world, the internal helpdesk and training can help bridge that gap. For those of our customers that have moved to the Office 365 world (especially smaller organizations), this can be a bit of a challenge.
We have worked to understand what most commonly looked for (and not found!) sharing scenarios are, and have leveraged the Guided Walkthrough (GWT) framework to help guide customers to correct features they need to get them enabled, taking into the consideration various clients and editions of service they might have.
It is worth mentioning that scenarios and steps listed in these GWTs apply to both Exchange Online and on-premises Exchange Server deployments. Typically, the on-premises workflow is the same as can be found if one chooses the “Enterprise Edition” option in those GWTs. Because many of these scenarios are what end-users can accomplish, I would be interested to hear your feedback whether a purely on-premises version would be useful, seeing that on-premises organizations are likely to have resources such as internal help desks and training. Please elaborate a bit in comments if you can, in case you see the value is separate versions?
Here are the new GWTs:
It has become a bit of a tradition to thank people who worked on GWTs when we announce them, so not to disappoint, I’d like to thank: Nagesh Mahadev, Jon Bradley, Charlotte Raymundo, Jon Hoerlein, Kweku Ako-Adjei, Sharon Shen, Chen Jiang as well as Scott Vidican, Adam Dudsic and Victor Zhang (ECO).
Hope you find this useful. You can give us feedback on Exchange GWTs by either posting a comment in this post (if it is about the 5 GWT listed above) or emailing ExchGWTfeedback AT microsoft.com if it's about any Exchange GWTs.
Often times in Exchange Support we get cases reporting that the size of one or more Exchange databases is growing abnormally. The questions or comments that we get will range from “The database is growing in size but we aren’t reclaiming white space” to “All of the databases on this one server are rapidly growing in size but the transaction log creation rate is “normal”. This script is aimed at helping collect the data necessary in determining what exactly is happening. For log growth issues, you should also reference Kevin Carker’s blog post here.
Please note when working with Microsoft Support, there may still be additional data that needs to be captured. For instance, the script does not capture things like mailbox database performance monitor logging. Depending on the feedback we get, we can always look at building in additional functionality in the future. Test it, use it, but please understand it is NOT officially supported by Microsoft. Most of the script doesn’t modify anything in Exchange, it just extracts and compares data.
Note: The space dump function will stop (and then restart) the Microsoft Exchange Replication service on the target node and replay transactions logs into a passive copy of the selected database, so use this with caution. We put this function in place because the only way to get the true white space of a database is with a space dump. People often think that the AvailableNewMailboxSpace is the equivalent of whitespace, but as Ross Smith IV notes in his 2010 Database Maintenance blog “Note that there is a status property available on databases within Exchange 2010, but it should not be used to determine the amount of total whitespace available within the database. AvailableNewMailboxSpace tells you how much space is available in the root tree of the database. It does not factor in the free pages within mailbox tables, index tables, etc. It is not representative of the white space within the database.” So again, use caution when executing that function of script as you probably don’t want to bring a lagged database copy into a clean shutdown state, etc.
Before we get into an example of the script, I wanted to point out something you should always check when you are troubleshooting database growth cases – what is the total deleted item size in the database and are any users on Litigation hold.
The following set of commands will export the mailbox statistics for any user that is on Litigation Hold for a specific database and furthermore will give you the sum of items in the recoverable items folder for those users (remember we use the subfolders Versions and Purges when Lit Hold is enabled).
1. Export the users mailbox statistics per database that have litigation hold enabled
get-mailbox -database <database name> -Filter {LitigationHoldEnabled -eq $true} | get-mailboxstatistics | Export-CSV LitHoldUsers.csv
2. Import the new CSV as a variable:
$stats = Import-Csv .\LitHoldUsers.csv
3. Get the sum of Total Deleted Item Size for the Lit Hold users in the spreadsheet
$stats | foreach { $bytesStart = $_.TotalDeletedItemSize.IndexOf("(") ; $bytes = $_.TotalDeletedItemSize.Substring($bytesStart + 1) ; $bytesEnd = $bytes.IndexOf(" ") ; $bytes = $bytes.Substring(0, $bytesEnd) ; $bytes } | Measure-Object –Sum
This will give you the sum for the specific database of recoverable items for users on litigation hold. I’ve seen cases where this amount represented more than 75% of the total database size. You also want to confirm what version of Exchange you are on. There was a known store leak fix that was ported to Exchange 2010 SP3 RU1. I don’t believe the KB is updated with the fix information, but the fix was put in place, so before you start digging in too deep with the script, make sure to install SP3 RU1 and see if the issue continues.
Ok moving onto the script. What can the script do you ask? The script can do the following:
You can download the script from here.
Issue reported: “Mailbox Database 0102658021” is rapidly growing in size.
The onscreen reports that you can scroll through include the Database size details and individual reports for the Top 25 of the following: mailboxes by item size, mailboxes by DeletedItemSize, mailboxes by item count, mailboxes by deleted item count, mailboxes by associated items, Folders by size, Folders by item count, and Folders by deleted item count.
The Full XML report will be stored in the location you specified.
If you close out of the PowerShell window and wish to review the reports again, just run the script in mode 2 (quotes are optional).
Now we have a valid report at a single point in time of what's going on in the database. Since we are troubleshooting a “Database Growth” issue, we will need to wait some time for the database to grow. If you have ample space on the database drive, then I would run the report every 24 hours.
Once you ready, compile a second report of the database (same way you did the first above)
Press enter for top 25 items and the onscreen report will start scrolling through. As you can see below our database size increased on disk from 1.38 GB to 1.63 GB.
So what grew? Well now we will use Mode 3 of the script to compare the 2 XML reports. Note the second XML report in the directory:
Run the script with –mode 3. You will be prompted to enter the full file path for the original report and then the second report after the DB growth was recognized.
Once the differential is completed you will see a report that is similar to the first two reports. Keep in mind this is a DIFFERENTIAL Report, so it is reporting on how many items in a particular folder grew or how much the DB grew, etc.
As you can see above the size on disk shows 256mb. This is actually how much the database grew as we know that it went from 1.38gb to 1.63gb. If I scroll through the reports, I can see that the Administrator mailbox is where most of the growth took place (which is where I added the content).
This data can be used to tell what user(s) might be causing the additional growth. As noted earlier, we have had some “phantom” growth cases as well where we had known store leaks which is why it is imperative to make sure you have installed Exchange 2010 SP3 RU1. Its possible that you could run into that type of scenario here, but the data should support that as you would see DB on disk grow but no real growth in the mailboxes at which point you would need to engage Microsoft Support.
A quick note on the Actual Overhead value. This is calculated by taking the physical size of the database and subtracting the AvailableNewMailboxSpace, TotalItemSize and TotalDeletedItemSize. Remember that AvailableNewMailboxSpace is not the true amount of whitespace, so the actual number may be a little higher than what is reported here.
The remaining modes of the script should be pretty self explanatory.
Mode 4 – Export Store Usage Statistics just uses the built in Get-StoreUsageStatistics function allowing you to run it at a server or database level.
Mode 5 – Will search the application log for events concerning Online Maintenance Overlap and Possible Corruption, outputting them to the screen. We probably didn’t get every event listed here, so we can add events as we see them.
Mode 6 – Will search the server that it is run on for passive copies of databases. It will alert you to any that are configured as lagged copies. If you choose to run this against a passive copy to get the true white space, then it will stop the Microsoft Exchange Replication service, do a soft replay of logs needed to bring the passive copy into a clean shutdown, and then run an ESEUtil /MS against the passive copy. Once completed it will restart the Replication service.
Mode 7 – will just read in one of the XML reports created from Mode 1 and break it out into its individual component reports in CSV format.
Jesse and I decided to build this because we continue to see cases on database growth, so a special thanks to him for running with the idea and compiling the core components of the script. We both had been running our own versions of this while troubleshooting cases, but alas, his core script was better (I still got to add some of the fun ancillary components). We’d like to thank Bill Long for planting the idea in our heads as he worked so many of these cases from a debugging standpoint as well as David Dockter and Rob Whaley for their technical review.
Hopefully this helps you troubleshoot any database growth issues you run across. We look forward to your comments and are definitely open to suggestions on how we can make this better for you.
Happy Troubleshooting!
Jesse Newgard and Charles LewisSr. Support Escalation Engineers
I’ve written a few blog posts now that get into the deep technical details of Managed Availability. I hope you’ve liked them, and I’m not about to stop! However, I’ve gotten a lot of feedback that we also need some simpler overview articles. Fortunately, we’ve just completed documentation on TechNet with an overview of Managed Availability. This was written to address how the feature may be managed day-to-day.
Even that documentation doesn’t address how you respond when Managed Availability cannot resolve a problem on its own. This is the very most common interaction with Managed Availability, but we haven’t described how specifically to do so.
When Managed Availability is unable to recover the health of a server, it logs an event. Exchange Server has a long history of logging warning, error, and critical events into various channels when things go wrong. However, there are two things about Managed Availability events that make them more generally useful than our other error events:
When one of these events is logged on any server in our datacenters, a member of the product group team responsible for that health set gets an immediate phone call.
No one likes to wake up at 2 AM to investigate and fix a problem with a server. This keeps us motivated to only have Managed Availability alerts for problems that really matter, and also to eliminate the cause of the alert by fixing underlying code bugs or automating the recovery. At the same time, there is nothing worse than finding out about incidents from customer calls to support. Every time that happens we have painful meetings about how we should have detected the condition first and woken someone up. These two conflicting forces strongly motivate the entire engineering team to keep these events accurate and useful.
Along with a phone call, the on-call engineer receives an email with some information about the failure. The contents of this email are pulled from the event’s description.
The path in Event Viewer for these events is Microsoft-Exchange-ManagedAvailability/Monitoring. Error event 4 means that a health set has failed and gives the details of the monitor that has detected the failure. Information event 1 means that all monitors of a health set have become healthy.
The Exchange 2013 Management Pack for System Center Operations Manager nicely shows only the health sets that are currently failed instead of the Event Viewer’s method of displaying all health sets that have ever failed. SCOM will also roll up health sets into four primary health groups or three views.
This wouldn’t be EHLO without some in-depth PowerShell scripts. The event viewer is nice and SCOM is great, but not everyone has SCOM. It would be pretty sweet to get the same behavior as SCOM to show only the health sets on a server that are currently failed.
Note: these logs serve a slightly different purpose than Get-HealthReport. Get-HealthReport shows the current health state of all of a server’s monitors. On the other hand, events are only logged in this channel once all the recovery actions for that monitor have been exhausted without fixing the problem. Also know that these events detail the failure. If you’re only going to take action based on one health metric, the events in this log is a better one. Get-HealthReport is still the best tool to show you the up-to-the-minute user experience.
We have a sample script that can help you with this; it is commented in a way that you can see what we were trying to accomplish. You can get the Get-ManagedAvailabilityAlerts.ps1 script here.
Either this method or Event Viewer will work pretty well for a handful of servers. If you have tens or hundreds of servers, we really recommend investing in SCOM or another robust and scalable event-collection system.
My other posts have dug deeply into troubleshooting difficult problems, and how Managed Availability gives an overwhelmingly immense amount of information about a server’s health. We rarely need to use these troubleshooting methods when running our datacenters. However, the only thing you need to resolve Exchange problems the way we do in Office 365 is a little bit of event viewer or scheduled script.
Abram JacksonProgram Manager, Exchange Server
In Exchange 2010 and Exchange Online, we introduced Litigation Hold to allow you to immutably preserve mailbox content to meet long term preservation and eDiscovery requirements. When a mailbox is placed on Litigation Hold, mailbox content is preserved indefinitely.
Placing a mailbox on Litigation Hold You can place a mailbox on Litigation Hold by using the Exchange Administration Center (EAC) or the Shell (set the LitigationHoldEnabled parameter). In Exchange 2010, you can also use the Exchange Management Console (EMC) to do this.
Figure 1: Enabling Litigation Hold for a mailbox using the EAC in Exchange 2013 and Exchange Online
Figure 2: Adding a note and a URL to inform & educate users placed on Litigation Hold
Preserving items for a specified duration To preserve items for a specified period, we added the LitigationHoldDuration parameter to Exchange Online. This helps you meet your compliance needs by preserving all items in a mailbox for the specified duration, calculated from the date the item was created (date received in case of inbound email). For example, if your organization needs to preserve all mailbox data for seven years, you can place all mailboxes on Litigation Hold and set the LitigationHoldDuration to 7 years (in days).
This functionality is also available in Exchange 2013, allowing you to preserve items for a specified duration in your on-premises organization – one example of how developments in Exchange Online benefit Exchange Server on-premises.
In Exchange 2013 and the new Exchange Online, we introduced In-Place Hold, which allows more flexibility in preserving your data. Hold functionality is integrated with In-Place eDiscovery to allow you to search and preserve using a single wizard or a single cmdlet (New-MailboxSearch). You can use the In-Place eDiscovery & Hold wizard or the cmdlet to search for and preserve items matching your query parameters, known as a query-based In-Place Hold, preserve items for a specified period, known as a time-based hold, and also preserve everything indefinitely, which emulates the old Litigation Hold feature. Check out In-Place eDiscovery and In-Place Hold in the New Exchange - Part I and Part II for more info.
If you tried placing a mailbox on Litigation Hold using the EAC or the Shell, both the interfaces displayed an alert message with a recommendation to switch to the new In-Place Hold feature. This recommendation was also reflected in the product documentation.
Figure 3: Warning displayed when using Litigation Hold in the EAC in Exchange 2013
Litigation Hold isn't going away: Since the release of Exchange 2013 and the new Exchange Online, we've received a lot of questions and feedback from you about whether Litigation Hold will be removed. We want to clarify that we do not plan to remove Litigation Hold from Exchange Online or Exchange 2013. We've removed the alert from Exchange Online and in Exchange 2013 SP1. We've also removed the recommendation from Exchange Online and Exchange 2013 documentation.
You can use either hold feature to preserve mailbox data in Exchange 2013 and Exchange Online, based on your preservation needs. Here are some scenarios to help you choose between the two holds.
1 Distribution group is expanded when you run the command. Future changes to the group require running the command again. 2 Distribution groups are expanded only when you create or refresh the In-Place Hold. Future changes to the group require refreshing the search object. 3 Inactive mailboxes is an Exchange Online feature. The linked documentation is being updated to clarify you can also use Litigation Hold to make a mailbox inactive.
Bharat Suneja
Updates