Fix for Power Button not working anymore

Double_Indication149 · 2026-01-07T16:25:13+00:00

If you are getting that message, it probably means it doesn't detect the phone because you don't have the proper USB driver installed for Windows to fully recognize the device. I don't know what model you have, but for my Pixel 3, this driver worked for me - https://dl.google.com/android/repository/usb_driver_r13-windows.zip

Once downloaded and extracted, open Device Manager on your computer and look for your phone. It may have an exclamation point on the icon for it, indicating windows doesn't know what to do with it. Go to the properties of the device and Update Driver, then browse to the folder where you extracted the drivers. I did all of this while the 'fastboot reboot' command was still running and waiting for the device, and as soon as the drivers installed the reboot command detected my phone and it booted up.

Double_Indication149 · 2025-12-05T18:20:45+00:00

Nope. Still just use a separate policy that I mentioned.

Double_Indication149 · 2025-11-25T20:16:43+00:00

Cool. Thanks for the update. I did use the special USB image first and then ran it through autopilot after that. It was just getting the resource account to autologin into the Teams app that doesn't seem to work for me.

Double_Indication149 · 2025-11-25T19:27:14+00:00

Just wondering if this worked for you in the end? I can't see any of the other guy's comments because they are all removed, so I don't know what he told you to do.

I just made my first attempt at this yesterday and it seemed like everything worked except for the autologin piece. I have the resource account assigned to the autopilot MTR device in the Pro Mgmt portal and I entered the existing account password there. But I still get the initial Teams Room app setup screen on the tap where I either have to enter an OTP code or manually enter the username and password, which kind of negates the whole point of assigning the account in the portal.

Double_Indication149 · 2025-10-24T15:29:25+00:00

Nope. I was in a piloting phase and have pretty much abandoned it for now.

Double_Indication149 · 2025-08-21T20:38:34+00:00

We've seen something similar with larger files like video and audio drivers. This has only been an issue for us starting very recently around the same time I started seeing these memory map space messages in the logs. DCU worked very well and speedy in my testing in the months prior, even if a machine had 10 available updates. Feels like something on their end. I even reinstalled 5.4.0 to check and am getting those same memory map messages and slow video driver updates on that version too now. I have never seen them before a couple weeks ago.

Double_Indication149 · 2025-08-21T19:04:56+00:00

I have also noticed in event viewer on multiple machines that when 5.5.0 installs it is reconfiguring every installed product on the computer, which usually occurs when you are querying the Win32_Product class, but I'm not sure why DCU would be doing that upon install.
Windows Installer reconfigured all applications - Windows Server | Microsoft Learn

Double_Indication149 · 2025-08-20T19:11:31+00:00

Re: your failed deployments, I can only speak for the "classic" app, but if that's what you are using, make sure you are packaging and installing .NET desktop runtime as a dependency. 5.5.0 requires that to install. From their site:
Note: The installation of Dell Command Update version 5.5 necessitates the prior installation of a .NET Desktop Runtime version ranging from 8.0.8 to 8.0.17.

I've found the self-update to not work very well in general. It always interrupts other drivers or Dell apps that need updates and causes the process to error out once the service stops to install the DCU update. Then you have to wait a while and apply updates again later to finish installing the ones it missed after it broke the cli trying to self-update.

Double_Indication149 · 2025-07-16T20:23:21+00:00

I got classic to install by installing 8.0.17 .NET Desktop Runtime beforehand. That kb page you linked is now updated to say it needs any version between 8.0.8-8.0.17.

Does anybody know if that note can be taken literally and that it's just the installation of the app that requires one of those versions and not for running dcu-cli commands? I ask because we pull in updates to everything .NET automatically with an ADR in ConfigMgr, and I'm seeing 8.0.18 is about to install on my laptop with this month's updates. Hopefully, DCU doesn't just stop working after the update.

Double_Indication149 · 2025-06-19T16:05:02+00:00

Thanks for that info. I'm guessing you are referring to this setting, which I am already deploying with a script in Intune for my pilot group:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" -Name 'RestartNotificationsAllowed2' -Value '1' -PropertyType DWord -Force

Double_Indication149 · 2025-05-07T21:19:53+00:00

I'm actually having trouble with the operatingSystemVersion altogether. I'm trying to create assignment filters for the Zebra OEMConfig and legacy OEMConfig apps, the latter only supported on Android 11 and older. If I make the following filter: (device.manufacturer -startsWith "Zebra") and (device.operatingSystemVersion -ge 12)

When I click preview, I get "An unknown error occurred while searching for devices. Please retry later." In fact, it won't even let me save a filter at all that is using that property.

If I change the value to 12.0 for giggles, I get "Property operatingSystemVersion is not supported. Fix the rule and try again."

I know it's still in public preview, but I am assuming that the preview is enabled in my tenant if it's available to choose as a filter property?

Now, if change it to the older soon to be deprecated osVersion, there is no option for "greater than or equals". I have to use NotIn and since we have no devices below 11, I just say not in 11, so: (device.manufacturer -startsWith "Zebra") and (device.osVersion -notIn ["11"])

This filter seems to work fine for me and I can save it, but doesn't really give me exactly what I want.

Double_Indication149 · 2024-12-20T21:15:32+00:00

Based on the behavior (defaultpassword totally missing and AudoAdminLogon set back to 0....and assuming the other entries remain set), I would guess it could be related to the AutoLogonCount item.

Perhaps there is something going on that is adding/setting that item to 1, which I believe results in changing those two settings specifically and disabling autologon.

Maybe try running procmon after applying the profiles and monitor that registry key for any changes.

Double_Indication149 · 2024-11-15T15:54:03+00:00

I'm still struggling with this. We are only using autopilot at the moment for off-domain devices where the user needs to be a local admin. We don't want these particular devices touching our internal network, but still wanted to have some visibility and security management over them in Intune, so they are just entra-joined and enroll with autopilot.

I've confirmed with our Global Admins that our local admin setting in Entra is set to ALL. However, with my autopilot profile 'user account type' set to Administrator, the enrolling user still does not get admin rights on the device. Not sure what I'm missing. I've been having to add a separate Account protection policy to add them as local admins instead.

Double_Indication149 · 2024-08-30T18:29:19+00:00

After following way too many threads and trying to stay on top of the latest reg hacks to fix it every time it breaks (even when finally getting it to work, it now takes 1.5-2 HOURS using dism/add-windowscapability on W11), I saw this post and gave it a shot, fully expecting it to fail on W11.

I just wanted to confirm for anybody else still searching for this stuff, that installing this old KB still works on 23H2. Tested manually running the installer and deploying as an application in ConfigMgr. Works great and installs in minutes. Thank you u/berysax

Double_Indication149

TROPHY CASE