Apply folder permissions in a SharePoint Online document library using PowerShell

Being a consultant with a primarily messaging background, it’s always interesting for me to blog about SharePoint and be out of my comfort zone.

What I am going to show you today, is how do you apply permissions to folders, in a SharePoint online document library, using PowerShell.

So what PowerShell module should you use?

Let me start by saying that, there’s multiple ways to programatically apply those permissions, to a SharePoint library. In this case I am using the SharePoint PnP PowerShell Module.

In the link above, you will be able to learn a bit more about the SharePoint Patterns and Practices module, as well as follow the steps to install it. Be aware that the PnP commands use CSOM, so you might get throttled at some point, if you execute too many.

Now lets look at the code in detail

I will try and break down the script, just so you understand all it does and adapt to your needs properly.

Configuration hard-coded values

It’s always best that you don’t hard-code any values in your script, just so you don’t have to edit it each time you want to run it for a different scenario, but I wanted to keep this one simple, so here it goes:

#This value if for your SharePoint Online Team site URL. In my case my team name is “Team1”. Change yours accordingly
#This is your list name. If you run a Get-PnPList you’ll see that Documents is for the Shared Documents library. You will need this for the cmdlet that sets the permissions
$ListName=”Documents”
#This is the user account you want to give permissions to
$UserAccount = “user1@domain.com”
#Role that you want to add (see permissions section for more information)
$Role = “Contribute”
#Relative URL of the parent folder for all folders you are applying permissions to (see different folder section below for more information on how to change this to target another folder)
$FolderRelativeURL = “/sites/Test1/Shared Documents/”

Connect to the SharePoint PnP Online PowerShell

#Connect to PnP Online. You will get prompted for credentials.
Connect-PnPOnline -Url $SiteURL -Credentials (Get-Credential)

Grab all Folders to apply permissions to

#I created a small try catch to exit the script if we can’t grab the folders
Try{
$AllFolders=Get-PnPFolderItem-FolderSiteRelativeUrl “/Shared Documents”-ItemType Folder -ErrorAction Stop
}
Catch{
Write-Host”Failed to list the folders”-ForegroundColor Red
Exit
}

 

Apply the permissions

#And finally the code for the loop to go folder by folder and apply the permissions
Foreach ($Folder in $AllFolders){
$RelativeURL=$FolderRelativeURL+$Folder.Name
Write-Host$RelativeURL
$FolderItem=Get-PnPFolder-url $RelativeURL
Set-PnPListItemPermission-List $ListName-Identity $FolderItem.ListItemAllFields-User $UserAccount-AddRole $Role
}

Now the entire script for you to copy

#Config Variables

$SiteURL = "https://yourtenant.sharepoint.com/sites/Test1"

$ListName="Documents"

$FolderRelativeURL = "/sites/Test1/Shared Documents/"

$UserAccount = "user1@yourtenant.onmicrosoft.com"

$Role = "Contribute"




#Connect to PnP Online

Connect-PnPOnline -Url $SiteURL -Credentials (Get-Credential)

Try{

$AllFolders=Get-PnPFolderItem-FolderSiteRelativeUrl "/Shared Documents"-ItemType Folder -ErrorAction Stop

}

Catch{

Write-Host"Failed to list the folders"-ForegroundColor Red

Exit

}

Foreach ($Folder in $AllFolders){

$RelativeURL=$FolderRelativeURL+$Folder.Name

Write-Host$RelativeURL

$FolderItem=Get-PnPFolder-url $RelativeURL

Set-PnPListItemPermission-List $ListName-Identity $FolderItem.ListItemAllFields-User $UserAccount-AddRole $Role

}

What if I want to do a different folder

The code above is to apply permissions in the top level folders within the Shared Documents library of your Team site. If you want to change to a different folder, edit the following lines in the code:

  • Line 4 – $FolderRelativeUrl: Add the folder structure here (i.e “/sites/Test1/Shared Documents/FolderA/SubFolderB/”
  • Line 13 – FolderSiteRelativeURL parameter: Add the folder structure here as well (i.e “/Shared Documents/FolderA/SubFolderB”

How about permissions

The example above applies the role “Contributor” to the folders, for the user defined. If you want to know more details about which role to apply, please go to this excellent article to understand permission levels in SharePoint.

Final notes

I hope this post is helpful. Like I stated initially there’s easy ways to make the script more complex but easier to manage, such as removing hard-coded values or for example creating a loop to add permissions to multiple users. Using the code above as reference will for sure save you some time or give you that quick win you need.

Advertisements

Microsoft Teams PowerShell – A simple use case to get you started

Not long ago I blogged about the new Microsoft Teams PowerShell module. Today I want to give you a quick example of how you can leverage it, to automate and make your work more efficient. I’ll show you how to list all Team Channels in your organization.

Connect to your Microsoft Teams Organization using PowerShell

The first thing you need to do is connect your Teams PowerShell module and authenticate to your Office 365 tenant.

  • If you don’t have the Microsoft Teams PowerShell module installed, click on the link in this article and install it
  • Once you have it installed the Connect-MicrosoftTeams cmdlet should be available. It’s as easy as running it and use the authentication prompt to pass the credentials, but you can also pass basic credentials if you want to, using the -credential parameter

TeamsPS01

List all Teams in your Microsoft Teams organization

To list all Teams in your organization, you can use the Get-Team cmdlet. By default the cmdlet will have as output the GroupID, DisplayName, Visibility, Archived, MailNickName and Description.

TeamsPS02

You can format your output to include any relevant Team attribute. Do a “Get-Team |fl” to list them all.

List all Team Channels in your organization

Now finally lets execute the use case of this post. To list all Team Channels in your organization, you can leverage the Get-TeamChannel cmdlet.

This cmdlet has a mandatory parameter -GroupID, which is basically the ID of each Team. That said you have two options:

Option 1: you run “Get-TeamChannel -groupid <TeamGroupID>”

TeamsPS03

You can use the Get-Team cmdlet to get the GroupId value for each team.

Option 2: you grab all Teams into an array and process each Team to list their channels, using the code snippet below.

$AllTeams = Get-Team

Foreach ($team in $AllTeams) {Get-TeamChannel -groupid $team.groupid |Ft $team.DisplayName, DisplayName}

TeamsPS04

What I did above, was changing the output of the command, to list in a readable way to which Team the Channels belong to. There are other ways, more organized, to format the output both to the console or an output file. Nevertheless this can easily guide you in that direction, and if you need any help let me know.

And that’s it. I can and will blog much more around Teams PowerShell. If you haven’t used it yet, you should.

Happy coding!

 

Use a Multi Factor Authentication enabled account to connect to Exchange Online PowerShell

Security is a big theme for any online applications and Multi Factor Authentication is used more and more everyday. Those security standards easily extend to PowerShell or any other admin sessions, to execute tasks in your tenant. It will be more and more common to see organizations that no longer allow their IT administrators to connect to their Exchange Online using basic auth.

If you’re a heavy PowerShell user like me, this is for you. Microsoft has an excellent article on how to leverage an MFA account to connect to Exchange Online PowerShell.

You should read the article, as this things tend to be updated and you’ll be sure the have the latest steps, but in essence what you need to do is:

  • Make sure you have all prerequisites (i.e .Net Framework), specially in older versions of Windows
  • Install the Exchange Online Remote PowerShell module (from the Exchange Online EAC)
  • Make sure that WinRM allows basic authentication

Finally you can run the following command to connect to Office 365 commercial:

Connect-EXOPSSession -UserPrincipalName chris@contoso.com

And if you are connecting to a different instance, such as GCC High or 365 Germany, you need to specify the ConnectionUri and the AzureADAuthorizationEndPointUri parameters (see official article for parameter configurations).

Connect-EXOPSSession -UserPrincipalName <UPN> [-ConnectionUri <ConnectionUri> -AzureADAuthorizationEndPointUri <AzureADUri>]

Here’s how the PowerShell session looks like after you install the module.

MFAPS01

And the authentication process.

MFAPS02

And that’s it. Happy scripting!!!

 

Goodbye 16-character limit for Azure AD passwords

Finally the change many were waiting for. The password length limit in Azure AD just went up from 16 to 256 characters and is now more in line with the On Premises AD limits.

Is there any immediate impact for the end user?

Not really. Apart from the fact that they will now be allowed to set longer passwords (and you should make them aware of that), the impact from the end user perspective should be null.

What about IT administrators and any external app that leverages Azure AD for integration?

The only thing you’ll probably need to be aware, before you start changing those service account passwords to 200+ character passwords (in the name of maximum security), is can your printer or your 3rd party app, that interacts directly with Azure AD or Office 365, support such long passwords? Be careful with that and you should be fine! 🙂

 

The Microsoft Teams PowerShell module GA is here

Great news for those who, like me, are heavy users of PowerShell and its available modules for the different Microsoft workloads: The Microsoft Teams PowerShell module is now in general availability, after being in Beta since last year.

There are several new functionalities, but the one I want to highlight is the new switch -TeamsEnvironmentName in the Connect-MicrosoftTeams cmdlet, that allows you to connect to environments different from 365 commercial, such as Government tenants.

If you haven’t already, read the Teams PowerShell Overview Microsoft documents.

I will be posting about Teams PowerShell scripting soon. Enjoy!

How do you plan and execute a successful Public Folder migration?

From all the years as a consultant, and now directly in the migration business, helping partners successfully plan and execute migrations, Public Folders as always been the one of the most challenging workloads I had to deal with.

There’s always a lot of questions when you have to execute such migrations, so I decided to write a blog post about it, where I am going to try and address as much as possible.

To try and keep it as organized as possible, and because there are so many different scenarios, I will divide this post into three main sections: General migration considerations, Migrating Hybrid Public Folders and Migrating Public Folders cross organization.

We will then also discuss some more generic questions, such as why use a third party tool vs the Microsoft native tool.

General migration considerations

This blog post is focused both on Hybrid and cross organization Public Folder migrations. Some steps however are exactly the same, regardless of what the migration scenario is. Those steps are described below. After reading this section you can then focus on your specific scenario in the sections that follow.

Prepare your On Premises Environment

One of the first things you need to look at is to the On Premises Public folder structure, to check if there’s any inconsistencies or invalid folders. The best way to that is of course via scripting, and you should use this excellent script from Aaron @Microsoft, called IDFix for Public Folders. Download it, run it and fix everything that the script highlights as needing to be fixed.

You should also make sure you create a report with all mail enabled Public Folders and address, and to do so you can leverage the Get-MailPublicFolder cmdlet.

How to migrate Public Folder access permissions, as well as Send-As and Send-on-behalf rights

Public Folder permissions should be migrated by the migration tool, provided of course identities match between on premises and Exchange Online (which should of course be true for Hybrid scenarios), or between premises  in cross organization migrations.

As for the Send-As and Send-on-behalf rights, the best option is to export them from the source system and import them into the destination system, once the migration is completed. Since this is not PowerShell code I’ve focused on recently, I did a quick research online and found this article online where you can find the code to export and import those access rights.

Note: I am not the author of the code below and I am only putting it directly in my blog post just so it’s easier for you to locate it and copy it. The code was taken from the article mentioned in the line above, written by Aaron Guilmette.

Export Send-As

Get-MailPublicFolder -ResultSize Unlimited | Get-ADPermission | ? {($_.ExtendedRights -Like "Send-As") -and ($_.IsInherited -eq $False) -and -not ($_.User -like "*S-1-5-21-*")} | Select Identity,User | Export-Csv Send_As.csv -NoTypeInformation

Export Send-on-behalf

Get-MailPublicFolder | Select Alias,PrimarySmtpAddress,@{N="GrantSendOnBehalfTo";E={$_.GrantSendOnBehalfTo -join "|"}} | Export-Csv GrantSendOnBehalfTo.csv -NoTypeInformation

$File = Import-Csv .\GrantSendOnBehalfTo.csv
$Data = @()
Foreach ($line in $File)
    {
    If ($line.GrantSendOnBehalfTo)
        {
        Write-Host -ForegroundColor Green "Processing Public Folder $($line.Alias)"
        [array]$LineRecipients = $line.GrantSendOnBehalfTo.Split("|")
        Foreach ($Recipient in $LineRecipients)
            {
            Write-Host -ForegroundColor DarkGreen "     $($Recipient)"
            $GrantSendOnBehalfTo = (Get-Recipient $Recipient).PrimarySmtpAddress
            $LineData = New-Object PSCustomObject
            $LineData | Add-Member -Type NoteProperty -Name Alias -Value $line.Alias
            $LineData | Add-Member -Type NoteProperty -Name PrimarySmtpAddress -Value $line.PrimarySmtpAddress
            $LineData | Add-Member -Type NoteProperty -Name GrantSendOnBehalfTo -Value $GrantSendOnBehalfTo
            $Data += $LineData
            }
         }
    }
$Data | Export-Csv .\GrantSendOnBehalfTo-Resolved.csv -NoTypeInformation

Import Send-As

$SendAs = Import-Csv .\SendAs.csv
$i=1
foreach ($obj in $SendAs) 
    { 
    write-host "$($i)/$($SendAs.Count) adding $($obj.User) to $($obj.Identity)"
    Add-RecipientPermission -Identity $obj.Identity.Split("/")[2] -Trustee $obj.User.Split("\")[1] -AccessRights SendAs -confirm:$false; $i++
    }

Import Send-on-behalf

$GrantSendOnBehalfTo = Import-Csv .\GrantSendOnBehalfTo-Resolved.csv
$i=1
Foreach ($obj in $GrantSendOnBehalfTo)
    {
    Write-host "$($i)/$($grantsendonbehalfto.count) Granting $($obj.GrantSendOnBehalfTo) Send-On-Behalf to folder $($obj.PrimarySmtpAddress)"
    Set-MailPublicFolder -Identity $obj.PrimarySmtpAddress -GrantSendOnBehalfTo $obj.GrantSendOnBehalfTo
    $i++ 
    }

Migrating Hybrid Public Folders

This scenario, when compared to the cross organization migration, is far more complex, because besides moving the data you will also have to worry about things like mail flow, user public folder access, etc. But lets address one thing at the time.

Microsoft Official guidance to configure Hybrid Public Folders

If you’re reading this article because you’re planning to migrate your Hybrid Public folders, chances are you already read and executed the Microsoft guidance to make your on premises Public Folders available to Exchange Online users, under a Hybrid deployment. Configure legacy on-premises Public Folders for a Hybrid Deployment is the article for legacy public folders and Configure Exchange Server Public Folders for a Hybrid Deployment is the one for modern Public Folders.

Both articles are focused on the hybrid coexistence and not the migration planning of the Public Folders, but they are important to mention as they impact the migration planning, based on what type of coexistence you configured and steps you followed.

Public Folder end user access in the context of a hybrid migration

When planning a Public Folder migration, under a hybrid scenario, one of the most important things you need to consider is, end user access. With that in mind, consider the following:

  • On premises users cannot access Exchange Online Public Folders
  • Exchange Online users can access on premises public folders and/or Exchange Online Public folders, although you cannot configure a single user to access both, you can configure some users to have access to on premises folders and some to see them locally, in Exchange Online.

Have the two principles in mind, during your planning. The Public Folder access for Exchange Online users is complex and by itself worthy of a dedicated blog post.

The Microsoft official guidance, mentioned in the previous section, explains how you configure Exchange Online users to access on premises Public Folders.

The bottom line of this section is, make sure you move all users to Exchange Online, before you consider moving the Public Folders, and if you don’t, make sure that the users left on premises do not require any Public Folder access.

Public Folder mail flow coexistence before, during and after the migration. How do you handle mail enabled Public Folders.

Another very important component of your Public Folder migration is the mail flow coexistence, or to be more precise, the way you deal with the mail enabled Public Folders.

Mail Enabled Public Folders before the migration

When you follow the guidance provided by Microsoft, you will be asked to execute the Sync-MailPublicFolders script.

This script enables Exchange Online users to send emails to on premises mail enabled Public Folders, by creating mail objects in Exchange Online with the primary and all other SMTP addresses that those folders have on premises. This objects are not actual Exchange Online Public Folder nor they are visible in the Exchange Online Public Folder tree. They also allow those on premises Public Folders to be present in the Exchange Online GAL (Global Address List), and once a user in Exchange Online emails that folder, the email gets forwarded to Exchange On Premises.

Mail Enabled Public Folders during the migration

During the Public Folder migration, whether it’s a single or multiple pass (with pre-stage + full migration) migration strategy, you should not change the Public Folder mail flow. That means that you should not mail enable the Public Folders in Exchange Online (chose a tool that gives you that option). Actually as you will see below, there are things that you need to do in Exchange Online, before mail enabling the Public Folders.

Mail Enabled Public Folders after the migration

Once your migration (or the pre-stage) is completed, you should transition the Public Folder mail flow to Exchange Online. To do so, you should follow these steps:

  1. Start the pre-stage or full migration and wait for it to be completed
  2. Once the migration pass is done, go to Exchange Online and delete all mail objects created by the Sync-MailPublicFolders script (NOTE: this will temporarily break mail flow between Exchange Online users and mail enabled Public Folders, online or on premises)
  3. Mail enable the Exchange Online Public Folders, either via a script or using the migration tool. Make sure you add all addresses from the on premises to the online Public Folders
  4. Run a full migration pass if in step 1 the pass that you ran was a pre-stage

To elaborate a little bit more in step 2, the reason that you need to delete those objects is because you need to avoid conflicting addresses, when enabling the mail enabled Public Folders in Exchange Online, and those objects are not associated with the new EXO Public Folders.

Migrating Public Folders cross Organization

Migrating Public Folders cross organization is not as complex, and you’ll see why in the sections below. This scenario can include migrations such as:

  • Exchange Online to Exchange Online
  • Hosted Exchange to Exchange on premises or Exchange Online
  • Exchange on premises to Exchange on premises

When to migrate users and Public Folders

Usually this Public Folder migrations cross organization come as an additional step to a migration that also includes mailboxes.

Although there’s no 100% correct answer, when it comes to the question of what should be migrated first, mailboxes or Public Folders, in this cases normally the best option is to migrate mailboxes first and Public Folders last. The main reason for that is because you should migrate the Public Folders when they’re not being used anymore, allowing you to do a clean single pass migration of all the data.

Public Folder end user access and mail flow coexistence

This is where things gets simple, for this type of scenarios. There’s no Public Folder access cross organization (unless the user is using the credentials for the 2 systems) and although technically you can configure mail flow between any two email systems, it’s not something you should consider for the majority of the cases.

Mail enabled Public Folders can and should be created at the destination during the folder hierarchy creation.

Why use a third party tool to migrate Public Folders

That’s probably the question I get the most, working for a third party migration tool company, that has an amazing Public Folder migration tool, BitTitan. And here is a list of reasons:

  • Migrate large volumes of data: Migrating 2, 5 or 10GB is easy with any tool, but not all tools can deal with Terabytes of Public Folder data.
  • Migrate parts of the structure or prioritize data: Either by targeting just specific parts of the Public Folder hierarchy or by using folder filtering. This is a very commonly used feature in tools like BitTitan MigrationWiz.
  • Flexibility on handling mail enabled Public Folders: As explained in the Hybrid mail flow section of this posts, you might need some flexibility on how to handle mail enabled Public Folders during the migration. MigrationWiz will mail enable in the destination all Public Folders that are mail enabled at the source, but you can also suppress that option, and should in some scenarios.
  • Data transformation: While planning a migration of Public Folders, some customers want to take that opportunity to also move that data into a different structure, which can be shared or resource mailboxes, office 365 groups, etc. That is something that can be successfully done with tools that are flexible enough to perform that transformation (i.e in many cases requires recipient mapping, folder mapping, folder filtering, etc), like MigrationWiz.
  • Supported sources and destinations: Exchange 2007+ to Exchange 2007+, including of course Exchange Online and hosted as source and/or destination – this is the answer most customers want to hear from the support ability stand point of a third party tool, to migrate their Public Folders, and that is something they won’t get with the native tool.

The bottom line

While reading this post, before publishing it, I always get the feeling that there’s so many other things that I could mention and talk about, but I do think that it addresses the core concerns of most Public Folder migrations, and hopefully it addresses yours.

Nevertheless, if you do have any questions don’t hesitate to reach out.

 

 

 

Office 365: Not sure if your vanity domain is being used by another Office 365 tenant? Don’t worry.

I remember not long ago, the pain of trying to find out in which Office 365 tenant your vanity domain was validated, when you bumped into the error stating that the domain was in use, while adding it to your current tenant.

This was maybe because I work with multiple tenants and I recycle my tenants quite often, for testing purposes, but I’ve also seen it with others while trying to assist them in their migration projects.

Fortunately Microsoft now is very clear in the error message you’ll see, when trying to add a domain to a tenant, that is in use. This is what you will see now:

vd1

As you can see above, it will tell you exactly in which tenant the domain is, just so you can login to it and remove it.

Now is there a catch with this? Of course!! Microsoft won’t give you such privileged information, until you enter a valid DNS record for the domain validation. You’ll see something similar to this, if the domain validation is not done properly:

VD2.png

So remember to add the DNS record first and click “Verify”, Microsoft will either add the domain or explain exactly why they can’t, which I am sure it was for a long time one of the main asks of Office 365 admins and consultants.

Populate Exchange mailboxes using Exchange Web Services

I just came across a very nice and handy script, that allows you to quickly populate your Exchange mailbox with test data, leveraging EWS.

Being in the migration business and having to do all sorts of tests and demos all the time, this to me is a very useful script, and I am assuming if you’re reading this post, there’s a chance that you also need it.

So this PowerShell script to generate mailbox test data over a period of time, when compared to other methods that leverage SMTP, is great because you can actually populate the mailbox with “old” data.

The parameters you can specify can also be found in the page of the author of the script. You can specify the target mailbox, number of days to fill the mailbox with, messages per day and message size, EWS endpoint or to use autodiscover and some EWS API specific parameters.

EWS1

Above you can see and example of the script execution.

EWS2

And this is how it’s going to look, as it executes.

The script should work perfectly both in Exchange Online and On Premises, as long as it’s a version that supports EWS.

Disclaimer: Unlike many other scripts I blog about, I am not the author of this script. I’ve seen it in the Technet Gallery, used it, and though I should blog about the experience. If you have any issues and/or recommendations or evens kudos to sent, refer to the author, identified in the Technet gallery page.

 

The differences in quotas and how to handle Public Folder migrations to Exchange 2013+ On premises vs Exchange Online

When we talk about migrating Public Folders, and believe me I talk about that a lot, the usual assumption is that the migration is to Exchange Online. That is true most of the times, but not all.

BitTitan MigrationWiz is a tool that adapts to all sorts of scenarios, the rule being if you have an Exchange 2007+ in the source and destination, and that of course includes Exchange Online, that MigrationWiz will be able to migrate your Public Folders. That being said I find myself discussing scenarios such as migrating Public Folders from Exchange on premises or Exchange Online, to a destination Exchange On Premises.

For those used to migrate Public Folders into Exchange Online, you would know that one of the main things to take into account is the volume of data to be migrated and how to make that work seamlessly, since the Public Folder mailboxes in Exchange Online have quotas you can’t change, as you can see here.

One of the things that makes MigrationWiz such a good tool to migrate large volume of Public Folder data, into Exchange Online, is that we will automatically split the Public Folder data into multiple mailboxes, therefore preventing a migrate failure and delay if one of the mailboxes gets full during the migration. This is done via support and explained in all the relevant migration guides, such as this one.

So the question now is, would this process be necessary when the destination are Exchange On Premises 2013+?

Answer: No. You can’t change Public Folder mailbox quotas in Exchange Online, but you can change them in Exchange On premises, so you don’t need to automatically split the data into multiple destination mailboxes.

And should I use a single On Premises mailbox for a large volume of data?

Answer: You can, but you shouldn’t. If you have 100, 150 or 200GB of Public Folder data, then yes a single mailbox approach seems reasonable, but if you have more than that you should think about having multiple mailboxes, for reasons like backup and restore management, among others. Another reason for having multiple Public Folder mailboxes might be if you have a multi region Exchange Organization and you want to provide localized access to Public Folders.

Why do you reference the destination as being Exchange 2013+?

Answer: Because this blog post focuses specifically in modern public folders (mailbox vs database).

Now lets have a look at a Public Folder mailbox in Office 365:

PFMBX1

As you can see above the quotas are well defined and cannot be changed.

How does that look in Exchange On premises?

PFMBX2

Above you can see 2 Public Folder mailboxes. One comes with the quota set to unlimited, which is the default when you create a new Public Folder mailbox in Exchange 2013, and for the other one I’ve set the limits to 150GB, with the following command:

Set-Mailbox -PublicFolder <mailboxname> -ProhibitSendReceiveQuota 150GB -ProhibitSendQuota 150GB -IssueWarningQuota 150GB -UseDatabaseQuotaDefaults $false

Note: Don’t forget to set the database quota defaults to false, if you want the new quotas to apply at the mailbox level.

As you can see above there are differences between Exchange Online and On Premises, and the control you have over both. Consider them when planning your migration.

 

While having Public Folder access in 365 set as remote in the Organization Config, point some users to the Exchange Online Public Folders

Some key things you should have in mind, when you’re moving your Exchange Organization from On Premises to Office 365, and Public Folders are in scope:

  • Before moving the Public Folders to Exchange Online, you need to move all of your users (at least you should move all of the ones that require Public Folder access). Users in Exchange On Premises cannot access Public Folders in Exchange Online.
  • You need to follow the Microsoft Official guidance to configure legacy on premises Public Folders under a hybrid deployment.
  • You can (and should in some scenarios) point some mailboxes to the online Public Folders and that’s what this blog post is all about

Now lets look at how a Hybrid Public Folder Organization Config looks like:

PFOrg1

As you can see above, the Public Folders in 365 are configured as remote (step 5 in the guide mentioned above), and an on premises public folder mailbox is defined as their mailbox (created in step 2 of the guide).

What this does is very simple: at the mailbox level, for each mailbox, it will set the parameter “EffectivePublicFolderMailbox” to the mailbox “OnPremPFMBX”, which is a synced mailbox object from on premises, as you can see below:

PFOrg2

And how do we change this, per user?

The answer is simple, you run a set-mailbox cmdlet, to one or multiple users, and you define the -defaultpublicfoldermailbox parameter, to a 365 Public Folder mailbox, that you of course need to have created before hand.

set-mailbox <Mailbox> -DefaultPublicFolderMailbox 365PFMBX

The command above is what you need to run, and you can adapt if to multiple users. Let me know if you need help with that.

Before closing this blog post lets just discuss one last thing: creating the Office 365 Public Folder mailbox.

A Public folder mailbox created under a Hybrid scenario, where public folder access is set to remote, will be set by default to a HoldForMigration state. Follow this excellent BitTitan article to understand why and resolve that issue. You need to resolve it before you can create new public folders in Exchange Online.

And while doing that don’t forget that, the best tool out there to migrate your Public Folders is the BitTitan MigrationWiz tool, so while you’re in our help center go ahead and read our migration guides and ask for a quote from our sales team.