WHairstonLOI

@djacobson My understanding from testing with LT was that the actual end-user installation files used by the LT plugin were downloaded from a MB server as needed and installed. I put LT Tech Support through extensive testing on this issue some months ago, and we could not find ANY of the installation files on our LT server. Moreover, as MBAM updates have been released, the newer versions of them have always been downloaded and installed by the LT plugin on NEW clients' computers. If this is truly the case, that the LT plugin merely downloads and installs the various program installers as needed, is it possible for the latest MBARW to replace the old installation file so that NEW installs will at least be the latest version?

@djacobson So how do those of us who purchased via LabTech get automatically notified of such updates? I personally never come to this forum unless I have an issue, and I don't receive ANY current newsletters from MB. Am I supposed to make a habit now of visiting this forum and scanning posts on a regular basis just to see if there is a new MBARW installer in the future? Moreover, will these "new installers" again require us to download new installation files, transfer those files to our LT servers, write and test new installation scripts in LT, etc? I thought this product was supposed to SAVE us time and effort!

@djacobson Appreciate your responses to this topic. Please elaborate: 1. When we push NEW installations of MBARW using our EXISTING LT plugins, I'm still seeing the OLD version of MBARW deployed. Am I correct that this will be the standard behavior until a NEW or UPDATED LT plugin is developed and distributed? 2. If we apply the update of MBARW (either manually or via the .MSI file you've referenced), will that cause any issues with the EXISTING LT plugin? (ex: installations no longer recognized, etc.) 3. Per the question posed by @jpereboom above, after the update of MBARW is installed (either manually or via the .MSI file), will FUTURE upgrades to MBARW still have this behavior, or will we simply have transparent updates from this point forward (at least for MBARW)? 4. WHEN can we expect the new MB Endpoint Protection product to be the one installed, supported, and managed by the LT plugin? I don't expect an exact date, but a general timeframe for moving us LT partners off the legacy platform and onto the current platform would be nice to know. After all, our clients expect us to provide them with the latest, best protection, and obviously what we're working with isn't it.

For those of us who are MSPs using the Malwarebytes plugin with Connectwise Automate (formerly LabTech), is this update going to be automatically applied to the client workstations, do we need an updated plugin, or are we stuck with having to field phone calls from all of our end users and installing this update manually? So far today, it was the latter. Like many of the above posters, VERY UNHAPPY to learn about this via a barrage of phone calls from end-user clients and to see that the update was not silently installed like the Anti-Exploit software usually is! On a related note, I still don't understand why the Anti-Malware component can't automatically update either, but that's another post...

I originally replied to another thread with the same name (there are now 2 on this message board). My post showed as a reply for a few hours, then suddenly there was this new thread. The "Labtech message" you refer to is produced by the plug-in, which Malwarebytes authored; thus, my request to Malwarebytes for a more meaningful error message. For what it's worth, I've already notified LabTech about this too.

(Apparently, you've created a new thread from my previous post, which is unfortunate because it is EXACTLY the same issue that others were having in the previous thread and introduces VALUABLE new information to that topic.) Maybe you don't understand how LabTech works; it simply downloads the Malwarebytes-supplied installer, then executes it on the target machine. The installation file is downloaded from a Malwarebytes-controlled location, NOT our LabTech server (as LabTech tech support confirmed for us yesterday). I will also note that Malwarebytes develops the plug-in for LabTech (confirmed by both companies) which makes ALL of this installation possible, so control of the installer for the Malwarebytes installer and downloading process is ABSOLUTELY within the control of the Malwarebytes developers. Furthermore, there is no "error 1603" returned via the LabTech plug-in interface - there is simply an error message "Failed to download Malwarebyts Anti-Exploit installation file" - it doesn't even manage to spell "Malwarebytes" correctly. I'm not dismissing the fact that DISM MAY (but not always) be needed to enable .NET 3.5 on a post-Win7 computer, but as I noted in my previous post, every reasonable effort to enable it or install it should be made by the installer first. I supplied links to the Microsoft MSDN documentation on how to do this programmatically in my previous post, but I suspect that you are probably already using a commercial installation back-end product that allows this functionality. Failing that, there should be some reasonable error message returned to indicate that the absence of .NET 3.5 is indeed the problem instead of some misleading message indicating a failure to download the installation file. Please pass this information along to your DEVELOPERS so they can make the installer perform in a reasonable way, as MOST other software installers already do with their software.

Like others, I've spent multiple days trying to resolve this, both on my own and with tech support from LabTech/ConnectWise, as we push Malwarebytes Endpoint Security installations from within the LabTech/ConnectWise Automate MSP system to systems we manage remotely. Coincidentally, we have only experienced this issue with Anti-Exploit, as Anti-Malware seems to install just fine in the absence of .NET 3.5. What's worse: after installing Anti-Exploit, we can uninstall .NET 3.5 and Anti-Exploit continues to run normally (as far as we can tell). It appears that .NET 3.5 is only necessary DURING THE INSTALLATION, not for the execution of the actual Malwarebytes software! WHY USE .NET 3.5 AS A PREREQUISITE FOR INSTALLATION ONLY? Certainly, there must be a programmatic way to do whatever the installer requires using a newer version of .NET!!! While I fully appreciate the respect for copyright laws, I also KNOW that in my 32+ years in this industry, I have installed PLENTY of software that is intelligent enough to determine that Microsoft .NET 3.5 is not installed and ask if the user would like to install it or abort the software installation process. Microsoft makes the .NET 3.5 runtime installer available to software companies for redistribution and provides methods to run its online installer from the web, so copyright infringement here is NOT a valid excuse for failing to have a detect-and-install mechanism in place. See the details here: https://msdn.microsoft.com/en-us/library/xak0tsbd(v=vs.90).aspx. As a professional programmer, I also know that every decent, modern toolkit used for creating installation programs has the ability to check for prerequisites, then install them, make registry entries, run batch files, etc. if those prerequisites are not met on the target machines. There are some general guidelines for application developers in performing the correct steps to install .NET 3.5 on Win8.x or Win10.x machines here: https://msdn.microsoft.com/windows/compatibility/net-framework-4-5-is-default and here: https://msdn.microsoft.com/en-us/library/hh506443(v=VS.110).aspx. In the event the above steps cannot be executed for whatever reason on a particular computer (ex: no Internet access to download files), then the next-most-acceptable solution would be to provide more meaningful error messages and/or prompt the user to manually enable/install .NET 3.5 before gracefully exiting the Anti-Exploit installer. BOTTOM LINE: There are certainly more reasonable ways for the installation program to approach this issue than what is currently in place. However, for MSPs like myself who manage hundreds (or thousands) of computers remotely, this could easily be a deal-breaker that would send us to a competitor's product. Malwarebytes developers - PLEASE FIX THIS ASAP !!!

PLEASE add the capability for MBAM to auto-upgrade the program (or at least give us the ability to push program upgrades) within the Labtech/MSP plugin !!! After Malwarebytes recently released a new MSP/business version of Malwarebytes Anti-Malware (supposedly fixing MAJOR compatibility issues with Windows 10), I realized that there is NO way to upgrade the software on previously-installed computers using the Malwarebytes/Labtech plugin. The majority of my workstations (all previously-installed) now remain on v1.80.0.1010, while the new, more compatible v1.80.2.1012 is only installed on NEW installations. Unfortunately, the plugin is the ONLY way to install this software on computers, meaning that EVERY COMPUTER must have the old version MANUALLY uninstalled (using the plugin interface), then the new version of Malwarebytes MANUALLY installed (again, using the plugin interface) in order to upgrade. This is asking FAR too much of any MSP, regardless of size - we simply can't afford to spend that much time uninstalling/reinstalling every time Malwarebytes issues a program upgrade. Strangely enough, the Malwarebytes Anti-Exploit piece of the Security Suite appears to upgrade on its own as new versions are released, only the Malwarebytes Anti-Malware software does not.