A while back I wrote a procedure to uninstall the Firebird SQL tool. It's a simple procedure that looks in Program Files (x86)\Firebird\Firebird_2_5 and Program Files\Firebird\Firebird_2_5 for the unins000.exe or unins001.exe and uses executefile with the /quiet argument and Execute as System and Continue. It ran perfectly until yesterday 10/2/2018 when it suddenly stopped working. I haven't made any changes to the procedure itself and when I run the procedure it's reporting success like it's actually running the exe but it's not actually doing anything. There is no GUID for it and Kaseya shows the uninstall string as C:\Program Files (x86)\Firebird\Firebird_2_5\unins000.exe on the current Win7 test machine I'm using.
I've tried creating a bat file with: Start "C:\program files (x86)\Firebird\Firebird_2_5\unins000.exe /quiet" and having the procedure run the shell command as system in 64bit and tried executing a shell command with the Start "C:\program files (x86)\Firebird\Firebird_2_5\unins000.exe /quiet" typed out with no success. If I locally run the command line there's no problem.
We're using SaaS and it's showing as the latest agent version of 22.214.171.124 so we haven't gotten the new patch yet. I did try updating the agent and re-running the procedure with no success.
Unfortunately I found out it wasn't working in the middle of a rollout yesterday.
So I just got off the phone with Kaseya support and the solution is to use the executeshellcommand instead of executefile. Fortunately it was a quick call because I had already been writing a new script that I hadn't fully tested yet. Mad a couple of quick changes to execute as System in a 64-bit shell since it's running on a 64bit OS and no issues while sharing the screen. Now I'm just updating my main procedure to use this new one to run everything together in a sequence to do an update.
When you open a command prompt, you're in a 32-bit shell. Try forcing that from your procedure, and don't forget DOUBLE quotes around the command (only) -
%COMSPEC% /c "C:\Program Files(x86)\Firebird\Firebird_2_5\unins000.exe" /Quiet
But what's odd is that the procedure as written worked fine up until recently. No changes to the procedure itself and I'm testing on the same machine I tested on previously. I'm down to something odd in Kaseya or a Windows Update came in and is killing the procedure. I actually opened up a ticket with Kaseya and it's been elevated to 2L today so I have to wait a bit longer.
I did find a workaround for this particular instance. It's a bit of a kludge but it's a safe kludge. The uninstall is just to remove a Windows service that calls to the exe in the folder. Stopping the service and deleting the folder works fine in this case.
I have had issues before where if you ran it once it worked but if you tried to run it twice on the same machine, it no longer worked. It wasn't for an application but removing and adding VPN connections. I ran it the first time, it did its job, but then we added a feature to it and tried to run again and it would do the same thing. Report success but do nothing. I would try running it on a new machine and see if it works.
What tipped me off that something was wrong was I deployed the procedure to a new set of users in Buffalo and got a 100% failure rate. The same uninstall procedure worked with users in Sacramento with no problems. It's quite the odd situation.
I spoke with a Kaseya tech and the suggested solution is to not use executefile but use the executeshellcommand instead. Fortunately I had started playing with that and had a partial procedure written already. I just had to update it to use "Execute as system in a 64bit shell" since it's running on Win7 and Win10. In a quick test with the tech watching the screen it was able to complete the procedure.