Registered server address cannot be found.

[sinistersnowgod]

I've recently installed Malwarebytes for business and when I launch the Management console from the server I get the following error message:

"Registered server address cannot be found.  Please go to the Admin pane to modify the server address."

It will then successfully launch the console.  When running the console on a desktop for management purposes I get the same result.

When trying to "Check for updates from a client" I get the error message "An error has occured. Please report this issue to our support team (include the content of all error message(s) and code(s) in your submission).

PROGRAM_ERROR_UPDATING (11001, 0, Host not found)

No such host is known."

I've validated that DNS is correct and name resolution for the server host works fine... as evidenced by the ability to run the management console from a client even though it throws this error.

 

Please advise.

 

Thanks,

Ian

 

 

 

[KDawg]

Can we attempt this with the server IP instead of DNS

Please let me know if the issue persists

many thanks

[sinistersnowgod]

Yeah I get the same error whether I use the IP address or the FQDN.

[KDawg]

Are you attempting this locally from the primary management server?

Can we attempt 127.0.0.1 or localhost

[sinistersnowgod]

I am attempting it from both the primary management server and a management workstation and getting the same result.  I get the same result with 127.0.0.1 or localhost.

 

[sinistersnowgod]

Ok... I found a way to get rid of the error however it is not a workable solution.  I changed the Server Address in Server Address Settings to match the local hostname of the server.... however this is a complex name and not resolvable outside of that AD domain.

It needs to be able to work with the "friendly" name I've registered in DNS... which is split between public and private.  It is also the name for which I've issued the public certificate.

So for example the server name is something like PMWBETPAV01.addomain.com.  The "friendly" name is mwbytes.fqdn.com

So now that I've updated the server address I can run the console without error, however I still get the error on the client which is configured to connect to the friendly name.

[djacobson]

Are you trying to set MBMC up to be accessible from outside of your network or accessible from alternate domain forests?

[sinistersnowgod]

Yeah I'm basically trying to set it up to be accessible from outside the network for roaming clients and let internal clients reach out to it using split DNS.  The recommended model in the install guide is a violation of our n-tier security policy so I've decided to just put this thing on the internet and lose the AD integrated functionality and instead use SCCM to push and manage the client packages and have our internal clients reach out to the Malwarebytes server in the Internet Services zone rather than communicate with it internally, since if I put it internally I wouldn't be able to manage our external clients or have them connect back for updates.

Usually products like this... whether it's Palo Alto Traps or AirWatch or whatever allow for kind of a split horizon... Traps for example has a listening service for roaming clients on a server facing the internet that writes to the same database as the internal management server but the installation guide for Malwarebytes doesn't seem to indicate that model is possible and suggests opening the firewall on 443 and 18457 to the internal server directly... which we would never do here and I would think that would not be an uncommon restriction.

[sinistersnowgod]

PS I am now seeing the test clients I have check into the server and populate the DB with their information... I am however still getting the same error message when trying to "Check for Updates" from the clients themselves.

[djacobson]

443, 135 and 137 are for outbound from the server to the client for the push installer tool, there's no need to expose them externally (at least for how the console was meant to be used). Remote administration and WMI should also be allowed. MBMC also uses netbios protocol for the push tool, so if you push outside of the MBMC server's subnet, you will not get a reply back from the clients without a WINS server in place to relay back the reply. All these pre-reqs can then be closed again once deployment is complete. This stuff is not applicable to you anymore when you use a third party deployment tool. I've included it for some clarity on what that tool needs to work, however 18457 still needs to be open for management after deployment, though this can be changed to a port of your choosing. It only needs to be outbound, upon connection the machines will perform a handshake and transfer whatever it is they need to, no need to risk inbound.

The MBMC product does not support roaming or remote clients / console access. I have seen some customers use VPN, DMZ and Microsoft Direct Access to access it though we cannot really provide information on how to do it, this will need to rely on your own resources and abilities as an admin.

For how you are setting this up though, I would recommend to not have the clients try and look to the MBMC server for their signature database updates, instead choose the update from internet option. This will also save you a ton of bandwidth as it allows for an incremental update instead of a full pull from the MBMC server. Incremental is 3-5kb from the internet in size versus 15-25mb each pull if from the console.

Add these to your network software or appliance to be allowed external access, also allow these URL's to be bypassed by any deep packet inspection or SSL filtering. If you do not, the built-in MITM protections the program has in place will cause the program to drop all packets and you will not be able to connect to the needed pieces for the program to update and run correctly - External URLs to have open for MBMC Console and Clients
https://data.service.malwarebytes.org
https://data-cdn.mbamupdates.com <-must be accessible to process updates
https://keystone.mwbsys.com
All are port 443 outbound, also add the keystone address to IE's trusted site list and disable IE Enhanced Security if you still have it enabled on your MBMC server.

[sinistersnowgod]

Yeah actually it was already set to update from the internet and by changing it to update from the MBMC the client was able to successfully update so it probably is a proxy issue for the client which is easy for me to resolve and switch back to internet updates or at least have the internet update fallback work.

So that's cool... making progress... but I'm still stuck with the issue of the "friendly" name not working.  When I change the server name to one that is publicly resolvable I get the "Registered server address cannot be found.  Please go to the Admin pane to modify the server address." error when running the management console... and I also need the friendly name to work so that clients on the internet can resolve it and check in.

[sinistersnowgod]

Hey Dyllon... any thoughts on the whole friendly name issue lingering here?  As far as I can tell it's really just impacting the launch of the management console creating that error but I'd like to eliminate that error and be certain it's not going to cause me issues down the road when the clients are rolled out.

 

Thanks!

[djacobson]

The console server's configuration requires the address to be the IP or FQDN, those are the only things it can use. Straying from this will present you the error you see even if it can log in to the console.

To get the clients to connect, you may have some success manually changing the server connection string in their config xml, C:\programdata\sccomm\sccomm.xml, this is where folks that have done MSDA have had their success. To be clear though, this is not something we can support, it is done at your own risk.

For full disclosure, I had gotten my own test environment to run MSDA long ago, how that is configured may help you or give you ideas.

I ensured the server name in Server Configuration was not configured as an IP4 address, but as the FQDN. I then created a installation package for a manual install, this part isn't as important as any client can have their config changed after install. I then stopped the MEEClientService on the endpoint, then copied the sccomm.xml file to my desktop for editing, made the edits, placed the desktop copy back into the original location, letting it overwrite the existing original default one. Here's how a client's sccomm.xml file looks by default:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <appSettings>
        <add key="ServerRef" value="https://[IP or FQDN]:18457/SCClientService/" />
        <add key="Group" value="[Group GUID]" />
        <add key="Client" value="[Client GUID]" />
        <add key="Policy" value="[Policy GUID]" />
        <add key="RegisterResult" value="Passed" />
    </appSettings>
</configuration>

The configuration on my Direct Access (DA) client now looks at:

<add key="ServerRef" value="https://[FQDN]:[PORT]/scclientservice/<https://3e:[PORT]/scclientservice/>" />

The Direct Access client was able to resolve this change in the XML and now my remote DA client is managed via the console. For your path though, I think the best approach to get the name to resolve is to do it manually in your host files or in your DNS, the console itself is not going to accept it, you'll need to do the routing behind the scenes.

 

 

 

[sinistersnowgod]

That's usefull information but I guess where I'm getting hung up is that I am using an FQDN... it's just not the FQDN of the local host as it is in the AD domain.  The AD domain has it's own DNS name that isn't publicly resolvable... so the internal FQDN of the server is complicatedservername.addomain.local.  The requisite ports for the clients are open to the server and a publicly resolvable DNS name is registered to the NAT address of the internal host IP.  The publicly resolvable "friendly" FQDN is mwbytes.publicdomain.com.  I'm using that FQDN in the configuration.  That FQDN is resolvable by the server and the clients... so that's where I'm confused because I believe that should work?

[djacobson]

The console can only have one address assigned and it is specifically looking for localhost / AD FQDN or internal IP for the server. This is one thing you may find with the MBMC console; there are many aspects of it that are hardcoded, like names and timeouts.

Check out your server's config file in C:\Program Files (x86)\Malwarebytes Management Server\SC.Server.WindowsService.exe.Config, you may get some ideas after checking that out.

The clients can all be manipulated to resolve to public through their XML, do it for your local ones as well instead of splitting private/public between locations. You may have to just live with the management side's problem when RDP'ing into the server and using the main console or from your workstation when using a secondary console. Even if it connects on localhost or 127 loop for local, or external IP for secondary, you'll always have that message because those addresses do not "match" to what the console has assigned to it via that config file.

[sinistersnowgod]

Ok... so I guess the best option for me at this time is going to be to adjust the XML file for the client which does work.  I can only think of two ways of doing that relatively elegantly but maybe you have another option?

I can either change the server config to the publicly resolvable name for as long as it takes to generate the installation package so that the package contains the XML file with the correct URL... or on my software deployment platform (SCCM) I can create a software deployment package that installs Malwarebytes and then goes back in and overwrites the XML file with one that has the correct URL.

I guess my question is, is there any easy way in the console to adjust the URL that will be in the XML file when generating the XML package without having to jump through those hoops every time we have a need to generate a new installation package?  Not the end of the world if we have to follow that process every time but just kind of messy.

 

Thanks,

Ian

[djacobson]

There's no real elegant way to do it, that XML is only imparted to the clients during a push, there's no interaction with it on the clients once that is over. The cleanest way I can think of, is once the console is set with the address you need to access it via the console, go to the package template area and edit the source sccomm.xml that the server copies for pushes and package generation - C:\Program Files (x86)\Malwarebytes Management Server\PackageTemplate\sccomm.xml.  After this, a package generated or new push deploy will have that address within it from the start. Be aware, any time you make a change to the servers address, this source file gets changed too, you will need to redo the public address in the package template area if any new connection address changes happen.

Any computers already installed can have their sccomm changed out while the service is off. A GPO run once reg entry assist is a good way of doing that. Copy the corrected sccomm.xml and a text.bat script to the C$ share. The script should tell the meecleintservice to stop, copy the new sccomm.xml file from your behind the scenes copy to the correct location, then restart the service. Call on that script via the GPO run once reg, that'll hit everyone without repeating on subsequent log ins.

Edited December 1, 2017 by djacobson

[sinistersnowgod]

Thanks Dyllon