Best Practices for External Presenters in your Teams Live Event

by Contributed | Nov 19, 2020 | Technology

This article is contributed. See the original author and article here.

External Presenters in a Teams Live Event: Best Practices

Many of my customers have reached out to me recently about this situation: they are organizing a Teams Live Event, they have presenters that are outside of their organization, and those external presenters are only able to join the event as attendees. Sound familiar?

Good news! I run webcasts constantly with presenters outside of the Microsoft tenant, and I avoid this confusion completely. Just proactively follow the three steps below for smooth sailing with your events:

1. Add the external presenter as a guest to a team.

No, it doesn’t matter what team! It doesn’t even matter if you add them to an existing team or a new team. In fact, I often create a sample team for a new event, and then delete that team after the event. Anyone with a business or consumer email account (Outlook, Gmail, others) can participate as a guest in Teams. Never added a guest to a team before? Here is a step-by-step guide on adding guests to a team.

2. Let the presenter know that they need to accept the guest invitation and join the team.

Even if you add them as a guest to your Teams tenant and they receive an email, the most important part is that they step through the entire flow. This ensures that the external presenter is authenticated as a guest within your tenant. Below is an example of an email that I sent to my guest presenters just last week! Feel free to save yourself time and use it as a template:

3. Schedule the live event and add the guest as a presenter in the event group.

When you schedule a live event, the first screen asks for the meeting title, date and time, and other details including the event group. Simply add in the presenters’ email addresses to add them to the event group as shown below:

After you invite the presenter, they will be added to the event group, as you shown here:

This can be done before step 1, and you can add more presenters to your event group at any time. That being said, until the external user goes through the flow to authenticate as a guest in your tenant (step 2), they will not be able to join the live event as a presenter.

That’s it, folks! Hopefully this simplifies the process of inviting external guests to present in your live events. For even more details on planning live events in Microsoft Teams, check out this resource.

Thanks and let us know how else we can help,

Sam Brown, Microsoft Teams Technical Specialist

Best practices for public folder preparation before migrations

by Contributed | Nov 19, 2020 | Technology

This article is contributed. See the original author and article here.

We wanted to share some best practices to prepare the on-premises public folders for migration to Exchange Online. The document will walk you through the overview of process to migrate public folders to Exchange Online, using the native tools as well as talk about best practices and tools used for trouble free migration.

Public folder migration process overview

A quick overview of how the native migration process works follows. The intention here is not to walk through details of each step of native migration, that is already done here and here.

Preparation is the key step, and we will be spending majority of this post on that part, which will ensure you face minimal issues during the actual migration.

As part of preparation you will:

• Find out stale/unwanted public folders and remove them


• Validate existing public folders for known issues and fix any issues found


• Check the size of existing public folders and public folder items and ensure they are not too large


• Create the mapping file and target PF mailboxes

Out of scope of this post: once all the preparation is completed, creation of a migration batch using a mapping file and starting of the migration batch.

Before we dive into the details of preparation, here are some of the highlights of the native migration process:

• There is no option to migrate only some public folders, therefore:
  
  
  
  • You must remove unwanted public folders if you don’t want them to be migrated.
  
  
  • If you wish to migrate some public folders to Microsoft 365 Groups, you should do this before you migrate the rest of your public folders to Exchange Online.
  
  
  
  


• Only one migration batch is allowed – all public folders will be migrated in a single batch.


• Once the migration is completed, no more data from source public folders can be copied over to Exchange Online public folders.


• Maximum of 250,000 public folders can be migrated to Exchange Online.

Preparation

As the famous quote goes “By failing to prepare, you are preparing to fail”; this applies to public folder migration. Let us now explore detailed steps of preparing the public folders at source.

Cleanup

We need to start with inventory. This is the time to take inventory of public folder deployment at the source. Find out stale public folders out there and decide if those folders are really needed? Do you really need to migrate data that has not been accessed for years?

The following commands show public folders that do not have user activity for last two years:

Exchange 2010:

$date=(Get-date).AddMonths(-24)
Get-PublicFolderStatistics -ResultSize unlimited | ?{$_.LastUserAccessTime -le $date}

Exchange 2013+:

$date=(Get-date).AddMonths(-24)
Get-PublicFolderStatistics -ResultSize unlimited | ?{$_.LastModificationTime -le $date}

Note: LastUserAccessTime is available only in Exchange 2010, not in later versions.

On public folder replicas (legacy public folders)

On a simple side of things, an organization might have a single (or two) public folder databases on two servers, with actual public folder data (replicas of actual content) on both servers. This can then scale to organizations that have 10s of public folders servers with complicated replication strategy.

The best chance of success to have timely migration can be achieved by having as few copies of same public folder data (replicas) as possible. Consider that during the migration stage, users are still using public folders as they currently are. The more replicas of public folder content there are, the more places we have where public folder data can be written to or changed. This then results in public folder replication process between different replicas. Many an Exchange administrator has spent lots of time troubleshooting legacy public folder replication – which can be challenging even if there is no migration going on at the same time!

Our recommendation therefore is to consider that in a large public folder environment, it might be worth it to consolidate / remove some folder replicas and therefore reduce complexity / data churn during the migration finalization stage. Also, you want to make sure that all the public folder databases are mounted (dismounting the database is not a way to try work around this complexity!)

Public folder size and item size

A lot of public folder migrations fail and get delayed because the individual items were too large, or a very large public folder was being migrated.

It is best to:

• Keep the maximum individual public folder size between 15 to 25 GB.
  
  
  
  • Use Export-PublicFolderStatistics.ps1 to get public folder size information. If you have any public folders larger than 25 GB, you should break them up to be less than 25 GB.
  
  
  • If you are planning to migrate large public folders, ensure to change the default public folder post limit in Exchange Online.
  
  
  
  

For public folder items:

The default MaxReceiveSize on public folder mailboxes in Exchange Online is 35MB. You should find out the public folder item sizes at the source. The following command example can help:

$pf=Get-PublicFolder -Recurse -ResultSize unlimited;foreach ($i in $pf) {$s=Get-PublicFolderItemStatistics $i.EntryID;foreach ($r in $s) {if ($r -gt “38600”) {$r.MessageSize,$r.PublicFolderName}}}

If you have public folder items that are large then 35MB, change the MaximumSend/ReceiveSize on target public folder mailboxes, once they are created in Exchange Online.

If public folder items are larger than 150 MB, you must remove these items before migration. See “Message limits” here.

Validate – SourceSideValidation.ps1

The following are major causes for migration slowness or failures, when it comes to public folder data issues:

• Bad ACLs


• Issues related to Mail Enabled Public Folders (MEPF)


• Health of dumpster folders


• Source exceeding limitations (things like folder depth etc.)

The Source Side Validation (SSV) script was developed to analyze the on-premises public folder deployment and report issues found along with providing guidelines to fix them. The script must be run from Exchange 2010 or Exchange 2013+ server, depending on where the public folders are deployed. Use the script before the start of migration process but after you have cleaned up the source environment from folders you do not need to migrate.

To get the script to perform all the checks:

.SourceSideValidations.ps1

To get the script to perform only public folder permission related validations:

.SourceSideValidations.ps1 -VerifyMEPF $false -VerifyDumpsterMapping $false -CheckLimits $false -CheckPermissions $true

Mail enabled public folders (MEPF)

The following are common issues encountered during migration of MEPFs:

• Orphaned MEPFs


• Non_Ipm_Subtree public folder is mail enabled

The .ValidateMailEnabledPublicFolders.ps1 script will help you find such MEPFs and provide you readily usable output to fix such MEPFs.

Target public folder mailboxes

Planning how many public folder mailboxes you need in Exchange Online is a critical task as well. You don’t want to create a ton of unnecessary public folder mailboxes and at the same time you don’t want to overload each target mailbox so that it might fill up during the migration (or soon after).

Some guidelines to remember:

• Do not place any content in the primary hierarchy mailbox, nor point any users directly to this mailbox. You can read more about public folder deployment best practices here.


• Plan to fill up to 50% of maximum allowed size of PF mailboxes during migration. Current maximum size of PF mailbox is 100GB. So, the “Total public folder size at source in GB”/50 should give you an idea of how many public folder mailboxes you need in Exchange Online.

So, for example, if you have 2 TB (2000 GB) of public folder data at source, you will need around 40 public folder mailboxes in Exchange Online.

The .ModernPublicFolderToMailboxMapGenerator.ps1 file can help you get idea of how many PF mailboxes are required in Exchange Online and also provides you the mapping file.

Mapping file

The Mailbox Replication Service uses the mapping file to place source public folders into specific target public folder mailboxes. The following are some guidelines on well-defined mapping file:

• Ensure the primary hierarchy mailbox is mapped to the root folder “”


• If you wish to place specific folder into a specific public folder mailbox, add the entry exclusively


• Once the entry is added, the folder and subfolders below it will be migrated to the target mailbox specified


• Ensure each folder that is present directly on the root has explicit mapping in the file and is mapped to a non-primary hierarchy public folder mailbox; this ensures the primary hierarchy mailbox serves only hierarchy


• Finally, ensure the target public folder mailbox names are correct

Connectivity

Migrations can fail or produce unexpected results if connectivity to source server is unreliable.

Migration from Exchange Server 2010 works using Outlook Anywhere (RPC/HTTP), even if you have Exchange Server 2013 (or higher) acting as a FrontEnd server.

It is best to ensure the service account being used to migrate public folders can access Exchange 2010 public folders from the internet using Outlook for desktop client or Microsoft Remote Connectivity Analyzer.

You can use the Test-MigrationServerAvailability command to ensure connectivity.

If your environment uses a load balancer, it is best not to use the load balancer for MRS related traffic as this is handled by EWS and the MRSProxyEnabled property on that Virtual Directory.

Finally, if you have a firewall with very stringent inbound connectivity, ensure that Exchange Online IP addresses are whitelisted.

Changing the default quota in Exchange Online

The default prohibit post quota to public folders in Exchange Online is 2GB. The migration may not fail if your individual public folders are larger than this size, but users might not be able to post or email items to public folders as soon as the migration is complete.

The default quota can be changed at organization level:

Set-OrganizationConfig –DefaultPublicFolderProhibitPostQuota 25GB -DefaultPublicFolderIssueWarningQuota 20GB

Note: Do not set the default quota above 25 GB as it may result in giant public folders, which might cause issues with the auto-split process in the future. You can read more about auto-split feature here.

Also by default, the MaxReceiveSize and MaxSendSize on public folder mailbox is configured at 35MB. You must increase this limit to accommodate largest public folder items from on-premises:

Set-Mailbox -PublicFolder -MaxReceiveSize 50MB -MaxSendSize 150MB 

ExcludeDumpsters

The deleted public folders are stored under Non_IPM_Subtree, also affectionately referred to as the Dumpster.

Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller. In some cases, corrupted dumpster folders can cause migration to fail.

Migration of public folders in dumpsters can be skipped using ExcludeDumpsters parameter.

This option is available only for migrations from Exchange Server 2013+ to Exchange Online and must be specified at the time of batch creation.

Example:

New-MigrationBatch -Name PublicFolderMigration -CSVData <mapping file> -SourceEndpoint $PfEndpoint.Identity -SourcePfPrimaryMailboxGuid <GUID> -ExcludeDumpsters

That’s it!

The goal of this article was to ensure the source is prepared for a successful and hassle-free migration. Once you are done with preparation, we recommend you follow each of the migration steps from here for a trouble-free migration experience.

Bhalchandra Atre