Author Topic: Evaluation of the Malwarebytes Endpoint Security Management Console  (Read 2927 times)

Randem

  • Administrator
  • Hero Member
  • *****
  • Posts: 2664


UPDATE:


05/01/2017: Malwarebytes technical coordinator has contacted me on 5/1/2017 about pushing the issues to the department that handles customer experiences. We will see how this goes.

07/01/2017: We still have not gotten any kind of response from Malwarebytes on anything except to say that they are moving to a cloud platform, which is ridiculous. Why would anyone serious about security use the cloud platform? It just opens the door for external hacking on your information and the most problematic situation is that you have to attach to an external system so that you can manage your own internal one. If your internet is down; you are screwed on ALL cloud platforms... It's like you need the police in your area but you have to call the police five states away... Don't expect help anytime soon.

Meanwhile here is some information on usage:

Malwarebytes Management Console Review - 05/02/2017

NOTES:

These tests were run in a real world environment initially with a policy update of 1 hour (real world would be 24 hours), this setting caused
multiple unexpected issues. We had to change the setting to non-real world lab settings (policy update 1 minute) in order to get some things
to somewhat work.

In order for this console and applications to work; TCP ports 135,137,445 & 18457 must be opened (traffic both ways) on your firewall
and or router with the remote port of 0 - 65535 open for this rule. This is especially true if you plan to use external clients
(PC's in another physical location or on another subnet). It may be prudent to add the files "Management Console.exe" and "SCCOMM.exe" to your
firewall allow rule list to prevent unexpected communications errors. The MBAM documentation is not clear about this.
   
It seems that the communications is backwards on this console which leads to much confusion. Apparently when you ask the console to do something
it queues the request then only when the client station contacts the console the request is given to the station. This makes the console
not "Management" in the fact that from the console you want to be able to control the stations behavior and force out of date scans updates etc...
or even force a scan or update for maintenance or testing reasons. This means that if the client station never contacts the console there is no
error telling you that anything is wrong or that your request have not been made. There is no request queue to see exactly what has not been
completed or to delete the request if you want to.

The only way to help this situation is to set the checking for a new policy to about 1 minute. The default of every 5 seconds will create a
large amount of useless network traffic. Say 200 stations checking every 5 seconds for an update that should only change once in maybe 3 - 6 months (if at all). All this network traffic is just clutter on a company's network and need not be there. We had our policy check set for 60 minutes
(real world would possibly once a day) and communications seemed to never happen for we had to wait 1 hour before the clients would check again
so that any new values would become effective. This new setting helped all our communications immensely. The policy update time should have nothing
to do with console requests to perform tasks immediately. These tasks should be a forced communication from the console. Also a policy update would
be better served as a broadcast to all stations to get the new policy. Stations that were offline at the time of the broadcast would naturally
automatically check when they are powered on or connected to the network.

Our test were performed using a packet sniffer and AVG Internet Security for Business (with Management Console). In the MBAM Console the following settings have been used is Auto Refresh on, Policy update to 1 Minute.

Client Tab:

These issues are for clients on the same subnet as the console, but also happen with external network clients.

  • Update to scanning status when scan command is sent to client stations; it is very much delayed (if it happens at all).
    The status may be better understood as "Online: Pending Scan" so that users know something actually happened. Even though one can check the
    Admin Log to see that the scan command was sent, that is all the evidence one has that something is actually happening. 1 hour later the
    timestamp in the log and still no evidence of scanning... Another issue is that we cannot query an external client to scan. It seems the communication
    is only client to console (communications needs to be bi-directional). Perhaps in the client logs all pending operations for the client should be
    listed so that all operations for the client can be viewed from the same screen without having to sort thru the other pages of the console.

    SOLUTION:

    a)   We found scanning directly connected to the policy update time.

  • It seems that we cannot query the client for an update status. Communication should be forced by the user in either direction to ensure
    accurate statuses. It seems that the refresh of the console only reports that which has already been reported to it, not querying the client for
    a real-time update. The console user should be able to force a communication check and diagnostic.

    UNCHANGED:

  • Some clients show offline even though I know that they are powered on and working correctly. This is sometimes sporadic and cannot be
    repeated by any means until it shows up. This may be due to different version of MBAE being installed and updated thru the console. It appears
    to have disappeared after using the MBAE uninstall tool on all clients. A day later this same issue reappeared with no changes to the system
    by us. This appears to be related to #12 in some cases.

    WORSE:

       We have clients that have been powered off for over a week and they still show up as online in the console.

    UPDATE: 04/27/2017 - Did a refresh on the console and the 3 laptops that have been powered off and not attached to the network since 4/15 finally showed offline. However one desktop that has been powered off and not connected to the network for the same amount of time still shows as online. Currently no stations show offline even though they are. How is this communication done to detect offline?

  • Better messages and some instruction on how to remedy the issue at hand need to be in the console. Example: a client is offline,
    How do we remedy this? What communication is failing? We should be able to force this communication or at least run a test between client
    and console to determine the problem.

    UNCHANGED:

  • On an external XP client we had to start the MEEClientService service, but when starting the MBAMService; it shutdown and also shutdown
    the MEEClientService service also. This is the client that shows Anti-Exploit as protected but Malwarebytes as unprotected and greyed out in
    the console. We got our internal XP Client to work properly. We checked the Windows Event log and fount that there was a problem with a
    .NET 2.0 installation, We re-installed .NET 2.0SP2 and .NET 3.5SP1 (just in case). We uninstalled MBAE using the uninstall tool, restarted
    the computer then re-installed MBAE and all worked properly.

    CHANGED:

    a)   When restarting the an XP client the MEEClientService service does not automatically start.

  • The uninstall tool should be a integral part of the console and used when one does a remote uninstall.

    UNCHANGED:

  • The logon user should be updated to the current user that is logged on at the time of query or reporting.
    This would be helpful in troubleshooting issues on the client side. Needs to be real-time query.

    SOLUTION:

    a)   We found this directly connected to the policy update time.

  • There is no way to currently push out anything to external IP clients. The communications is from client to console only.

    UNCHANGED:

  • Some clients will not show up in the client list after manual installation with a ClientSetup installation package.
    The clients will not show up until a push installation is done from the console. This is due to the IP address of the server not being in the setup package in the sccomm.exe.config file. A setup package for external clients should have the option to set the IP address of the console server which will be remote from the console.

    UNCHANGED:

  • If a client is removed from the client list, it takes a restart of the client machine to get the client back in the list.
    This should actually be done in a forced communications check to re-populate the list.

    UNCHANGED:

  • There seems to not be an automatic refresh setting in the client area of the console and it does not refresh the client
    screen to give a real-time update on client statuses. The refresh button does almost nothing for realtime communications.

    SOLVED:

  • On some clients the MEEClientService service does not start or it terminates at startup and there is no error message or any clue to why the client is not communicating with the console. If this service is not started then there is no communication between the two and the client
    is reported as offline in the console. It seems the only way for the console to get an update is to restart the MEEClientService service.
    This service also seems to terminate on some computers without notice. The only way to diagnose a none communicating client is to check the
    Windows services to see if this service is started. Sometime setting the MEEClientService service to Automatic Delayed will allow the
    service to startup. If this is the case the installation of this service should be automatically set as so to avoid trouble.

    UNCHANGED:

  • The "Server Address Setting" in the Admin tab has a bad issue if you manage to check the box "Force Managed Clients to use new address".
    It cannot be unchecked unless the server address is changed to another WORKING console IP Address. This poses a problem with clients
    that are not on the same subnet or are an external client. This address will keep changing the external client's console contact IP address.

    UNCHANGED:

  • A message is displayed in the Client Push Install tab of the Admin section. "Newer version of Malwarebytes Anti-Exploit was already installed;
    Client software has been installed and registered to this server.   1.80.2.1012   1.09.2.1384   4/19/2017 4:54:28 PM". Why do the clients have a newer version of software than the console will deploy? The console should have the latest updated version of software to deploy first. There needs to be an ability update the console so that our installation package and deployment schemes have the latest software first?

    UNREPORTED:

  • There should be a BIG warning on the communications tab of the Policy editor stating that changing this value will affect ALL communications
    and that long delays, incorrect statuses and incorrect station information will apply. Better yet; have a separate area (not in policy update)
    for the communications of the rest of the system. A policy update does not appropriately state what this setting will actually affect.
    The rest of the system should and needs to work independently of this setting.

    UNREPORTED:

  • When powering off a client station, it could take several hours for the console to show that the station is offline.

    UNREPORTED:

  • External client stations are constantly reporting in their system logs "About to set Server Address to 192.168.1.27". This is not good for the
    external server address is 98.xx.xx.xx and resetting the address would disconnect the client permanently. This message fills the system log for the
    station with 1 message every 1 to 2 minutes. I imagine this is tied to the policy update setting (our setting 1 minute). We cannot stop this message from occurring. This started in #13.

    UNREPORTED:

  • On some external client stations the scans do not seem to be executing at the time recorded in the deployed policy; some times the scans seem to be missed for days. The "Last Scan Time" in the console states this, while in the system log of the same station we can see that the station was online the whole time by the recorded messages from the prior reported issue being in the log the whole time. Verifying the time the station was on.
    The station is being reported in the console as online this whole time. The policy version and database version are being reported correctly
    with the current date and time.

    UNREPORTED:

  • Stations go offline and do not want to return online no matter what we did. We uninstalled the software and did a network scans and the scan returned information about the stations installed software from the database which was incorrect since the application was not installed on the station.
    This is not a real scan if it returns stored information. We had to uninstall MBAE & MBAM from the client with the uninstall tool then reinstall from the
    console in order to get the computer to be noticed and to show up in the client station list. This brings to light the instability of the console that you can
    not trust what is shown in the console. After getting the station back online we powered the station off then back on the next day, the process started all over again for the station would not go online, we had to set the MEEClientService service to "Automatic Delayed" for the station to come back online. This station has been working all along until this incident. This does not make any sense that the station should stop working like this for no apparent reason. If the stations now require Automatic Delayed start, this is the way the installation should install the service. The user should not have to debug this. I definitely have no trust in the system now which makes it useless to a customer. At this point the system is causing more trouble and work than it is said to alleviate.

    UNREPORTED:


Randem

  • Administrator
  • Hero Member
  • *****
  • Posts: 2664
Re: Evaluation of the Malwarebytes Endpoint Security Management Console
« Reply #4 on: April 23, 2017, 12:16:12 PM »
Malwarebytes Management Console Review - 04/23/2017

We are resellers of Malwarebytes products and have been evaluating and testing the Malwarebytes Console since March in the hopes of getting our customers to use it and to help make this a better product. The concept being that is a technical expert with over 35 years of experience on Wall Street cannot get the system to work properly in real world situations; then the average consumer does not have a chance (our customers).

Malwarebytes support gave me a few new installs and install techniques that worked for a brief period. Some of the same problems seemed to reoccur, this may be from the program updating itself and the corrections were not implemented on the update server at Malwarebytes. These updates however proved to be meaningless if the program is just going to revert back to its old behaviors from updates after a correction. Here is a list of current issues that have not been resolved or have gotten worse since my last review of 3/14/2017. We have had a change of support staff since the last review that does not seem at all concerned for they seem to refuse to give any answers or knowledgeable support. The last contact from support was on 4/17/2017 telling us to restart the server as if that was going to solve the listed issues… they have not responded to our support request since then.

Client Tab:

These issues are for clients on the same subnet as the console, but also happen with external network clients.

  • Update to scanning status when scan command is sent to client stations; it is very much delayed (if it happens at all).
    The status may be better understood as "Online: Pending Scan" so that users know something actually happened. Even though one can check the Admin Log to see that the scan command was sent, that is all the evidence one has that something is actually happening. 1 hour later the timestamp in the log and still no evidence of scanning... Another issue is that we cannot query an external client to scan. It seems the communication is only client to console (communications needs to be bi-directional). Perhaps in the client logs all pending operations for the client should be listed so that all operations for the client can be viewed from the same screen without having to sort thru the other pages of the console.

    WORSE: Scheduled scanning seems to happen sporadically or not at all; even though all stations have the same policy which is set to scan every night at 10pm. This scanning information is gathered from the client screen in the console. We sent a scanning request to a station and 2 days later the console still shows that the scan is taking place. Restarting the server made no difference, restarting the station did.

  • It seems that we cannot query the client for an update status. Communication should be forced by the user in either direction to ensure accurate statuses. It seems that the refresh of the console only reports that which has already been reported to it, not querying the client for a real-time update.
    A "Refresh" should force a communication check and diagnostic.

    UNCHANGED

  • Some clients show offline even though I know that they are powered on and working correctly. This is sometimes sporadic and cannot be repeated by any means until it shows up. This may be due to different version of MBAE being installed and updated thru the console. It appears to have disappeared after using the MBAE uninstall tool on all clients. A day later this same issue reappeared with no changes. This appears to be related to #12.

    WORSE: We have clients that have been powered off for over a week and they still show up as online in the console no matter what we do. We have restarted the console server; still no change.

  • Better messages and some instruction on how to remedy the issue at hand need to be in the console. Example: a client is offline,
    How do we remedy this? What communication is failing? We should be able to force this communication or at least run a test between client and console to determine the problem.

    UNCHANGED

  • On an external XP client we had to start the MEEClientService service, but when starting the MBAMService; it shut down and also shut down the MEEClientService service also. This is the client that shows Anti-Exploit as protected but Malwarebytes as unprotected and greyed out in the console. We got our internal XP Client to work properly. We checked the Windows Event log and fount that there was a problem with a .NET 2.0 installation, we re-installed .NET 2.0SP2 and .NET 3.5SP1 (just in case). We uninstalled MBAE using the uninstall tool, restarted the computer then re-installed MBAE and all worked properly.

    CHANGED: This seems to not have happened again.

  • The uninstall tool should be a integral part of the console and used when one does a remote uninstall.

    UNCHANGED

  • The logon user should be updated to the current user that is logged on at the time of query or reporting.
    This would be helpful in troubleshooting issues on the client side.

    UNCHANGED This needs to be real-time query.

  • There is no way to currently push out anything to external IP clients. The communications is from client to console only.

    UNCHANGED

  • Some clients will not show up in the client list after manual installation with a ClientSetup installation package.
    The clients will not show up until a push installation is done from the console. This is due to the IP address of the server not being in the setup package in the sccomm.exe.config file. A setup package for external clients should have the option to set the IP address of the console server which will be remote from the console.

    UNCHANGED

  • If a client is removed from the client list, it takes a restart of the client machine to get the client back in the list.
    This should actually be done in a forced communications check to re-populate the list.

    UNCHANGED

  • There seems to not be a automatic refresh setting in the client area of the console and it does not refresh the client
    screen to give a real-time update on client statuses. The refresh button does almost nothing for real-time communications.

    UNCHANGED

  • On some clients the MEEClientService service does not start or it terminates at startup and there is no error message or any clue to why the client is not communicating with the console. If this service is not started then there is no communication between the two and the client is reported as offline in the console. It seems the only way for the console to get an update is to restart the MEEClientService service. This service also seems to terminate on some computers without notice. The only way to diagnose a non-communicating client is to check the Windows services to see if this service is started.

    CHANGED: This seems to not have happened lately.

  • The "Server Address Setting" in the Admin tab has a bad issue if you manage to check the box "Force Managed Clients to use new address".
    It cannot be unchecked unless the server address is changed to another WORKING console IP Address. This poses a problem with clients that are not on the same subnet or are an external client. This address will automatically keep changing the external client's console contact IP address.

    UNCHANGED:

Randem

  • Administrator
  • Hero Member
  • *****
  • Posts: 2664
Re: Evaluation of the Malwarebytes Endpoint Security Management Console
« Reply #3 on: March 18, 2017, 10:51:46 PM »
Malwarebytes Management Console Review - 03/14/2017

Finally got everything up and running after multiple uninstalls and re-installs. Found that the process of uninstalls/installs only worked if using the MBAE uninstall tool. Remote uninstalls should be updated to only use the tool instead of the current process used. There are times when the console appears not to be real-time or it just loses the ability to communicate with some clients. One example is that when a client computer is shutdown; over an hour later the client is still being reported as online. I eventually had to use the MBAE uninstall on all client stations to get some stability.

Client Tab:

These issues are for clients on the same subnet as the console, but also happen with external network clients.

  • Update to scanning status when scan command is sent to client stations; it is very much delayed. The status may be better understood as "Online: Pending Scan", so that users know something actually happened. Even though one can check the Admin Log to see that the scan command was sent,
    that is all the evidence one has that something is actually happening. 1 hour later the timestamp in the log and still no evidence of scanning...
    Another issue is that we cannot query an external client to scan. It seems the communication is only client to console (communications needs to be bi-directional). Perhaps in the client logs all pending operations for the client should be listed so that all operations for the client can be viewed from the same screen without having to sort thru the other pages of the console.

  • It seems that we cannot query the client for an update status. Communication should be forced by the user in either direction to ensure accurate statuses. It seems that the refresh of the console only reports that which has already been reported to it, not querying the client for a real-time update.
    A "Refresh" should force a communication check and diagnostic.

  • Some clients show offline even though I know that they are powered on and working correctly. This is sometimes sporadic and cannot be repeated by any means until it shows up. This may be due to different version of MBAE being installed and updated thru the console. It appears to have disappeared after using the MBAE uninstall tool on all clients. A day later this same issue reappeared with no changes. This appears to be related to #12

  • Better messages and some instruction on how to remedy the issue at hand need to be in the console. Example: a client is offline,
    How do we remedy this? What communication is failing? We should be able to force this communication or at least run a test between client and console to determine the problem.

  • On an external XP client we had to start the MEEClientService service, but when starting the MBAMService; it shutdown and also shutdown the MEEClientService service also. This is the client that shows Anti-Exploit as protected but Malwarebytes as unprotected and greyed out in the console. We got our internal XP Client to work properly. We checked the Windows Event log and fount that there was a problem with a .NET 2.0 installation, We re-installed .NET 2.0SP2 and .NET 3.5SP1 (just in case). We uninstalled MBAE using the uninstall tool, restarted the computer then re-installed MBAE and all worked properly.

  • The uninstall tool should be a integral part of the console and used when one does a remote uninstall.

  • The logon user should be updated to the current user that is logged on at the time of query or reporting. This would be helpful in troubleshooting issues on the client side.

  • There is no way to currently push out anything to external IP clients. The communications is from client to console only.

  • Some clients will not show up in the client list after manual installation with a ClientSetup installation package. The clients will not show up until a push installation is done from the console.

  • If a client is removed from the client list, it takes a restart of the client machine to get the client back in the list. This should actually be done in a forced communications check to re-populate the list.

  • There seems to not be a automatic refresh setting in the client area of the console and it does not refresh the client screen to give a real-time update on client statuses.

  • On some clients the MEEClientService service does not start or it terminates at startup and there is no error message or any clue to why the client is not communicating with the console. If this service is not started then there is no communication between the two and the client is reported as offline in the console. It seems the only way for the console to get an update is to restart the MEEClientService service. This service also seems to terminate on some computers without notice. The only way to diagnose a none communicating client is to check the Windows services to see if this service is started.

  • The "Server Address Setting" in th Admin tab has a bad issue if you manage to check the box "Force Managed Clients to use new address". It cannot be unchecked unless the server address is changed to another WORKING console IP Address. This poses a problem with clients that are not on the same subnet or are an external client. This address will keep changing the external client's console contact IP address.


Randem

  • Administrator
  • Hero Member
  • *****
  • Posts: 2664
Re: Evaluation of the Malwarebytes Endpoint Security Management Console
« Reply #2 on: March 02, 2017, 01:38:47 PM »
Client Management

After figuring out all the firewall issues, we ran into this issue. We saw that one client was being reported as offline, and the strange thing is that we can still uninstall and reinstall the software remotely; so I am at a loss to what Offline really means. What I had to do to get rid of this status was to delete the client and refresh the clients screen then the client was online; this status seems not to be real time. The IP nor the computer name was changed but the system could not locate the computer to report on it but could locate it to uninstall/re-install the software. I also had to push uninstall/reinstall the software on several computers to get the protection icons to show the protected state in the client screen. This may have had something to do with the firewall exception rule not being on the client computers at the time of the original install.

On some stations I cannot get the protection icon to show for Anti-Exploit no matter what I do, even with the same procedure that I have done for other stations. On the some stations Anti-Exploit is working and in a protection state but the console does not recognize this. All the stations have the same firewall rules because they are pushed from the firewall management console so that cannot be the issue. A few minutes later the status changed to protected without any reason that I can tell. This was after several refreshes of the screen. For some stations; they are still reported as offline even though on the station itself Anti-Exploit and Malwarebytes are running fine.

The thing that I really dislike about this management console is that when you send a command to the client such as to update the database, there is no indication to the user that anything is happening at all. So you are really at a loss as to what is really happening.

NOTE: After several push uninstalls/re-installs; the anti-exploit protection icon showed up and is working properly on some stations, on others not. Also interesting is that after deleting one problem station from the client screen, the client computer will not show up again even though It will show up on the Admin scan and I can still install and uninstall on it. Client machines go offline for no reason in the client view screen, the software on each machine is active and running but it is still reported as offline in the console. In order to get a station back online you have to restart the computer and even that is no guarantee it will be reported as online. We have had to restart 4-5 time just to get one computer online, not a real world situation.

UPDATE: 03/8/2017 Malwarebytes support sent me a cleaning tool and a new Anti-exploit install and instructed me to install uninstall/install directly on the client stations that did not work and then push an installation of Anti-Malware/Anti-Exploit from the console and everything worked the first time. Malwarebytes support stated that a new roll-out of the console would be release in the second quarter of the year.

From the contacts I have had with support; they don't seem to understand how the real world small businesses use computers & networks and only seems to only be concerned about corporate uses of networks with Windows servers and Active Directory installations. Most real world small business have no use for Windows Servers or AD...

CMS products are supposed to make life easier for the businesses that have no IT departments. Fore thoughts like this would open the market up to these types of small businesses who could have their sites managed by off-site personnel. The "cloud" is not an option...

UPDATE: 03/17/2017 After uninstalling from every client using the MBAE uninstall tool, we re-installed the new MBAE software on every client and we have had some success in getting things to work correctly. We had one issue with an XP client but after checking the Windows Event logs we found out that the real problem was .NET 2.0. So, we re-installed .NET 2.0sp2 and .NET 3.5SP1 on that client then uninstalled/installed MBAE and all was working correctly.

UPDATE: 04/13/2017 Malwarebytes has sent me a new console install with a fixed communications program. i have installed the communications program and all seems to work as expected with the stations showing up and the components being marked as installed and working. Also I was instructed on how to get the console to monitor client stations that were not on the same network segment (IE. another building across town). You cannot remotely deploy to these external stations but you can monitor them once you get the software installed.

Randem

  • Administrator
  • Hero Member
  • *****
  • Posts: 2664
Evaluation of the Malwarebytes Endpoint Security Management Console
« Reply #1 on: March 01, 2017, 03:42:07 PM »
Initial Client Push Installs

IMPORTANT: Every station that you want to push the client software has to have the default Administrator account active and setup (including the Endpoint Management machine). Meaning that the Administrator account has to be logged into at least once after setting the account to the active state. If you do not do this all your software push installations will fail. If you have a lot of stations on a domain then much of this requirement can be accomplished with a few server pushed scripts, but if not on a domain this will be a lot of work to satisfy this requirement.

  • Uninstall ANY previously installed version of Malwarebytes.

  • Open an Administrative Command Prompt.

  • Type net user Administrator [Password] /active:yes then press enter. Replace [Password] with the actual password you will use for the account.

  • Exit from the command prompt.

  • Log into the Administrator account to set it up.

  • Hide the Administrator Account using registry entry (Our personal taste), We create a .reg file with the following commands to do so.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList]
    "Administrator"=dword:00000000

  • Log out of the Administrator account.

  • Restart the computer. (You will have issues if you do not restart).

  • Return to the machine with the Endpoint Security software to push out your installations.

If you attempt to push an installation to the client without setting up the Administrative account on the client you will get messages something like these:

"3/1/2017 2:12:24 PM","Admin","127.0.0.1","System",5011,"""RS-WS1"" [192.168.1.28]: Installation failed. Access is denied.","RS-WS2"
"3/1/2017 2:48:23 PM","Admin","127.0.0.1","System",5010,"""RS-WS1"" [192.168.1.28]: Simulation failed. The specified network password is not correct.","RS-WS2"


There is no attempt to tell you the actual problem or to offer a solution, just some general messages which do not help much.

We have also found that if you have a different version of Malwarebytes Premium or Free installed; the Endpoint software will still attempt to push the installation of the client software; but will fail. We uninstalled the premium version 3.0 from the client computer then attempted to re-push the client software installation and it installed successfully but failed this time on registration, "unable to connect to remote server". Do not know what this means for both machines have internet connections and update on each machine works... The strange part is the client push of Malwarebytes installs version 1.80 on the client station. Not sure if this is updated software; or if the management software will upgrade this later. From a look and feel point of view; our software is regressing, and makes one feel a bit uneasy thinking that they might not be getting the latest and greatest protection going from version 3.0 or 2.x to 1.80...

"3/1/2017 3:19:13 PM","Admin","127.0.0.1","System",5011,"""RS-WS1"" [192.168.1.28]: Installation failed. Managed client software installation failed.","RS-WS2"

We strongly suggest using a simulation installation before attempting to push the software to the client. It also seems that all the errors that happen do not end up in the Admin log. It would be very helpful for some of the error messages are overwritten on the screen and leave no trace of their existence for late debugging.

IMPORTANT: It turns out that if we disable the firewall on the Endpoint machine the installation goes smoothly. This means that the installation of the Endpoint Management software does not create a firewall exception rule for itself so that the clients can communicate with it. The instructions in the manual only gives instructions for the Windows Firewall, but we all know that anyone serious about security does not use the Windows Firewall. The exception rule that needs to be created on every station is:

Protocol: TCP
Direction: IN
Local Port: 18457
Remote Port: 1024-65535 (or ANY)
Remote Addresses: All Networks

Once you get this straightened out; the push installations will work smoothly. What we did was to create the firewall exception in our firewall Central Management System then push out the rule to all the stations.

We have attached the complete MBAM official operations manual