Jump to content

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


Recommended Posts

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:

  1. 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.
  2. 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)
  3. 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
  4. 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
  5. The installer does not include any way to enable the Windows Feature
  6. 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+)

Link to post
Share on other sites

  • Root Admin

Hi @PhillyPhotog

Sorry for the delay. You may wish to contact the Business Support Helpdesk for direct assistance with installation issues. Below is the information regarding the prerequisites for clients.

Business Support
https://www.malwarebytes.org/support/business/#techhelp


What are the prerequisites for Managed Clients to register to the Malwarebytes Management Console?
https://support.malwarebytes.org/customer/en/portal/articles/1835499-what-are-the-prerequisites-for-managed-clients-to-register-to-the-malwarebytes-management-console-?b_id=6520

 

The following prerequisites must be met for all Managed Clients using the Malwarebytes Management Console:

  •     .NET Framework 3.5 or higher
  •     Windows Installer 4.0 or higher
  •     File and Printer enabled
  •     NetBIOS enabled
  •     Network Discovery enabled

Regarding Firewalls:

The following is a list of ports that are commonly used for operation of the Malwarebytes Management Console.

Management Server Ports:

  •     53: Domain Name Services (DNS) lookups
  •     137: NetBIOS Name Resolution
  •     139: NetBIOS Session Service
  •     389: Active Directory (AD) authentication
  •     443: Default Management Server port
  •     18457:  Default client communication port

Client Ports:

  •     135: Process control related to file transfers to/from server
  •     137: NetBIOS Name Resolution
  •     445: File transfers from server associated with install, uninstall and simulations
  •     18457: Default client communication port

 

Thank you

Ron

 

 

Link to post
Share on other sites

I have to agree.  I have wasted probably 2 days trying to figure out how to make this deployment work appropriately while working around some of your restrictions.  There is zero need for Netbios these days, and my DHCP server disables Netbios, so I can't push install (mind you, I've been pushing installs of AV for 10+ years without issue, or Netbios).  I've been trying to find out why I can't get my group policy install to install on a Windows 10 machine.  This is because .NET 3.5 is not installed.  You say .NET 3.5 or above, well 4.6 is installed and that is not enough.  I don't want to force 3.5 on the newer OSes.

Any updates to the sofware to resolve this would be greatly appreciated.

Rob

Link to post
Share on other sites

Ron, Thanks for the reply.  I did submit a ticket (00015829) via the site form, but the technician assigned to the ticket did not satisfactorily address the question posed. The first response just told me to enable 3.5 manually.

When I restated a need to deploy via GPO, I received a reply saying that GPO pushes are possible (they aren't, without the manual enabling of 3.5) and that console deployment requires 3.5.

Unsure if I was missing something, I replied back indicating that I was not sure I was following, and attempted to restate what I though was communicated, hoping that there was in fact a way to deploy through GPO without manually touching each machine (or using a script):
"If I have a management console installed on a server, along with the installed console, files are located that can help me deploy via GPO, using a separate server with Domain Controller functionality."

The reply I received provided no new insight and looped back to the first reply, that 3.5 is a requirement. 

Either there is a severe misunderstanding that the support and developing teams have regarding the inability for your users to automate the installation of your product using existing mechanisms, that they think it works, but in real-world applications, it is broken, OR, you know it doesn't work in real-world deployments, and have not documented that this is an unavailable feature with the latest OS's without manual or scripted intervention by administrators. 

I do not have an insurmountable issue with the requirement of 3.5 (though, really, we are on 4.6. 3.5 was released in 2007. 4.5 was released in 2012, 4.6 almost a year ago. Let's update to the most current version, and those with old .Net, can upgrade through available MSIs).  My issue lies with:

  • The lack of documentation that spells out that out-of-the-box deployments are not possible with the most current OSs
  • The lack of a method to insert the necessary scripts to include in the MSI created by the console.
  • The lack of indicators to help troubleshoot deployments from the console to help admins understand why the deployments are failing (3.5 not installed, OS version, etc)

As a business customer, I would expect that this would be a priority, as businesses are upgrading their assets, this is going to become an increasing issue and frustration, especially since there is no indication provided as to why deployments are failing and your pre-requisites omit that ".Net 3.5 or higher" actually means 3.5-3.999 is required, and it has to be enabled manually on Windows 8-10

Link to post
Share on other sites

  • 3 weeks later...
  • Staff

PhillyPhotog,

I am trying to put together documentation that will show admins how to satisfy the pre-requisites (which are clearly listed in the Admin Guide) via a Group Policy update.  That is not ready yet.  I also would like to see Malwarebytes be able to easily take care of the changes that need to be done on your endpoints, but at the same time, as an admin I'm not sure I would want to allow an external vendor to be able to make changes at a sysadmin level.  Its a balancing act.

In the Management Console Admin Guide AND the Endpoint Security Quick Start Guide, the pre-requisites for a successful install are listed.  Some versions of Windows require a download, while others require enabling the .NET which is already there.  I could make apologies, excuses, or point fingers.  Instead, because I recognize the need (as you do), I am trying to put together documentation that can better assist you in clarifying and achieving your goals.

Reading the last paragraph of your post, the reference to ".NET 3.5 or higher" is not what is listed in the Quick Start Guide or the Admin Guide.  3.5 is listed, because Microsoft does not include everything from 3.5 in higher versions.  If you want 3.5 compatibilty, you must install 3.5.  You are correct that we do not specify whether downloading or enabling an existing implementation is required.

Regardless of all of this, we are trying to make this better AND as seamless as possible.  We do have limitations, but when developers cannot figure out how to do it with code (while balancing their other requirements), I try to do it with documentation.  If you have suggestions, please send me a private message here.  I bend over backwards to do the best job possible, and I am your advocate more than you can imagine.

I obviously don't hang out here often, but a PM will trigger an email to me so that I know to pay attention.

 

Link to post
Share on other sites

  • 6 months later...
On ‎6‎/‎25‎/‎2016 at 0:49 AM, gonzo said:

Reading the last paragraph of your post, the reference to ".NET 3.5 or higher" is not what is listed in the Quick Start Guide or the Admin Guide.  3.5 is listed, because Microsoft does not include everything from 3.5 in higher versions.  If you want 3.5 compatibilty, you must install 3.5.  You are correct that we do not specify whether downloading or enabling an existing implementation is required.

Issue is the staff member above you states this:

On ‎6‎/‎3‎/‎2016 at 2:03 AM, AdvancedSetup said:

The following prerequisites must be met for all Managed Clients using the Malwarebytes Management Console:

  •     .NET Framework 3.5 or higher

Regardless, I resolved the issue by following the enabling of 3.5 via these instructions here:

https://msdn.microsoft.com/en-us/library/hh506443(v=vs.110).aspx

and got a successful deploy on a windows 10 machine via the Malwarebytes Management Console "Client Push Install".  I hope this helps others, as it took a lot of reading and googling to figure out that .NET 4.6.X =/= .NET 3.5

 

(re: 'Simulation failed. .NET Framework 3.5 is not installed on client computer.')

Edited by Grant_Beehler
Link to post
Share on other sites

  • Staff

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.

Link to post
Share on other sites

when I try to add the .NET 3.5 program and feature via control panel, I get the following error - 

Window's couldn't connect to the internet to download necessary files. Make sure that you're connected to the internet and click 'Retry' to try again.

 

Error Code: 0x800F0906

 

 

Yes I have internet access. This is a error I am seeing on many of my Windows 8.1 VM's and Surface machines.

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

Back to top
×
×
  • 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.