Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


rdeal last won the day on December 10 2018

rdeal had the most liked content!

Community Reputation

2 Neutral

My Information

  • Agent Count
  1. I don't see it under the 'new'/Advanced search UI, but if you right-click and switch to 'Legacy' you'll see patch-related search options under "Related - Hotfixes." I'm fuzzy on specific memory, but IIRC 'Installed' was straightforward, 0 = No, 1 = Yes... for 'Approved' it depends on the specific patch manager version. 10.5 Patch Manager: 0 = Not-Set 1 = Approve Beyond that, I don't remember... I think 2 was Deny and 3 was Ignore? 11-12 Patch Manager: 0 = Not-Set 1 = Ignore 2 = Approve 4 = Deny That tripped us up when we upgraded the Patch Manager a year or two ago - a bunch of our external patch reporting was keyed to the Approval setting, which changed and made our numbers look really really weird.
  2. (edit: not the person you were asking, but...) We generally use "default" group + its own autojoin search, and have individual groups + searches for the exclusions roughly by client/OS, like: "Patch Install - Workstations" and "-Servers" by default "Patch Install - Contoso Workstations" with its own autojoin search tagged to clientid + OS "Patch Install - Fabrikam Servers" with its own autojoin search tagged to clientid + OS ...etc. It works well for us because diverging from the primary schedule is pretty uncommon, so it's not a big deal to create a custom group/search for exceptions. If you've got an even distribution of clients in each group/day and there isn't really a default, it sounds like doing individual searches/groups per client could be a pain, though still not *that* bad... if you really had to, my instinct is something like client-based EDF with a group per day (i.e. "Patch Install - Monday 1-3AM," "Patch Install - Tuesday 1-3AM") targeting by that client EDF and whatever else you want. You'd have to tag each client correctly once, but then it'd go from there and capture everything inside it. One thing that threw us off early on was that in the "Groups" window, the *lower* a group is, the higher the priority is (i.e. it processes from bottom to top). It looks like the tooltips reflect that now, though!
  3. 1) Inventory... no matter what, everything's using the Windows Update Agent on a given computer (which is a weakness in terms of Windows 7/2008 R2 patching in particular, regardless of the patch system you use - WUA versions lower than 7.6.7601.23453 are effectively broken and will not consistently report what patches they need). I'm not 100% on this, but if you're using Managed Mode, LT makes a call to the WUA, which checks in with MS (or WSUS) directly and reports back to LT on what it needs/wants. tldr, the list of patches you see on a given computer is what you would see if you just opened Windows Update directly. 2) Schedule - yeah, the template patching schedules have no connection to the machine-type schedules. There's one gotcha in that the previously mentioned WUA is more or less single-threaded - if two different processes attempt to call it at the same time, it bails out and tosses a 0x8000xxxx error, failing both requests. You don't want to have a patch install interrupted by a patch inventory or vice versa, because *both* will fail (i.e. a patching window of 1am-2am combined with a patch inventory of 1:15am is likely to have problems). This also applies to non-LT patch queries - you can see different products hitting the WUA in the WindowsUpdate.log file. 3) For effective policy under 10.5, you want to look at the "Current Config" trees - they show you the sum total of the templates vs. priorities, etc. - sort of like running a gpresult to see how the group policies will resolve on a machine. Whatever you see in there is what it's going to try to do, and if something is unexpected there, there's probably something unexpected happening somewhere. As a couple of asides: - v11 has a pretty massive change in the UI, and similarly huge changes to how patching works. It is itself about to be replaced by v12 literally right now, so you might want to start reading into the updates! It's a very different paradigm, but better if you're messing with multiple custom schedules/approval policies for patching - you're kind of limited on schedules via templates, at least from my experience on v10/10.5 Ignite. Also if you have any kind of custom scripts or reporting running against the patching database, the 'v_hotfixes' table changes "1" from "Approve" in 10/10.5 to "Ignore" in 11, so watch out for that lol. - LT/Automate doesn't handle the "upgrade" patches for Windows (i.e. Upgrade Win8.1 > Win10, or 'upgrade' Win10 v1607 > Win10 v1703) yet - they show up as Windows Updates and so appear as any other patch, but will basically silently download, report 'OK!' and not actually install.
  4. What are you doing script-wise to actually install the latest version of the Windows Update agent? If I'm understanding your script correctly, you call another script that actually does the install. Are you able to do a silent install of a Windows Update package? Via wusa.exe, you can silently install .msu packages (which all of these KBs being discussed are), fairly similar to msiexec. /quiet will force no UI with an automatic reboot, /quiet + /norestart will force no UI and skip the automatic reboot (though LabTech will still pick up the machine needs to reboot after), /warnrestart, /promptrestart, /log, etc. So if your script does SHELL: wusa %ltsvcdir%\[file location]\Windows6.1-KB3172605-x64.msu /quiet /norestart, it'll silently (attempt) to install the hotfix. The stuff being discussed immediately above was mostly geared towards making sure the wusa command actually works.
  5. So far the process I've got that's been working 99.9% of the time (it's failing on two computers, but TrustedInstaller is broken on both so they've got other problems, haha). stop wuauserv rename c:\windows\softwaredistribution (as opposed to deleting it, which might take enough time that the service restarts before the folder's gone) start wuauserv install patch via wusa rmdir the renamed softwaredistribution folder Specifically, stopping the service, *removing* SoftwareDistribution (delete or rename), starting the service and immediately running the patch has worked reliably. We jumped from ~80% full to ~95% full on Win7 with no human interaction. Our WUA-fix script is also pulling down the prereq April 2015 hotfix on computers that don't have it, but that doesn't need a reboot so it can go through no problem.
  6. I'd be interested in this, too - downloading the .msu file and running it locally on the machine, it will stall at 'Searching for updates...' for hours if left to its own devices on about 90% of the Windows 7 PCs that are still behind. If I run the installer, immediately stop and restart the WU service, and run it again a second time, it goes through almost immediately with no problems, but that requires a manual followup on each Windows 7 machine. Running it in the background via wusa.exe seems to have very little feedback and not work - I've tried scripts/psexec with variations on "wusa execute hotfix > wait 30 seconds > bounce the WU service > wusa execute hotfix," but that doesn't seem to work as it does if done via GUI.
  7. My experience echoes Josh.eblogix's, for the most part - there's no issues pushing patches and end-users don't get prompts. We're only having a hard time with the major build upgrade(s), i.e. the 10.10240 to 10.10586 '1511' or 'November' update, which shows up as KB3012973. That one shows up in patch management as normal and can be approved/denied, but when LT attempts to push it, nothing happens. We made a script out of the 'patch install' command as instructed by LabTech support, but that seems to pull down a 15MB executable, which doesn't look promising. Has anyone been able to get that 'upgrade' patch to work at all? In the past with XP/Vista/7 we'd had scripts specifically to do OS service packs by downloading the offline installers, but I'm not really seeing an equivalent for this aside from just downloading the Media Creation Tool and making an ISO. There's only a handful of 10.10240 machines out there, so I wouldn't worry, but I feel like we're about to run into the same problem all over again with the upcoming August 2 update.
  8. Also as a related heads-up, I've been following this in general with regards to the Windows Update Agent side of things - it looks like on 6/21, Microsoft released a hotfix that specifically addresses many of the remaining WUA performance issues on Windows 7: https://support.microsoft.com/en-us/kb/3161647 •An optimization that addresses long scan time for updates that's reported on some computers. •Fix for a Windows Update error 0x8007000E on some computers while they are updating. •Some reliability improvements. There is no standalone download for that, it was just contained within another rollup: https://support.microsoft.com/en-us/kb/3161608 As long as we're seeing 7.6.7601.23453 on a Windows 7 machine, the patching performance in terms of querying/installing hotfixes is FAR improved (compared vs. -.19161 from Mar, -.19116 from Feb, -.19077 from Dec, -.19046 from Nov, etc.) to the point where I think we might be able to see Windows 7 patching start working normally again!
  • Create New...