mjolly803

@AlexSmith Understood. Unfortunately that is not what we were told when asking questions ahead of purchase and that incorrect response is what influenced out decision to make the purchase. We will work back through that channel to get a resolution to this issue. Thank you for your assistance and the information.

Thanks for the reply @AlexSmith. My follow up based on your response is what is the determination of "properly licensed for Server support"? The reason I'm trying to determine all this is our environment includes quite a few virtual machines that run Windows Server as the OS, but they stay off a large majority of the time. We of course want them protected when they are on, but its hard to justify the cost of an Endpoint Protection server license for those instances. We want to license those endpoints with Endpoint Protection workstation licenses, knowing that doing so may mean some loss of functionality on those endpoints (in the sale process we were told using workstation license on Windows Server would mean loss of real-time scanning, but scheduled/manual scanning is possble). Is that possible and if so how do we make sure the endpoints we want licensed as workstation or server are configured that way? Thanks!

I'm doing that as well, but I know they are slow right now so was posting here to see if users potentially had a faster answer for me. Appreciate the feedback though!

It appears the Endpoint Agent Setup installer is capable of detecting the OS flavor (workstation vs server) on run. Is there a way to force the installer to install the workstation version of the Endpoint Agent via command line or some other method? Even though the Nebula portal has different options under Endpoint Installers in the Downloads section for Windows and Windows Server. They appear to be the same installer in running them and the hash values shown. We have a need to install the workstation version of the Endpoint Agent no matter the Windows OD flavor. Thanks!

We have previously tried the Sync button multiple times without success, so we went the remove and re-add route. At this point, the list of clients in the console matches the OU in AD. All the listed clients are showing in an Unregistered status, but we will give that some time for the deployed client software to connect back and report status to the server. Thank you for the assistance thus far!

Attached are a couple examples. The first one is a PC named 'GEORGEOFFICENEW' that was added to the AD and the OU in question (TMClients) on 9 Oct 2018 and is still not present in the console. The second example is a PC named 'SUPPORT117NEW' which no longer exists in the OU (renamed I believe) but it still shows in the console. Additionally, in the group Ungrouped Clients, we have two PC's (SUPPORT114 & SUPPORT117) listed as ungrouped, but they are a part of the OU in AD (example #3). We debated removing the OU from the console then adding it back, but we were not sure of the full repercussions of that and we are speculating the issue is in the database and were unsure if removal of the OU group would trigger the clean out of all those associated records to then re-add the OU fresh.

In the Management Console, we added a group via the 'Add AD OU as Group...' and are noticing that the clients listed in the group are not up to date with the computer objects in the AD OU itself. The AD sync settings are configured to occur every hour and we do not see any failures in that process. How can we make sure the group in the Malwarebytes Console stays up to date with the OU in AD?