Therefore, another runbook you may run to just report on your inactive devices, or to automatically (and optionally periodically) clean up inactive devices in your environment when the removeInactiveDevices switch is supplied.
When run locally, interactive sign in is required. When running as a runbook in Azure automation, the Managed Identity of the automation account is leveraged. This requires you to set Device.ReadWrite.All or Device.Read.All permissions depending on if you want to script to do the cleanup as well.
Autopilot / on premises devices
Note that the script will log an error (and not attempt to delete the device) when a device is an autopilot record (not a real device) or when the device is synced from an on-premises active directory.
Microsoft started using these properties in april 2020, so accounts active before that will seem like they have never been active.
This script supports running non-interactive as a runbook in Azure Automation if you supply the -nonInteractive switch. Before this will work, you’ll have to enable Managed Identity on your automation account and run a small script to assign graph permissions to the Managed Identity: AuditLog.Read.All and Organization.Read.All
As always this script is provided as-is and should be reviewed and then used at your own risk.
With the introduction of Onedrive Sync Heath in the Office portal, we have a much improved view on sync errors of our users. Errors they may not even be aware of.
However, there is no remediation option, so I am sharing a framework based on previous work in Proactive Remediations that can report on the Onedrive client status and trigger a remediation, which looks like this:
Currently, the only remediation method is to restart the Onedrive client, but the script is easily adjusted for additional remediation actions or conditions the community deems useful.
When Paused or Disabled are detected, there is no remediation as this is not technically an error but something the user manually set. This can be adjusted to your local needs easily.
You can find the Proactive Remediation script on Gitlab:
FSLogix, the defacto profile management solution for Azure Virtual Desktop, allows you to easily roam profiles between different Azure Virtual Desktops.
A solution to convert profiles to FSLogix profiles is available, but for the reverse, I couldn’t find anything.
In some situations, e.g. dedicated VDI’s, a local profile may perform better and reduce infrastructure complexity (no share required). Especially in larger environments with thousands of VDI’s the required performance of the profile share is very high.
I wanted to test converting / migrating back from FSLogix profiles to local profiles on a specific machine, which resulted in a simple PowerShell script that can be executed using Run Command or by an admin on the VM.
It mounts the profile of a given user, copies the data to the local VM, unmounts the profile (so the profile is not deleted!) and sets a bunch of registry keys to properly connect the local profile and disable FSLogix roaming on that VM for that user.
Another week, another use case for Managed Identities in Automation Accounts!
The scenario today concerns a PowerApp and connected resources that should be shared with external identities, automatically of course. For each user this requires a guest account in the host / resource tenant, and a license. The license can be applied in the home tenant of the guest, or in your tenant.
Runbook that invites a user and adds the resulting guest account to a security group
Security group gives access to the PowerApp and underlying (SpO) resources, and uses Group Based Licensing to license the guest for PowerApps and Sharepoint Online
Logic App that is triggered by the PowerApp (trigger on create item in a sharepoint list), and starts the runbook
When the invited user (guest) redeems the invitation, they are directed to a Sharepoint page first so Sharepoint syncs their profile. Otherwise, the PowerApp will not have access to any lists in Sharepoint Online as Guests are not synced to SpO until they access SpO directly.
I may demo the PowerApp, Logic App and Sharepoint lists at some point, but the main thing I wanted to share today is the Azure Runbook that creates the Guest invitation and adds the Guest to a security group using the Managed Identity of the Automation account, instead of service accounts or other pre-2021 solutions: