Issues With Managed Deployment To Latest Operating Systems (Windows 8, Windows 8.1, Windows 10)

[WHairstonLOI]

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

Edited January 30, 2017 by WHairstonLOI

[djacobson]

.Net 3.5 is not a requirement for the operation of standalone Anti-Malware or Anti-Exploit. It is, however, a requirement for the communication of the modified managed versions in use by MSP's like Labtech and our own Management Console software.

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.

[WHairstonLOI]

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.

[djacobson]

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.

[WHairstonLOI]

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.