Microsoft is planning to modify the Office 365 sign in process slightly by September 15th or October 1st and has kindly supplied advance notice and support for OnedriveMapper, but only for V3.29+ and V5.15+
So if you’re on a lower version -> update asap!
The new login interruption looks like this:
Teams Room accounts are usually excluded from conditional access. To do so, they have to be in a security group, which of course we don’t want to do manually.
Most companies choose to use a naming standard and simply use that as a rule to create an exclusion group. This is easy to circumvent, I can create a guest user / get invited with the right name et voila zero CA policies!
A better way is to identify the accounts based on their assigned licenses, e.g. Teams Rooms Basic (6af4b3d6-14bb-4a2a-960c-6c902aad34f3). This, however, is not supported as an Azure AD group membership rule as this is stored in the AssignedLicenses property which will throw an “Unsupported Property” error.
The assignedPlans property however does contain the GUID we need.
The following Azure AD Group dynamic membership rule only matches users that have a Teams Room Basic, Teams Room Standard or Teams Room Pro license:
(
(
user.assignedPlans -any (
assignedPlan.servicePlanId -eq "8081ca9c-188c-4b49-a8e5-c23b5e9463a8"
-and
assignedPlan.capabilityStatus -eq "Enabled"
)
) -or
(
user.assignedPlans -any (
assignedPlan.servicePlanId -eq "ec17f317-f4bc-451e-b2da-0167e5c260f9"
-and
assignedPlan.capabilityStatus -eq "Enabled"
)
) -or
(
user.assignedPlans -any (
assignedPlan.servicePlanId -eq "92c6b761-01de-457a-9dd9-793a975238f7"
-and
assignedPlan.capabilityStatus -eq "Enabled"
)
)
) -and not (
user.assignedPlans -all (assignedPlan.servicePlanId -eq "")
)if you want to do something similar for other licenses, here are the options/combinations:
When working with the api.interfaces.records.teams.microsoft.com API, I noticed that the MS portal uses an X-MS-Forest header.
At first, ignoring this went fine as doing GET calls to this api didn’t seem to require it. But, of course the moment I wanted more, it suddenly WAS required (PUT/POST).
The question was; how does the portal determine the value for this header and how do we replicate that? Well, that wasn’t difficult: apparently a call to api.interfaces.records.teams.microsoft.com/Teams.Tenant/tenants suffices and returns the value for the X-MS-Forest header for the tenant identified in your token. Example:
$headers = Get-GraphToken -tenantid $tenantId -scope "https://api.interfaces.records.teams.microsoft.com/user_impersonation"
#get the correct forest
$tenantInfo = Invoke-RestMethod -Method GET -uri "https://api.interfaces.records.teams.microsoft.com/Teams.Tenant/tenants" -UseBasicParsing -ContentType "application/json" -Headers $headers
#add the X-MS-Forest header (required) for subsequent calls
$headers["X-MS-Forest"] = $tenantInfo.serviceDiscovery.Headers.'X-MS-Forest'
V3.24 of OnedriveMapper is now available for download.
I’ve seen a few examples of distributing a set of teams backgrounds to users in MEM, mostly they seemed a little overly complex, especially in targetting all local users and/or packaging the script into an application. I wanted to:
Here’s my take, first autocreate a blob storage location using my template:
Note down the name you used for the storage account (which was the only parameter to the template), and use it to configure this PowerShell script:
https://gitlab.com/Lieben/assortedFunctions/-/blob/master/add-teamsBackgroundsFromBlobContainer.ps1
Finally, deploy the script to a group of your users in MEM, in their own context:
