Windows 365 Boot
Hi folks – Mike Hildebrand here! It’s the July 4 th holiday here in the good 'ol USA and happens to also be our country’s 250 th birthday … and where I live, that means it’s probably hot. VERY hot. So, I’m taking some time to enjoy the A/C and type up a ‘cool’ post about a ‘cool’ solution. In the land of Windows 365, there are a couple of physical endpoint connectivity options – the Windows App or browser from any device and thin-client or other purpose-built devices, like our own Link (and one soon coming from Asus). We also have another option called Windows 365 Boot. In this nifty little situation, we take a full-throated Windows 11 device and apply policy from Intune to transform the shell and other settings into a Link-like experience. NOTE: For a long time, the Boot configuration process was only configurable via a ‘black-box’ guided flow in the Intune portal – and that works just fine. However, after an update of docs and the Intune Settings Catalog, the W365 Boot configurations can now be hand-carved like all of your other Intune configuration policies. Recently, I was part of a customer conversation where they had a substantial quantity of Flex Dedicated CPCs used by rotating call center staff and accessed from a fleet of Windows 11 PCs deployed at hot-desk stations. They wondered about a model to simplify and streamline access directly to the CPCs, bypassing the local Windows OS, which wasn’t used/needed and sometimes caused confusion. The physical devices were still ‘current’ and had a lot of life left (i.e. warranty coverage, driver and firmware support, parts availability, etc.) - and due to the price-jumps of new devices, it made ‘dollars and sense’ ( 🙂 ) to leverage that investment and re-purpose them. They also wondered if they could use Autopilot in ‘Self-deploy’ mode to further automate the deployment process for these endpoints. “Let’s try it out” I proposed a rapid, off-the-cuff ‘right now’ PoC to try out the W365 Boot scenario in their environment and they were up for it. These days, it’s common and easy to perform carefully controlled ‘production pilots’ to more accurately validate the proposed experience. NOTE: Since the customer already had Entra, Intune, and modern management in steady-state operations for quite some time, we were able to make this idea very real, very fast. We reset a few of the test PCs they use for their hot-desks and uploaded them into Autopilot via the Get-WindowsAutopilotInfo PowerShell script and the -online switch. Entra – Create a Device Group We created a device group in Entra for the PoC Boot devices and added the Autopilot-uploaded test devices into it as members This group was used by Intune to target several different elements of the PoC: o An Autopilot Self-deployment Profile - for an almost zero-touch rollout o An Enrollment Status Page (ESP) profile - to prevent access to the Boot device until the Windows App is installed o The Windows App – used by the Boot device to connect to Cloud PCs o A W365 Boot Configuration Profile to transform the Windows 11 OS into a W365 Boot device Intune - Autopilot Self-deploy Profile We created an Autopilot ‘self-deployment’ profile via Intune, to automatically enroll the physical endpoints at the call center desks. Autopilot self-deploy requires very little interaction at the endpoint - plug in power, connect to network and turn it on. o There are some specific URLs and other requirements for Autopilot Self-deploy devices so be sure to check this (i.e. you can’t use Hyper-V VMs) https://learn.microsoft.com/en-us/autopilot/self-deploying Intune – Enrollment Status Page We created an ESP targeted at the device group to block access to the Boot devices until the Windows App is installed. Intune – Windows App They already deploy the Windows App to ‘All Devices,’ so this step was easy 😊 The key thing here is make sure it installs in the ‘System’ context: Intune - Boot Device Configuration Policy We created a very simple Configuration Policy (two settings from the Settings Catalog – that’s it) in Intune to transform these self-deployed endpoints into “Shared PC Mode” Windows 365 Boot devices. These have minimal ‘end user’ configurations/apps because they boot to the W365 purpose-specific ‘cloud shell’ – which allows the user to sign in to the Boot device and be directly SSO’d into their CPC. NOTE: The ‘Boot to Cloud PC Enhanced’ setting includes many other settings/behaviors but they’re all bundled up which makes it super easy to deploy this NOTE: If the ‘Personalization > Company Name’ setting isn’t used, you’ll see ‘Cloud PC’ at the sign in screen Self-deploy…oh the joy! Plug it in; turn it on … Autopilot Self-deploy OOBE screen, followed by a brief ESP NOTE: As part of the Autopilot deployment profile, a device naming template was applied and the devices were renamed; this was reflected in various portals/UIs Before: After: “So, what does it look like for the users?” I thought you’d never ask! A PIN, a touch and TA DA! NOTE: The org already was using FIDO2 for these users, so they insert their FIDO2 key to the Boot device, enter the PIN for it, touch it for ‘proof of presence’ - and that’s it. No long username to type in; no long password to remember/type; no additional prompts. The users glide right through to their CPC desktop. NOTE: Hello for Business (H4B) is supported for the “Dedicated Mode” Boot deployment option but since we used the “Shared PC Mode” setting, where H4B is not supported, we didn’t test. Maybe official H4B support will come later to Shared PC Mode, but given how easy FIDO2 is, and the fact that the target users already use FIDO keys, we didn’t spend any more time on H4B. At the end of the shift, disconnect the session from the CPC desktop to get back to the Boot sign in screen: A few FAQs “What if a user has more than one CPC?” Connection Center is supported via Boot – here’s one of my demo users, using Boot w/ more than one CPC: Further, you can select ‘Connect automatically’ from the three dots of a specific CPC’s card; then you’ll always bypass the Connection Center and get SSO’d right into that one. o To get back to the Connection Center from the Cloud PC, you can use the hotkey combo of <Ctrl> + <Windows key> + <Up Arrow> o BONUS SECRET HOTKEY COMBO (just between us) – For detailed connection info, from the Cloud PC: <Ctrl> + <Windows key> + <Down Arrow> “Can I customize the look and feel of the Boot sign in experience?” Yes – There are policy settings for a custom icon, company name and wallpapers to help differentiate Boot devices from other PCs/devices. o Personalization CSP | Microsoft Learn TIP: those docs indicate needing to use a URL for files – you can use this syntax for local content already on the device: file:///C:/Folder/File.jpg There you have it, folks … Windows 365 Boot (or, DAS BOOT!! as I like to sometimes yell) … in the form of a quick PoC. P.S. A special shout-out is in order for Mr. Liu for his assistance and appreciation of the Boot scenarios. Stay cool out there… HildeWindows 365 Link – Deployment Planning, Setup and Enrollment
Introduction and Initial Thoughts The Windows 365 Link is a neat little purpose-built device, designed to enable easy deployment and simple, secure access to your Windows 365 Cloud PCs. The Link device is a ‘last mile’ endpoint device; there are pre-requisites that need to be in place in Intune, Entra and Windows 365 for both deployment of Link, as well as on-going use of Link to access Cloud PCs. In many cases, where Intune, Entra and Windows 365 are in ‘Production’ use in typical enterprise environments, many/most of the pre-reqs will already be met – but not always. Lastly, it is easy to forget that “Entra Join” and “Intune enrollment” are separate backend actions, occurring separately, in separate services and with different limits and controls All that to say, your current tenant configurations might allow you to successfully deploy Link devices, right now. If you’re feeling lucky, give it a try; otherwise, read on… Deployment Model – User-driven or Admin-driven User-driven – a given end-user goes thru OOBE and moments later, device is Entra joined, and Intune enrolled. The user is passed right into her CPC (or the ‘CPC chooser’ if she has more than one assigned). IMPORTANT: If Link is enrolled this way, by a typical end user: It will be listed (and renamable and resettable) in that user’s Company Portal device list. If the Link device is going to be shared, you might not want the enrolling user to be able to reset or rename it as that could impact others use of the Link device. Link devices start off as ‘personal’ Windows devices. You may need to adjust your Intune tenant’s Windows device platform enrollment restrictions to accommodate for this. Otherwise, you’ll probably encounter this failure during enrollment: To address this, you can either: Upload a “Corporate device identifiers” CSV file into Intune with the Link device info (probably the simplest way to deal with this situation): OR Set the default policy to “Allow” personally owned Windows devices to enroll (not common in enterprise environments) OR If you’ve set the default policy to “Block” personally owned Windows devices from enrolling (common in enterprises): You can create a subsequent “Device Platform Enrollment Restriction Policy” and set the Windows platform to “Allow” personally owned devices, then assign the Policy to ‘All Users’ (or a group of users) and use an Intune filter (discussed further below) to Include the Link devices Admin-driven - a DEM ID is used to go through OOBE and moments later, device is Entra joined and Intune enrolled and then the device is ready for users to access their CPCs DEM IDs are ‘normal’ Entra IDs that are marked specially in Intune and are: o Limited to the Entra join settings defined in the Entra portal o Limited to enroll up to 1000 devices into Intune - but not bound by the Intune device enrollment limit settings defined in the Intune portal o Exempt from Intune “Device Platform Enrollment Restrictions” Because of these conditions and depending on your tenant settings, you might need to create more than one DEM ID if you need to deploy 100s or 1000s of Link devices (maybe create “one DEM ID per location” or “one DEM ID for each “batch” of Link deployments or something similar). Also, consider your DEM ID naming standards (i.e. DEM-LNK-01) and be sure to have processes in place to exempt the DEM IDs from being cleaned up/purged; deleting DEM IDs used to deploy active devices is a no-no: NOTE: Since DEM IDs generally don’t have a CPC provisioned/licensed, there is an error after the OOBE/Entra join/Intune enrollment completes – just click ‘Sign out’ and the link will return to the Sign in screen: Review Existing Tenant Configurations Entra settings Limits to Entra Join device counts- limits apply to all users (incl DEM IDs) NOTE: ‘Custom’ can be any value up to 100: Authentication Methods – managed via Entra; apply to both enrollment of the Link, as well as day-to-day use to access Cloud PCs For enrollment, username + password is the default but you can use others by clicking ‘Sign-in options’ on the OOBE screen (i.e. a FIDO2 key): For day to day use you can use two options (a) Web sign in – by default, and out of the box, username ('Email) and password is available (b) FIDO2 key – you’ll need to enable the “Use Security Key For Signin” setting via Intune and target the Link devices before the security key icon/option will show up. Intune settings Limits to Intune enrollments – limits for users (up to 15); DEM IDs ignore these limits (each DEM can enroll up to 1000 devices) Additional Considerations and FAQs Link device names can’t be customized/edited during deployment, but the devices can be renamed via Company Portal or the Intune Portal, after deployment, if desired: “CALL-CTR-01” “ALEXW-LNK-01” “Do Link devices on-board to Microsoft Defender for Endpoint?” If your existing Intune tenant is configured to on-board devices into MDE, then yes However, the MDE agent, AV settings, etc. are NOT active within the OS – you’ll just see a device record in MDE with some device telemetry “Do I need to configure Link devices for Windows Update settings, rings, etc.?” No, the Link OS has local Windows Updates settings defined to check for OS and firmware Updates, each night at 3:00 am local time. If the device is in a ‘sleep’ state, the OS will wake itself and check for Updates, including firmware. NOTE: this wakeup only checks for Updates – it doesn’t wake the MDM stack in the OS nor check-in to Intune if it’s in a ‘sleep’ state. NOTE: a manual check for Updates can be done from the device “What are the most-common policy settings that aren't OS defaults?” The following common power and privacy settings can be changed via Intune as shown: Set the device’s 5-minute default screen time out (set to 1 hr/3600 seconds in the policy below) Set the device’s location service to discover and auto-set the local-to-the-Link time zone Set the device’s Power Management settings to prevent it from going to ‘sleep’ IMPORTANT: As mentioned above, a Link that’s in a ‘sleep’ state isn't remotely admin-manageable from the Intune portal “How do I create an Assignment Filter for Link in Intune?” “Can I turn off physical capabilities on the device?” Yes - take a look here for UEFI controls to manage ports and configurations at the firmware level Manage firmware settings for Windows 365 Link devices. | Microsoft Learn “Does SSO work to get me signed into the Link and right into my Cloud PC?” Indeed, it does! Just make sure SSO is enabled and working for the CPCs Realize this requires more than just the checkbox in the CPC Provisioning Policy; review additional SSO setup Unbox and Connect In the box is the device, a power brick and a power cord Ports Front 1 - standard headphone jack 1 – USB-A port Power light Power button Back 1 - USB-C port 2 - USB-A ports 1 - DisplayPort 1 - HDMI port 1 - RJ-45/LAN 1 - Power jack Here's my desktop setup for this article: En'Roll the Bones After plugging it all in, turn it on and at OOBE, click ‘Next’ NOTE: You’ll see the Wi-Fi connection UI if not using a physical network cable Enter ID and pwd or click ‘Sign-in options’ for different sign in method (i.e. FIDO2): NOTE: Even though ‘Domain join instead’ is listed there as a Sign-in option, it doesn't work and isn’t supported For those more inclined to 'Moving Pictures' ... Full enrollment + Link Sign-in + CPC SSO + disconnect - NOTE: this first vid SEEMS 'long' but I'd argue it's actually amazingly fast (Entra Join + Intune Enrollment + CPC sign in + close Evernote + Disconnect) ... ~1 minute and 30 sec 😎 Link Sign-in + CPC SSO + Disconnect ~30 seconds NOTE: Right-click the vid > 'Refresh' to watch again A Few Other Resources Setup vid (first 6 min are overview; setup starts around 6 min mark) https://www.youtube.com/watch?v=joec9L6EeqU&t=4s Docs - https://learn.microsoft.com/en-us/windows-365/link/ That's a Wrap! If you can't tell, I think the Link is a great device that continues to expand the Windows 365 solution. I hope these details help you as you try them out in your environment. Drop a note into the comments and share how your Windows 365 journey is going. Also, a couple of shout-outs - AJ for allowing me to 'borrow' the Link device (good luck getting it back); Dan Ram for validating scenarios and details; Mr. Shannon and Matt A. for their Link help and Brandon Wilson for helping (as always) w/ blog snafus. Cheers! Hilde
Creating Custom Intune Reports with Microsoft Graph API
Systems administrators often need to be able to report on data that is not available in the native reports in the Intune console. In many cases this data is available to them through Microsoft Graph. However, in some instances administrators may need to pull data from other sources or store it for tracking trends over time. For example, generating a custom dashboard to track Windows 365 license costs requires pulling data from Microsoft Graph and combining it with licensing details that are not available in Graph, but may be stored in another location (an IT Asset Management Tool for example). The Windows 365 Cost Dashboard is an example of how you can combine Intune data from Microsoft Graph with information pulled from another source. This guide provides step-by-step instructions to pull data from Microsoft Graph API, ingest it to Azure Log Analytics, and connect to your workspace with Power Bi. This solution demonstrates how to gather and store Graph API data externally for richer reporting and integrate it with data from an additional data source to produce a dashboard tailored to your unique needs. By using this dashboard as an example, administrators can unlock deeper insights while leveraging Intune's powerful foundation. The solution: This dashboard and the accompanying PowerShell script are meant to demonstrate an end-to-end example of gathering data from Microsoft Graph and ultimately being able to visualize it in a Power Bi dashboard. While it does create the Azure Infrastructure needed to complete the scenario in the demonstration, it can be extended to gather and report additional information. What does this do? This example consists of two separate pieces – the Power Bi dashboard and a PowerShell script that creates all the Azure resources needed to gather data from Microsoft Graph and ingest it into a Log Analytics workbook. This post will discuss all of the infrastructure elements that are created and the steps to get your data from Log Analytics into the Power Bi dashboard, but I want to strip away all of the “extra” elements and talk about the most important part of the process first. Prerequisites The scripts shared in this blog post assume that you already have an Azure subscription and a resource group configured. You need to have an account with the role of “Owner” on the resource group (or equivalent permissions) to create resources and assign roles. The account will also need to have the “Application Developer” role in Entra Active Directory to create an App Registration. To run the resource creation script, you will need to have several modules available in PowerShell. To see the full list please review the script on GitHub. From Microsoft Graph API to Log Analytics: How we get there Microsoft Graph API can give us a picture of what our environment looks like right now. Reporting on data over time requires gathering data from Graph and storing it in another repository. This example uses a PowerShell script running in Azure Automation, but there are several different ways to accomplish this task. Let’s explore the underlying process first, and then we can review the overall scope of the script used in the example. The Azure Automation runbook [CloudPCDataCollection] calls Graph API to return details about each Windows 365 Cloud PC. It does this by making GET requests to the following endpoints: https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs https://graph.microsoft.com/v1.0/users/<userPrincipalName> As a best practice, we should only return the properties from an API endpoint that we need. To do that, we can append a select query to the end of the URI. Queries allow us to customize requests that are made to Microsoft Graph. You can learn more about Select (and other query operators) here. The example dashboard allows you to report on Windows 365 cost over time based on properties of the device (the provisioning policy, for example), or the primary user (department). We will request the Cloud PCs id, display name, primary user’s UPN, the service plan name and id (needed to cross reference our pricing table in Power Bi), the Provisioning Policy name, and the type (Enterprise, Frontline dedicated, or Frontline Shared). The complete URI to return a list of Cloud PCs is: https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs?$select=id,displayName,userPrincipalName,servicePlanName,servicePlanId,ProvisioningPolicyName,ProvisioningType Once we have a list of Cloud PCs, we need to find the primary user for each device. We can return a specific user by replacing the <userPrincipalName> value in the users URI above with the primary user UPN for a specific Cloud PC. Since we only need the department, we will minimize the results by only selecting the userPrincipalName (for troubleshooting), and department. The complete URI is: https://graph.microsoft.com/v1.0/users/<userPrincipalName>?$select=userPrincipalName,department Data sent to a data collection endpoint needs to be formatted correctly. Requests that don’t match the required format will fail. In this case, we need to create a JSON payload. The properties in the payload need to match the order of the properties in the data collection rule (explained later) and the property names are case sensitive. The automation script handles the creation of the JSON object, including matching the case and order requirements as shown here: # Get Cloud PCs from Graph try { $payload = @() $cloudPCs = Invoke-RestMethod -Uri 'https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs?$select=id,displayName,userPrincipalName,servicePlanName,servicePlanId,ProvisioningPolicyName,ProvisioningType' -Headers @{Authorization="Bearer $($graphBearerToken.access_token)"} $CloudPCArray= @() $CloudPCs.value | ForEach-Object { $CloudPCArray += [PSCustomObject]@{ Id = $_.id DisplayName = $_.displayName UserPrincipalName = $_.userPrincipalName ServicePlanName = $_.servicePlanName ServicePlanId = $_.servicePlanId ProvisioningPolicyName = $_.ProvisioningPolicyName ProvisioningType = $_.ProvisioningType } } # Prepare payload foreach ($CloudPC in $CloudPCArray) { If($null -ne $CloudPC.UserPrincipalName){ try { $UPN = $CloudPc.userPrincipalName $URI = "https://graph.microsoft.com/v1.0/users/$UPN" + '?$select=userPrincipalName,department' $userObj = Invoke-RestMethod -Method GET -Uri $URI -Headers @{Authorization="Bearer $($graphBearerToken.access_token)"} $userDepartment = $UserObj.Department } catch { $userDepartment = "[User department not found]" } } else { $userDepartment = "[Shared - Not Applicable]" } $CloudPC | Add-Member -MemberType NoteProperty -Name Department -Value $userDepartment $CloudPC | Add-Member -MemberType NoteProperty -Name TimeGenerated -Value (Get-Date).ToUniversalTime().ToString("o") $payload += $CloudPC } } catch { throw "Error retrieving Cloud PCs or user department: $_" } After the payload has been generated, the script sends it to a data collection endpoint using a URI that is generated by the setup script. # Send data to Log Analytics try { $ingestionUri = "$logIngestionUrl/dataCollectionRules/$dcrImmutableId/streams/$streamDeclarationName`?api-version=2023-01-01" $ingestionToken = (Get-AzAccessToken -ResourceUrl 'https://monitor.azure.com//.default').Token Invoke-RestMethod -Uri $ingestionUri -Method Post -Headers @{Authorization="Bearer $ingestionToken"} -Body ($payload | ConvertTo-Json -Depth 10) -ContentType 'application/json' Write-Output "Data sent to Log Analytics." } catch { throw "Error sending data to Log Analytics: $_" } Getting access tokens with a managed identity Security should be top of mind for any Systems Administrator. When making API calls to Microsoft Graph, Azure, and other resources you may need to provide an access token in the request. Access to resources controlled with an App Registration in Entra. In the past, this required using either a certificate or client secret. Both options create management overhead, and client secrets that are hard coded in scripts present a considerable security risk. Managed identities are managed entirely by Entra. There is no requirement for an administrator to manage certificates or client secrets, and credentials are never exposed. Entra recently introduced the ability to assign a User-assigned managed identity as a federated credential on an App Registration. This means that a managed identity can now be used to generate an access token for Microsoft Graph and other azure resources. You can read more about adding the managed identity as a federated credential here. Requesting an access token via federated credentials happens in two steps. First, the script uses the managed identity to request a special token scoped for the endpoint ‘api://AzureADTokenExchange'. #region Step 2 - Authenticate as the user assigned identity #This is designed to run in Azure Automation; $env:IDENTITY_header and $env:IDENTITY_ENDPOINT are set by the Azure Automation service. try { $accessToken = Invoke-RestMethod $env:IDENTITY_ENDPOINT -Method 'POST' -Headers @{ 'Metadata' = 'true' 'X-IDENTITY-HEADER' = $env:IDENTITY_HEADER } -ContentType 'application/x-www-form-urlencoded' -Body @{ 'resource' = 'api://AzureADTokenExchange' 'client_id' = $UAIClientId } if(-not $accessToken.access_token) { throw "Failed to acquire access token" } else { Write-Output "Successfully acquired access token for user assigned identity" } } catch { throw "Error acquiring access token: $_" } #endregion That token is then exchanged in a second request to the authentication endpoint in the Entra tenant for a token that is scoped to access 'https://graph.microsoft.com/.default' in the context of the App Registration. #region Step 3 - Exchange the access token from step 2 for a token in the target tenant using the app registration try { $graphBearerToken = Invoke-RestMethod "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" -Method 'POST' -Body @{ client_id = $appClientId scope = 'https://graph.microsoft.com/.default' grant_type = "client_credentials" client_assertion_type = "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" client_assertion = $accessToken.access_token } if(-not $graphBearerToken.access_token) { throw "Failed to acquire Bearer token for Microsoft Graph API" } else { Write-Output "Successfully acquired Bearer token for Microsoft Graph API" } } catch { throw "Error acquiring Microsoft Graph API token: $_" } #endregion Azure Resource Creation Script The PowerShell script included in this example will complete the following tasks: Creates a Log Analytics Workspace Define a custom table in the newly created workspace to store Cloud PC data Configure a data collection endpoint and data collection rule to ingest data into the custom table Create an Azure Automation account and runbook to retrieve data from Microsoft Graph and send it to the data collection endpoint Establish a User Assigned Managed Identity to run the data collection script from Azure Automation Register an App and assign a service principal with required Microsoft Graph permissions Add the Managed Identity as a federated credential within the App Registration Assign workbook operator and Monitoring Metrics Publisher roles to the Managed Identity Steps to Implement: 1. Download the script and Power BI Dashboard: Download the Power Bi dashboard and PowerShell script from GitHub: Windows 365 Custom Report Dashboard 2. Update Variables: Modify the PowerShell script to include your Tenant ID, Resource Group Name, and location Adjust other variables to fit your specific use case while adhering to Azure naming conventions 3. Run the PowerShell Script: Execute the script to create the necessary Azure resources and configurations. 4. Verify Resource Creation: Log into the Azure Portal. Navigate to Log Analytics and confirm the creation of the W365CustomReporting workspace. Click on Settings > Tables and confirm the W365_CloudPCs_CL table was created Search for Automation Accounts and locate AzAut-CustomReporting. 5. Run the Runbook and Pull Data into Log Analytics: Open the CloudPCDataCollection runbook, select Edit > Edit in portal and the click on Test Pane. Click start to test the CloudPCDataCollection runbook and ensure data ingestion into Log Analytics. The runbook may take several minutes to run. You should see a “Completed” status message and the output should include, “Data sent to Log Analytics.” Return to the Log Analytics workspace and select “Logs.” Click on the table icon in the upper left corner of the query window. Select Custom Logs > W365_CloudPCs_CL and click on “Run.” (Please note: initial data ingestion may take several minutes to complete. If the table is not available, please check later.) The table Logs should populate with data from the last 24 hours by default. Click on Share > Export to Power BI (as an M query)Export the data to Power BI using an M query. The file should download. Open the file to view the completed query. Select the contents of the file and copy it to the clipboard. 6. Import Data into Power BI Dashboard: Open the Power BI template. In the table view on the right side of the screen, right click on the CloudPCs table and select “Edit Query.” Click on “Advanced Editor” on the ribbon to edit the query. Paste the contents of the downloaded M Query file in the editor and click “Done.” A preview of your data should appear. We need to make sure the columns match the data in the template. Right click on the “Time Generated” column and select Transform > Date Only. Right click on the same column and select “Rename.” Rename the column to “Date” Click “Close and Apply” to apply your changes and update the dashboard. 7. Update the Pricing and Service Plan Details table (Optional) The Pricing and Service Plan Details table was created via manual data entry, which allows for it to be updated directly within Power BI. To update the dashboard with your pricing information, right click on PricingAndServicePlanDetails table and select edit query Click on the gear icon to the right of “Source” Find the SKU Id that matches the Windows 365 Enterprise or Frontline licenses in your tenant; update the price column to match your pricing 8. (Optional) Update the timespan on the imported M query to view data over a longer period When we initially viewed the logs in Log Analytics, we left the time period set with the default value, “Last 24 Hours.” That means that the query that was created will only show data from the last day, even if the runbook has been configured to run on a schedule. We can edit that behavior by updating the table query. Edit the Cloud PCs table as you did before. In the advanced editor find the “Timespan” property. The Timespan value uses ISO 8601 durations to select data over a specific period. For example, “P1D” will show data from the previous 1 day. The past year would be represented by “P1Y” or “P365D”. Learn more about ISO 8601 duration format here: ISO 8601 - Wikipedia Please note that this query can only return data that is stored in Log Analytics. If you set it to “P1Y,” but only have collected information from the past month, you will still only see 1 month worth of data. Parting thoughts This example demonstrates how a systems administrator can leverage Microsoft Graph, Azure Log Analytics, and Power Bi to create custom reports. The script provided creates all the required resources to create your own custom reports. You can leverage the concepts used in this example to add additional data sources and expand your Log Analytics workbooks (by adding additional columns or tables) to store other data pulled from Microsoft Graph. By following this example, Systems Administrators can build custom Intune reports that integrate data from Microsoft Graph and external sources. This solution provides comprehensive, historical reporting, helping organizations gain valuable insights into their IT environments. Additional Credit: The script to create resources was adapted from the process described by Harjit Singh here: Ingest Custom Data into Azure Log Analytics via API Using PowerShell. Please visit that post for additional information on creating the underlying resources. Limitations: This example is not intended to be ready for production use. While the script creates the underlying infrastructure, it does not automatically schedule the Azure Automation runbook, nor does it change the default retention period in Log Analytics beyond 30 days. The use of Log Analytics and Azure Automation can incur charges. You should follow your organization’s guidelines when scheduling runbooks or updating retention policies. The pricing details table was created based on the Windows 365 SKUs listed on the Product names and service plan identifiers for licensing and the corresponding retail prices for Windows 365 Enterprise and Frontline as of February 26, 2025. You may need to update the pricing details to match your license costs or connect to an outside data source where your license details are stored to accurately reflect your cost details. Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.Windows 365 Enterprise – Points of Clarification and PoC Proven Practices
It took me a while to get my head around some of the technical aspects of Windows 365 Enterprise. Here, I'll share my own confusions, some common questions encountered in the field and tips for success with Windows 365 Enterprise. I've also included a planning document to help plan your efforts and a high-level visual aid.
