Jump to content

PhillyPhotog

Members
  • Posts

    22
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @vs2015sv, see the link in my previous post. You likely need to manually define the location of a windows install file (specifically the sxs). You can find this by grabbing any Genuine Windows install CD or ISO.
  2. Not sure what sparked the new conversation here, but I wrote up a brief synopsis on how to overcome this here: http://weisswesley.com/deploying-malwarebytes-on-windows-8-8-1-10-using-group-policy-software-deployment-or-other-3rd-party-deployment-tools/
  3. Thanks for the response @AdvancedSetup. I should have been a bit more detailed in my post. This is what I am seeing Client Group A (~2% clients) Database Version 2016.11.17.15 Anti Malware Version 1.80.2.1012 Managed Client Version 1.7.0.3208 Client Group B (~96% clients) Database Version 2016.11.17.15 Anti Malware Version 1.80.1.1011 Managed Client Version 1.6.1.2897 Client Group C (~2% clients) Database Version 2016.11.17.15 Anti Malware Version 1.75.0.1300 Managed Client Version 1.4.1.2329 Is there an integrated upgrade engine / mechanism in the Management Console to address the Managed Client Version mismatches? Is there an integrated upgrade engine / mechanism in the Management Console to address the Anti-Malware Version mismatches? So far, all I have found is the Client Push Install, which isn't the cleanest mechanism, since I have to be scanning at the particular time that a client system is online. I was looking for something like Symantec Endpoint's upgrade mechanism, which forces managed clients to upgrade the next time they check in with the management server.
  4. Not sure what the implications are, 98% of my clients are running the most recent Anti-Malware Version and relatively recent Database Versions, but I have a notable number of clients (which have recent anti-malware and database versions) which are running older version of the Managed Client. It has been over 2-3 months since we upgraded the Management Console to the latest release (1.7.0.3208) My questions: Does the installed version of the management client have any impact on the speed of updates or effectiveness of the scanning engine? (any impact to the safety of my clients) How do I go about deploying the latest version of the Management Client to my clients
  5. Submitted. What is the upper limit for embedded? At what point does MB recommend that a deployment team consider utilizing SQL for database rather than embedded (# of clients, record length, etc.)
  6. Embeded, sorry for delay, did not see the reply. Error went away for a bit, but just popped again.
  7. Performing an audit of the installs on our network of MBAM, and noticing a variation between services that are installed / not installed, running / not running. Searching the forums did not shine any light on the different services that Malwarebytes Enterprise relies on, what they do, if they should always be running, if they should always be installed, etc. The services that I have discovered are: MBAMService, MBAMScheduler, and MEEClientService
  8. More information on this. I disabled the cleanup settings for Obselete logs / clients. This allowed the management service to stay alive and collect data from clients. I have been running manual cleanups for the past day, and the log keeps getting a bit smaller (as reported by console, but not realized in app_data folder in MBMC install path), but still fails eventually and kills the service.
  9. Correction, Database now shows as .54 GB in MBMC, but when looking @ app_Data folder in Malwarebytes Management Server folder, scdb shows as .978 GB and SCDB_Log shows as 2.1 GB
  10. Interesting note, began a database cleanup and the service just crashed on me. Server had just been rebooted about 45 minutes prior... Database corrupt? How can I confirm / rebuild? I have been able to repeat this and get the same result. Database size is currently .9 GB. Too large?
  11. My management console is failing after about 24 hours of uptime. Specifically, I am getting an error with ID 7034 from source Service Control Manager Eventlog Provider, with the detial I am running Management Console version 1.7.0.3208 I am not sure where to begin troubleshooting this one. Search of forums came up blank for me. Any guidance would be appreciated.
  12. 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
  13. Does anyone from MalwareBytes have any feedback regarding improving Windows 8, 8.1, and 10 compatibility so that this tool can be more consistently implemented in updated environments?
  14. All of our clients appear to be 2 hours behind in updates throughout the day on a consistent basis. Of the 600 managed, the reporting interface shows <10 as on the most current release at any time. When manual updates are triggered on clients (from client desktop), client shows that it is on an older than most currently available definition, but reports that it is up to date (and does not download the most current definition. Are there any guides to troubleshooting Update Lag / Update Issues
  15. 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+)
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.