##Update##
Since writing the post, I have been able to obtain a copy of the hotfix described in KB2926055 and I can confirm that it does fix this issue.

I recently came across an interesting issue when attempting to log into Lync Online using Lync for Mac 2011. This was a newly installed an updated version of Lync for Mac 2011, version 14.0.7 (131205) to be exact. At first I thought I’d made a typo with my password but after a couple of attempts I knew something else was wrong. I tried a couple of other Lync accounts and still kept receiving the “Lync was unable to sign in. Please verify your logon credentials and try again. If the problem continues, please contact your support team.” error message.

I tried using manual server configuration as suggested in the “Troubleshoot sign in issues with Lync for Mac 2011 in Lync Online” article, but that didn’t make any difference either. I then tried using a different Mac with Lync for Mac version 14.0.6 and that one was able to log in without any issues. After digging into the client logs, we saw the following entry:

04/08/2014|20:48:55.286 25A:B0115000 WARN  :: GetNewWebTicket: "Got new web ticket already expired: Current time=1396954135, expire time=0"

It seems Lync for Mac 2011 tries to use a web ticket that is expired. After a bit of searching around, we found Article ID: 2927775 “Can't sign in or see contact pictures in Lync for Mac 2011 when system time zone is set to UTC+8 or an earlier time zone” which exactly describes the issue which occurs because Lync for Mac 2011 calculates the expiration time of a web ticket based on an incorrect time zone.  I was able to confirm this by changing my time zone settings which resulted in my client immediately being able to log in.

Once you have successfully logged in, you can change your time zone back to the correct configuration and you will still be able to log in. Unfortunately, this workaround does not persist across reboots or hibernations.

Article ID: 2926055 “Description of the Microsoft Lync for Mac 2011 14.0.7 hotfix” describes a hotfix that should resolve this issue, unfortunately you need to contact Microsoft Customer Support Services to obtain this hotfix and I haven’t been able to obtain it yet. I have logged the appropriate service request and will update this post once I have tested it.

With the correct DNS configuration, I haven’t found the need to use manual server configuration as suggested in numerous support articles. I find that the default configuration works just fine.

I also wanted to thank for my colleague, Lync MCM Aidan Freeman for helping me troubleshoot this issue.

Yesterday I wrote a post noting the lack of any warning on the Exchange 2013 SP1 download or description page about the bug that affects environments that make use of third-party or custom-developed transport agents. Tony Redmond also published a similar post on windowsitpro.com. I noticed earlier today that Microsoft have updated the relevant page with a note to acknowledging the bug:

Thanks Tony Redmond and Microsoft for making that happen! My comments about thorough planning and testing before deploying SP1 in your production environment still apply!

The Exchange Team announced the release of Exchange 2013 SP1 in late Feb and while SP1 introduced some great new features and functionality like Windows Server 2012 R2 support, it didn’t take long for customers to start reporting transport issues after the update. To their credit, Microsoft responded quickly to address these issues and released KB 2938053. The issue affected environments that make use of third-party or custom-developed transport agents, typically in the form of anti-virus or disclaimer software.

All good then? Well, yes and no.. If you were affected by the issue you can now download the relevant PowerShell script that corrects a formatting error in the configuration files that govern the transport extensibility built into Exchange Server 2013 and issue will be resolved. If you are about to update your Exchange 2013 environment to SP1 you should note that this fix has not been included in the SP1 download and a permanent fix for this will only be delivered in Exchange Server 2013 CU5. There also doesn’t appear to be any warning about this issue on the any of the SP1 pages on the Microsoft website so if you make use of any third-party software or custom-developed transport agents you will break your Exchange environment if you apple the SP1 update.

It is important to be aware of any applications running on your Exchange servers that may be making use of transport extensibility and as always I recommend thorough planning and testing before deploying SP1 in your production environment.

For more information about the issue, see KB 2938053

Tony Redmond has also written a great, in-depth article about this on windowsitpro.com

Every now and then I have a need to contact Office 365 support in order to help a customer resolve a particular issue. Logging a support request is easily done via the “Support” menu in the Office 365 admin portal, however it usually takes me a while to find a a contact telephone number for Office 365 support. The support engineers always have phone numbers listed in their email signatures, however these are rarely local numbers.

Earlier today, I was once again in a position where I needed to call Office 365 support and since I had to call from my mobile phone, an international number just wasn’t going to work. I finally found this link buried in some support documentation and thought I would post it here in order to help someone else out and spare myself the effort next time I need it.

http://virtualchat.support.microsoft.com/client/default.aspx?siteid=32ECF580-B446-44E5-8B4D-25F0AFE07779&scope=S&query=Support%20phone%20number

Only a couple of months to go before the Microsoft Exchange Conference 2014 (MEC) in Austin (March 31 - April 2). I’ll be attending and I am really looking forward to catching up with everyone in the community. This event truly is worth getting to - I'll prove it, I'm travelling from Australia! The first 100 sessions have already been posted here. For more info, check out http://www.iammec.com/

Let me know if you are also planning to attend, it would be great to catch up!

I recently completed a small migration for a customer using the MigrationWiz online migration tools. This wasn’t the first time I’ve used these tools, but it was the first time I’ve actually provisioned new destination mailboxes myself. I used PowerShell with a .csv file as input to automate the process of creating each mailbox, granting the correct level of access to the migration account as well as performing a few other tasks that were relevant to the particular migration.

Once I started the migration I was confused for a second when I received the following error message: “Connection did not succeed. Try again later.” The associated MigrationWiz knowledgebase article contained a few suggestions, but none of them applied to my particular situation. When trying to log into one of the test mailboxes, I noticed that it asked me to set my preferred language and time zone.. which is expected:

Once I had set these, I was able to connect and migrate data to that mailbox as expected. Obviously, I didn’t want to manually configure these settings for each mailbox and was able to use PowerShell and the Set-MailboxRegionalConfiguration cmdlet to do this for all the relevant mailboxes. Here is a very simple script that will use a .csv as input and set the regional settings for all aliases. It can easily be modified to use some other input too:

[powershell]#The users.csv should contain a Alias colum, eg
#Name,Alias,Email,Whatever
$Users = Import-Csv .\users.csv
Foreach ($User in $Users){
$Alias = $User.Alias
$Language = "en-NZ"
$DateFormat = "d/MM/yyyy"
$TimeFormat = "h:mm tt"
$TimeZone = "New Zealand Standard Time"
Set-MailboxRegionalConfiguration -Identity $Alias -Language $Language -DateFormat $DateFormat -TimeFormat $TimeFormat -TimeZone $TimeZone
}[/powershell]

The easiest way to find your desired settings it to look at a correctly set mailbox using the Get-MailboxRegionalConfiguration cmdlet:

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.