Enable Microsoft Whiteboard for Teams

Whiteboard in Teams is powered by Whiteboard for the web and this is a very useful feature for collaborating in group meetings. A shared canvas space allows meeting participants to collaborate. In Office 365, Whiteboard feature is enabled by default unless you disabled it manually (mostly customers disable it due to data residency concerns).

Microsoft Note: The ability to start a new whiteboard is currently limited to the Microsoft Teams clients on Windows 10, macOS, and for the web. The Teams apps for iOS and Android cannot initiate sharing a whiteboard, but they can collaborate once a whiteboard is shared.

Now let’s get this configured. Login to Office 365 Admin center using admin credentials and type ‘Whiteboard’ in the global search field. You will get the Whiteboard global settings option in a search result dropdown.

Check the ‘Turn on’’ tick box to enable it globally in your Tenancy. Diagnostic data collection by Microsoft is disclosed via three options here.

Connected experiences and sharing from Surface Hub are two optional settings depending on the organizational requirements. Finally hit ‘Save’ to complete it.

Now the global setting is enabled, we need to ensure the Whiteboard capability is also enabled in the Meeting policies. If you have multiple policies, make sure this is enabled for all of them to affect it to the desired target audiences.

From the Teams admin center, navigate to Meetings –> Meeting policies

Then click on the desired policy (in my case, the ‘Default’ as it affects to all users)

Toggle the ‘Allow Whiteboard’ switch to ‘On’ state to enable it and hit ‘Save’

Notes: This might take a couple of ours to reflect to all users (in my case it took 7+ hours).

Testing the feature.

1. Now to try this out, you can create a test meeting with another user and ensure the Whiteboard is appearing once ‘Share’ option is clicked.

1. Also, if you login to office.com, you should be able to see the ‘Whiteboard’ App under the Apps list.

Troubleshooting:

If you still don’t see the feature in Teams meetings, try to toggle ‘Off’ the Whiteboard feature from Teams meeting policy. Then turn in it on again and try it in a couple of hours.

Advertisement

Allow all users to see everyone’s calendar in an Office 365 environment

Yes you are right!. Setting this access right organization-wide is surely raises a major privacy concern specially when it comes to personal details (such as HR and Operation related events) in employee’s calendars.

However, there can be exceptional scenarios where business decides what they need, such as the pandemic situation the whole world face right now (COVID-19) as every organization prepares to work from home and allow people to interact online in more efficient and effective ways. In my case, one of our top level client badly needed to enable everyone’s calendar visible to everyone in the company to allow people to efficiently get in touch.

This is possible and exchange online has the capability to do it, but, make sure you do it for an absolute purpose. In Exchange online, you can set the default internal sharing policy for Office 365 user’s calendars using PowerShell. You may decide to set the default for all current users to Limited Details, then add exceptions for users whose calendar is to be kept to Availability (Free/Busy) only. There are various roles to define as per your need.

The AccessRights parameter in the PS command below specifies the permissions that you want to modify for the user on the mailbox folder. The values that you specify replace the existing permissions for the user on the folder.

You can specify individual folder permissions or roles, which are combinations of permissions. You can specify multiple permissions and roles separated by commas.

I am emphasizing again, DO NOT DO THIS Unless there is an absolute necessity.

For None-MFA environment (even though MFA is a fundamental and very common security requirement, there can be exceptional cases) – Amend the AccessRights parameter accordingly

$credentials = Get-Credential -Credential elliot@gcits.com.au

Write-Output “Getting the Exchange Online cmdlets”

$Session = New-PSSession -ConnectionUri https://outlook.office365.com/powershell-liveid/ `

-ConfigurationName Microsoft.Exchange -Credential $credentials `

-Authentication Basic -AllowRedirection

Import-PSSession $Session

foreach($user in Get-Mailbox -RecipientTypeDetails UserMailbox) {

$cal = $user.alias+”:\Calendar”

Set-MailboxFolderPermission -Identity $cal -User Default -AccessRights Reviewer

}

For MFA environments

Preparation:

Run this to get the current state of all user mailboxes as exported to a CSV file. This will help on the verification later in case if you need to reverse this (Pre)

Connect-EXOPSSession

foreach($user in Get-Mailbox -RecipientTypeDetails UserMailbox) {

$cal = $user.alias+”:\Calendar”

Set-MailboxFolderPermission -Identity $cal -User Default -AccessRights Reviewer

}

$file=”C:\Temp\Calendar-Post.csv”
$Usermailboxes = Get-Mailbox -RecipientTypeDetails UserMailbox
foreach($user in $usermailboxes) {
$cal = $user.alias+":\Calendar"
$perms = get-MailboxFolderPermission -Identity $cal -User Default
$Perms | select identity, Foldername, AccessRights | export-csv $file -append
}

Applying Access Rights:

Now let’s change the access right for all user mailboxes. Amend the AccessRights parameter according to your requirement (applied to all user mailboxes)

foreach($user in Get-Mailbox -RecipientTypeDetails UserMailbox) {
$cal = $user.alias+”:\Calendar”
Set-MailboxFolderPermission -Identity $cal -User Default -AccessRights AvailabilityOnly
}

If you wish to avoid an selected user mailbox (May be CEO’s ?), you can use the following (with the “userprincipalname” “–ne” parameters to add an exception)

foreach($user in Get-Mailbox -RecipientTypeDetails UserMailbox | where userprincipalname -ne “mark@mantoso.onmicrosoft.com”) {
$cal = $user.alias+”:\Calendar”
Set-MailboxFolderPermission -Identity $cal -User Default -AccessRights AvailabilityOnly
}

Connect-EXOPSSession

foreach($user in Get-Mailbox -RecipientTypeDetails UserMailbox) {

$cal = $user.alias+”:\Calendar”

Set-MailboxFolderPermission -Identity $cal -User Default -AccessRights Reviewer

}

$file=”C:\Temp\Calendar-Post.csv”
$Usermailboxes = Get-Mailbox -RecipientTypeDetails UserMailbox
foreach($user in $usermailboxes) {
$cal = $user.alias+":\Calendar"
$perms = get-MailboxFolderPermission -Identity $cal -User Default
$Perms | select identity, Foldername, AccessRights | export-csv $file -append
}

Verification:

To verify the result against a single user mailbox, you can run this line

Get-MailboxFolderPermission neil@mantoso.onmicrosoft.com:\calendar

Or run the following to get the result of all user mailboxes exported as a CSV file so it can be compared with the CSV you got before applying the change (Post)

$file=”C:\Temp\Calendar-Post.csv”
$Usermailboxes = Get-Mailbox -RecipientTypeDetails UserMailbox
foreach($user in $usermailboxes) {
$cal = $user.alias+":\Calendar"
$perms = get-MailboxFolderPermission -Identity $cal -User Default
$Perms | select identity, Foldername, AccessRights | export-csv $file -append
}

Testing:

Now let’s see how this works after changing the permissions. Details wise, this is how it shown now (looking at Chnau’s Calendar from Manoj’s Mailbox)

Private Events in Chanu’s Calendar (Only the date/time and Subject)

None Private Events in the Chanu’s Calendar (Shown Items in detail)

1. Subject
2. Location
3. Organizer
4. Attachments
5. Attendees and response status
6. Date/Time 

Item opened in full window

Here’s the full list of roles available to set. You can specify individual folder permissions or roles, which are combinations of permissions. You can specify multiple permissions and roles separated by commas.

Individual permissions:

• CreateItems: The user can create items in the specified folder.
• CreateSubfolders: The user can create subfolders in the specified folder.
• DeleteAllItems: The user can delete all items in the specified folder.
• DeleteOwnedItems: The user can only delete items that they created from the specified folder.
• EditAllItems: The user can edit all items in the specified folder.
• EditOwnedItems: The user can only edit items that they created in the specified folder.
• FolderContact: The user is the contact for the specified public folder.
• FolderOwner: The user is the owner of the specified folder. The user can view the folder, move the folder, and create subfolders. The user can’t read items, edit items, delete items, or create items.
• FolderVisible: The user can view the specified folder, but can’t read or edit items within the specified public folder.
• ReadItems: The user can read items within the specified folder.

The roles that are available, along with the permissions that they assign, are described in the following list:

• Author:CreateItems, DeleteOwnedItems, EditOwnedItems, FolderVisible, ReadItems
• Contributor:CreateItems, FolderVisible
• Editor:CreateItems, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItems
• None:FolderVisible
• NonEditingAuthor:CreateItems, FolderVisible, ReadItems
• Owner:CreateItems, CreateSubfolders, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderContact, FolderOwner, FolderVisible, ReadItems
• PublishingEditor:CreateItems, CreateSubfolders, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItems
• PublishingAuthor:CreateItems, CreateSubfolders, DeleteOwnedItems, EditOwnedItems, FolderVisible, ReadItems
• Reviewer:FolderVisible, ReadItems

The following roles apply specifically to calendar folders:

• AvailabilityOnly: View only availability data
• LimitedDetails: View availability data with subject and location

Reference – Set Mailbox Folder Permissions (Microsoft Docs)

Moving Microsoft Teams Data Location

If you are a existing Office 365 customer who have been waiting Microsoft to allow you to move your Teams data location, It’s now time to do it.

Office 365 now allows you to decide where your Teams data residency should be. We have noticed that most of our clients got their Data residency set to Australia as the data region.

Microsoft now offer existing O365 customers listed in the following table an option to request early migration of organization’s core customer data at rest to their new datacenter geo.

Changing the geo location is completely taken care by Microsoft behind the scene. You as a customer, only have to opt-in to allow Microsoft to do this in the backend (despite your request, this will anyway happen eventually) and the change is seamless with no user interaction, interruption.

To see your current data location for each workload, go to Office 365 Admin center –> Settings –> Settings –> Organization Profile

Navigate to Data Location to see where your data currently resides

Switch to Data Residency and “check the tick box” below to opt-in. You will not see this option if:

• Your tenant is not eligible for the Office 365 Move Program. Eligibility is determined by tenant signup country.
• All of your core customer data at rest is already located in the new geo (see Data Location section of the page).

And wait for a few months as advised in the notification. Microsoft will notify you stage-wise in the Office 365 Message center when the activity is being actioned or completed.

Note: The information on this page only applies to customers who had existing Office 365 tenants before the new datacenters in their geo launched.

More details are here – https://docs.microsoft.com/en-us/Office365/Enterprise/request-your-data-move

Change default File Open Behavior of SharePoint Online

The default option in SharePoint online to open files stored in document libraries is “Open in Browser”. You can leave it like that as long as you don’t have an specific requirement to change this behavior.

In some cases, end users prefer to open file by client application due to many reasons and they are fair reasons, mostly.

1. Client application offers rich capabilities which allows users to get things done effectively and efficiently
2. Some organizations using SharePoint as the central document management platform across the entire company. At this point they might prefer to have the files opened by client application as default.

There are various ways to enable this functionality which impact different levels.

1. Document library level
2. Single site collection level
3. Across the entire tenant

If you’d like to set a specific document library to open files in client application by default. Simply log in to your SharePoint online tenant, direct to the desired library and select the radio button under the Advance Settings as you wish (This overrides the setting applied at site collection level and open documents in client application instead of browser)

Navigate to the Document Library –> Click on Settings gear –> Library Settings from the menu.

Under General Settings –> Click on “Advanced Settings”

To enable this for a specific site collection (applies for the entire collection unless you have chosen from individual libraries manually as shown in the screenshot above to opt out)

To do this for an specific site collection, we have to activate a site collection level feature. Simply log in to your SharePoint online tenant, direct to the desired site.

Go to Site Settings –> Site Collection Features

Click on “Activate” button next to “Open Documents in Client Applications by Default” feature

You can use the following PowerShell script to do get the same thing done in a bulk mode across all site collections in the tenant (ORG WIDE).

This is a SharePoint PnP PowerShell script which uses an CSV file as the source for site names.

1. First you have to get all the site URLs exported from the SharePoint Admin Centre in Office 365 Admin Portal
2. Then save it as an CSV file and point this script to that file (Change the CSV path in the script)

Your CSV should look like this (Site URLs separated in to individual columns, not rows. If you are having hard time getting this format, it’s quite easy, use the Transpose feature under Paste special)

Note: Obviously, this script will only cover the existing site collections of your tenant. For any upcoming new site collection created after running this has to enable it manually again.

$username = Read-Host "Provide the username"
$password = Read-Host -Prompt "Password for $username" -AsSecureString
$O365credential = New-Object PSCredential($userName,$passWord)

# Chnage CSV path here
$site = Import-csv C:\Official\Tools\remain.csv

Foreach ($URL in $site.URL)
{
try {
    Connect-PnPOnline -Url $URL -Credentials $O365credential

    Write-Host "Connected to " $URL 
    Write-Host "Enabling features on" $URL 

	# Enter Feature Id & scope

    Enable-PnPFeature -Identity 8a4b8de2-6fd8-41e9-923c-c7c3c00f8295 -Force -Scope Site

    Write-Host "Disconnecting from " $URL 
    Disconnect-PnPOnline    
    }
    Catch 
    {
    Write-Host "Got error" $error
    }
}
Write-Host "Completed"

Retrieve Office 365 users with a specific SKU using PowerShell

Its common that every Office 365 Administrator/Engineer is asked to provide user license stats from sales department for billing or reviewing purposes with the client. This quick read will demonstrate how you can easily get the User license count for a specific SKU via a simple PowerShell cmdlet.

Instead of logging in to Office 365 Admin Center and going through the admin UI to find and export these stats, we can easily do that same using a PowerShell Script. Before you start, ensure that you have latest PowerShell version and the MSOLSERVICE module installed on top of it.

Connect to Office 365 via PowerShell using this command

Connect-MsolService

Once connected, it should simply show as below and no errors or warnings

Now, let’s run Get-MsolAccountSku to get a list of the current licenses in your Office 365 tenant. Make a note of the AccountSkuId value for the license you want to filter on.

Get-MsolAccountSku

Next, you can edit this script to get the users matching that license. In this case, we’re getting users with the EnterprisePremium license.

Get-MsolUser | Where-Object {($_.licenses).AccountSkuId -match "EnterprisePremium"}

Replace EnterprisePremium with the AccountSkuID you’re trying to filter by. As we use the -match operator here we don’t need to type the entire AccountSkuID, we can just type enough of it to ensure that we’re only retrieving that specific SKU. You can change the SKU to meet your specific needs there.

Now we can export this result using this PowerShell line. Change the path to match your target location and file name.

Get-MsolUser | Where-Object {($_.licenses).AccountSkuId -match "EnterprisePremium"} | Out-file C:\Official\ENTPREMUsers.csv

Excel unable to access SharePoint Online files, fails with an error “sorry we couldn’t open”

This happened to few of my clients time to time in SharePoint online environments. You may have seen it but weirdly for some users only? You are not alone.

One of the errors is ‘Sorry we couldn’t open https://mantoso.sharepoint.com/DocumentLibrary/excelfile.xlsx’

And, the other error is – ‘Microsoft Excel cannot access the file ‘https://mantoso.sharepoint.com/DocumentLibrary/excelfile.xlsx’. There are several possible reasons:

• The file name or path does not exist.
  
• The file is being used by another program.
  
• The workbook you are trying to save has the same name as a currently open workbook.’

This issue in my perspective, can be caused by Office Document Cache of your Office Desktop application. Here’s how I managed to get rid of it.

Open Windows Explorer and copy and paste one of the following locations into the address bar:

Clearing Office Document Cache for Office 2016

%localappdata%\Microsoft\Office\16.0\OfficeFileCache

Clearing Office Document Cache for Office 2013

%localappdata%\Microsoft\Office\15.0\OfficeFileCache

Select all files beginning with ‘FS’

And delete those files. Restart the Excel application and you should now be able to open files from SharePoint.

‘Connect-MsolService’ is not recognized as the name of a cmdlet

If you are facing this issue, you are not alone. In my case, I had run the install-Msolservice command before and it completed with no errors but nothing seemed to be installed, therefore it didn’t connect or recognize the modules in the machine. Here are the steps to get it fixed.

Open PowerShell as Admin –> Run the following commands in sequence (ensure your machine is connected to internet)

Firstly, uninstall the Azure-AD module

uninstall-module AzureAD

The re-install it

Install-module AzureAD

Install-module AzureADPreview

Try to run this. It will complete without any errors if you have the module existed but somehow corrupted (It could fail too but just run it anyways to verify)

Uninstall-module MSOnline

Now re-install the MSOnline Module

Install-module MSOnline

And now you can connect to O365. It should prompt you for credentials to login

Connect-MsolService

Once completed, the following command can be used to verify the installation.

Get-Module -ListAvailable -Name MSOnline*

Permanently deleting an Office 365 Group object in retention enabled environment

There is a stage where an Office 365 group can reach its end. As O365 group acts a major role for may Office 365/Azure related workloads, there could be plenty of situations you come across that you have to get rid of some of your Office 365 Groups.

For instance, a situation where you have removed your Team and Its associated SharePoint site but Group object could be still hanging in the recycle bin until it reaches the retention period based on the retention policy you have set. Or, perhaps, you have decided to delete a SharePoint site or Microsoft Team, you will find you cannot create another team or site in its place. You will receive an error saying this group already exists.  This is because the group was deleted as a ‘soft delete’. Meaning it’s sitting in a recycle bin for a number of days until it’s permanently deleted (retention plays again). Just follow these steps and you will immediately get rid of that unnecessary group object.

First and foremost, ensure that you have Azure AD PowerShell module is installed in your PC.

Run the following commands in sequence.

This first line will connect you to your Office 365 Tenant’s Azure AD. you will be prompted for the credentials to log in.

Connect-AzureAD

Now let’s run this one to get the group GUID from the deleted list

Get-AzureADMSDeletedGroup

Copy that GUID of the desired group and run the following by targeting that ID.

Remove-AzureADMSDeletedDirectoryObject -Id <ReplaceWithGroupID>

It should result as follows if it was success

To ensure the deletion is successful, run the same command again and see if it doesn’t return the group name you deleted. It shouldn’t !

Get-AzureADMSDeletedGroup

OneDrive sync error: ‘You are already syncing this account’

This message appeared on plenty of end user devices across many of my clients when they try to synchronize their SharePoint Libraries using OneDrive sync client (Not OneDrive library itself though), no big deal, it was all about browser in our case (could differ in some case as well, I presume). The exact error is ‘You’re already syncing this account’. Open your OneDrive – Your Organization Name folder or sign in with a different account’

A common nature of the scenario was that, everyone got this error was using either Microsoft Edge or Internet Explorer. The immediate solution was using an alternative browser instead, we tried Chrome and it worked like charm.

When Chrome prompted options, choose: ‘Open URL : OneDrive client protocol’

And, you can now start syncing the library

Get End User OneDrive URL with PowerShell

This minor task was part of a major activity I carried out for one of the clients recently here in Australia. Used the SharePoint PnP PowerShell to do this, pretty simple with the commands and controls it offers.

SharePoint PnP cmdlets reference – https://github.com/SharePoint/PnP-PowerShell

First and foremost, ensure you have installed the latest PnP module in your machine. Run this cmdlet to get the latest bits installed

Update-Module SharePointPnPPowerShell*

Now verify the version by running this

Get-Module SharePointPnPPowerShell* -ListAvailable | Select-Object Name,Version | Sort-Object Version -Descending

Firstly you must connect to SharePoint Online using Connect-PnPOnline cmdlet (none MFA environments)

$cred = Get-Credential
Connect-PnPOnline -Url https://<tenant>-admin.sharepoint.com/ -Credentials $cred

If your Office 365 Environment is MFA enabled, use this instead (Notice the login is different to the traditional method)

Connect-PnPOnline -Url https://sitename-admin.sharepoint.com -UseWebLogin

Now we can run the Get-PnPUserProfileProperty cmdlet to get the information about the user’s profile and select only the PersonalUrl which is the URL of that user’s OneDrive for Business.

$username = "<UserName>"
$OneDriveUrl = Get-PnPUserProfileProperty -Account $username | select PersonalUrl
$OneDriveUrl

$username = "<UserName>" $OneDriveUrl = Get-PnPUserProfileProperty -Account
$username | select PersonalUrl

There is it ! that’s the ultimate end user URL of OneDrive