Server Execution Time

The system is setup to only manual update, for some reason this is what the company does.

Anyways, I have another issue. This worked for one computer, but the other one doesn’t have any of these updates on it and is experiencing the same issue… Any thoughts on which one might be the issue?

Scroll down further in that list, the Microsoft Windows specific updates section is not visible.

Without getting rid of some random security updates to see if there is now yet another culprit the only suggestion I have is stemming from an experience that ERPSysAdmin had in the other topic. They removed the KB4562830 which is the 20H2 Enablement Package and that helped their situation. I’m wondering if something is being included in that update.

What’s the install date on that KB of that machine?

The user is out of office today, so I cannot check. I will be sure to check the install date as soon as they are back.

On yet again another note, I have 3 new cases of this issue. The one user though ran into this issue… Did this happen to any of you?

Yes that is what happens if both updates have been installed in sequence. When you remove March it rolls back to Feb Security update which is KB4601319 and you are required to remove that as well. I however have not had issues removing that update, but then again I removed it from all of my machines prior to KB5000802 coming out so I never had to do a back to back removal of both updates.

The only solution would be to try and remove KB4601319 via a PowerShell command and maybe it will remove that way, but if that is installed then yes Epicor will still be slow unfortunately.

This is the command I’ve been using to remove KB4601319 remotely.
powershell.exe -ExecutionPolicy Bypass -command "$SearchUpdates = dism /online /get-packages | findstr 'Package_for'; $updates = $SearchUpdates.replace('Package Identity : ', '') | findstr '19041.804.1.4'; DISM.exe /Online /Remove-Package /PackageName:$updates /quiet /norestart"

I had ONE laptop that “uninstall” ways grayed out so on that one I did a fresh W10 install to build 1909 and then updated it to 2004 and blocked KB4601319 before it installed. That was the only machine I had an issue with.

Here is the dates they were installed. Would you suggest uninstalling the KB4562830?

That’s the only logical suggestion I can make going off of other users experiences and testing. Keep in mind it’s only a suggestion and I would only do it if your IT Management is ok with that test to see if it restores the performance.

It seems like when 20H2 is getting applied via that update pack in March it’s also degrading the performance of the machine. And to be honest, that install happening on March 5th post when KB4601319 was installed may explain why that’s no longer on the list of updates that you can remove. But once again I’m only guessing since I don’t have a similar situation here to test with.

You rock!! I am going to try your suggestions tomorrow and see if it works. Thank you for your help. I will let you know if it worked. :smiley:

So if I enter this into the Windows Powershell application on the users computer (Not from a different computer), it will remove the update?

I believe to get that to work in powershell locally, just remove the powershell.exe at the beginning of the text. I have not tested that method myself though.

I got this code from an application called BatchPatch. I had to make a slight edit to their script to search for the build number vs the KB number since the KB number is not listed in the title of the installation.

19041.804.1.4 is to remove KB4601319, and
19041.867.1.8 is to remove KB5000802

Okay, so I should be able to just enter this in powershell and it should be good to go? Just double checking to make sure.

Try putting the - in front of ExecutionPolicy.

-ExecutionPolicy Bypass -command “$SearchUpdates = dism /online /get-packages | findstr ‘Package_for’; $updates = $SearchUpdates.replace('Package Identity : ', ‘’) | findstr ‘19041.804.1.4’; DISM.exe /Online /Remove-Package /PackageName:$updates /quiet /norestart”

Worse that can happen is it fails… :slight_smile:

I should note, this did not resolve the issue. I had the user remove this and Epicor is still slow.

What does their machine now show for installed updates? As noted I never experienced this since my machines are all at 2004 right now, sorry that didn’t seem to help.

Also is their slowness the text book reaction to these updates? My experiences are unpatched a form will load in 1-3 seconds, it was taking 10-13 sec on a patched one as well as you would see the Open, Engineered and Released boxes light up well before there was any text in the form, and when closing the Job entry box it would hit a state of “Not Responding” before closing, which also took near 13-15 seconds to do.

I think I figured out the users issue. They haven’t updated to the 20H2 yet. I am hoping by updating to that it will install the updates, in which I can remove the problem ones.

Yes if there is anything pending install it will typically prevent removal of previous updates. I always do a reboot on a machine before trying to remove anything or modify installs, that insures it’s completed any pending operations.

When I use that code I get an error.

Unfortunately I’m not able to help in troubleshooting that. As noted I got that script from another application and I’ve been using it through that, OR through PDQ Inventory using their “Run Command” function. Both of those methods send that as a CMD script to my knowledge (with that powershell.exe at the beginning to I’m assuming launch powershell), and they are both run using administrative credentials to do that. With you running it locally in PowerShell I can’t guarantee it working, sorry.

My only other suggestion is to launch a CMD window as an Administrator and paste the original script in there with the powershell.exe at the beginning. That’s all I’ve got.

Scratch that, its not working for me either… there must be something about this script that is not allowing it to be run interactively at the machine in question.