Truly Remote Wiping and Setup

[Dr_Snooze]

I'm looking for a way to wipe and re-configure my Win10/11 endpoints without losing remote access afterward. My endpoints are all AAD-joined and Intune (MEM)-managed with remote access through ConnectWise Control. Yet for all that, I'm unable to complete a device wipe and reconfigure remotely. When I wipe, I choose the "keep enrollment state and associated user acct" option, but the device is incommunicado until someone does something on the box itself. This "someone" is usually me and "something" usually involves driving an hour into the office to do the something. I feel like truly remote mgmt should be possible, but I can't seem to get there. I've tried deploying the agent through Intune, deploying a PS script through Intune, etc., but Intune won't work until someone actually logs into the refreshed device for the first time. Advice? 

PS: We are a cloud-only shop. There is no server in the office. 

[#2]

Hi,

Few questions:

So when you go there, do you see the device waiting for user to sign in?

Do you have Enrollment Status Page enabled? This might be the problem, Enrollment Status Page restricts users from accessing the desktop until all their apps and settings are installed.

Moe

[#3]

Thanks Moe.

So the Enrollment Status Page looks like this and yes, it's set up to allow the user to bypass it and go to the desktop. 

My frustration is the loss of remote access during the process. If I do a format and clean install, the computer will start at the Out-Of-Box-Experience, then proceed to the Enrollment Status Page after the user first signs in. So remote access is lost until someone either sits down at the machine and installs my remote agent, or sits down at the machine and logs in to get the Intune deployments going. Either way, someone needs to sit down at the machine. 

If I initiate a device wipe from Intune, the computer will start with a default Windows sign in screen, and again, proceed to the desktop after the user first signs in. And again, my remote access is lost until someone sits down at the machine to re-install my remote access agent, or sits down at the machine to log in and get the Intune deployments started. Again, someone has to sit down at the machine either way, which is the step I'm trying to eliminate. 

Surely there is a way around this. ?

[#4]

Are you pushing the remote tool app from Intune? I use LogMeIn and I can remote after wiping from Intune by installing the app remotely.

Does the remote tool app use unattended agent? I would package it and scope it to the PC. If the app needs user and password to get installed you can use Orca to edit MSI file.

Moe

https://cloudbymoe.com/f/deploy-an-app-that-prompts-for-username-password-using-intune

[#5]

Hey @Dr_Snooze,

I think this does not 100% solve you issue but you can use quick assist bevor the real enrolment start. The only issue here is that someone has to enter the connection code. But as soon as this is done you can do the enrolment remote.

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-to-remote-assist-autopil...

[#6]

Yeah, I'm deploying it from Intune, but deployment only happens after someone logs in. How do you install your remoting app remotely if you can't remote?

[#7]

Hi,

I don't have to login, the app get installed before I login (Intune Management Extension). I'm pushing the remote tool using Win32 with Access Code packaged using Orca so the device shows up online and can remote to it.

Moe

[#8]

Just to be sure: you are assigning this app as required to devices, right? It kinda sounds like you're assigning it to a user (which would require a user to sign in).

[#9]

I'm also using a Win32 app packaged with the Intune App Wrapper. It's a simple installer. One double-click and it does the rest. No login is required for the app. All my apps are deployed to device groups, not user groups.

I set up a VM for testing this yesterday because it's starting to sound like I'm the only one having this problem. I'll watch my VM carefully today to make sure I'm not imaging things. In my experience, no Intune magic happens, no apps get installed, no policies get applied, until someone sits down at the machine and performs that first Windows login following a device wipe. After that, Intune kicks in and everything is good. Is that not how it works for everyone else? I'll confirm on my VM today and report back.

Thanks

[#10]

I've confirmed the issue. I sent a Wipe request from Intune to my VM yesterday morning. The VM wiped and came to rest at the Windows login screen with the old username prefilled. I left it sit like that overnight and this morning there was still no remote access. After I logged the VM in today, however, Intune immediately began deploying policies, doing app installs and even processing the 2 reboot requests I had sent to the VM yesterday afternoon. My remote agent was also installed and my access returned within 10 minutes. I'm not sure why my setup acts this way, unless it's because I'm not using AutoPilot, but I doubt it.

What's the way around this? I run a data entry department where productivity is all important. Having my users wait around while Intune configures the device is not ideal. Asking someone to stop what he is doing and go fiddle with a machine for me is also not ideal, and I'd rather avoid the hour's drive into the office (or the user's house for that matter).

[#11 · Accepted solution]

I think we all were (incorrectly) assuming you were using Autopilot. At least I was .

The ESP will only start through OOBE with AAD-join or during the Autopilot process (see Set up the Enrollment Status Page in the admin center - Microsoft Intune | Microsoft Docs). That probably explains why you need to sign in before anything happens. With Autopilot, the device configuration is applied before the first sign-in.

[#12]

That's an exceedingly important distinction. You'd think that would be spelled out more clearly in the documentation. We're coming up on a hardware upgrade cycle here, so I'll look into transitioning my devices over at that time. Thank you for your help!