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.
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.
Also, if you login to office.com, you should be able to see the ‘Whiteboard’ App under the Apps list.
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.
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
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)
Attendees and response status
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.
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:
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.
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.
Client application offers rich capabilities which allows users to get things done effectively and efficiently
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.
Document library level
Single site collection level
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.
First you have to get all the site URLs exported from the SharePoint Admin Centre in Office 365 Admin Portal
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)
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
Write-Host "Got error" $error
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
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.
Next, you can edit this script to get the users matching that license. In this case, we’re getting users with the EnterprisePremium license.
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.
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
The re-install it
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)
Now re-install the MSOnline Module
And now you can connect to O365. It should prompt you for credentials to login
Once completed, the following command can be used to verify the installation.
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.
Now let’s run this one to get the group GUID from the deleted list
Copy that GUID of the desired group and run the following by targeting that ID.
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.
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.