Fixing Well-Known Folders Troubles (Update)

Posted on January 19, 2013 by Michel de Rooij

Last update: Version 1.47, April 17th, 2017

Depending on your migration scenario, you could be exporting and importing PST files when migrating mailbox contents from one Exchange environment to another. Now folders in PST files are just folders, i.e. Inbox is a folder just like any other folder and well-known folders lose their identification. Because of this, you may end up with unexpected additional folders in your mailbox after importing PST files.

For example, when importing a non-US mailbox PST in a mailbox set to en-US you may end up with well-known folders and their regional counterparts, e.g. “Inbox” and “Postvak In” or “Calendar” and “Agenda”.

It can also happen that you import the PST file before setting the regional settings of the mailbox. In that case the folders with the local names are already present and Exchange will generate sequence number folders, e.g. Inbox1 or Calendar1.

Note that the above behavior goes for all well-known folders, such as Inbox, Calendar, Contacts and Sent Items. Users logging in early, i.e. logging on to their mailbox while they shouldn’t, can also create these situations.

One way to fix this situation is to manually move contents to the proper location using an e-mail client, which is tedious and something you don’t want to trouble end users or admins with. Another way is to set the mailbox’ regional configuration before importing the PST file.

A better way is of course to have an Exchange Management Shell script which talks to Exchange Web Services, essentially doing the same but in an automated kind of fashion. Here’s where the Fix-MailboxFolder.ps1 script comes into play. Using Fix-MailboxFolders.ps1 requires Exchange 2010 SP1 and Exchange Web Services 1.2 (or later), which you can download here. The script hasn’t been tested yet against Exchange 2013.

Since the script will process user mailboxes, it needs to be run by a user with full mailbox permissions or impersonation permissions. Granting full mailbox access can be done on several levels, e.g. mailbox or database. For example, to grant ExAdmin Full Access on a mailbox:

Add-MailboxPermission –Identity User –User ExAdmin –AccessRight FullAccess

However, a more elegant and preferred method is to utilize impersonation through Role-Based Access Control (RBAC). Information on configuring impersonation in your Exchange environment using RBAC is found here. As an example, to grant ExAdmin permissions to impersonate all(!) users in an organization, use the following cmdlets:

New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:ExAdmin

After executing this cmdlet, the account ExAdmin can succesfully impersonate mail-enabled users. To limit impersonation to a certain subset of the user population, you could use a write scope; for more information on RBAC and write scopes, check out my past blog on this topic here.

Fix-MailboxFolders.ps1 uses the following syntax:

Fix-MailboxFolders.ps1 [-Identity]  [[-Language] ] [[-FromLanguage] ] [[-Server] ] [-ScanNumericals] [-Impersonation] []

A quick walk-through on the parameters and switches:

Mailbox is the name or e-mail address of the mailbox of which to fix the folder structure. If you specify a mailbox, the current Active Directory domain is consulted. When specifying an e-mail address, Autodiscover is used.
Language is the language to configure. If this isn’t specified, the script will use a default value of en-US;
FromLanguage is the language in which to scan for folders. When omitted, the script will use the currently configured mailbox language;
Server is the name of the Client Access Server to access for Exchange Web Services. When omitted, the script will attempt to use Autodiscover;
The switch ScanNumericals will tell the script to look for folders in the language specified by FromLanguage with sequence numbers, e.g. Inbox1 or Calendar1;
When the Impersonation switch is specified, impersonation will be used for mailbox access. When this switch isn’t used, the script will run in the context of the current user.
Credentials can be used to specify the credentials to access the mailbox or impersonator when Impersonation is specified as well.
Of the common parameters, only the Verbose switch is currently supported and will tell you exactly what the script is doing

So, for example assume you have a mailbox with en-US folders but also Dutch folders and the proper regional setting is en-US, use the following cmdlet:

.\Fix-MailboxFolders.ps1 –Identity Francis -Language nl-NL -FromLanguage us-EN –Impersonation

To fix the folders of an Office 365 mailbox, connect remotely to an Exchange Online session, and run the script using the e-mail address of the mailbox, specifying credentials optionally in combination with impersonation with sufficient permissions.

If you want to fix the folders of multiple mailboxes you can use a CSV file. The CSV needs to contain at least the Mailbox, but can optionally settings for Language and FromLanguage since the script will accept both through the pipe.

A sample of how the csv could look:

Mailbox,Language,FromLanguage
francis,en-US,nl-NL
philip,en-US,nl-NL

The cmdlet should then be something like:

Import-Csv .\Users.csv | .\Fix-MailboxFolders.ps1 -Language en-US -ScanNumericals -Impersonation –Verbose

Should you be running this in a resource-forest deployment, the script will by default try to retrieve the e-mail address of the specified mailbox – assuming you didn’t enter an alias instead of an e-mail address – in the current domain. You can override that by modifying the line which reads:

$ADSearch= New-Object DirectoryServices.DirectorySearcher( [ADSI]””)

$ADSearch= New-Object DirectoryServices.DirectorySearcher( [ADSI]”dc=user,dc=contoso,dc=com”)

where user.contoso.com is the distinguished name of your account forest.

Be advised that the script currently only contains en-US and nl-NL settings; you need to add additional language settings to the $LanguageInfo structure. The $LanguageInfo structure contains localized names for each of the well-known folders and has the following format.

"en-US"= @{ 
     "Inbox"="Inbox"; 
     "SentItems"="Sent Items"; 
     "Notes"="Notes"; 
     "Drafts"="Drafts"; 
     "DeletedItems"="Deleted Items"; 
     "Outbox"="Outbox"; 
     "Contacts"="Contacts"; 
     "Calendar"="Calendar"; 
     "Tasks"="Tasks"; 
     "JunkEmail"="Junk E-mail"; 
     "Journal"="Journal"; 
     "DateFormat"="M/d/yyyy"; 
     "TimeFormat"="h:mm tt" 
};

To increase readability I’ve created one setting per line in the script; everything could be stored on a single line of course. The values DateFormat and TimeFormat should be provided in a valid format for the related regional setting. Depending on feedback and demand, I can add additional languages to future versions of the script.

You can download the script from TechNet or GitHub.

67 thoughts on “Fixing Well-Known Folders Troubles (Update)”

Sysadminlab on January 19, 2013 at 9:04 AM said:

Excellent! At last a script that is easy to understand for this problem. This has been a problem forever on Exchange when doing migration on Exchange environments at companies who are multilanguage. I hope Microsoft one day simply doesn’t change the actual folder names according to the language but rather the “interface” just shows the language the user has chosen. Would be much easier to perform migrations if you don’t have to care about language setting of a mailbox…

LikeLike

Reply ↓
Ashley on January 20, 2013 at 1:05 AM said:

Nice!

LikeLike

Reply ↓
Michel de Rooij on January 20, 2013 at 9:12 PM said:

For those inquiring; yes I know there’s a script from Steen Kirkby/Tamas Flamich (Cleanup-Mailbox) but that’s very limited; it handles limited folder depth and doesn’t do sequence folders for instance. Also, it’s less readable.

LikeLike

Reply ↓
Daniel on January 27, 2013 at 2:22 PM said:

Hi Michel,

I gets “The script failed due to call depth overflow. The call depth reached 1001 and the maximum is 1000.” error when I run the script.

The strange thing is that I could do 3 mailboxes, and now I get this error every time, I tried to both exchange servers, still the same error.

Do you have any idea how to fix that?

Cheers

LikeLike

Reply ↓
- Michel de Rooij on January 27, 2013 at 2:47 PM said:
  
  The script is recursive so it’s only bound to PowerShell limitations. But I guess your structure doesn’t contain 1000+ levels, so I’ll see what can be going on. Can you elaborate a bit on your folder structure and language? (preferred offline through mail)
  
  LikeLike
  
  Reply ↓
  - mendel on March 26, 2013 at 5:45 PM said:
    
    I have a very common issue as Daniel! Even with empty folder it gives the error mentioned above!
    Please email me, we can work this out together!
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on March 29, 2013 at 9:51 PM said:
      
      Looped when “Top of Information Store” is localized; please try version 1.2.
      
      LikeLike
      
      Reply ↓
Pingback: The UC Architects Podcast Ep16 | EighTwOne (821)
Massimo on March 30, 2013 at 3:02 PM said:

Great post!
Michel, do you think I can use impersonation to execute “Get-MailboFolder” against a different mailbox from the one executing the powershell?

LikeLike

Reply ↓
- Michel de Rooij on March 31, 2013 at 2:03 AM said:
  
  You can’t impersonate cmdlets afaik. You could utilize EWS and impersonation to achieve the same result.
  
  LikeLike
  
  Reply ↓
Erik on July 5, 2013 at 12:50 PM said:

Hey,
Looks to be a great script for my foldertroubles but im running into trouble on Exchange2013 with error “Cannot find an overload for “makegenerictype” and the argument count: “1”

Any idea if this command isn’t supported on exchange 2013?

LikeLike

Reply ↓
- Michel de Rooij on July 5, 2013 at 1:07 PM said:
  
  Sounds like a PowerShell v3 thing. Try replacing
  $ItemIds= [activator]::createinstance(([type]’System.Collections.Generic.List`1′).makegenerictype([Microsoft.Exchange.WebServices.Data.ItemId]))
  
  with
  
  $type = (“System.Collections.Generic.List”+’`’+”1”) -as “Type”
  $type = $type.MakeGenericType(“Microsoft.Exchange.WebServices.Data.ItemId” -as “Type”)
  $ItemIds = [Activator]::CreateInstance($type)
  
  and let me know if that works for you.
  
  LikeLike
  
  Reply ↓
  - Manuel on October 24, 2014 at 8:16 AM said:
    
    The solution you gave is correct for me 🙂 Thank you so much!!
    
    I am using Windows Server 2012 R2 and this works:
    $type = (“System.Collections.Generic.List”+’`’+”1″) -as “Type”
    $type = $type.MakeGenericType(“Microsoft.Exchange.WebServices.Data.ItemId” -as “Type”)
    $ItemIds = [Activator]::CreateInstance($type)
    
    On Windows Server 2008 R2 worked with this (as you also said above):
    $ItemIds= [activator]::createinstance(([type]‘System.Collections.Generic.List`1′).makegenerictype([Microsoft.Exchange.WebServices.Data.ItemId]))
    
    Thank you so much Michel
    
    LikeLike
    
    Reply ↓
  - i3laze (@i3laze) on June 4, 2019 at 2:58 PM said:
    
    Hi again. Time passes, PST-import mistakes still exist.
    
    Here’s a Powershell v5 thing on Server 2016 running Exchange 2016:
    > Can’t access mailbox information store (
    Cannot find an overload for “Bind” and the argument count: “2”.
    )
    Any updates for $RootFolder, $ParentFolder and $TargetFolder script blocks?
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on June 5, 2019 at 6:43 AM said:
      
      Thanks for the heads-up (works fine with PS51 on W10 though)
      
      LikeLike
      
      Reply ↓
Ernst on August 12, 2013 at 3:33 PM said:

We have the same issue here. When running the script we get the message: Can’t access mailbox information store. We set the Full Access permission for the Exchange administrator and we set the impersonation options using the command above. Our environment has two backend exchange servers configured as DAG and two frontend exchange servers. The servers are all in a resources domain, all users are in separate domains. All domains are in one forest. Every users domain has it’s corresponding mail database. Any idea?

LikeLike

Reply ↓
- Michel de Rooij on August 12, 2013 at 4:23 PM said:
  
  Protected Group? Deny permissions? Are you running the script from the (Exchange) resource forest?
  
  LikeLike
  
  Reply ↓
  - Ernst on August 12, 2013 at 4:34 PM said:
    
    running the script as the same user who installed Exchange, running from either frontend and backend server. I cannot find any denies . What do you mean: protected groups?
    
    thanks for your quick response!
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on August 12, 2013 at 9:59 PM said:
      
      Is the WebServices virtual directory configured properly? Try bypassing Autodiscover by specifying Server (just server name, not the full URL). Have you run the script with ‘verbose’ to see what EWS url is used and checked if that works in IE? Is there a proxy configured and is that bypassed for local addresses (EWS)?
      
      LikeLike
      
      Reply ↓
      - Ernst on August 13, 2013 at 8:22 AM said:
        
        yep, we ran the script with ‘verbose’. We also tried the -server switch and checked the link in IE.
        There’s no proxy in place. When testing the EWS url we had to supply credentials and after that an XML page appeared…. Might the login prompt be the problem?
        
        LikeLike
        
        Reply ↓
    - Michel de Rooij on August 13, 2013 at 9:32 AM said:
      
      No, the prompt is ok – that’s what your credentials or the impersonation should take care of. Can you replace the line:
      Write-Error “Can’t access mailbox information store”
      with:
      Write-Error “Can’t access mailbox information store”
      Write-Error $error[0]
      and see what it throws?
      
      LikeLike
      
      Reply ↓
      - Ernst on August 13, 2013 at 9:44 AM said:
        
        it throws: Can’t access mailbox information store Exception calling “Bind” with “2” argument(s
        ): “Exchange Server doesn’t support the requested version.”
        At line:1 char:25
        We tried all versions of EWS api: 1.2 and 2.0
        
        LikeLike
        
        Reply ↓
      - Ernst on August 13, 2013 at 9:56 AM said:
        
        the last script was run on backend server 1. When the script is run from backend server 2 the response is:
        Can’t access mailbox information store Write-Error Exception calling “Bind” with “2”
        argument(s): “Exchange Server doesn’t support the requested version.” No Windows PowerShell snap-ins matching the patt
        ern ‘Microsoft.Exchange.Management.PowerShell.E2010’ were found. Check the pattern and then try the command again. Cann
        ot bind parameter ‘FilterScript’. Cannot convert the “” value of type “System.String” to type “System.Management.Automa
        tion.ScriptBlock”. Cannot find path ‘HKLM:\Software\microsoft\ExchangeServer\v14\CentralAdmin’ because it does not exis
        t. Cannot find path ‘HKLM:\Software\microsoft\ExchangeServer\v14\CentralAdmin’ because it does not exist.[0]
        10:53
        
        LikeLike
        
        Reply ↓
    - Michel de Rooij on August 13, 2013 at 9:57 AM said:
      
      Ah. There’s a line which reads:
      $ExchangeVersion= [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2
      (defines minimum version when binding to EWS)
      
      You seem to be running it against a lower version (I wrote SP1 required in the article). I haven’t tested it against SP1; try replacing Exchange2010_SP2 with Exchange2010_SP1. I’ll make a note of it; see not why it shouldn’t work for 2007 as well now I think of it – I’ll test and update where required.
      
      Thanks for your feedback!
      
      LikeLike
      
      Reply ↓
      - Ernst on August 13, 2013 at 10:03 AM said:
        
        You nailed it! The server is running SP1… after this last change the script ran successful!
        Thanks for the support so far!
        
        LikeLike
        
        Reply ↓
Anders on November 3, 2013 at 1:26 PM said:

C:\Users\xaner\Desktop\Fix-MailboxFolders.ps1 : Can’t access mailbox information store (Exception calling “B
specified object was not found in the store.”)
At line:1 char:25
+ .\Fix-MailboxFolders.ps1 <<<< -Mailbox ed-joaed -Language sv-SE -FromLanguage en-US -verbose
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Fix-MailboxFolders.ps1

LikeLike

Reply ↓
- Michel de Rooij on November 3, 2013 at 1:58 PM said:
  
  Check permissions and when adjusting permissions give the store time to update (up to 2hrs).
  
  LikeLike
  
  Reply ↓
Kim Johnson on November 23, 2013 at 2:34 AM said:

Great script, but I’m getting an error when I try to run it. The mailbox DOES exist
[PS] C:\software>.\fix-mailboxfolders.ps1 -mailbox camilla.gagnum -language nb-NO -fromlanguage us-EN -impersonation -verbose
VERBOSE: Loading EWS Managed API DLL
VERBOSE: Loading C:\Program Files\Microsoft\Exchange\Web Services\1.2\Microsoft.Exchange.WebServices.dll
Processing mailbox camilla.gagnum
VERBOSE: Set to trust all certificates
C:\software\Fix-MailboxFolders.ps1 : Specified mailbox camilla.gagnum not found
At line:1 char:25
+ .\fix-mailboxfolders.ps1 <<<

LikeLike

Reply ↓
- Michel de Rooij on November 23, 2013 at 9:14 AM said:
  
  Check permissions. It’s preferred to utilize impersonation, the article contains brief instructions and links to more detailed instructions to cover specific scenarios.
  
  LikeLike
  
  Reply ↓
  - Kim Johnson on November 23, 2013 at 1:58 PM said:
    
    I’ve tried it with and without impersonation. The account I’m using has full mailbox access and Send-as permission.
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on November 23, 2013 at 3:36 PM said:
      
      Have you set up autodiscover properly? Try running it with server switch and specify the FQDN of a CAS
      
      LikeLike
      
      Reply ↓
      - Kim Johnson on November 23, 2013 at 7:47 PM said:
        
        Tried that, still getting the same error. Autodiscover is working fine, this environment has been running for several months.
        
        LikeLike
        
        Reply ↓
Geni H. on November 24, 2013 at 4:06 PM said:

Michel, I’ve been working with Kim trying to resolve their issue with this. I’ve explicitly assigned our administrative account full permissions on the mailboxes we’re running the script against, I’m running Powershell as administrator, Autodiscover is working correctly, and we’ve tried this with and without impersonation, with and without the -server switch, on the mailbox server where the mailboxes reside, and on the CAS server, and the result is always the same – “specified mailbox not found” – even though a get-mailbox for that same works perfectly. Any suggestions would be very welcome at this point.

LikeLike

Reply ↓
- Michel de Rooij on November 24, 2013 at 4:40 PM said:
  
  Check out the permissions on the mailbox; be sure to check out permissions on the server and DB level as well and see if there is no DENY in there somewhere. Also see if it’s possible to access Exchange Web Services, i.e. by browsing to https:///EWS/Exchange.asmx
  
  LikeLike
  
  Reply ↓
  - Geni H. on November 24, 2013 at 5:20 PM said:
    
    Yes, we can browse to the EWS using servername\EWS\exchange.asmx. I checked both AD and mailbox permissions, and this account is a member of Exchange Organization Admins with full rights on server/database. The AD rights are a bit more limited, but do have Send As. I see no Deny’s checked. Is there a specific permission that we should be checking?
    
    Thanks for responding, this one is extremely frustrating. The user would really like to have a better solution than mfcMAPI, but so far, none of us can get the script to find the mailboxes in question.
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on November 24, 2013 at 6:32 PM said:
      
      What are the permissions on on “Top of Information Store”? Is it hidden from address book?
      
      LikeLike
      
      Reply ↓
      - Geni H. on November 24, 2013 at 7:03 PM said:
        
        (by the way, I really appreciate your responding to these; thank you so much)
        HiddenFromAddressBook: False
        and for the account I’m using:
        AccessRights: {FullAccess}
        Deny: False
        InheritanceType: All
        IsInherited: False
        IsValid: True
        I explicitly assigned the account I’m using Owner permissions to Top of Information Store. This is what the results look like when I run the command:
        VERBOSE: Loading EWS Managed API DLL
        VERBOSE: Loading C:\program files\microsoft\exchange server\v14\scripts\Microsoft.Exchange.WebServices.dll
        Processing mailbox camilla.gagnum
        VERBOSE: Set to trust all certificates
        C:\program files\microsoft\exchange server\v14\scripts\Fix-MailboxFolders.ps1 : Specified mailbox camilla.gagnum not found
        At line:1 char:25
        + .\fix-mailboxfolders.ps1 <<<< -mailbox camilla.gagnum -language nb-no -fromlanguage us-en -server mailcas02 -impersonation -verbose
        + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
        + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Fix-MailboxFolders.ps1
        
        LikeLike
        
        Reply ↓
    - Michel de Rooij on November 24, 2013 at 11:44 PM said:
      
      Try specifying the SAM accountname
      
      LikeLike
      
      Reply ↓
      - Geni H. on November 24, 2013 at 11:54 PM said:
        
        Interesting! It got a little further. Now, the result is “can’t determine source language setting” (even though the mailbox regional settings let us use nb-NO):
        
        VERBOSE: Loading EWS Managed API DLL
        VERBOSE: Loading C:\program files\microsoft\exchange server\v14\scripts\Microsoft.Exchange.WebServices.dll
        Processing mailbox cgagnum
        VERBOSE: Set to trust all certificates
        VERBOSE: Using cgagnum@contoso.com for impersonation
        VERBOSE: Using Exchange Web Services URL https://mailcas02/EWS/Exchange.asmx
        VERBOSE: From language selected is us-en
        C:\program files\microsoft\exchange server\v14\scripts\Fix-MailboxFolders.ps1 : Can’t determine source language setting
        s
        At line:1 char:25
        + .\fix-mailboxfolders.ps1 <<<< cgagnum -language nb-NO -fromlanguage us-en -server mailcas02 -impersonation -verbose
        + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
        + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Fix-MailboxFolders.ps1
        
        LikeLike
        
        Reply ↓
      - Geni Hawkins on November 24, 2013 at 11:56 PM said:
        
        (by the way, my response is awaiting moderation…if you can edit it first, please redact the customer’s email address, which I accidentally included in the error message I pasted.)
        
        LikeLike
        
        Reply ↓
      - Geni H. on November 25, 2013 at 12:11 AM said:
        
        I’ve made a little more progress, but it’s hanging up on the destination language now. I fixed it to be -fromlanguage en-US, as it should be, and now the error is “can’t determine destination language settings.” But it’s definitely processing the mailbox using EWS now. The mailbox regional configuration is definitely set to nb-NO. What am I still missing?
        
        LikeLike
        
        Reply ↓
      - Michel de Rooij on November 25, 2013 at 12:22 AM said:
        
        The article contains instructions on how to extend the languages (currently only has EN, NL and SE), i.e. you need to add a section where you define all localized names to be used to look up existing folders, e.g.
        “nb-NO”= @{
        “Inbox”=”;
        .. etc.
        };
        
        LikeLike
        
        Reply ↓
Nicole on December 12, 2013 at 9:36 AM said:

Hello Michel,
first of all: thanks for this wonderful script, we also ran into the import problem with duplicate folders. I tested it in my lab (english) and it worked very well, but when I try to run it in the customer environment, I run into problems with Journal and Junkmal-Folders, though i checked thoroughly that the neames were correct. For me it seems that the user (exchange admin with impersonation role) does not have access rights to the folder, as it shows the usual “bind”-error.
German addition to the script looks like this:

“de-DE”= @{
“Inbox”=”Posteingang”;
“SentItems”=”Gesendete Elemente”;
“Notes”=”Notizen”;
“Drafts”=”Entwürfe”;
“DeletedItems”=”Gelöschte Elemente”;
“Outbox”=”Postausgang”;
“Contacts”=”Kontakte”;
“Calendar”=”Kalender”;
“Tasks”=”Aufgaben”;
“JunkEmail”=”Junk-E-Mail”;
“Journal”=”Journal”;
“DateFormat”=”dd.MM.yyyy”;
“TimeFormat”=”HH:mm”;
};

The script runs through, copying mails from inbox, contacts, calendar etc. until it gets to JunkEmail (there is no JunkEmail1, so it tells me that there is no folder but shows me the destination folder as “[]” instead of “[Junk-E-Mail]” and stops with a write error (as supposed, as a folder [] does not exist). Any idea what i might wanna check ? Access rights to folders and subfolders look completely normal.
We are currently working on Exchange 2013 CU1, german language.

Kind regards,
Nicole

LikeLike

Reply ↓
- Michel de Rooij on December 13, 2013 at 10:07 PM said:
  
  Odd. I’ll try the provided German config in my lab ASAP.
  
  LikeLike
  
  Reply ↓
  - Nicole on December 14, 2013 at 8:54 AM said:
    
    Hello Michel,
    thanks a lot.
    Some update here: leaving Journal and Junk-E-Mail out (and eliminating it from the array of well known folders) makes the script work (it is OK, because these folders are not doubled), but we stumbled into another problem: big mailboxes (talking about 10 GB+) with a lot of subfolders and mails in some folders start copying but after about 10000 items, the script stops with an error about missing IDs (will send you my transcript of that session later, have to get access to the servers). Seems to me that the script – while collecting the item IDs – stumbles because of too many items. The big problem then is: you can restart the script, it goes on copying but when still around 3000-4000 mails should be moved, it just moves on to deleting the folder (like Posteingang1/Inbox1) and a lot of mails are missing (compared the folders before and after move). We tried altering the batchsize down to 100, but still same problem. Could this be a problem of Exchange throttling, as the script uses EWS ? Exchange 2013 is known to be using a harsh throttling policy out of the box and we didn’t change anything there.
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on December 24, 2013 at 7:18 PM said:
      
      It is recommended to disable throttling (EWS) for the account you use to impersonate mailboxes. I just did some testing with a mailbox configured to German (back and forth) and without the issue mentioned, so I can only guess it’s a permission thing. Revision of the deletion process is put on the to do list.
      
      LikeLike
      
      Reply ↓
      - Nicole on December 25, 2013 at 12:44 PM said:
        
        Hello Michel,
        thanks for testing again. Permission issue sounds weird with impersonation and full access. Are Junk-E-Mail- and Journal-Folders (without any policy or journaling in place) handled differently ? We tried using full access and impersonation, same result.To disable throttling for this user sounds like a plan (already thought about it), but as the customer does not have any test environment, we are always working in productive environment and this might result in customer impact if things go bad.
        Anyway, for further migration they will nail all mailboxes down to fixed language and regional settings to avoid future problems with imported .pst files. We were just trying to fix the first problem.
        
        You are doing a really good work here, so thank you again for solving problems like these. Keep on the good work.
        A merry christmas and a happy new year to you and your beloved ones.
        
        LikeLike
        
        Reply ↓
Niels on November 8, 2014 at 11:16 PM said:

Hi Michel,

It is working on Exchange 2013 sp1. Some errors but ok.
Tank You,
Regards, Niels

LikeLike

Reply ↓
i3laze on July 5, 2016 at 3:33 PM said:

Thanks for a script!

Here’s Russian translation:
“ru-RU”= @{
“Inbox”=”Входящие”;
“SentItems”=”Отправленные”;
“Notes”=”Заметки”;
“Drafts”=”Черновики”;
“DeletedItems”=”Удаленные”;
“Outbox”=”Исходящие”;
“Contacts”=”Контакты”;
“Calendar”=”Календарь”;
“Tasks”=”Задачи”;
“JunkEmail”=”Нежелательная почта”;
“Journal”=”Журнал бесед”;
“DateFormat”=”dd.MM.yyyy”;
“TimeFormat”=”H:mm”;
};

The script still doesn’t rename “Inbox1” to “Inbox” while they are in the same language.
As a workaround I had to fix it in two steps: -language OtherLanguage and then -language DestinationLanguage

LikeLike

Reply ↓
- Michel de Rooij on July 5, 2016 at 3:50 PM said:
  
  Thanks. That ‘workaround’ is sometimes necessary when the projected target folder is already present.
  
  LikeLike
  
  Reply ↓
i3laze on July 6, 2016 at 11:01 AM said:

Sorry, doesn’t use Journal often, so the correct translation is:
“Journal”=”Дневник”;

—-
I see you use in the script “nl-NL2” for the same reason/workaround.

Verbose: Target folder is [Входящие]
Verbose: Accessing folder [Входящие] in Top of Information Store
Verbose: Folder [Входящие] not found
Verbose: Accessing folder [Входящие1] in Top of Information Store
Verbose: Processing folder Top of Information Store\Входящие1 (Depth:1)
Successfully processed Входящие1

Using breakpoints I figured out no actual processing of “Inbox1” folder occurs, if “Inbox” doesn’t exist.
That’s the next script’s feature to look into.

LikeLike

Reply ↓
i3laze on July 6, 2016 at 2:45 PM said:

Wishlist #2: handle Get-Mailbox as input pipe for the script..)

LikeLike

Reply ↓
chatcoda on November 14, 2016 at 12:19 AM said:

Hi, nice script !
However I noticed a little mistake for fr-CA: “JunkEmail”=”Courrier indésirable” (without “s”)

LikeLike

Reply ↓
- Michel de Rooij on November 14, 2016 at 10:26 AM said:
  
  Merci beaucoup!
  
  LikeLike
  
  Reply ↓
exonlineblog on October 17, 2017 at 2:14 PM said:

Hi Michel, I’m trying this for Exchange Online but I’m getting the following error:
Load-EWSManagedAPIDLL : This script requires EWS Managed API 1.2 or later to be installed, or the Microsoft.Exchange.WebServices.DLL in the current folder.

LikeLike

Reply ↓
- exonlineblog on October 17, 2017 at 2:19 PM said:
  
  Nevermind, the error has more information 🙂 I had to install EwsManagedApi
  
  Sorry to bother and thanks! Great script!
  
  LikeLike
  
  Reply ↓
- Michel de Rooij on October 17, 2017 at 2:20 PM said:
  
  Script requires Exchange Managed API – you can download it here: https://www.microsoft.com/en-us/download/details.aspx?id=42951
  (also mentioned in accompanying blog article)
  
  LikeLike
  
  Reply ↓
  - exonlineblog on October 17, 2017 at 3:26 PM said:
    
    Thanks Michel, you’re the best 😉
    
    LikeLike
    
    Reply ↓
Patrick on November 30, 2018 at 11:07 AM said:

Just wanted to say thank you! Awesome script! This script saved me from a lot of manual labour.

Probably a good thing to change the sample syntax on this page to the correct one: (parameter mailbox should be identity)

Fix-MailboxFolders.ps1 [-Identity] [[-Language] ] [[-FromLanguage……

LikeLike

Reply ↓
- Michel de Rooij on November 30, 2018 at 11:42 AM said:
  
  Thanks for catching that!
  
  LikeLike
  
  Reply ↓
Alexander on January 4, 2022 at 2:57 PM said:

Do you updated the script to use Modern Auth?

LikeLike

Reply ↓
- Michel de Rooij on January 6, 2022 at 3:53 AM said:
  
  That’s not required- the script requires you to connect to Exchange Online using Exchange Online Management module, prior to using it. The method of authentication is irrelevant to the script.
  
  LikeLike
  
  Reply ↓
  - Martin on February 18, 2023 at 12:35 PM said:
    
    really great script and it works for me with Exchange OnPrem but not with Exchange online:
    
    AUSFÜHRLICH: Using Exchange Web Services URL https://outlook.office365.com/EWS/Exchange.asmx
    AUSFÜHRLICH: From language selected is de-DE
    AUSFÜHRLICH: Setting mailbox language to en-US, DateFormat=M/d/yyyy, TimeFormat=h:mm tt
    C:\temp\FixFolders\Fix-MailboxFolders.ps1 : Can’t access mailbox information store (Ausnahme beim Aufrufen von “Bind” mit 2 Argument(en): “The
    request failed. Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.”)
    In Zeile:1 Zeichen:1
    
    I tried it with delegated access to the mailbox as well as with impersonation. What can I do?
    
    LikeLike
    
    Reply ↓
    - Michel de Rooij on February 18, 2023 at 6:10 PM said:
      
      1) Connect to Exchange Online using Exchange Online Management PowerShell module (for altering the regional settings)
      2) BasicAuth is – likely – blocked, thus configure an app in AzureAD with full_access_as_app application (not delegate) permissions (under Office 365 Exchange Online), and use TenantId, ClientId and CertificateThumbprint, CertificateFile+CertificatePassword or Secret to parameters with the script to authenticate (as the configured app). Credentials won’t work (=Basic).
      
      LikeLike
      
      Reply ↓
      - Martin on February 18, 2023 at 7:29 PM said:
        
        Thank you for quick response:-)
        
        I thought this already and registered an application. I also tried with your other script Remove-DuplicateItems.ps1 and in both cases now I get:
        
        (for removing duplicates)
        
        AUSFÜHRLICH: Module Microsoft.Exchange.WebServices v2.2.1.0 already loaded
        AUSFÜHRLICH: Module Microsoft.Identity.Client v4.43.2.0 already loaded
        AUSFÜHRLICH: Will use provided secret to authenticate
        AUSFÜHRLICH: Authentication token acquired
        AUSFÜHRLICH: Cleanup Mode: Folder
        Processing mailbox test@contoso.com
        AUSFÜHRLICH: Using test@contoso.com for impersonation
        AUSFÜHRLICH: Using Exchange Web Services URL https://outlook.office365.com/EWS/Exchange.asmx
        AUSFÜHRLICH: Constructing folder matching rules
        WARNUNG: Cannot bind to MsgFolderRoot: Ausnahme beim Aufrufen von “Bind” mit 2 Argument(en): “Credentials are required to make a service request.”
        WARNUNG: Cannot bind to ArchiveMsgFolderRoot: Ausnahme beim Aufrufen von “Bind” mit 2 Argument(en): “Credentials are required to make a service
        
        For fixing folders I edited in your script here: DefaultParameterSetName = ‘OAuthCertSecret’,
        Result:
        
        Fix-MailboxFolders-oauth.ps1 : Can’t access mailbox information store (Ausnahme beim Aufrufen von “Bind” mit 2 Argument(en):
        “Credentials are required to make a service request.”)
        
        Something I did wrong…
        
        LikeLike
        
        Reply ↓
      - Martin on February 18, 2023 at 9:47 PM said:
        
        Thanks for quick response:-)
        
        I thought about it and it works now! First I got “Credentials are required to make a service request.”
        
        But after starting it over, I corrected my mistake: I used the wrong secret for the application;-)
        
        I will test it a very large online mailbox (>50 GB)
        
        LikeLike
        
        Reply ↓
        
        Michel de Rooij on February 18, 2023 at 10:40 PM said:
        
        Glad you got it working
        
        LikeLike
        
        Reply ↓