anyweb

I asked copilot and it gave me this response, try it !, if it works then you can just apply the registry key via a step in the task sequence just before it normally shows up Open Registry Editor: Press Win + R, type regedit, and press Enter. Navigate to the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE Create a new DWORD (32-bit) Value: Name it SkipMachineOOBE. Set its value to 1. Create another DWORD (32-bit) Value: Name it SkipUserOOBE. Set its value to 1. These changes should bypass the "Just a moment" screen during the OSD process.

I'd suggest you talk to your network team.

here's the error in CMTrace, you really should use that for reviewing any SCCM log as it highlights warnings and errors The text of interest is: Failed to download PXE variable file after 6 entries. Exit code=14. A quick google reveals that this could be because your VMware client is on a different subnet to that hosted by your PXE enabled distribution point, or that your router is handling subnets in an incorrect way.

you need to press F8 as soon as you the Configuration Manager wallpaper (see my screenshot below).... (also make sure command prompt/f8 support is enabled on the boot image) and grab the smsts.log in X:\Windows\Temp\SMSTSLog, in there you'll probably find out that the reason it's restarting is because of missing drivers or no task sequence advertised to these devices. you can post the log here once you have it, you can copy it off the machine using a usb key or map a network share using net use

I guess you were trying to ask a question, but in case you didn't know CMTrace.exe is already in the C:\Windows\CCM folder see here so as long as you have the ConfigMgr client installed, you'll also have CMTrace.

Introduction Last month I posted about my CMG (Cloud Management Gateway) going AWOL (absent without leave) and staying broken, this was in response to a tweet from Panu, and I documented the sorry story here. I tried many things including the hotfix that was available at the time of posting, but nothing helped. My CMG remained broken and stayed in a state of disconnected. I had planned on removing it entirely and recreating the CMG but time got the better of me. Today however I got a notification from Linkedin that someone had responded to one of my posts about that problem so I took a look. Steven mentioned a hotfix rollup (HFRU) and it was a new one. https://learn.microsoft.com/en-us/mem/configmgr/hotfix/2409/30385346 The issues fixed with this hotfix rollup are pasted from that article below, with the important CMG bits highlighted in bold italic: Issues that are fixed Internet based clients using the alternate content provider are unable to download content from a cloud management gateway or cloud distribution point. Deployment or auto upgrade of cloud management gateways can fail due to an incorrect content download link. Internet based clients can fail to communicate with a management point. The failure happens if the SMS Agent Host service (ccmexec.exe) on the management point terminates unexpectedly. Errors similar to the following are recorded in the LocationServices.log file on the clients. Console [CCMHTTP] ERROR INFO: StatusCode=500 StatusText=CMGConnector_InternalServerError The Configuration Manager console displays an exception when you check the properties of a Machine Orchestration Group (MOG). Membership of the MOG can’t be modified; it must be deleted and recreated. The exception happens when the only computer added to a MOG doesn’t have the Configuration Manager client installed. Hardware inventory collection on a client gets stuck in a loop if the SMS_Processor WMI class is enabled, and the processor has more than 128 logical processors per core. If a maintenance window is configured with Offset (days) value, it will fail to run on clients if the run date happens on the next month. Errors similar to the following are recorded in the UpdatesDeployment.log file. Console Failed to populate Servicewindow instance {GUID}, error 0x80070057 The spCleanupSideTable stored procedure fails to run and generates exceptions on Configuration Manager sites using SQL Server 2019 when recent SQL cumulative updates are applied. The dbo.Logs table contains the following error. Console "ERROR 6522, Level 16, State 1, Procedure spCleanupSideTable, Line 0, Message: A .NET Framework error occurred during execution of user-defined routine or aggregate "spCleanupSideTable": System.FormatException: Input string was not in a correct format. System.FormatException: at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) at Microsoft.SystemsManagementServer.SQLCLR.ChangeTracking.CleanupSideTable(String tableToClean, SqlInt64& rowsDeleted) ." Multiple URLs are updated to handle a back-end change to the content delivery network used for downloading Configuration Manager components and updates. The Configuration Manager console can terminate unexpectedly if a dialog contains the search field. This gave me some hope so I powered up that lab and took a look. As you can see the hotfix rollup is ready to install. Note: Yes I’m aware one of my app secrets is about to expire, that’s not part of this blog post or problem so I’ll ignore it for now. Before installing the hotfix rollup however I checked on the status of my CMG. And to my great surprise after weeks (a month even) of being broken and disconnected it was now………. connected. Uh… what ? Ok, that’s weird. I ran the connection analyzer as well just for giggles, and for the first time in a long time it passed with flying colours. As the server log files have unfortunately rolled over, I cannot see ‘when’ it self-fixed itself or whether that was on the backend (the CMG in Azure) or on the CM server itself. Just as a reminder, my now working CMG is in this state without me doing anything further after my original blog post, so it self fixed itself after many weeks of being broken. Installing the hotfix rollup To wrap things up, I decided I’ll install the hotfix rollup, to see what if anything it can do. And after some time it was done, however as you can see I still have 2 Configuration Manager 2409’s listed (one was the early ring upgrade). Well that’s it for this blog post, thanks Steven for the heads up on the hotfix rollup, however it didn’t resolve my issue, which seemed to solve itself prior to the rollup.

10 years actually

have you verified that the cert in your dp is updated also ? see step 5 here

ah great to hear it and thanks @Cerberus24 for posting your findings, i'm sure it'll help someone !

hi @Martinez in my #11 lab (domain controller) I have a DHCP server running, so any device that connects into that lab will receive a valid ip address I hope that helps cheers niall

Introduction Panu Sakku posted the following tweet recently asking if anyone noticed their CMG (Cloud Management Gateway) was broken after it got a recent update. I checked my lab, and sure enough, it was also dead in the water, and could not start. After checking the logs I replied to Panu. The errors in the SMS_CLOUD_PROXYCONNECTOR.log file in red were many, and here’s a paste of some of them to help others find out how to resolve this problem. ERROR: Web socket: Failed to online with Proxy server CLOUDATTACHCMG.AZURENOOB.COM:443. System.AggregateException: One or more errors occurred. —> System.Net.WebSockets.WebSocketException: Unable to connect to the remote server —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 20.126.223.196:443~~ at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)~~ at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)~~ at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)~~ — End of inner exception stack trace —~~ at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)~~ at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)~~— End of stack trace from previous location where exception was thrown —~~ at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()~~ at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)~~ at System.Net.WebSockets.ClientWebSocket.<ConnectAsyncCore>d__21.MoveNext()~~ — End of inner exception stack trace —~~ at System.Net.WebSockets.ClientWebSocket.<ConnectAsyncCore>d__21.MoveNext()~~ — End of inner exception stack trace —~~ at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)~~ at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.WebSocketConnection.Online()~~—> (Inner Exception #0) System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 20.126.223.196:443~~ at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)~~ at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)~~ at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)~~ — End of inner exception stack trace —~~ at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)~~ at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, and ERROR: Failed to build WebSocket connection 1800a2f4-5e7c-4aa7-9c5d-0b4027ab939d with server CLOUDATTACHCMG.AZURENOOB.COM:443. Exception: System.Net.WebException: Failed to online~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.WebSocketConnection.Online()~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.ConnectionBase.Start()~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.ConnectionManager.MaintainConnections() and ERROR: Failed to build HttpV2 connection 1800a2f4-5e7c-4aa7-9c5d-0b4027ab939d with server CLOUDATTACHCMG.AZURENOOB.COM:443. Exception: System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 20.126.223.196:443~~ at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)~~ at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)~~ at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)~~ — End of inner exception stack trace —~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.HttpConnectionV2.SendInternal(HttpMethod method, String path, String payload, Int32& statusCode, Byte[]& responsePayload)~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.HttpConnectionV2.SendInternal(HttpMethod method, String path, Byte[] payload)~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.HttpConnectionV2.Online()~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.ConnectionBase.Start()~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.ConnectionManager.MaintainConnections() Shortly after I replied, Johnny Radeck posted an update, he solved it by uninstalling an extension and then making a change to the CMG properties. But let’s see why he did that. If you go to the Azure portal and locate your CMG, you’ll see it’s got a Failed status (1). If you click Restart (2) after a few minutes it’ll be failed again but you’ll get a notification (3) explaining what failed. Failed to restart virtual machine scale set Failed to restart virtual machine scale set ‘cloudattachcmg’. Error: VM has reported a user failure when processing extension ‘InstallCMG’. Please correct the error and try again. (publisher ‘Microsoft.Compute’ and type ‘CustomScriptExtension’). Error code: ‘2’. Error message: ‘Command execution finished, but failed because it returned a non-zero exit code of: ‘1”. Detailed error: ”. More information on troubleshooting is available at https://aka.ms/VMExtensionCSEWindowsTroubleshoot. So it’s clear that Azure has problems starting the CMG due to “VM has reported a user failure when processing extension ‘InstallCMG’.” I wonder what the ‘user failure’ means ? Let’s try Johnny’s advice then. Fixing the problem ? Click on Settings, select Extensions + applications and then place a checkmark in InstallCMG, it’ll bring up it’s properties and you can now select Uninstall. The settings in that extension are listed here, just to see if they change after the fix. “commandToExecute”: “powershell.exe -File cmgsetup.ps1 -storageAccountName cloudattachcmg -storageEndpointSuffix core.windows.net -serviceName cloudattachcmg -serviceCName cloudattachcmg.azurenoob.com -certStoreName My -certThumbprint 2D2F89A0F44335C0D57678DA5AC80663660B0250 -crlAction enable -tls12Enforced True -nodeName localhost -bDisabledSharedKey True”, “fileUris”: [ “https://cloudattachcmg.blob.core.windows.net/stageartifacts/cmgsetup.ps1” ] } After a while it’ll be uninstalled and you’ll get a notification telling you that it’s done. After changing Client revocation settings, and changing the maintenance window to be in the future (otherwise you’ll get an error) before clicking Apply. A quick look at the CloudMgr.log reveals it’s updating the CMG and the status of the CMG in SCCM changes to Upgrading. while in Azure, the CMG has a status of Updating. and after a while everything should hopefully be fixed. Note: If it works for you, then don’t forget to set the client revocation option back on again. Oops In my case however, no matter how many times I tried my CMG remained well and truly broken. It’s still broken. I’ll update this post if/when I come up with a solution that works for me, but for now, this is just where I’m at with this problem and I’m blogging this as I’ve spent so many hours on it already.

if you have access to teams we can do a session to talk about this, ping me there niall AT windowsnoob DOT com, i'm based in Europe.

@Cerberus24 what client OS are you testing this on as a matter of interest? I'm, happy to do a remote session to compare my lab to yours but it would be good to get more info about your setup

and it's encrypting without any interaction from me

before getting bitlocker policy added the device to my bitlocker policy collection the client has determined it is 'non compliant' for Encryption

ok imaging done, device is NOT encrypted (as I wanted), next up, i'll add it to a collection targeted by BitLocker Encryption policy and see what happens

i'm imaging a VM now and will let it complete, once done i'll drop it un-encrypted into a collection targeted with BitLocker policy, i'll share my results here once done

i'll double check in my https 2409 lab this evening and report back have you verified that these devices are not targeted by any gpo from your 'old' mbam infrastructure ?

can you logon locally to a test device to verify encryption ?

hiya, is there any CD/DVD or iso mounted or present in a tray ? are you RDP'ing to the device when checking ? or logged on directly

Introduction This is Part 4 of a new series of guides which will cover managing Windows 365 Cloud PCs using PowerShell and Microsoft Graph. This mini series should help you get started with automating and managing your Cloud PCs using PowerShell via Microsoft Graph. If you are new to Windows 365 Cloud PCs then please read our previous series called Getting started with Windows 365 available here. At the time of writing, Paul is a 8 times Enterprise Mobility MVP based in the UK and Niall is a 14 times Enterprise Mobility & Windows and Devices MVP based in Sweden. Below you can find all parts in this series: Automating Windows 365 part 1 - Introducing Graph and setting up Visual Studio code Automating Windows 365 part 2 - Using Graph X-Ray Automating Windows 365 part 3 - Provisioning Cloud PC's Automating Windows 365 part 4 - Managing your Cloud PC <- you are here Automating Windows 365 part 5 - TBD In this part of our guide to managing Windows 365 Cloud PCs via PowerShell and Microsoft Graph, we'll cover the following management actions: Resize Restore Reprovision Restart Resizing your Windows 365 Cloud PCs The Resize remote action for Windows 365 Cloud PCs retains user and disk data which is very cool, and allows you the IT Admin to resize the users device as required based on usage or requests. The resize action allows you to: Upgrade the RAM, CPU, and storage capacity of a Cloud PC. Downgrade the RAM and CPU of a Cloud PC. Note: The resize option does not support reducing disk space. Also worth mentioning, you cannot resize a Frontline provisioned Cloud PC. The available options when attempting to resize your Cloud PCs are also based on the Windows 365 licenses you have in your tenant. For example, in our tenant we have the following licenses available: Windows 365 Enterprise 2 vCPU, 8 GB, 128 GB Windows 365 Enterprise 4 vCPU, 16 GB, 128 GB Windows 365 Enterprise 16 vCPU, 64 GB, 512 GB There are various resize options available but for this guide we'll upgrade from 2vCPU to 4vCPU, we cannot downgrade the disk space from 128GB to something smaller as this is not supported and we don't have the licenses available anyway. With that in mind in the Microsoft Intune admin under Devices > Device onboarding > Windows 365 > All Cloud PCs, if you select a device and choose Resize, you are presented with the options to Resize. Selecting an inappropriate option results in you being informed that the selected license is not available in your inventory as shown below in the screenshot. Keep this in mind when you attempt to resize your Cloud PCs via Graph. To get started with Resize via Graph and PowerShell, we need to list all the service plans available. Remember, these are not all the sizes available, just a list of them all. Using the following code, we can list all of those service plans, this uses the following cmdlet Get-MgBetaDeviceManagementVirtualEndpointServicePlan documented here. Install-Module Microsoft.Graph.Identity.DirectoryManagement -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Connect-MgGraph -Scopes "CloudPC.Read.All" Get-MgBetaDeviceManagementVirtualEndpointServicePlan -Property "id,displayName,type,vCpuCount,ramInGB,storageInGB,category,provisioningType,supportedSolution" Launch Visual Studio Code give it a go. The results will be displayed similar to the below output. To demonstrate the Resize action, we will upgrade one of our Cloud PCs, you can try this out on one of your own Windows 365 Cloud PCs by substituting the relevant service plan information. Currently, our Cloud PC is 2 vCPU, 8 GB, 128 GB as you can see below. Looking at the output from Graph for our service plans, we can see that we need service plan with the ID 2de9c682-ca3f-4f2b-b360-dfc4775db133 as this matches the subscription we have available. In the code below, we use the Get-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet, documented here, to retrieve the details of the device we are going to resize. Remember, you will need to change the ManagedDeviceName from CPCnM7PRJ to one of your own Cloud PC device names and select an available target service plan Id. We store the service plan information in the variable targetServicePlanId in the $params array. You will also need to change this to your target service plan ID. Finally, we issue the Resize-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet to kick start the resize process. Read about that cmdlet here. Install-Module Microsoft.Graph.Beta.DeviceManagement.Administration -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Connect-Graph -Scopes "CloudPC.ReadWrite.All" $cloudPc = Get-MgBetaDeviceManagementVirtualEndpointCloudPc | Where-Object { $_.ManagedDeviceName -eq "CPCnM7PRJ" } $params = @{ targetServicePlanId = "2de9c682-ca3f-4f2b-b360-dfc4775db133" } Resize-MgBetaDeviceManagementVirtualEndpointCloudPc -CloudPCId $cloudPC.Id -BodyParameter $params If you have picked a service plan which is not applicable, based on the criteria we have mentioned previously, you will receive a failure to resize when you view the device in the Intune admin center. If however you have executed the code against a valid target service plan, you will see the Resize action taking place in Intune. Return to the All Cloud PCs view under Devices > Device onboarding > Windows 365 > All Cloud PCs you will notice that the device will be listed with its Status as Resizing. After some time, the resizing operation will complete and this will be reflected under Device actions status when viewing the targeted device. In the screenshot below however you can also see that the old device model is listed. Triggering a Sync of the device or just waiting will update the model to the correct specs. In the All Cloud PCs view, the Status will now report as Provisioned and the PC type should reflect the new service plan. We can see below that the device does indeed have the new changes (CPU/RAM). Also, if the user attempts to access the Cloud PC from the Windows app or Windows 365 website, the size details of the Cloud PC will be reflected with the new resized information. Finally, the quick check on the Cloud PC itself confirms the change in CPU/RAM. The resize via Graph was a success! The Restore action via Graph In our previous Windows 365 series about Windows 365 we covered the Restore action, a feature specifically available to Cloud PCs. These restore points allow you, as the admin, to choose from a series of long or short term restore points. Long term restore points are saved every 7 days and there are a maximum of 4 long term restore points. Short term restore points are saved based on the user settings interval, so can be every 4, 6, 12, 16 or 24 hours. Read more about restore points at our blog post, here. You can view the available restore points for a device by navigating to Devices > Device onboarding > Windows 365 > All Cloud PCs in Intune. You then select a device and choose Restore from the menu. You are presented with a list of the available restore points which can be selected to revert the Cloud PC to. When managing our Cloud PCs for Restore via Graph, we need to begin by querying those restore points for our device. Start off by running the relevant modules and connecting to Graph. Next, you need to obtain the details of the Cloud PC you want to run the Restore action on. We are reusing our code from previous to do this by running the Get-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet and filtering on a specific hostname. Then we utilise the Get-MgBetaDeviceManagementVirtualEndpointCloudPcSnapshot cmdlet to gather all the snapshots for this Cloud PC. Read more about that cmdlet here. Install-Module Microsoft.Graph.Beta.DeviceManagement.Functions -Scope CurrentUser -Force -AllowClobber Install-Module Microsoft.Graph.Beta.DeviceManagement.Administration -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Functions Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" # Get Cloud PC $cloudPc = Get-MgBetaDeviceManagementVirtualEndpointCloudPc | Where-Object { $_.ManagedDeviceName -eq "CPCnM7PRJ" } # Fetch snapshots for the current Cloud PC $snapshots = Get-MgBetaDeviceManagementVirtualEndpointCloudPcSnapshot -CloudPcId $cloudPc.Id After executing, all the snapshots will be stored in the $snapshots variable. Let's say that we want to create a new snapshot for this Cloud PC. We can execute the New-MgBetaDeviceManagementVirtualEndpointCloudPcSnapshot cmdlet to achieve this. Details of this cmdlet are here. #Create a new snapshot New-MgBetaDeviceManagementVirtualEndpointCloudPcSnapshot -CloudPcId $cloudPc.Id In the Intune console, if you take a look at the targeted device you will see that Take Snapshot: Active is reported and initially in a Pending state before becoming Active. Once the Restore action of taking the snapshot is compete, the Device action status will be updated to reflect this. You can now re-run the Get-MgBetaDeviceManagementVirtualEndpointCloudPcSnapshot -CloudPcId $cloudPc.Id command to see the newly created, manual, snapshot listed. Likewise, in the Intune console, the snapshot will be listed. Note that the Restore point type will be listed as manual. OK, let's look at how you can restore to a specific restore point. You previously collected all the snapshots for a device and stored them in the $snapshots variable. You can use the ID from that data to run the restore. These are the ID's starting with CPC. Find the ID you want to use for your restore point and use the code below, changing the cloudPcSnapshotId details to match the ID of your snapshot. The code runs the Restore-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet to restore the Cloud PC. You can read about this cmdlet here. Install-Module Microsoft.Graph.Beta.DeviceManagement.Actions -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Actions $params = @{ cloudPcSnapshotId = "CPC_cea5e16c-bdda-4f5a-9742-7edc350a3243_db8e01ae-d20a-42d0-b81f-2f9af940705b" } Restore-MgBetaDeviceManagementVirtualEndpointCloudPc -CloudPCId $cloudPC.Id -BodyParameter $params Once again, check the device in the Intune console to observe the status of the action. Here you can see from the All Cloud PCs view that the device is Restoring. and the Device action status will show when that Restore action is complete. Whilst a restore takes place, the user is unable to access the Cloud PC. In the Windows app, or the Windows 365 website, the status of the device will report Restoring Cloud PC. How to Reprovision a Cloud PC with Graph Another action, which is unique to Windows 365 Cloud PCs, is Reprovision. This action effectively deletes a user's current Cloud PC and creates a brand new one for the same user. Note that all the user's data, applications, customisations, etc, are also removed as part of this process. The code, once again, utilize the Get-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet and, as before, remember to change the name of the Cloud PC to match your device. To reprovision the device you simply need to run the Invoke-MgBetaReprovisionDeviceManagementVirtualEndpointCloudPc cmdlet against that Cloud PC. Read about that cmdlet here. Install-Module Microsoft.Graph.Beta.DeviceManagement.Actions -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Actions Install-Module Microsoft.Graph.Beta.DeviceManagement.Administration -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" # Get Cloud PC $cloudPc = Get-MgBetaDeviceManagementVirtualEndpointCloudPc | Where-Object { $_.ManagedDeviceName -eq "CPCnTGYOI" } # Reprovison the device Invoke-MgBetaReprovisionDeviceManagementVirtualEndpointCloudPc -CloudPCId $cloudPC.Id Let's check the Intune console once again for the status of the Reprovision action. You will see it reporting as Active in the device view. In the All Cloud PCs view it will state Provisioning in the Status column. Since our Cloud PCs using a random naming template, the device will be created with a new name. In our case the device is now called CPCn4D8PH. Finally, in the device view, the reprovisioning will be marked as Completed. Restarting a Cloud PC As with the reprovisioning via Graph, the Restart action is fairly simple to implement. The Restart device action initiates a reboot of the selected device within five minutes. Keep in mind that the device owner won't receive an automatic notification, which could result in unsaved work being lost. Since we provisioned the Cloud PC previously, we have updated the hostname in our command to get the Cloud PC via the Get-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet. Be aware of that if you have followed along and also reprovisioned prior to running this action. As mentioned, the reprovision action may have changed the device name. With details of the Cloud PC gathered, you can execute the Restart-MgBetaDeviceManagementVirtualEndpointCloudPc cmdlet. Details here. Install-Module Microsoft.Graph.Beta.DeviceManagement.Actions -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Actions Install-Module Microsoft.Graph.Beta.DeviceManagement.Administration -Scope CurrentUser -Force -AllowClobber Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" # Get Cloud PC $cloudPc = Get-MgBetaDeviceManagementVirtualEndpointCloudPc | Where-Object { $_.ManagedDeviceName -eq "W365-5AMXD" } # Restart the device Restart-MgBetaDeviceManagementVirtualEndpointCloudPc -CloudPCId $cloudPC.Id The device will report as Restart: Active in the device view in the Intune console. As mentioned, the user will get disconnected from their Cloud PC. and when the action is complete, it will be reported as such in the Intune console and the user will be able to log back into their device. Summary Managing your Cloud PCs via Microsoft Graph is super simple and we have showed you how you can run effective code to execute the resize, restore, reprovision and restart actions against a specific device. You can take the code provided and expand this to create scripts which could run these actions against a collection of devices, similar to the Bulk actions options available in the Microsoft Intune admin center.

if they click cancel then the required task sequence will not run and it will want to reboot the computer

check your messenger

thanks for sharing !

I have the following prerequisites, take your pick