Jump to content

WHairstonLOI

Members
  • Content Count

    8
  • Joined

  • Last visited

Posts posted by WHairstonLOI


  1. 12 minutes ago, djacobson said:

    That is correct. The plugin is only going to install what it has available within it. 

    @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?


  2. 14 minutes ago, djacobson said:

    Hi @jpereboom, the MBARW team learned a valuable lesson from the backlash and case inundation we received, one which us B2B agents already know; that our admin customers need to have program revision update control. Bar none, end of story. Whether that's due to end user restrictions, update vetting, change control processes or just bundling all the work into one day of updates across your environment, or more honestly a week cause crap happens ;p - the B2B team gets it, we've all been system admins in previous lives, we are your advocates and we do not want your tickets/helpdesk to blow up any more than our own. These expectations have been communicated and the MBARW team is stepping up to meet them on behalf what our people need.

    There are no controls for the MBARW system tray icon, so to prevent things like this in the future, it is wholly on our shoulders here internally when the time comes to "flip the switch" for updates, so here's what we are doing; the business MBARW build will no longer be part of the over the air updates. Future updates will be done via new installers, which will be communicated in our new support community here - https://support.malwarebytes.com/community/business - We will also mirror this communication via forum posts and possibly the B2B newsletter emails.



     

    @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!


  3. @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.


  4. 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...


  5. On 1/31/2017 at 7:43 PM, djacobson said:

    I have done nothing to your thread or post except to answer you. If you check your inno setup log area in Windows, you are sure to find the installation logs identifying the exact failure, which is highly likely to be 1603. The Labtech message is not at all verbose to what's actually happening. If you would like to have a case elevated to the development team, you will need to open a support ticket at corporate-support@malwarebytes.com, otherwise all support requests for partner applications must be done through that partner.

    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.


  6. 5 hours ago, djacobson said:

    Our managed client offline packages created by our console will install the prerequisites as needed, although for Win 8 and above, .Net 3.5 is already installed and disabled by default and the install will fail. The error code is usually 1603, which in this context means the failure was caused by the software already being installed. Our installer cannot correct for this condition. You will instead need to enable .Net 3.5 in Windows Features. If you stripped this out of your desktop image, you'll need DISM to re-install it.

    The Labtech plugin installer we provide only installs the installation files to your Labtech server. Deployment via the Labtech server is dependent on Labtech's chosen engine, we are not at liberty to change their installer.

    (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.


  7. On 1/5/2017 at 7:41 PM, gonzo said:

    Grant,

    I verified with the QA staff responsible for testing Management Console and deployment methods that what I had written in the guide is correct.  Ignore the "or hjgher" part that was suggested,

     

    vs2015sv,

    Sorry to hear that.  We would not be able to include software that is not created by Malwarebytes or provided as open source.  Microsoft owns .NET technology, so that would be copyright infringement.

    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 !!!


  8. 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.
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.