If you are here, you have probably discovered that Malwarebytes’ .NET requirement of 3.5+ is note met with the current releases of .NET (4.6.2 as of this writing) (more about this here, here, and here). You have also probably discovered that you can not simply deploy .NET 3.5 in an environment with managed Windows updates. This is because .NET 3.5 is considered a feature in Windows 8, 8.1, and 10, and must be added, not installed. In a managed environment, with imaged PCs that do not have ready access to the system WIM
There are 2 workarounds for this issue. The cleanest workaround is to build .NET 3.5 into your image.
If you are not imaging, or you do not want to build .NET 3.5 into your image,you can run the following line as a batch file (I like using PDQ Deploy to push these out, paired with PDQ Inventory, I can target machines without MBAM, and both are free). The only catch is you need to host the SXS source directory from each OS’s install disk.
dism.exe /online /enable-feature /featurename:netfx3 /all /Source:\\SourceShare\win81\sxs /limitaccess
I have two versions, one for Windows 8/8.1 that points to a Win8 SXS directory, and one for Windows 10, that points to the Windows 10 SXS directory. This command will bypass a search on the local computer, followed by an attempt to search the Windows Update Source location (which in a managed environment will likely fail), and goes directly to the location that you defined.
Once you have enabled .NET 3.5, you can go ahead and deploy Malwarebytes using your preferred method.
My suggestion to Malwarebytes would be to build into their deployment package builder the ability to define the source location for the above files, and allow us to manually download and host these files, and have your installer perform this DISM operation. You will have our gratitude!