Category Archives: Office 365

OnedriveMapper V5 required update!

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:

OnedriveMapper V5 @ GitHub

OnedriveMapper V3 @ GitHub

Map Onedrive profile Dir to O: at logon

For a basic scenario where users are unwilling or unable to navigate to the Onedrive folder in their profile, the following script will ensure all users on a given machine get their Onedrive profile folder mapped to the O: drive, it auto-installs as scheduled task at logon.

https://gitlab.com/Lieben/assortedFunctions/-/blob/master/set-scheduledTaskToInstallODriveToOnedriveAtLogon.ps1

Dynamic membership rule for Teams Room accounts

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:

https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/active-directory/enterprise-users/licensing-service-plan-reference.md

The mysterious X-MS-Forest header

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'