Sometimes Windows’ relationship with 365, or a user’s profile, or just a user on a PC or terminal server, will not log into 365. This appears to be the result of corruption of cached credentials.
The most straightforward way is probably to nuke all User/Windows/Azure relationship and recreate. As written, this would probably be very bad on a terminal server, because it will nuke the relationship for all users and all profiles. So far, no per-user commands identified.:
Remove 365 accounts from “Access Work and School”, then run these:
dsregcmd /debug /cleanupaccounts
dsregcmd /debug /leave
from administrative CMD, and also from SYSTEM (paexec or psexec can do this), then reboot, then remove from Access Work and School if still there, then set up user relationship(s) again.
But today we have a report that dsregcmd /status did something, unknown, which fixed one terminal server user. Not sure what. Next time I plan to run many tests with this info:
ss64.com/nt/dsregcmd.html
And if you see error CAA5021, do this:
Search for Manage user certificates in the search bar and open it from Best match. Then navigate to Current User\Personal\Certificates and make sure the MS-Organization-Access and MS-Organization-P2P-Access entries are deleted.
No reboot needed for that last.
Categories:
Microsoft 365
Azure
Seen it twice now, different audio hardware. After Windows 11 upgrade, audio shows working in Device Manager, but does not actually work. So far, the solution is to get into Device Manager, and delete the driver items for the hardware which should be working, from both “Software Devices” and “Sound, video and game controllers”. Then reboot. After the reboot, both times, it created two new sections at the top for audio, and then sound began working fine. Here’s an example:
Categories:
Windows OS-Level Issues
Audio-Video
This method uses Powershell module PsWindowsUpdate.
First, a complete script which gets the module in and updates everything available from Microsoft, including patches and drivers and firmware:
#begin script
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-Executionpolicy RemoteSigned -Scope Process -Force
Install-PackageProvider -Name NuGet -Force -ErrorAction 'SilentlyContinue' > $null
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
If (Get-InstalledModule -Name PsWindowsUpdate -ErrorAction 'SilentlyContinue') {
Update-Module -Name PSWindowsUpdate -Force
} Else {
Install-Module -Name PSWindowsUpdate -Force
}
Import-Module PSWindowsUpdate
Install-WindowsUpdate -AcceptAll -AutoReboot
# end script
Next, the bits. We do need to install and keep up a module.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-Executionpolicy RemoteSigned -Scope Process -Force
Install-PackageProvider -Name NuGet -Force -ErrorAction 'SilentlyContinue' > $null
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
If (Get-InstalledModule -Name PsWindowsUpdate -ErrorAction 'SilentlyContinue') {
Update-Module -Name PSWindowsUpdate -Force
} Else {
Install-Module -Name PSWindowsUpdate -Force
}
Import-Module PSWindowsUpdate
Then we can check the list of available updates:
Get-WindowsUpdate
And then we probably want to actually do updates. There are good reasons and multiple methods to be careful. Alas, thus far, there does not appear to be a way to install updates a given number of days after release, e.g., 30, so as to give Microsoft time to respond to issues. Here is a glancing overview of what we do have:
- Lots of firmware is being sent by Microsoft now, and some of this is more up-to-date than that available from the vendors. But there is risk in these, don’t forget. You may find that you want to install current Windows patches, but no drivers, firmware, services packs, feature packs, etc. To do this:
Install-WindowsUpdate -NotCategory "Drivers","Service Packs","FeaturePacks" -NotTitle "preview" -AcceptAll
And to do it while ignoring reboot:
Install-WindowsUpdate -NotCategory "Drivers","Service Packs","FeaturePacks" -NotTitle "preview" -AcceptAll -IgnoreReboot
The -IgnoreReboot ignores all relevant reboot automata. -NotTitle "preview" omits all updates with the word “preview” in their name.
But sometimes, e.g. with a new PC install, we’ll want to install all updates and reboot automatically:
Install-WindowsUpdate -AcceptAll -AutoReboot
- You may find that you want to omit granularly, e.g., specific build upgrades. If you found one marked KB1234567, you would install all and omit that one thus:
Install-WindowsUpdate -NotKBArticleID KB1234567 -AcceptAll
- If you wanted to do that, and explicitly not reboot if indicated:
Install-WindowsUpdate -NotKBArticleID KB1234567 -AcceptAll -IgnoreReboot
- If you had two KBs to omit:
Install-WindowsUpdate -AcceptAll -NotKBArticleID "KB1234567,KB7654321"
- There are other noteworthy items. Lots of firmware is being sent by Microsoft now, and some of this is more up-to-date than that available from the vendor. But there is risk in firmware updates, don’t forget. Some of the items don’t have KBs, and there are two other command-line arguments to omit those,
-NotTitle and -NotUpdateID.
Reset-WUComponents
- To get a full list of functions:
Get-Command -Module PSWindowsUpdate
Get-Help works for all of them.
Categories:
Windows Installer, Updates, Patching
Powershell
Older hosted Exchange mailboxes, are starting to fail Autodiscover in newer Outlook installs. Below is a registry fix which gets them working. Apply the change and then reboot, then try it again.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeHttpsRootDomain"=dword:00000001
"PreferLocalXML"=dword:00000000
"ExcludeHttpRedirect"=dword:00000000
"ExcludeHttpsAutodiscoverDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000001
"ExcludeExplicitO365Endpoint"=dword:00000001
Categories:
Exchange and Exchange Online
Outlook & Exchange / Exchange Online
Try this:
winget install microsoft.edgewebview2runtime --force
Categories:
Windows OS-Level Issues
For a long time the standard was, contact your S1 support and receive a removal tool. The sweeper can still be found, but only old versions among rare people that held onto it, and it does not always work. This works sometimes:
SentinelOneInstaller_windows_64bit_v22_2_4_558.exe --clean_only --dont_preserve_config_dir --dont_preserve_agent_uid -t xyzpdqxyzpdq
You’ll want the latest .exe, not the above version. And if this is not an agent from your own console, in the place of xyzpdqxyzpdq, try “1”, or omit the -t … altogether. Sometimes works outside of safe mode, sometimes works inside.
Categories:
SentinelOne
This seems to be able to help. It does take down New Outlook and New Teams and any other Webview app first.
taskkill /f /im msedgewebview2.exe
$ResolveWingetPath = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
if ($ResolveWingetPath){
$WingetPath = $ResolveWingetPath[-1].Path
}
$ENV:PATH += ";$WingetPath"
winget install microsoft.edgewebview2runtime --force --accept-package-agreements --accept-source-agreements
Categories:
Outlook
Windows OS-Level Issues
So we have a PC that is Azure-joined, not AD, not standalone. Domain admin is obvious. And we can set PC-local admin using domain admin. But how do we give an Azure user local admin rights? Well, the simplest is in administrative Powershell:
net localgroup Administrators /add "AzureAD\userupn@domain.com"
where userupn@domain.com is the UPN of the user, the user’s login into Azure/365. Note that the text AzureAD is not the domain name, it is literal characters as you see it here. In other words, a breakage of historical syntax!
Categories:
Azure
Categories:
Tools
Since Windows 7, I have been adding the Everyone group to Windows-hosted printers, and checking every permissions box, as a method to drastically increase reliability and controllability, using other groups only if restrictions were necessary. The inestimable Dave Gottschamer just reported a scenario in which Everyone was there, but didn’t work; he tried Authenticated Users and it worked. This is quite the sea change. Not exactly unexpected, as Microsoft has been slowly denaturing Everyone for quite some time, but now we have a definite diagnostic-and-fix change for printers, including desktop USB printers, which will help!
Categories:
Printers & Printing
Windows OS-Level Issues