WSM Clean Uninstall

Anyone have an official or unofficial list of where WSM keeps all of its goodies? Having an issue with 12.6.3 wanting to use the wrong path for Fireware OS upgrades. Fresh install on a separate computer works without issue. If I uninstall, reboot, reinstall all the previous settings and/or metadata has been retained and the issue persists. I made a case and asked for a directory listing for a clean uninstall, and for the first time was astonished by the rep's response instructing me to 'Google' it.

I don't want to use a different user profile or machine. I just want my current setup to work properly. I prefer some sort of official listing versus me searching the disk and/or registry. Appreciate any help.

Comments

  • A fresh install for me asks where I want to do the install, which defaults to:
    C:\Program Files (x86)\WatchGuard\wsm11\wsm\bin

    There are lots of Registry entries which have this default path.

    Request your support incident to be escalated. That is a terrible answer from support.

  • edited January 2021

    I don't have an official list.

    (EDIT: Remove WSM normally first!)

    I recommend deleting the "C:\Program Files (x86)\WatchGuard\wsm11" and "C:\Program Files (x86)\Common Files\WatchGuard\wsm11" folders, plus the "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WatchGuard\wsm" registry key. You may want to remove any installed Fireware releases as well and then delete any subfolders under "C:\Program Files (x86)\Common Files\WatchGuard\resources\FirewareXTM", then reboot and reinstall.

    Gregg Hill

  • Thank you. Nice edit Gregg. Made me giggle.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @DStone
    I'll get this escalated for you. My apologies for that response.

    It sounds like an environment variable for that user may have gotten out of whack. Do you see that same issue if you log in as a different user on the same workstation, and try the same thing?

    WSM constructs where to find the upgrade file based on that variable, and the entry added in its catalog file, which is stored with the sysa-dl file in the directory (like C:\Program Files (x86)\Common Files\WatchGuard\resources\FirewareXTM\12.5.6\T70 for example)

    -James Carson
    WatchGuard Customer Support

  • Thank you Mr. Carson. My apologies for the delay in response. Had a fire to put out.

    Different user, same machine yields the same result. The specific path is: 'C:\Program Files (x86)\Common Files\WatchGuard\resources\FirewareXTM\12.6.3\FirewareXTM\M270_M370_M470_M570_M670.sysa-dl'

    Notice the second 'FirewareXTM' in the path, which should be a folder named 'M270_M370_M470_M570_M670'.

  • I don't have the 2nd 'FirewareXTM' in my path

  • james.carsonjames.carson Moderator, WatchGuard Representative

    If it's happening for every user, it's not an environment variable.

    If you open registry editor with the WSM and any fireware installs uninstalled, and search for:
    C:\Program Files (x86)\Common Files\WatchGuard\resources\FirewareXTM

    do you get any hits?

    Unfortunately, there isn't a set directory aside from it putting things in .\resources\FirewareXTM inside of where it's told to.

    -James Carson
    WatchGuard Customer Support

  • There was in the neighborhood of 20ish OS image installs dating all the way back to 2015, for 3 different models installed on the machine. The thought had crossed my mind to remove these just for good system hygiene.

    Apparently, having this many Fireware installs causes the issue. Just another example of a negative testing script that shouldn't have to exist. The issue no longer exists after removing all the old OS installs.

    I would be lying if I said I wasn't curious why that could happen, but alas it isn't worth a QA or dev blowing time on.

    I'll update the support ticket with the same info just in case another individual with too much system detritus comes knocking.

    Thanks for all your help!

  • I have 14 OS directories, the oldest being 12.1, for 2 firewall models.
    Again, I don't have this issue.
    Odd.

  • Ohh, it's very odd, and it might not be the total number that caused it. Don't remove any and see if you get the same behavior eventually. Be an interesting test case.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @DStone If removing the old Fireware installs did it, it was likely one of the catalog files that caused the problem.

    I'll see if we can reproduce it in lab -- but it sounds like it might be one of those situations where something else may have happened to get it into that state, and uninstalling just got rid of the resultant bit that caused the problem.

    Either way, I'm glad to hear it's working better.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.