Search the Community
Showing results for tags '.net 3.5'.
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 !!!
For some reason a bunch of my posts were taken out of their respective topics and mushed into one kind of related topic, so I am reposting, with the specific questions that need to be addressed. Currently, any attempt to deploy to stock installs of Windows 8, Windows 8.1, and Windows 10 fail, whether the Malwarebytes management console is used, or the MSI package created using the console is deployed via other means (I have tried PDQ Deploy and Group Policy Software Installation). The root cause of this issue is a reliance on .NET 3.5, which is not activated by default on Windows 8+, and must be manually enabled on each machine you wish to deploy on. This is an issue for a number of reasons: There is no clear documentation, or indication provided in the installer, that the installer is not compatible with a base installation of Windows 8+ and that a manual change by the user is required. Instead, the installer tries (and fails) to install .NET 3.5, and provides no guidance. The installer fails without any indication of the source of the issue when silently deployed on a Win 8+ asset without .NET 3.5 Windows Feature being enabled (not a default setting) The console does not indicate the source of issues when failing to deploy to the affected OS's, leading the admin to pull their hair out, trying to figure out why the deployment is failing Automatic deployments based on variables such as OU, computer type, user, are not possible due to the installer failing due to the 3.5 requirement The installer does not include any way to enable the Windows Feature While it is possible to enable 3.5 using DISM, there is no ability to define a script to be run as part of the MSI that could enable the feature (you need to point to a source folder in order to use DISM) The only resolutions that I see at this point are as follows: Update the program to not rely on what is not a standard feature for 34% (and growing) of Windows PCs (https://analytics.usa.gov/) Update the installer to be able to enable the feature without user intervention At minimum, update the installer to alert the user that the feature must be manually enabled and provide helpful documentation as to how to enable if an incompatible OS is detected Provide a mechanism in the console to allow for the insertion of a custom command / script at the beginning of the installer for incompatible OS's that would allow us to enable the required feature The command would be "dism.exe /online /enable-feature /featurename:netfx3 /all /Source:PLACE_LOCATION_OF_OS-SPECIFIC_SOURCE_FOLDER\sxs /limitaccess" You would have to allow the ability to define each source directory for the different OS'ss Provide clear documentation that managed deployments to unsupported OS's are not possible just using the stock generated installer, without additional modifications to the OS's Update the failure notices in the console, or at least place in the OS that is detected, so that we know that the deployment has failed due to an unsupported OS, and how we can modify the OS to accept the installation. TIP FOR THOSE WHO JUST NEED TO GET THIS DONE and can't wait for MalwareBytes to catch up with 34% of the PCs out there. PDQ Deploy is free and able to deploy out batch scripts to PCs defined in multiple ways (works great with PDQ inventory to identify Windows PCs that meet various criteria, such as no malwarebytes, windows 8+)