Find and Eliminate Slashes for Public Folder Migration

I’m going to kick off this blog with some fun information about my efforts in migrating my company’s Public Folders from Exchange 2010 to Exchange Online. As I come across things, I’ll post them and try to give some PowerShell examples to help you through this. First – some context – our Public Folders are massive. We have about 100k of them weighing in at about 5 TB! Yes – it’s nuts. Luckily, we were able to take part in Microsoft’s TAP (Technology Adoption Program) to allow us to migrate such a behemoth over to Exchange Online. One of the pre-requisite steps to moving your Public Folders over to EXO is a lot of clean up, which includes removing the dreaded “slashes” (back, forward, and otherwise – not just backslashes).

If you’re familiar with the documentation at TechNet (here), you’l recall they give you a one-liner to find the backslashes in your Public Folder tree and remove them. This one liner is fantastic if you have about 10 Public Folders in your tree and live in a perfect world. For most people, this isn’t the case. There are likely hundreds to thousands of folders. As such, we need to adjust the PowerShell accordingly to achieve the same results. Here is an example of what I used and how I did it:

This is a good point to stop what you’re doing and take some time to parse the CSV file. You may notice duplicated entries in this file – that’s because of Public Folder replicas. Your results may vary depending on how you have replica folders configured. This is totally fine. You don’t need to dote over this as when you remediate these in the next step, it will skip ones that you already fixed. You’ll also decide if you want to communicate the change you’re about to make to your users. It’s a nice thing to do, but note that changing a name of a PF won’t affect their Favorites or links. There may, however, be third party apps that depend on an exact name, so I’ll leave that up to you to determine. The main point here is that the CSV is there for you to review and do what you need to with it. Anyway, on with the show. Let’s fix this!! Check out the following:

I want to talk about each of those commands and what’s happening there. I’ll try to break this down:

$backslashes | %{…} – This is short for ForEach-Object. I like typing % better than all the other stuff. That’s just me.

$newname = (Get-PublicFolder -Identity $_.Identity).name – This assigns the CURRENT name to a variable named $newname. Pretty straightforward.

$newname = $newname.Trim() – This reassigns the $newname variable with the updated name WITHOUT the leading and trailing whitespaces. This is a bonus tip because this isn’t well documented but can cause issues when it comes time to sync and migrate, so why not take care of it right here? Remember – we are not searching the entire tree for leading or trailing whitespaces, just the folders we found with slashes. You could take this further and adjust the PowerShell command above to also search the tree for this – up to you.

$newname = $newname.Replace(‘\’,’-‘) – This is a cool one that further augments the name. What this does is save you a TON of work by replacing one character with another character. This will search the name string of the variable for the ‘\’ character and replace it with a ‘-‘. Why a ‘-‘ you ask? It’s because it’s what we decided to replace our slashes with. You can choose whatever makes sense for you.

$newname = $newname.Replace(‘\’,’-‘)  – Same as the one above. At this point you should have a $newname with a clean, slashless, whitespaceless, totally syncable name! Now it’s time to change the name!

Set-PublicFolder – Identity $_.identity -Name $newname – At this point your folder will be renamed with the cleaned up name. If you had duplicate entries in your CSV from replicas as I mentioned above, don’t sweat it – it will just tell you there is nothing to change and it will just skip it. All good!

OK, so now you’ve got a clean folder tree a lot closer to being able to be migrated. The steps above are glossed over in the TechNet article above, but there is WAY more to it for more complicated environments.

Please feel free to comment below with your thoughts, comments, or tips of your own!

*IMPORTANT* – Remember to TEST EVERYTHING in a lab before messing with your production systems!!! You should always understand the commands you’re issuing before using them.

Leave a Reply

Your email address will not be published. Required fields are marked *