BryanP

I can't seem to find a straight answer to this anywhere, so I'm hoping someone here will know. I'm running SCCM 2012 R2 SP1 CU3. I need to enable the Upgrade classification for Windows 10 in WSUS and SCCM as shown here: https://4sysops.com/archives/so-you-broke-wsus-how-to-fix-the-broken-windows-10-upgrade-classification/ I've upgraded my test environment to Server 2012 R2 (I was on Server 2008 R2). The Upgrade classification is available in WSUS, but not in SCCM itself. When I go to Administration -> Site Configuration -> Sites -> Configure Site Components -> Software Update Point and select Classifications, it starts with Critical Updates and ends with Updates. It's pasted all over the internet that you have to be at Server 2012 to enable the Upgrade Classification. What I can't find is any definitive answer whether you have to go ahead and upgrade to SCCM 1511 or if you can enable it with SCCM 2012. Is there anyone out there who can answer this for me?

I figured it out. Looking at one of the sql files where it stopped processing, I found references to a driver package. A tech who works in my group said "Oh yeah, we've been having problems with that driver package not distributing properly." I pulled it off the distribution point and the backlog of files in statmgr.box\retry immediately began processing. I'm going to have him rebuild that driver package.

I had this issue with Lenovo T460 ultrabooks a few months back, and this hotfix ended up being the resolution.

I'm running SCCM 2012 R2 SP1. Recently I went to look at my component status and noticed that if I try to open the message viewer most of them were empty unless I told it to show me events from a month ago. Doing some digging, I found several instances of people having had this problem, and they all went back to the same solution. Go to \inboxes\statmgr.box\retry, delete the oldest sql file and then restart the SMS_EXECUTIVE service. Sure enough, I went there and had a backlog of thousands of files. I did as suggested, and it proceeded to process a few hundred files, then stopped. If I repeat the process, it will then process anywhere from a couple of dozen to a few hundred backlogged files before stopping again. If I look in statmgr.log, I see entries like this: WARNING: SMS_STATUS_MANAGER could not insert 41 status messages, 67 insertion strings, and 45 attribute ID/value pairs into the database at this time but retry them in 600000 milliseconds. Has anybody experienced this or have any insight as to what may be going on?

So it appears I have to upgrade my WSUS server from Server 2008 R2 to Server 2012 R2 before I'll be able to add the Update classification to my SCCM 2012 R2 SP1 environment (yes, I'm preparing to update to 1511, but that's another subject). I do plan to upgrade my entire SCCM environment to Server 2012 R2, but in the short term I'd like to just do my WSUS server. I had someone ask me if the Site Server needed to be upgraded first. As far as I've been able to find the answer is no, I should be able to upgrade my WSUS server and leave everything else at 2008 R2 for right now. My current plan is as follows: Have our VM people spin up a new Server 2012 R2 VM (this is all VMs by the way) Back up my WSUS server. Remove the roles from the old server. Remove the old server from AD, but leave the server object in place. Join the new server the domain with the same name and IP address. Install WSUS. Install the hotfix required for the Update category to work. Add the SUP role. Does anyone see a problem with this? Does anyone know if only upgrading the WSUS server for now will be a problem? I'm Hoping to save myself some headaches. I'm going to do this in my test environment first, but I'm hoping someone here has already been through this.

I do it with a collection that queries for computers running Flash older than the one I'm currently deploying. The query below looks for any computer running Adobe Flash ActiveX below 18.0.0.209, for example: select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "%Adobe Flash%" and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "%ActiveX%" and SMS_G_System_ADD_REMOVE_PROGRAMS.Version < "18.0.0.209" Then I use Orca to make any changes to the flash .msi, drop it in a folder with the current flash uninstaller (ever since I had couple of rounds of flash that wouldn't consistently install over the previous version I've been uninstalling it myself first), and package it up with the .bat shown below. I know it can be done more elegantly, but this works pretty well for me. @echo off taskkill /F /IM iexplore.exe /T taskkill /F /IM firefox.exe /T taskkill /F /IM chrome.exe /T uninstall_flash_player.exe -uninstall activex msiexec.exe /q /i "install_flash_player_18_active_x.msi"

Yes,I do have a standing update like you describe. But I would think it wouldn't install those updates until after the PC reboots and completes the installation of IE11? I'll dig through the logs some more. Thanks for the suggestions. I've done something similar to what you describe with IE10, in my case with a simple .cmd file that applies prerequisite updates before installing IE10, but haven't had much luck getting that to work with IE11. I'll look at your method and see if I can get it to work. Right now I'm trying to get a package working using what I'm finding here: https://gallery.technet.microsoft.com/How-to-deploy-Internet-0b98a8fb As for leaving them half-installed, I agree entirely. Unfortunately, (as I have been reminded, in these exact words), I don't make policy, I perform tasks.

I'm hoping someone can point out something obvious I'm missing here. I need to install IE11 without forcing a reboot, so that the user gets 11 the next time they choose to reboot. I've created SUG for IE11, with the deployment having the settings shown in the image below, but workstations I've deployed it to are still being forced to reboot. When I look in the RebootCoordinator.log file I see this entry right before the reboot: Scheduled reboot from agent UpdatesDeploymentAgent. Deadline local time: 08/08/2015 11:58:09 AM, PreferredRebootWindowType = 4

Aaaaand I'm an idiot. Remember I inherited this and I've been trying to educate myself on it without, oh, you know, actual training? This means some details I only learn as things go wrong. Client Settings -> Software Updates. The schedule is set for every 2 days. If I had set it to more frequent this wouldn't have happened. Now I just need to get through this month and confirm. I've already been told I'm dead man walking if certain people reboot again tonight. *sigh*

Doing some more digging on other PCs this is happening to, it seems to be that for some computers, round 1 of updates is applying, then it waits anywhere from a few hours to a few days before deciding to check in again and realize there are more updates to be applied. The question is ... WHY is it waiting so long between checks?

Hi everyone. I've been working on SCCM for a little while now, inheriting management of an existing setup with about 30,000 clients. I've learned a lot, but I'm still trying to get it all figured out. Please bear with all the background below to get to the real question. I realized recently that a lot of updates weren't being applied and dug into the ADRs to figure out why. I found the problem and ended up having to split it into two ADRs by Severity (Critical/Important in one and Moderate/Low/None in the other) to get everything we need to patch in under the 1000 update limit. I informed my manager that April would be a lot of updates as the ones that were being missed all applied. Forcing users to reboot is a big deal in our environment. You catch a LOT of flack over it. So I distribute the updates over a weekend, which catches about 15000 or so that leave them turned on like they're supposed to. The rest start applying them when they come in Monday and are forced to reboot 4 hours later. You don't leave it turned on over the weekend, you have to reboot for updates in the middle of the day, live with it. Fine. So along comes this extra large round of updates, (people getting 200-500MB of patches depending on their individual setup). I started getting calls about people who left their computers on over the weekend yet they were still rebooting in the middle of the day. Not everyone, but enough to get some people upset. Looking at ccmcache I see where users would download a bunch of updates, reboot, then hours (or the next day), download another round. Sure, that makes sense. You installed a bunch of older updates and there were dependencies for newer updates. This month will be painful, but after that everybody should be back to normal. Using User X as an example. The ADR was set to execute at 8PM on Saturday night. I look in their CCMCACHE folder and see 61 folders (303MB) downloaded between 9 and 9:30PM that night. Then I see 5 more folders (66MB) created at 10PM that Sunday night. No problem. The PC rebooted twice over the weekend, they're fine to go on Monday morning. Except they rebooted yet again at 7PM Tuesday night. So I look and sure enough, 4 updates applied that Tuesday afternoon and forced the reboot 4 hours later. My first thought was they would have been in the second round and for some reason they didn't apply immediately. But no, all of them were in folders dated Saturday night, they just didn't apply until Tuesday afternoon, after a ton of other updates had applied. The KBs that applied late were KB3045999, KB3042553, KB3037574, and KB3045685. So that was a long way to go to get to my question. Anybody know why SCCM would wait like that? I've checked and rechecked the ADR settings. The deployment schedule is set for As Soon As Possible, so there should be no delays there. The only theory I have at this point (other than "Windows is weird, and it just waited to install the updates for a bit, sorry!"), is that instead of splitting the ADRs by Severity, maybe I should have split them by OS to get it down? Is it possible that having two ADRs push updates to the same PC at the same time would be a problem? I could get around that by splitting them by OS instead of Severity so that only one ADR is applying for a given machine. I've checked and it will still be under the 1000 limit, but by a smaller margin.