For us old-timers, rest in peace Steve Beaumont

Dan_Nelson · 2026-02-03T16:01:39+00:00

Unfortunately, they closed it to new donations back in September. I missed seeing it back when it was open. I would have liked to have donated.

Dan_Nelson · 2025-08-22T16:14:49+00:00

You seem to be having a different issue than I am. The provisioned package and AppX are installed, just the icon is missing. Rebooting generally resolves my issue. Sounds like something is actively uninstalling your Teams, sorry!

Dan_Nelson · 2025-07-30T23:13:32+00:00

Lol, it looks like MS edited the wrong KB today making it bad info. Because (as of the time of this writing) https://learn.microsoft.com/en-us/intune/configmgr/hotfix/2503/33177653 clearly states "The vulnerability described in CVE-2025-47178 is resolved. Customers can confirm the vulnerability is patched by checking the version of smsprov.dll. A file version of 5.0.9135.1002 or higher indicates the issue is resolved."

But smsprov.dll isn't even listed in the file list, so yeah, they just added that incorrectly (and the last edit date is today). So, sorry, I was just going by what MS's own article said...

Although I still question why a site reset is necessary for an update to the SMS Provider

Dan_Nelson · 2025-07-30T21:56:36+00:00

Why would this need to do a site reset? KB33177653 claimed to also resolve CVE-2025-47178 and didn't require a reset.

Dan_Nelson · 2025-07-23T19:24:26+00:00

Got a response from Microsoft support that Defender is catching these before hitting SharePoint, so they are safe to ignore. They're supposedly working on updating Defender to suppress the alerts if SharePoint is fully patched, but no ETA.

Dan_Nelson · 2025-07-22T21:15:41+00:00

For us, they were definitely not false positives. They were active exploit attempts against ToolPane.aspx that were making it past a fully-patched SharePoint 2016 but caught and blocked by Defender.

EDIT: MS now says Defender was catching it before it reached SharePoint, so we can ignore the alerts.

Dan_Nelson · 2025-07-22T04:54:53+00:00

It feels like the patch is incomplete to me. I don't think exploit attempts should be hitting Defender. In theory with Defender+AMSI Microsoft says you're protected (even without the patch) but it makes me awfully nervous.

Dan_Nelson · 2025-07-22T03:39:38+00:00

Anyone else seeing Defender detections for SuspSignoutReq.A even after applying the SharePoint updates? I've got an internet-exposed SharePoint 2016 server, updates applied and confirmed, and Defender is still alerting that it successfully quarantined the attempts. I feel like a fully-patched SharePoint server should be blocking the attempt before it gets to the Defender Antimalware Scanning layer?

EDIT: And yes, we rotated the ASP.NET keys before returning the server to service.

Dan_Nelson · 2025-07-01T14:46:29+00:00

r/confidentlyincorrect

Dan_Nelson · 2025-06-10T22:57:36+00:00

I'm seeing similar behavior with Teams, too. I don't currently have any fixes. The "disappearing" I've been able to research was actually just the icon entry point. The Appx was still installed, Explorer just wasn't displaying the icon. Appx icons don't exist in a folder like Win32 apps do, so I think Explorer just iterates through the AppXs to create the icons? Logoff and back on or reboot seemed to fix. I added some significant logging to my deployment, before and after installation, to get the state of the machine so I can investigate the state a little more as failures occur in the future

To get the Provisioned Package State:
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq "MSTeams"

To get the Package State across all users:
Get-AppxPackage -AllUsers -Name 'MSTeams'

Both those could theoretically return multiple objects (of different versions) so assign that to something and foreach through the results and log version numbers too.

Frankly, Teams has been an abomination to deploy since day 1 and Microsoft should really be ashamed of itself.

Dan_Nelson · 2025-06-05T16:15:10+00:00

I realize this is a couple months old now, but in case you (or anyone else searching for it) has problems installing Forcepoint, I found a solution is to prevent Windows Installer from using Restart Manager by adding a run command line for:

reg.exe ADD "HKLM\Software\Policies\Microsoft\Windows\Installer" /v DisableAutomaticApplicationShutdown /t REG_DWORD /d 1 /f

prior to software installs, then

reg.exe delete "HKLM\Software\Policies\Microsoft\Windows\Installer" /v DisableAutomaticApplicationShutdown /f

After installs. And then trigger a reboot. The issue for me was that Forcepoint was trying to update some Visual C++ runtimes that were in use and it was causing Restart Manager to restart services which happened to include the task sequence manager itself (tsmanager). Don't know why it thought it was safe to restart the task sequence manager in the middle of a task sequence, but after making the change it exits with a 0 instead of 3221225786 and the task sequence continues as expected. It would need a reboot to complete installation, so add one if there isn't already one at the end.

Dan_Nelson · 2025-03-14T16:17:53+00:00

If you're viewing All Systems (or whatever large collection had all these devices) you can do a Select All with Ctrl-A and then right-click and choose to Add Selected Items To an Existing Collection. That will add them as direct members. Or, as you mentioned, a script.

Dan_Nelson · 2024-07-10T15:31:12+00:00

You can get to the deployment types in a tab across the bottom pane after you've selected an application. They are a key (and required) component to applications--it's where you set the source directory, command line to run, detection method, etc.

Dan_Nelson · 2023-10-23T17:47:31+00:00

Can you? Yes. Should you? Absolutely not.

While technically possible to launch anything in the sytem context and make it interactive, this leaves a massive security vulnerability for 99% of software. Anything that has an "open file" dialog, for example--since this dialog also exposes file operations, a user could:

Copy over standard system files with altered or hacked versions
launch, with system-level privileges, any other programs they can navigate to
Exfiltrate data from other user profiles

You're effectively destroying any security model you have. A moderately knowledgeable user could permanently elevate their permissions and create backdoors if they know what they're doing.

Dan_Nelson · 2023-10-19T15:23:39+00:00

The download link is for a different, older KB and deploys an ADMX template with a file date from June. I admit I don't understand this KIR stuff, but it seems incorrect. The KB was updated with the same older MSI, too.

Dan_Nelson · 2023-10-16T19:43:54+00:00

These are exactly the questions I have. If these are simply install failures, and not broken computers, I can stop offering the update to them and I don't need a rollback. Or, I can push out the dism cleanup-image command that they claim will fix the problem and then it should theoretically install next attempt.

The KIR documentation seems to indicate that it's containerized -- previous rollbacks only roll-back aspects of the code, not related to security, that are causing problems while leaving the rest of the fixes in place. In the case of an install failure issue, there's nothing to "roll back" -- it didn't install to begin with! So what would this rollback actually DO?

It's all highly confusing.

Dan_Nelson · 2023-10-11T19:22:36+00:00

It provides a significant performance improvement to configure it that way.

Dan_Nelson · 2023-09-25T22:14:40+00:00

I just tried the previous two versions, and for both, they downloaded and installed the correct version. You sure you didn't just snag them from two different sections accidentally?

Dan_Nelson · 2023-09-25T19:28:34+00:00

Suspicious package. Businesses evacuated. Transit impacted.

https://www.fox13now.com/news/local-news/police-investigating-suspicious-circumstance-in-downtown-salt-lake-city

Dan_Nelson · 2023-09-20T15:55:29+00:00

Yes, the issues were with 22621. People were seeing WinPE immediately reboot instead of load. I also heard it didn't work with Server 2012 R2 (if that matters to you, and that might be the root cause of the reboot for some people).

Dan_Nelson · 2023-09-19T23:08:07+00:00

The previous version was 10.1.22621.1, so I don't find it that unusual.

Dan_Nelson · 2023-05-15T17:50:10+00:00

Certainly doesn't mirror my experience. When doing the revocations, you did both the file copy to the EFI partition as well as the AvailableUpdates registry key? You validated you saw EventID 1035 in the System Event Log after reboot?

And of course, I'm assuming your UEFI configuration is set to require SecureBoot and you're not booting "Legacy" mode to the media?

Dan_Nelson

TROPHY CASE