Back in 2011 I posted about the Microsoft Online Services Internet Connection Performance Test which was a tool that helped measure response times, bandwidth, and overall connection quality in preparation for consuming Microsoft Online services. The tool disappeared without warning after a while and was never replaced. A few months ago now it seems a new tool was made available, however I seem to have missed the announcement and only recently came across it. The Office 365 Fast Track Network Analysis tool is a similar web based tool that performs various connectivity tests and presents the results in a easy to read report. It looks very similar to the old speedtest.microsoftonline.com tool, but performs a few more tests:

To access the tool, simply visit the URL appropriate to your region:

• For North America use: http://na1-fasttrack.cloudapp.net/
• For Asia Pacific use: http://ap1-fasttrack.cloudapp.net
• For Europe, Middle East and Africa use: http://em1-fasttrack.cloudapp.net/

In part 1 we briefly looked at the architectural changes made to modern public folders in Exchange 2013 as well as some of the things to you may want to consider as you prepare to migrate you public folders to Exchange Online. In this post we will step through the actual migration process in detail.

Let’s firstly take a look at the migration scripts. I typically place all these scripts in the same folder, c:\pfmigration for example. You should have the following scripts downloaded:

• Export-PublicFolderStatistics.ps1 - This script creates a .csv file that contains a folder name-to-folder size mapping.
• PublicFolderToMailboxMapGenerator.ps1 - This script uses the mapping file to create a public folder-to-mailbox mapping file which is also a .csv file.
• Export-MailPublicFoldersForMigration.ps1 - This script exports the mail-enabled public folder objects from the on-premises organization’s Active Directory into a .xml file.
• Import-MailPublicFoldersForMigration.ps1 - This script imports the mail-enabled public folder objects into Exchange Online.

Note: These scripts also have support files with a .psd1 extension, it is important that these support files are placed in the same folder.

Before starting the migration process, you should confirm that there are no existing public folder migration requests in Exchange Online. These would need to be removed before you can continue, but it is important to first understand why there are already there before removing them. You can easily see if there are any existing request by running the following cmdlet in Exchange Online:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

The first step in the migration process is to ensure that mail-flow to mail-enabled public folders will continue to work. The steps required to do this will depend on your configuration. If you already have an Exchange Hybrid configured (as I do), you will most likely not need to do anything as the Hybrid Configuration Wizard will take care of this step.

Next it is time to start using the migration scripts. We start with the Export-PublicFolderStatistics.ps1 script to create our name-to-folder size mapping file. This script is run on the legacy public folder server:

Export-PublicFolderStatistics.ps1 

Once we have our size mapping file, we can run the PublicFolderToMailboxMapGenerator.ps1 script to create the public folder-to-mailbox mapping file which is used to calculate the correct number of public folder mailboxes that will be required in Exchange Online. This script is run on the legacy public folder server:

PublicFolderToMailboxMapGenerator.ps1

Note: The parameter is used to size your public folder mailboxes in Exchange Online. In my example I have used 10 GB (or there about!) Public folders in Exchange Online can be a maximum of 50 GB, however I would recommend leaving enough room for growth.

I was having a discussion with a colleague of mine last week about public folder migration, more specifically how to selectively migrate only certain public folders. In the interest of full disclosure, I have not tested this (yet!), but in theory it should work. If you were to edit the size mapping file in Excel, you will notice that it contains two columns: ‘FolderName’ and ‘FolderSize’. Remove all the entries for folders that you don’t want to migrate before running the PublicFolderToMailboxMapGenerator.ps1 script and complete the rest of the process as documented. If you have tried this and have some feedback, let me know. I hope to be able to test it soon.

Moving on.. once we have our mapping files created, we should export our mail enabled public folders on our legacy public folder server:

Export-MailPublicFoldersForMigration.ps1

Next, we can connect to Exchange Online and create our new public folder mailboxes. The first public folder mailbox that is created will be the primary hierarchy mailbox and it must be created in ‘HoldForMigration mode’. This public folder mailbox should also be excluded from the serving hierarchy so that the public folders won’t be available to Exchange Online users.

New-Mailbox -PublicFolder -HoldForMigration:$true -IsExcludedFromServingHierarchy:$true

We should also import our mail enabled public folders:

Import-MailPublicFoldersForMigration.ps1

We are now ready to submit the migration request, but before we do, let’s gather all the required information for the New-PublicFolderMigrationRequest cmdlet:

First we need our Outlook Anywhere hostname and authentication method:

Get-OutlookAnywhere | Format-List Identity, ExternalHostName, IISAuthenticationMethods

We also need the LegacyExchangeDN of the administrator mailbox:

Get-Mailbox | Format-Table LegacyExchangeDN

Lastly, we need the ExchangeLegacyDN of the legacy public folder server:

Get-ExchangeServer –Identity | Format-Table ExchangeLegacyDN

Given the length of the cmdlet and parameters, I recommend using variables. Using the information we have gathered, we can easily do this:

$OAHostname =

$Csv = Get-Content c:\PFMigration\pf2mbx.csv -Encoding Byte

$OnPremCred = Get-Credential

$Rmldn =

$Rpfsldn =

We can then run the New-PublicFolderMigrationRequest cmdlet using these variables. You’ll know that the command started successfully when the migration request reaches a status of ‘Queued’ or ‘InProgress’:

New-PublicFolderMigrationRequest -OutlookAnywhereHostName $OAHostName -CSVData $Csv -RemoteCredential $OnPremCred -RemoteMailboxLegacyDN $Rmldn -RemoteMailboxServerLegacyDN $Rpfsldn -AuthenticationMethod

Once the migration request kicks off it will copy the public folder data and will continue running until it reaches 95% at which point it will auto suspend the request. We can monitor the progress using the Get-PublicFolderMigrationRequest and Get-PublicFolderMigrationRequestStatistics cmdlets:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List Status, SourceServer, SourceVersion, BytesTransferred, ItemsTransferred, PercentComplete, Message

In order to complete the migration request, we need to arrange downtime or a service outage as there will be period while the last bit of data is transferred where public folders will be unavailable to end users. The amount of downtime depends on how much new content has been generated since the migration was suspended. In large environments with a lot of changing content, I would recommend running the Resume-PublicFolderMigrationRequest cmdlet. This cmdlet can be run as often as required and will merely copy any new content and auto suspend at 95%, this will reduce the amount of downtime required.

Once we have scheduled a service outage and informed out end users, we need to lock the legacy public folder environment in order to prevent any further changes:

Set-OrganizationConfig –PublicFoldersLockedForMigration $true

Next we need to allow the migration request to complete, we do this by removing ‘PreventCompletion’:

Get-PublicFolderMigrationRequest | Set-PublicFolderMigrationRequest -PreventCompletion $false

We can now resume the migration request and this time it will run through to completion and not auto suspend at 95%:

Get-PublicFolderMigrationRequest | Resume-PublicFolderMigrationRequest

We monitor the request as before to verify that it has completed successfully:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List Status, SourceServer, SourceVersion, BytesTransferred, ItemsTransferred, PercentComplete, Message

Once we are happy that the migration has completed successfully, we allow the hierarchy to be served:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

The final set in the process is to set the migration as complete in the legacy environment:

Set-OrganizationConfig -PublicFolderMigrationComplete $true

It is possible to roll back the migration, however I would like to mention a few really important points about rolling back:

• The roll back process will not copy any changed data back to the legacy environment, this should be considered when deciding to roll back. It would be a really bad idea to try and roll back a change heavy environment after 3 weeks.
• Roll back will obviously require the original public folder databases to be online, I therefore recommend dismounting these for a period of time after the migration just in case you need them. This process is a lot more difficult if you delete the databases and then try and roll back.

For more information on the migration process, see the following article on TechNet:

• Migrate Legacy Public Folders to Exchange Online

I’ve been meaning to get this series published for some time now. I can’t believe it is almost 2 months since TechEd Australia 2013! During my session, I briefly covered modern public folders and how to migrate them to Exchange Online. My aim is to build on that session with a couple of posts that run through the entire process of migrating legacy public folders to Exchange Online. This first post will provide an overview of modern public folder architecture as well as some of the planning and preparation required prior to the migration.

I’m sure by now everyone is aware that in Exchange 2013 public folders were re-engineered using mailbox infrastructure to take advantage of the existing high availability and storage technologies of the mailbox database. Public folder architecture uses specially designed mailboxes to store both the public folder hierarchy and content. This also means that there is no longer a public folder database and high availability for the public folder mailboxes is provided by a DAG. Let’s briefly look at the new architecture:

The main component of public folders are the public folder mailboxes, which can reside in one or more mailbox databases. Public folder mailboxes can be either ‘Primary’ or ‘Secondary’. The primary hierarchy mailbox is the 1 writable copy of the public folder hierarchy. The public folder hierarchy is copied to all other public folder mailboxes, but these secondary copies are read-only copies. The public folder hierarchy contains the folders’ properties, organizational information and tree structure. Public folder content can include email messages, posts, documents, and eForms. The content is stored in the public folder mailbox but isn’t replicated across multiple public folders mailboxes. All users access the same public folder mailbox for the same set of content.

 

Because there is only 1 writable copy of the hierarchy, it is necessary to synchronize changes to other mailboxes when they are made. Hierarchy synchronization takes place as follows (as illustrated in the diagram above):

1. Let’s say for example a client connects to a secondary public folder mailbox to access content (Folder 5) and
2. Then that client creates a new public folder (Folder 6 in the example)
3. The request will be proxied to the primary public folder mailbox where it is written to public folder hierarchy
4. Public folder hierarchy synchronisation is triggered immediately to content mailbox
5. The public folder hierarchy is updated on all public folder mailboxes. This takes place after 15 mins for mailboxes with connected users and after 24 hrs for mailboxes with no connected users.

In order to move legacy public folders to Exchange Online, you need at least Exchange 2007 SP3 RU1 or Exchange 2010 SP3 and there are a few other considerations you may want to take note of:

• There is no coexistence between legacy and modern public folders, the migration is a all at once ‘cutover’ migration
• All mailboxes must be on Exchange 2013 and/or Exchange Online prior to migration
• Migrations are PowerShell based using scripts, there is no migration wizard or GUI
• While a Exchange Hybrid Deployment is not required, it does make things easier as you do not have to manually configure message routing for mail-enabled public folders
• Public folders are migrated using Outlook Anywhere, therefore Outlook Anywhere must be published to the internet and enabled on all legacy public folder servers
• EWS clients such as Entourage 2008 EWS Edition and Outlook for Mac 2011 with mailboxes on Exchange 2013 will not be able to access legacy public folders
• Public folders that include a Backslash (“\”) in their names are not supported

You should also ensure that you have the correct permissions:

• In Exchange Online, you need to be a member of the ‘Organization Management’ role group
• In Exchange 2010, you need to be a member of the ‘Organization Management’ or ‘Server Management’ RBAC role groups.
• In Exchange 2007, you need to be assigned the ‘Exchange Organization Administrator’ role or the ‘Exchange Server Administrator‘ role. You should also be assigned the ‘Public Folder Administrator’ role and local Administrators group for the target server.

As previously mentioned, the migration is done via PowerShell. There are a few scripts that should be downloaded, these will be used during the various stages of the migration. Be sure to download the following:

• Microsoft Exchange 2013 Public Folders Migration Scripts
• Microsoft Exchange 2013 Public Folders Directory Sync Support Scripts

Finally, when preparing for a public folder migration to Exchange Online, I would highly recommend that public folders are first analyzed and classified. It is not uncommon to see public folder structures that were implemented in the early days of Exchange more than 10 years ago and are now no more than a dumping ground for old data. Often these hierarchies where designed to match an organization structure or meet business requirements that no longer exist. Exchange has come a long way since then and by taking a good look at your public folder use cases, you may find that there are better and more efficient ways to do things today.

In part 2 we’ll will run through the migration process.

In case you missed my session at TechEd Australia last week the session recording and slide deck is available on Channel 9 or by clicking here: http://cgoo.se/18TNT8Y

I’m currently working a series of posts about Public Folder migration to Exchange Online. I touched on it during the session, but will be publishing more details in the series so look out for it soon.

##Update 30 Aug 2013##

The MS13-061 security update has been re-released for Exchange Server 2013, the download links below have been updated.

##Update 15 Aug 2013##

The MS13-061 security update for Exchange Server 2013 has been pulled as it seems to cause an issue with the Content Index for mailbox databases. If you have already installed this update see KB2879739 for information on how to resolve this. This issue does not occur in Exchange 2010 or Exchange 2007.

A few hours ago Microsoft released a critical security update for all supported editions of Microsoft Exchange Server 2007, 2010, and 2013. This security update addresses vulnerabilities that exist in the WebReady Document Viewing and Data Loss Prevention features of Exchange that could allow remote code execution in the security context of the transcoding service on the Exchange server if a user previews a specially crafted file using Outlook Web App. For detailed information, see Microsoft Security Bulletin MS13-061

Microsoft recommends that customers apply the update immediately. The update can be downloaded at the following links:

• Update Rollup 11 for Exchange Server 2007 SP3
• Update Rollup 7 for Exchange Server 2010 SP2
• Update Rollup 2 For Exchange 2010 SP3
• Security Update For Exchange Server 2013 CU1
• Security Update For Exchange Server 2013 CU2

Perhaps you are planning your on-premises upgrade to Exchange 2013 or you’ve just introduced the first Exchange 2013 server into your existing Exchange 2010 environment. Welcome to coexistence! Hopefully by now you already know that the Exchange Admin Center (EAC) is the web-based management console in Microsoft Exchange Server 2013 and it replaces the Exchange Management Console (EMC) and the Exchange Control Panel (ECP), which were the two interfaces used to manage Exchange Server 2010.

So how do you access the EAC? Well.. if you had just installed a fresh new Exchange 2013 org you would simply navigate to https:///ecp in your browser. In a coexistence scenario however, doing that would redirect you to Exchange 2010 ECP and you would probably see something like this (once logged in):

The reason for this is that your mailbox is probably still located on an Exchange 2010 server. You now have two options:

1. Move your mailbox to Exchange 2013 and try again, or
2. Use the following URL: https:///ecp?ExchClientVer=15 

You should now see the Exchange 2013 Admin Center which will look something like this:

You are now able to continue configuring Exchange 2013 via the EAC.

Read more about the EAC here

Mario Tevanian (Microsoft) and I will be presenting a “Exchange 2013 Hybrid Deployments” session at TechEd Australia 2013 (3-6 September, Gold Coast) The session will provide an overview of the complete range of migration options that are available when migrating to Exchange Online and discuss the new Exchange 2013 hybrid configuration wizard. Did you know that public folders are now supported in Exchange Online? Come and learn more about modern public folders and how to migrate them. In this session we also share some notes from the field and highlight the recommended approach and best practices you should consider as you plan to migrate your existing Exchange environment to Exchange Online.

Room and time slot details are not available yet, but I’ll share them as soon as I know what they are. The session code is: EXL314. See you there!

Microsoft Application Request Routing (ARR) is a proxy-based routing module for IIS that forwards HTTP requests to content servers based on HTTP headers, server variables, and load balance algorithms. After my recent posts on reverse proxy servers and Exchange Server I received a few emails about using ARR as a reverse proxy for Exchange Server. The Exchange Team recently released some guidance on how to achieve this on their blog for those of you who are interested in this setup, here is a link to the post.

In March this year I wrote a post entitled “Exchange Server and the Reverse Proxy”. I had many similar conversations with peers and customers about the topic, and at the time my intention was twofold:

1. Question the ‘old school’ notion that Exchange services published to the internet are only secure if a reverse proxy is used;
2. Provide a high-level list of potentially suitable solutions for customers planning new deployments who felt they still needed a reverse proxy.

I’ve received many comments and emails about that post and have been planning to put together this follow-up for some time now so it was a happy coincidence when the ever entertaining (and deceptively brilliant!) Greg Taylor recently posted about the same topic on the Exchange Team blog. I’m sure he won’t mind me ‘borrowing’ some of this content, it is not my intention to take anything out of context so feel free to read this entire post here. A couple of things that really stand out in his post are:

“Here are some interesting Exchange-related facts to help further cement the idea I’m eventually going to get to.

1. We do not require traffic to be authenticated prior to hitting services in front of Exchange Online.
2. We do not do any form of pre-authentication of services in front of our corporate, on-premises messaging deployments either.
3. We have spent an awfully large amount of time as a company working on securing our code, writing secure code, testing our code for security, and understanding the threats that exist to our code. This is why we feel confident enough to do #1 and #2.
4. We have come to learn that adding layers of security often adds little additional security, but certainly lots of complexity.
5. We have invested in getting our policies right and monitoring our systems.”

“Do I think everyone should throw out that TMG box they have today and go firewall commando? No. not at all. I think they should evaluate what it does for them, and, if they need it going forward. If they do that, and decide they still want pre-auth, then find something that can do it, when the time to replace TMG comes.

You could consider it a sliding scale, of choice. Something like this perhaps;”

The recent release of Windows Server 2012 R2 Preview brings with it the new Web Application Proxy role. Web Application Proxy is a new Remote Access role service in Windows Server 2012 R2 Preview that provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy. My esteemed colleague Marc Terblanche has put together a couple of great posts on the Kloud Solutions blog about the Web Application Proxy role, check them out here:

• Windows 2012 R2 Preview Web Application Proxy – Exchange 2013 Publishing Tests
• Publish Lync 2013 with 2012 R2 Preview Web Application Proxy

I also wanted to post an update on the Apache/mod_proxy solution I mentioned in my previous post. Free time (aka lab time) has become somewhat limited lately so I haven’t been able iron out all the issues with the solution yet, but I recently came across an open source project that looks very promising. The guys at Vulture seem to have created exactly what I was trying to do in a much more elegant way. They’ve put together a web application firewall using open source components like Apache and mod_security and have even added a configuration web gui to it. Vulture does pre-authentication using a number of authentication providers and also provides other features like load balancing. I have not tested it myself (yet!) but if this interests you, check it out here: http://www.vultureproject.org/ – The documentation is in French but seems to translate reasonably well..

Ross Smith IV announced the release of Exchange Server 2013 RTM Cumulative Update 2 (CU2) on the Exchange Team blog earlier today.

In addition to bug fixes, Exchange 2013 RTM CU2 introduces enhancements in the following areas:

• Per-server database support - increased from 50 to 100 databases
• OWA Redirection - adds single sign-on when FBA is used on source and target
• High Availability - introduces the new "DAG Management Service"
• Improvements to Managed Availability
• Cmdlet Help - introduces Update-ExchangeHelp cmdlet to update local Shell help
• OWA Search Improvements
• Malware Filter Rules - introduces the –MalwareFilterRule cmdlets

He also announced that the Exchange Product Group is in the final validation stages to support Windows Azure for Witness Server placement. There has been much talk about leveraging Windows Azure for things like Witness Servers lately, so this is quite an exciting announcement for many organizations.

Exchange 2013 CU2 does include schema changes so I highly recommend reading the upgrading/deploying section before attempting to implement it. The download is available here.