For some reason I’ve had a lot of Windows 10 PCs fail on their Windows Update with the error 0x8024401C . The “why” probably has to do with some secret handshake that I failed to do with the WSUS server, but the fix (such as it is) was hard fought. The trick I’ve found is to force install the next patch in the Windows 10 update tree. The chart to the “tree” is here: https://technet.microsoft.com/en-us/windows/release-info.aspx. So for example, if I have a system on build 14393 that was last updated in October 2017 I would pull down KB 4052231 and apply that patch. Reboot, and fingers crossed, Windows Update will work. Some caveats:
- I always go with the lowest patch that I can find as it might fail and I will need to install the next patch in the tree.
- Sometimes the patch that I need is not in the update catalog to be downloaded which leaves me having to poach it (painfully) out of the WSUS catalog.
To apply “CAB” patches, start and elevated command prompt and enter the command Dism /Online /Add-package /packagepath:./patchName.cab
Running DISM with no switches will also tell you the Build Number of the Windows 10 system.
(In hindsight, given my access to volume licenses downloads, I could have just downloaded the newer Windows 10 ISOs and updated the systems manually, perhaps, but the above method has the novelty of being able to be run remotely).
[Note (9/25/2020): this process seems to have gotten much better with subsequent Windows 10 updates and it’s usually enough to just go the MS Windows 10 download site and kick off a forced update).
In the past I’ve had good luck ‘stacking’ Adobe Flash Player installs on top of each other in group policy. For some reason one of the newer versions (10.3.183.7) choked, leaving something along the lines of an ‘FP_AX_MSI_INSTALLER’ error in the event viewer. That error led me to this post which stated, more or less, that a computer logon batch file is the best bet (so ’90s!). I implemented the batch file and had no issues getting everyone’s Flash updated (do note though that you’ll need to do a double detect if you have 64 bit systems in your environment as the version key is at “HKLM\SOFTWARE\Wow6432Node\Macromedia\FlashPlayer” on 64 bit systems).
It was at this point that I moved on to Acrobat Reader. I was a little puzzled because I downloaded the latest version (10.1.1), but after installing it, it reported that it was only ‘10.1.0’. It turns out the ‘.1’ is a standalone patch that is included with the distribution. Unfortunately, as I’d found with Office 2007, group policy does not do .msp files (msi patch files). Right away I thought of my Flash Player install batch file, but Acrobat Reader (as near as I can tell) does not have a version registry key like Flash Player. I hunted for an easy way out, but finally gave up and wrote a program to return the Acrobat Reader version (based on what’s reported by the installed executable file). You can download the excutable and the batch files that I used for Adobe Flash Player and Acrobat Reader here. (Note: if the computer does not have Acrobat Reader installed, the detector should return the string “NotInstalled”. I didn’t worry much about this detection as I have the batch file in the group policy that installs Acrobat Reader.)
Justin scopes out some optical ejection tools that many a tech has to rely on from time to time. I figured I’d point out this snazzy version in my possession:
What makes it so expensive is that it was crafted by an expert IBM DBA who crafted this while he was waiting forever for an AIX system to complete some series of tasks (which on AIX systems of that gen, pretty much every task took forever). By my estimates that’s about $300 computer tool. At least he had the courtesy to leave it with us since we footed the bill for it.
I’ve decided to move us away from McAfee and onto Kaspersky. I’ve used McAfee’s product here for more than ten years and have been pretty happy with it and it’s protection has been pretty top notch, too ‘top notch’ as a matter of fact. I’ve in fact gotten away from even installing McAfee on mission critical systems due to it’s penchant for bringing systems to their knees at seemingly random intervals. It had gotten to the point that I didn’t even see the point of paying for McAfee since I had so sparesly installed.
It was at that point I knew a change was required: a virus scanner barely wroks to begin with, but not at all if it’s not installed. I’ve had a foul experience with Symantec (doesn’t seem to stop anything) and Trend (ditto, at least for their home product), so I decided to go with Kaspersky.
What was interesting though was when I first went to install it on a batch of PCs I got a bluescreen error on one of the PCs (my bosses system!) of 0x000000d1.
As it turned out though, the issue had nothing do to with Kaspersky, and everything to do with some bum DNS entries. In my initial testing I was installing to two computers of users who weren’t in that day, but then my boss called and said that it was installing on hers. I thought this was odd, but when I checked the logs Kaspersky did indeed say that I had installed it to the incorrect system. Flustered, I ran it again while double checking the computer name (which is fairly similar), and around that time my bosses PC bluescreened and Kaspersky again said that I was installing to the wrong computer. At that point I resolved that I would use the IP address of the computer I wanted to use, so I pinged it and plugged it into the script and as a joke before running it I pinged my bosses computer to see what it was, and it turned out that it was the same. My desired target PC had the wrong address assigned to it in DNS.
Kaspersky proved rather extra adept since it detected the name failure and then helpfully replaced the ‘wrong’ name with the ‘right’ name that the system was reporting and the blue screen was caused by trying to force an install over the existing install.
For some reason I never thought to note a workaround that we use for our JD Edwards ‘ocx’ files, probably because I figured that no one would be running on a tools release as old as our own. Trying to run the export to Excel program and whatnot with newer versions of Internet Explorer can lead to errors like “This media object is not viewable on this type of browser” or the program flat out not executing.
The problem, as it turns out, is due to a browser check issue in the programs where they don’t know what to do if your browser is newer than ‘6’. The solution is for your browser to lie about what version it is. The first step is to download and install a ‘user agent’ picker, such as this one. The next step is within IE, go to Tools->Set UA String->and set it to ‘MSIE 6.0’. You can then load the addons, and after they load in the browser you can set the browser UA string back to the original setting.
UPDATE 12/5/2013: It appears that starting with IE 10 that UA picker will not work if you are not a local admin, which is the case for 99% of our systems. The only work around that I’ve found for our particular situation is to have a hard setting in Group Policy that gets pushed down to the clients. It would appear that IE 10 only pays attention to the UA setting in the “Version” key in the registry hive “HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent”. The “Policies” hive, despite being in HKEY_CURRENT_USER, cannot be written to by the current user by default (thus any solution run by a user without elevated privileges will not work). If you are running as a local admin, I did stew up my own program to change the registry key on demand (NO WARRANTY!): Source (VS 2010 project), Executable (.Net 2.0 required). Remember, it’s required that the program be run as Administrator (right click->run as Admin). You cannot run this as an admin apart from the account that you want changed (i.e. user1 is logged on, but right click->running it as user1admin) as the changes must take place in the profile of the ‘Current User’.