Microsoft Technical Takeoff: Windows and Microsoft Intune
Oct 24 2022 07:00 AM - Oct 27 2022 12:00 PM (PDT)
Updates to the Windows Autopilot sign-in and deployment experience
Published Oct 14 2021 07:22 PM 45.3K Views

Update: Starting with Intune’s July (2207) service release, we’re excited to announce that some key Windows Autopilot functionality has been securely returned. Thanks to your patience and feedback, we were able to securely bring those features back. To learn more, see: Return of key functionality for Windows Autopilot sign-in and deployment experience for more information.

 

At Microsoft, we want to ensure that we are providing our customers with features that help to increase productivity and securely protect organizations. To improve the baseline security for Windows Autopilot, we recently made a few changes that affect new Windows Autopilot deployments:

  • Users enter their credentials at initial sign-in during enrollment. While we no longer allow pre-population of the Azure Active Directory (Azure AD) User Principal Name (UPN) under the pre-provisioning landing page, any user targeting during pre-provisioning will still occur during the technician phase.
  • For deployments where the profile is set to self-deploying mode (Public Preview) or pre-provisioning mode (formerly known as white glove, also in Public Preview), you cannot automatically re-enroll a device through Autopilot after an initial deployment in either of these modes. Instead, delete the device record in Microsoft Intune All Devices blade before re-deploying a device.

 

The intent of this post is to provide more context on why we made the changes and to provide links to documentation to help you be successful with your Autopilot experience.

 

Why did the Windows Autopilot team make these changes?

This was the biggest question we’ve received so far from customers. You liked, for example, giving a teacher a set of computers and using the welcome screen so the teacher could know which student to assign each device to. It’s a cool user experience when you assign a device, ship the device, and then the user opens that PC, and it welcomes them.

 

We loved the experience too! However, we made the changes because the reuse of hardware components, such as motherboards, or the refurbishment of devices without deregistration could potentially cause an issue if the device identifier can still be linked to a previous company. Hardware is being reused at record levels, partly due to the pandemic’s effect on global supply chains. While this reuse helps meet corporate sustainability goals, we had to remove the could and ensure no issues were caused. To date, we have found no evidence that anyone has used this to their advantage.

 

What’s next?

We are in the early design stages of an experience that customizes Autopilot enrollment. Using best practices from other enrollment workflows, we're looking at alternative solutions to reinstate this feature securely. Our goal is to improve your productivity and delight your users with what we bring back to the enrollment experience.

 

Additional Information:

  • Getting Started with Autopilot deployments.
  • Troubleshooting Autopilot deployments, including guidance how to resolve error code 0x80180014.
  • MC288489 and MC289488 both address these changes. See this post for more information on staying up to date on Intune new features, service changes, and service health notices. 
  • The change to device re-enrollment only impacts users with reset or reused devices, and only for devices using self-deploying mode or pre-provisioned deployment. This change will not impact users with devices in user-driven mode. There is also no impact to current users whose devices were provisioned for the first time in self-deploying mode or pre-provisioning mode (no existing device record in these modes). We don’t anticipate additional changes to user-driven mode. This experience is different between user-driven mode and self-deploying mode or pre-provisioned deployment because of the enrollment mode used.  
  • To redeploy a previously provisioned device through Windows Autopilot (in self-deploying mode or pre-provisioning mode), first delete the device record from the All Devices blade in Microsoft Endpoint Manager. Be sure to not delete it from the Autopilot devices blade as that deregisters the device. 
  • For more on motherboard replacements, see Windows Autopilot motherboard replacement | Microsoft Docs.
  • For CSPs/Resellers: You’ll need to request a communication process with your customer(s) to request that the device record be deleted when a deletion is required. We’re working to address and improve the customer experience for CSPs/Resellers and appreciate your feedback. Though we don’t have any ETAs currently, we’ll keep this post updated as soon as we have more information.
  • Note that when initiating a “Wipe” remote action, the “Retain enrollment state and user account” checkbox should be unchecked to remove the device from Intune device management.
  • To help troubleshoot/identify which Intune managed devices were enrolled via self-deploying or pre-provisioned mode, you can navigate to the Microsoft Endpoint Manager admin center > Devices > All devices > locate the impacted device > Monitor > Hardware > Enrollment profile.

Screenshot of the Microsoft Endpoint Manager admin center > Device pane to help troubleshoot/identify which Intune managed devices were enrolled via self-deploying or pre-provisioned mode.Screenshot of the Microsoft Endpoint Manager admin center > Device pane to help troubleshoot/identify which Intune managed devices were enrolled via self-deploying or pre-provisioned mode.

 

If you have questions or comments for the Intune team, reply to this post or reach out to @IntuneSuppTeam on Twitter.

 

Post updates:

01/11/22: Updated Additional Information section.

02/24/22: Updated post with additional clarification that while the username or UPN will not be displayed, any user targeting during pre-provisioning will still occur during the technician phase.

54 Comments
Contributor

Would preforming a Wipe be enough of an Intune deletion?

Regular Visitor

Just to make sure I understand correctly:

For devices enrolled with a profile set to self-deploying mode you can't use the Autopilot reset option? Why is that please?

Occasional Contributor

 according to a deployment profile, pre-provisioning and user driven mode can co-exist, but it sounds like you’re saying they’re completely different things?

 

can we perform a wipe or fresh start with preprovisioned devices? Or does the manually delete before redeploying only apply to autopilot reset?

New Contributor

How does this change affect CSPs?

Imagine a device being setup for the first time with Autopilot PPD. During "Device preparation" the MDM registration accomplished successfully.
When the "Device setup" process fails because of an application installation error, do I need to de-register the failed device within MPC portal and register again for getting an additional attempt installing the device?
For compliance reasons as a CSP we don't have access to our customers Intune and therefore we are unable to delete devices there directly.

Senior Member

What does this mean for Device Resellers? Are CSP/ADRs still able to pre-provision devices in Partner Center?

Occasional Contributor

Speaking from the school-system support side, this change is awful.  Students laptops that are running slow, not updated correctly, fell out of Intune etc, we reimage upward of 30-50 devices a day.  This change has added additional time that our students will not have a device in their hands.  Awful, just awful...

Occasional Contributor

What about devices that are currently user driven and assigned? Would the assignment just get removed or will they act as pre-provisioned needing to be deleted from Intune.

Contributor

In October, without notice Microsoft has removed the user to device assignment in Windows AutoPilot. It has been called “cosmetic” change. No comment. The MC didn’t remove the company to device registration functionality in AutoPilot. It removed only user to device assignment. De-assignment doesn’t mean de-registration from AutoPilot. Could you please explain a bit more precise how de-assignment helped to solve the issue of de-registration?

Btw. it’s time to solve the terminology issues, too. “Registered” is primary a state of a device. Which is different from “device registered” in AutoPilot portal. De-registration could mean both. So, please solve the terminology discrepancy too.

Hi @Nathan Hartley@Michaelvds, and @Greg_A - Thanks for the questions! A Wipe action is possible, though if you try to redeploy the device (in self-deploying mode or pre-provisioning mode) without deleting the Intune record, you may receive the error code 0x80180014. See this troubleshooting article for guidance on how to resolve this error. If we receive any additional information will keep you updated.

 

Note that when initiating a Wipe action, the “Retain enrollment state and user account” checkbox should be unchecked to remove the device from Intune management.

 

@Greg_A - Yes, both they can co-exist and different Windows Autopilot deployment scenarios can be used based on your organization's specific needs. For more information on deployment scenarios, see: Windows Autopilot scenarios and capabilities to learn more.

Occasional Contributor

@Intune_Support_Team 

Two questions

1. user-driven deployments are not affected by this? The user can redeploy the device at any time. The device does not have to be deleted in Intune?

2. pre-provisioned / white glove deployed devices can be reset by the user and can be user driven enrolled or does the device also have to be deleted because it was initially white glove deployed?

Occasional Contributor

@Intune_Support_Team 

regarding 


@Intune_Support_Team wrote:
  • Users enter their credentials at initial sign-in during enrollment. We no longer allow pre-population of the Azure Active Directory (Azure AD) User Principal Name (UPN). 

Are you referring to the "assign user" button when selecting a device from the "Windows Autopilot Devices" list in Intune? if so, I still see this option available on all my customers tenants.

Does "We no longer allow pre-population" means I'll be able to assign a user to an Autopilot device but it won't have any effect during user initial sign-in (user won't see welcome screen with its name)?

Occasional Contributor

@Intune_Support_Team 

 

Should the pre-provisioning screen still show the assigned user, or was that broken as part of removing the pre-populated UPN? 

Contributor

For AutoPilot reset after microsoft change.
Even removing devices in Intune, device still associates in AAD. I had to remove serial number (unenroll) from Intune and then remove device from Azure AD Devices and then enroll device again.

If I just do AutoPilot reset, it completes autopilot reset without ESP. So, no policies or applications install.

It doesn't look efficient way to do AutoPilot Reset.

Contributor

@Greg_C_GilbertThat's the impact of MC288489. The User-Devices assignment in AutoPilot is gone.

Occasional Contributor

@Red Flag but it is still there and I'm able to assign/unassign users from the device, am I missing something or we are talking on other thing?

giladkeidar_0-1634654090137.png

 

Contributor

@giladkeidar you might will get error during pre-provisioning.

Contributor

@giladkeidarWe talk the same thing. UX is still there but functionality gone. Docs didn't mention the change. What's new in Intune - no a single word on the downgrade and its impact. The only communication is MC288489. And btw don't use anymore "Hide change account option" in AutoPilot portal - it does nothing. See my comment above, Oct. 15th. and discussion under the link: https://docs.microsoft.com/en-us/answers/questions/587962/hide-change-account-options-what-it-actual...

Occasional Contributor

@Intune Support Team

 

This change is causing A LOT of undue burden to already short-staffed school districts.  Now, the vendor that we use to repair our student laptops is experiencing the same error.  Previously, we had them white-glove any repairs.  Kept my environment safe and I didn't have to supply them with an enrollment account.  Now with this change, they can no longer consistently reimage devices causing a backlog getting devices back into the hands of students.  I really don't want to create an account for someone outside my organization to do something that used to be accomplished without one.

 

We are asking that you rollback this change until you have an alternative solution that works the same way in place.  Pulling the rug out from under us after school starts is NOT the way to build confidence for Microsoft products.

Occasional Contributor

BRUTAL change with no consultation.

Who made THAT choice?

Thank you Microsoft!

@BraulioCulcay, this change will not impact users with devices in user-driven mode. There is also no impact to current users whose devices were provisioned for the first time in self-deploying mode or pre-provisioning mode (no existing device record in these modes). We don’t anticipate additional changes to user-driven mode. This experience is different between user-driven mode and self-deploying mode or pre-provisioned deployment because of the enrollment mode used.

New Contributor

Hello Together

I have just tested
Set up device with White Glove (pre-provisioning), logged myself in and then wiped the device.


Wipe deletes the device from Intune, so it is ready to use again.

Occasional Visitor

if I unplug the network cable during the autopilot flow, autopilot stops with an error and I can create a local account with administrative privileges, install any software I need, etc.
Next I do a sysprep, which does not remove any changes I made to the OS and start the autopilot flow again. This time I enroll with my employers Azure AD credentials and have a standard user account with no privileges. However, I do have an admin account already on the system :)

When will that "feature"be solved?

 

Best regards,

wannes

New Contributor

@SaschaBanz, Sorry, but I can't confirm that. I did >10 device installations yesterday with PPD (White Glove) while the device installation failed due to an application installation error on all devices. I wiped the devices and tried re-installation. All the devices ran into 0x80180014. Now I need to interact with my customer to get rid of device records within Intune. Other devices that were installed cleanly had to be reset and could not be reinstalled with PPD afterwards either until the device entries in Intune were deleted.

Contributor

@PeMiGra if you check the device serialnumber under enrollement>devices> right side it would mentioned AAD device assoicates, you need to remove your serial number and AAD device later and enroll back. if you are in AAD. I had lots of issue on those.

New Contributor

@Orion-Skol, thank you for the hint. Unfortunately I don't have access to AAD or Intune due to the fact I'm a CSP and don't own appropriate permissions at my customer's tenant.

In my opinion this change regarding PPD is likely to be counterproductive for most providers. I'm not sure if this change was announced anywhere but it should have surprised most providers and their customers.

 

Senior Member

So the reason for this changes is said to be security driven, how?

 

The tenants that keep their environment neat and tidy by deleting objects for laptops that are being repaired (or by just configuring the delete devices not contacting the environment for x number of days) are being punished by those that do not do any housekeeping on their tenant? The only security risk I see here is that now there is a need to give delete permissions on objects in tenants to teams that do not necessarily need those permissions. Besides that this change creates extra workload for IT staffing around the globe that is under enough pressure as is due to corona related measures.

 

This change should be rolled back asap.

Hi @PeMiGra@joshisasoftie0000, thank you for the questions. To redeploy a previously provisioned device through Windows Autopilot (in self-deploying mode or pre-provisioning mode), you’ll need to request a communication process with your customer(s) to request that the device record be deleted when a deletion is required. We’re working to address and improve the customer experience for CSPs/Resellers and appreciate your feedback. Though we don’t have any ETAs currently, we’ll keep this post updated as soon as we have more information.

Senior Member

Please reconsider this decision. Pre-Provisioning has been a great addition to our workflow and has exponentially made the user experience better. This change discourages the use of pre-provisioning. In a school district environment, devices move around and get repurposed all the time, especially in a 1:1 deployment. Having to delete a device and record just to hand it back out is an unnecessary step. One or two devices, no problem, devices that go out for repair, sure. We collect thousands of devices at the end of the school year and prep (pre-provision) for the following year. You're telling me I have to manually delete all of those just so I can pre-provision again? 

Hi @trebelow

1. Yes, user-drive deployments are not affected. This experience is different between user-driven mode and self-deploying mode or pre-provisioned deployment because of the enrollment mode used.

2. If a pre-provisioning profile was previously targeted, you can use it with user-driven enrollment. Note that if making any changes to existing devices and profiles, ensure that the intended Windows Autopilot deployment profile has been assigned to the device before attempting to deploy that device.

Regular Visitor

So then AutoPilot Reset, Fresh Start, And Wipe are now absolutely useless? In order to reset and reuse a machine in our program, it almost sounds better to just delete everything and wipe the machine then pretending it’s new out of box and readd to the AP program.


This is a silly and ridiculous change for an almost non-existent attack vector and makes admins, CSP and technician jobs way more difficult for no reason. The fact you emphasized *could* be a problem when you shove TPM down our throats makes absolutely no sense. If TPM is required and attested properly any reuse and refurbishment of hardware will break TPM. So again, what is the point of walking backwards on several core features of AutoPilot?

Occasional Contributor

@Avenues Spot on!!!

Occasional Visitor

Dear Intune support, please get your stuff together.
At one point you are talking about ditching pre-registration of a user, but not why Intune record needs to be deleted - there is no real explanation of why “Enrollment blocked for AP device by SDM One Time Limit Check”

I’m not really buying the “linked to previous company” argument. It’s totally NOT about Intune record, it’s about AP record. The hash is a property of AP profile. It can exist in a given tenant, and only one. You can’t add the same hash to another tenant without deleting it from the old one first. With that said, what kind of deregistration they are talking about here and what Intune object has to do with it?

Senior Member

This probably should have gone out BEFORE the change was made but nonetheless be sure to voice your feedback.

 

Via Twitter:   https://twitter.com/JasonSandys/status/1453066485925040133?s=20 

 

Windows Autopilot Feedback Survey:

https://forms.office.com/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbR75mLBTtYBZDkYV2EDOxDmJUQU5Q...

Occasional Contributor

Thank you @Edgar_Izaguirre !!

Senior Member

After these changes, my suggestion is to cancel the Autopilot service or change the name to Manual-Pilot, even it's not Pilot anymore, sorry its useless

Occasional Visitor

Of all the dumb things Microsoft has done, this has to be one of the dumbest. Any org that uses primarily shared devices, like a school district, just got completely wrecked. AutoPilot self-deploying was the entire reason we left SCCM, and now it's completely neutered and requires more steps and things for technicians to get wrong than PXE-boot OSD. I can't implore you enough to revert this change.

New Contributor

I work for a school system and this has impacted us too. We use Auto-Pilot Self-Deploy for all student computers.  Typically, we wipe devices when needed. So far, I have found two procedures for us that seem to work with Windows devices at the moment . 

 

Locate the devices in the Windows Device list in Intune/Endpoint. Select Wipe as we have always done. When the device starts to reset, delete the device from the list. We have not had to touch Enrollment or AAD so far.

 

The other scenario is we forgot to Delete the device or the device had the OS re-installed for repair and it starts to Auto-Pilot and fails with 0x80180014.  Then we Delete the Device from the list in Endpoint. At the failed deployment screen use Shift + F10 to get a command prompt.  Then use "SystemReset -FactoryReset", answer a couple of reset questions and done.

 

So far, the time it takes the device to reset seems to be enough time for Endpoint to do all it's behind the scenes magic.  

 

Thank you

 

 

 

Frequent Visitor
  • For CSPs/Resellers: You’ll need to request a communication process with your customer(s) to request that the device record be deleted when a deletion is required. We’re working to address and improve the customer experience for CSPs/Resellers and appreciate your feedback. Though we don’t have any ETAs currently, we’ll keep this post updated as soon as we have more information.

    Ummmm....Seriously?!?!?
    I work for a very large company and we utilize a CSP config center for our pre-provision builds. The amount of requests we are getting to delete devices itself is overwhelming. We cannot keep up. Not to mention the impact it has on our own ability to walk a user through a reset/re-provision in the field. Please revert this this change it is costing us time and money. It has seriously degraded the value of the pre-provision process. We might as well go back to using "Gold Images" at this point.
Regular Visitor

Well great, we recently went into production with self-deploying mode for unattended Kiosk computers and now find out that this change breaks our set-and-forget automation. When computer needs a reinstallation, we can do with a SCCM wipe and load and during OOBE Windows will automatically download profile and the whole process done in less than 15 mins. Now with this change in Intune, we have to delegate permissions to our fieldservice engineers permissions to search for serialnumber and remove it. And as @venues said, a remote freshstart becomes also useless. Please reconsider this change again.

New Contributor

Is there any update on this?  I agree with everyone here that the changes Microsoft has made are Awful and shortsighted.  This needs to be properly addressed by Microsoft. 

Occasional Visitor

I can't believe Microsoft released the update and in fact reply "You should change you process".

The use of pre-provisioned mode was the best option for our 3000 laptops. We used the Fresh Start or Wipe option remotely as devices are geographically far from the HQ. 

 

Now we need to send a Fresh Start action, ask the user to call us when the reset begins then delete the device on the portal.. If we forget they have an error on screen and need to start a Shift+F10 and cmd systemreset to initiate a new wipe and delete the device.... quite heavy process and no more "seamless" for user.

 

It's really annoying and can not continue this way.

Senior Member

@Intune_Support_Team, it doesn't seem like you're listening to your customers. This change is crippling a lot of our existing workflows. 

 

What options do we have for bulk deleting devices? We collect 2500+ devices at the end of the school year that now need to be deleted before being re-provisioned for use next school year. 

New Contributor

Real life example.

 

A customer orders 500 brand new devices.

The devices are staged on configuration workbenches and the begins the pre provisioning workflow.  Most of the devices provision correctly, but there is a 2% error rate and some devices will fail pre provisioning due to external factors, network issues, etc. 

 

In this batch of 500 devices approxometly 10 device may fail pre provisioning.   Once pre provisioning is attempted again 2 devices may fail pre provisioning.

 

The workflow would look like this.  

 

  1. Confirm 500 devices have been Enrolled for pre provisioning
  2. Stage Devices on workbenches / Unbox Devices
  3. Connect Network Cable
  4. Boot the device.
  5. From the first OOBE screen press the Windows key five times to view an additional options dialog.
    1. From that screen, choose the Windows Autopilot provisioning option and then click Continue.
    2. Select Provision to begin the provisioning process.
  6. If the pre-provisioning process completes successfully:
    1. A green status screen appears with information about the device, including the same details presented previously.
  7. Select Reseal to shut down the devices that passed. At that point, if all the devices passed they can be shipped to the end user.
  8. If some failed
    1. Box  and set aside completed units
    2. Create ticket to contact customer to remove device record from Intune 
    3. Customer Service Team reaches out to customer
    4. Customer responds and either does what is asked or customer asks for instructions on how to remove a device record.
    5. device is removed
    6. device is enrolled for pre provisioning
    7. Stage rework Devices on workbenches / Unbox Devices
    8. Connect Network Cable
    9. Boot the device.
    10. From the first OOBE screen press the Windows key five times to view an additional options dialog.
      1. From that screen, choose the Windows Autopilot provisioning option and then click Continue.
      2. Select Provision to begin the provisioning process.
    11. If the pre-provisioning process completes successfully:
      1. A green status screen appears with information about the device, including the same details presented previously.
    12. Select Reseal to shut down the devices that passed. At that point, if all the devices passed they can be shipped to the end user.
    13. If some failed
      1. Box  and set aside completed units
      2. Create ticket to contact customer to remove device record from Intune 
      3. Customer Service Team reaches out to customer
      4. Customer responds and either does what is asked or customer asks for instructions on how to remove a device record.
      5. device is removed
      6. device is enrolled for pre provisioning
    14. Stage rework Devices on workbenches / Unbox Devices
    15. Connect Network Cable
    16. Boot the device.
    17. From the first OOBE screen press the Windows key five times to view an additional options dialog.
      1. From that screen, choose the Windows Autopilot provisioning option and then click Continue.
      2. Select Provision to begin the provisioning process.
    18. If the pre-provisioning process completes successfully:
      1. A green status screen appears with information about the device, including the same details presented previously.
    19. Select Reseal to shut down the devices that passed. At that point, if all the devices passed they can be shipped to the end user.
    20. order is complete

In a production facility to maximize bench availability for other customers only orders actively being worked remain on the bench's. Any rework gets boxed up, until tickets are resolved and then put back in the queue to be staged back on a bench and worked on by a technician. 

 

  @Intune_Support_Team  states 

"For CSPs/Resellers: You’ll need to request a communication process with your customer(s) to request that the device record be deleted when a deletion is required."

 

Above is how the process looks in a production facility. 

 

@Intune_Support_Team  continues

 

"We’re working to address and improve the customer experience for CSPs/Resellers and appreciate your feedback. Though we don’t have any ETAs currently, we’ll keep this post updated as soon as we have more information."

 

Well it's not quick enough. It's been three months and Microsoft has no comment nor solution. Maybe some of the customers can move to Chromebooks and stop using Microsoft windows for certain segments of the computer population.  Especially for Kiosk deployments and K-6 Chromebooks look pretty appealing.

Seriously though, we want to use Microsoft Windows devices and we are committed to it and that is why we are here.  Microsoft needs to listen and resolve this problem.     

@wdeboodt to prevent the scenario you described to get local admin rights wouldn't you simply use a script or policy to remove everyone from local admins? I always monitor the local admin membership and/or set it using a policy or script. 

Occasional Contributor

Will you please just fix Autopilot so people don't have to delete records before reusing a PC? It's getting ridiculous. There's nothing "auto" about this process anymore.

 

With your fleet of engineers this seems like a problem you should be able to overcome.

Occasional Contributor

I concur with both Michiel_van_Heerde and Avenues,   
The feature of assigning UPN to a device was the exact feature that brought me to AutoPilot versus other vendors. 
Couple this with a massive deployment of (for example) Hololens 2 without keyboards, needing to physically type in each username into a virtual keyboard.  This has generated lots of pushback from customers who prefer simplicity and easy OOBE.
This change removes the distinction of "zero touch" deployment because we are adding more steps for the end-user.  

I hope that this feature comes back somehow, in some shape or form. 

Occasional Contributor

This change is more weird than I thought.

I wiped some self-deploying mode devices and their records seems to be removed automatically in MEM portal.

But I still get stuck in autopilot process with error code 0x80180014.

Solution listed in Troubleshoot Autopilot device import and enrollment says:

"To redeploy the device through Autopilot:

  1. Delete the device record in Intune.
  2. Redeploy the Autopilot deployment profile."

Since the wipe action already remove the device record for me, I made another autopilot profile (profile B) to replace the original one (profile A).

Stupid but it works.

 

Summary:

To MANUALLY run an AUTOpilot self-deployment for reused devices, you need to MANUALLY delete the device records in MEM portal.

(If you are lucky, Mr. Wipe could also do this for you automatically.)

AND you need to MANUALLY assign a different autopilot profile (profile B) to those devices.

For configuration consistency, you may want to assign profile A back. And yes, MANUALLY.

 

ONE deletion and TWO assignments MANUALLY for ONE reused device. Image you have 50 or more.

Thank you Microsoft, you just made other MEM/MDM solutions more attractive.

Occasional Contributor

@Intune_Support_Team, does this update (July 26, 2022—KB5015878 (OS Builds 19042.1865, 19043.1865, and 19044.1865) Preview (microsoft.com)) mean that self-deploy/white glove is working again?  

JoelParmer_0-1659226875614.png

 

Occasional Contributor
Occasional Contributor

@Greg_A , Oh thank GOD!!  

Version history
Last update:
‎Sep 15 2022 03:22 PM
Updated by: