During a recent batch of dry-runs, we had a whole lot of mailbox failures with issues related to folder language.  Our organization is all english, as far as we know, and would not have expected there to be any language issues.

One of Priasoft’s migration tools great features is the ability to handle foreign languages as a first class option.  To date, no other solution on the market, including Microsoft, provides any clear in-line support for environments that work with multiple languages.
However, this ability is often lost on engagements where it is well known that all users are of the same language, yet it appears that “language” issues still appear.  Some clear explanations will likely help address this case.

Folder Language versus User Language
One of the first things to understand is that there are two distinct issues related to language, even if all users are of the same language.  The first issue relates to the language of the standard folders in a mailbox (Inbox, Calendar, Tasks, etc.) and the language of a user, which determines the language a user receives server-generated messages (like NDRs and over-quota messages).
User Language
The screenshot below specifically, and only, deals with user language.  Regardless of whether the option is enabled or what value is used, the language of the standard folders is not handled by this setting.

Shows the batch wizard option for User Language migration

If it is fully validated that NO USER in the organization uses/needs a different language than others, this option can be safely ignored.  However, if a survey of users has not been performed to certify this, users may complain after a migration if server-generated messages are in a different language than expected.  It is recommended, even when all users are of the same language, to use this option.
User Language support for exchange did not arrive until Exchange 2007.  As such, mailboxes in Exchange 2003 and earlier always received the messages in the language of the server.  In Exchange 2007, the AD schema was updated to include a new attribute (msExchUserCulture) that an exchange server could query help it select an appropriate language.  Exchange 2007 did not force the use of this value and the standard dialogs for mailboxes did not present an option for language.  As such, few environments even used the feature.  The results is that many users, especially when the organization was upgraded from Exchange 2003, do not have a value to migrate.  When the above option is enabled AND when the source account DOES NOT HAVE a language setting, the language is set based on the value selected in the drop down box in the wizard feature above.  So, if all users in the organization are US English, one simply sets the drop-down to US English [en-US].  The migrator will then set that value on the user account as part of the migration.  This has become a required value in Office365 and will likely be a required value in Exchange 2016 and later, so implementing now is a prudent action.
Lastly, there is a relationship between the user language and the language of the mailbox’s standard folders.  In exchange 2007 and later, the FIRST CONNECTION TO A MAILBOX will determine the language of the standard folders.  In that moment, if a value exists for the user language, the standard folders will be created in that language.  However, due to the idiosyncrasies of AD replications, it is sometimes difficult to guarantee this result.  Setting the user language is a good idea for controlling the standard folder names, not only for migrations, but also for regular daily activities like new mailboxes for new hires.
Folder Language
In contrast to the above, the language of the standard folders of a mailbox are always analyzed and managed by the migration solution.  There is no option to disable such; and who would really want that anyway?
The issue with folder language is that there is NO setting anywhere that describes the language of the standard folders.  The reason is that before Exchange 2010, the responsibility of creating the standard folders was left to Outlook, not Exchange.  Therefore, in Exchange 2007 and earlier, there can be many mailboxes that do not even have the standard folders.  Exchange, at the time, was only responsible for 4 default folders: Inbox, Outbox, Sent Items, and Deleted Items.  Outlook was responsible for the rest and would create them the first time Outlook connected.
However, the language of those folders was determined by the regional settings on the user’s computer.  Furthermore, the language of those folders was only every applied the first time Outlook ever connected to the mailbox – so, only on the creation of the folders.  Subsequent logons by Outlook, even if the regional settings where changed would not change the folder language.  In the time of Exchange 2007 and earlier, developers and script writers were able to change the names of the standard folders directly.  This includes the Priasoft migration tools as well.  As such, prior to Exchange 2010, folder language was never an issue as the tools would simply copy the source folder names to the target – there was no real concern of care with regards to the folder language created by exchange or outlook prior to migration (or at the time of mailbox creation) because the names could be changed.
However, with Exchange 2010 things changed.  The responsibility of creating and naming the standard folders was removed from Outlook’s purview and shifted to Exchange – it was now up to Exchange to create all the standard folders, both the 4 original ‘Exchange’ folders, and the other folders originally created by Outlook.  With this change also came a severe restriction – developers and script writers could no longer directly modify or rename the standard folder names.
The only way to affect a change to the standard folder names is by powershell, using set-MailboxRegionalConfiguration.  However, this command requires supplying a language code (like en-US) and a default date/time format.  Properly executed, powershell will cause the standard folders to be renamed to match the configured language.
While calling the command is relatively simple, the issue that arises is how to get the language value to send to the command.  As mentioned previously, there is not a value on a mailbox, neither in Active Directory nor in Exchange’s databases, that define the language of the folders.  In fact, in versions of Exchange prior to 2010, it is possible for a mixture of languages on the folder names and even possible for some mailboxes to not have all the standard folders.
Priasoft, when faced with this issues years ago, realized that a table of languages had to be built.  We created 350+ mailboxes – one for each unique language that was supported by Exchange – and proceeded to force all those mailboxes to have folders created in each language.  From that, we exported the language of all the standard folders to build our internal “lookup table”.
Our internal table then consist of 10 standard folders:  Calendar;Contacts;Drafts;Deleted Items;Inbox;Notes;Sent Items;Outbox;Journal;Tasks – and in that very specific order.
Our process captures the standard folders from each source mailbox and compares those folder names to our internal list.  If a match is found, we know the language code and can call powershell to enact the change to the folder names.  However, any deviation from our internal list results in a warning message and a mailbox failure.
The subtleness of this, especially when an organization is known to be all of the same language, is that folders in the source mailbox (when the source is Exchange 2007 or earlier) may be missing or may not exactly match our table.  As an example, consider a non-user, shared or application mailbox in the source that only has the 4 Exchange default folders.  When we capture the folder names for that mailbox, the pattern of folder names will certainly not match ANY of the folder language patterns in our internal list; the result is that the application is unable to determine the language to apply to the target folders.
Visually, we would see the source folders like this:  ;;;Deleted Items;Inbox;;Sent Items;Outbox;;
See how there are several semicolons stacked together?  Those show cases where the folder we were looking for did not exist in the source mailbox.  That pattern won’t match any pattern in our pre-built list of languages.
This situation doesn’t only occur due to missing folders.  Microsoft, over the years, has changed the names of some folders for the same language.  For example, older versions of Exchange and Outlook would set the “Calendar” folder in Dutch to “Agenda”.  However, in more recent times (Exchange 2010 and later), the same folder is named “Kalendar”.  This subtle difference also causes a mailbox failure because our internal table is based on Exchange 2010’s folder names – “Agenda” is not in our internal list.

Registry Override
Realizing that this would be an immediate issue, an ability to manually set the language for such odd folder patterns was enabled.  The full detail on that override is in this document: Folder Language Overrides.
Essentially, a registry value is entered where the value name is the language value (like en-US, fr-CA, nl-NL, or something similar) and the value is one or more folder patterns.  When the migrator runs the next time, it will look to see if the source folder pattern is in our internal list, fail, and then will look to see if the pattern exists in any of the registry values configured.  If found in the registry, the language code is passed to the powershell command to set the target mailbox’s folder language.

Conclusion
The language issue is one of the quirkiest and strangest issues we have ever seen, and it has not been solved by Microsoft.  This issue even exists when migrating to Office365.  Priasoft is the only solution that provides any options to resolve this issue and to attempt to preserve the Monday Morning Experience of end users.
The use of our dry-run feature then becomes even more important to use since that process will also cause language (and missing folder) issues to surface, giving you a chance to rectify the issue – either by causing the standard folder to be created in the source mailbox, or by the use of the registry override – before the production migration ensues.
If there has been any thought of only using the dry-run on a percentage of the environment, the risk is high for folder language issues.  If nothing else, a dry-run without migrating data (zero or -1 days in the cutover pass) may be a prudent alternative just so that this issue can be exposed early.

Additional notes: The migration log, when a mailbox fails due to issues with the standard folder language, attempts to report the specific folder name pattern that caused the failure.  Due to the fact that the log file is an HTML file and is rendered as html, some characters are incorrectly rendered – most commonly with characters that have accents or decorators. If you find that the folder name pattern in the log file is suffering from the issue of conversion to html, simply open the *.hta file in notepad or another plain text editor (or right-click and choose view source).  You can then search the text for the folder name pattern and copy from there.  The underlying text should be properly preserved while viewing in a plain text editor. The folder pattern is also automatically added to the registry in an ‘unknown’ key.  It is possible then to capture the folder pattern exactly as it needs to be formatted from the registry, then pasted in a new or pre-existing language value.