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:
go to resource ADDRS
5. Under the Identity option, click Azure Role Assignments:
Go to 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:
create runbookselect runbook type and click Create
11. Go to modules and click browse gallery, search for ADDRS:
browse PS gallery for modulesSearch for ADDRSSelect ADDRSSelect runtime v 7.1 and import
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:
Az.Compute
Az.OperationalInsights
Az.Resources
Az.Accounts
13. Run the runbook to test, or link it to a schedule:
link runbook to a new scheduleCreate a schedule as desired and press create.
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.
It has long annoyed me that all the scaling options in Azure just add and remove hosts. They never target the host itself. Hosts are either under or overutilized in 84% of the case.
And this is especially relevant for AVD personal hostpools where users each have their own personal “VDI”.
So I’m releasing a custom PowerShell module called “ADDRS” (Azure Data Driven Right Sizing) that grabs mem/cpu performance of the VM or all VM’s in a resource group you tell it to check. It will then do some smart voodoo magic to determine what size out of an allowlist best fits.
Instructions / Example:
Use -WhatIf if you don’t want it to resize the VM
Use -Force if you want to resize a VM even if it is online (which will cause it to be shut down!)
Use -Boot if you want the VM to be started after resizing (by default it will stay deallocated)
Use -domain with your domain if your VM is domain joined
Use -region if your region is not westeurope
Use -Verbose if you want the full output incl financial projection
Use -Report if you want to output data to csv. Can be used together with -WhatIf
Modify minMemoryGB, maxMemoryGB, minvCPUs, maxvCPUs as desired for your usecase
You can adjust the preconfigured allowedVMTypes array to only allow specific VM types, by default it contains “Standard_D2ds_v4″,”Standard_D4ds_v4″,”Standard_D8ds_v4″,”Standard_D2ds_v5″,”Standard_D4ds_v5″,”Standard_D8ds_v5″,”Standard_E2ds_v4″,”Standard_E4ds_v4″,”Standard_E8ds_v4″,”Standard_E2ds_v5″,”Standard_E4ds_v5″,”Standard_E8ds_v5”. Overwrite it by using the following parameter: -allowedVMTypes @(“Standard_D4ds_v4″,”Standard_D8ds_v4”)
use -maintenanceWindowStartHour, -maintenanceWindowLengthInHours and –maintenanceWindowDay if you want to ignore performance data during a maintenance window (e.g. for patching) as that isn’t representative
Set an Azure Tag called LCRightSizeConfig with the value disabled on machines you want to ignore
Set an Azure Tag called LCRightSizeConfig with a machine type value (e.g. “Standard_D4ds_v4“) if you want to lock a specific size for that machine, this can be useful if you want the script to resize from current to target automatically when it runs while the VM has been deallocated.
Example -Verbose output of two VM’s being resized:
The module will check if there is sufficient data about the machine in Azure Monitor, if not, no action will be taken. You can determine how far back the function looks by modifying $measurePeriodHours
If you’re using the more recent Azure Monitoring agent, add the perf counters here:
Required access
Virtual Machine Contributor to the resource group(s) containing your VM’s and Log Analytics Reader on your log analytics workspace.
It is recommended to match job schedules to the lookback period, or at least not run multiple times in the same lookback period. Otherwise, the data that is being used for sizing may not be representative if the machine had already been resized in an earlier run.
Issues / notes
Make sure you’ve got enough data in Log Analytics
Make sure the allowedVMTypes list contains only VM types that you can actually upgrade to. If e.g. your VM has an ephemeral disk, and your allowList has types that do not, the resize will fail with an error message (but no harm will be done to the existing VM)
I’ve only tested the maintenance window parameters using UTC time, if you’re using different timezones your results in excluding data generated during the maintenance window may vary from mine