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'
For a customer case/project, we wanted to move only recently synced/modified Sharepoint Online data from Tenant A to the user’s Desktop on the device itself.
The Desktop was synced to Onedrive for Business in Tenant B.
After copying, files from Tenant A should become read-only on the local device, and the link in Explorer to Tenant A’s sharepoint should be removed, including the actual onedrive sync relationship to prevent further ul/dl’s.
For Intune / Microsoft Endpoint Manager, no solution was known yet. So I base64 encoded Bernd’s solution and wrapped it into a SYSTEM wide scheduled task that is triggered by a security eventlog logoff entry.
Deploy this to your VM’s in Intune (either through a user or a machine group) and it’ll ensure users’ VM’s get deallocated when they log off.
This also works on shared VM’s, as it will only deallocate if it is the last user logging off.
4. Accept further defaults and when created click Go to resource:
5. Under the Identity option, click Azure Role Assignments:
6. Be sure to select the same subscription your Virtual Machines are in:
7. If you wish to scope permissions more specifically (always recommended), at minimum you’ll need to assign Virtual Machine Contributor to the resource group(s) containing your VM’s and Log Analytics Reader on your log analytics workspace.
8. Now create a runbook in your new automation account:
11. Go to modules and click browse gallery, search for ADDRS:
12. Wait for the import to complete. If it fails, check if you have installed the 7.1 versions of these requires modules, install if needed and try again:
13. Run the runbook to test, or link it to a schedule:
14. if you want to use a schedule different from weekly, make sure to also add the -measurePeriodHours parameter to match, and if you use maintenance windows, include those as well as described in the module manual.