This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

login details invalid when protecting some servers

Hi,

i have a problem with two servers. I installed the endpoint package that i created via deployment packager, everything worked fine, endpoint protection ist installed.
Then i started the  discovery over the sophos enterprise console, the two servers showed up as gray icons. I dragged them to the right group, but when i try to start the assistent to protect them, it says that my login details are invalid. These two servers are in different domains than my sophos enterprise server. I tried the domain admin accounts (domain\username) and other user accounts from these domains with no luck. Both servers are domain controllers. I verified the accounts by connecting via RDP to the servers.

Regards,

Roman



This thread was automatically locked due to age.
Parents
  • Hi,

    I'm a little confused by the details. I'll try and summarise:

    • You have two DCs in different domains to the Sophos management server that you want to protect/manage?
    • You have used the deployment packager to create a deployment package to install the endpoint software on the two DCs? I'm not sure why this method was chosen but this should be OK if you slected the management option.
    • This worked to some extent, in that some software was installed on the computers but there is no SAV as it failed to install and or the computers were unmanaged in SEC (grey)?
    • To rectify these failed/partial installs you are now trying to push an install to these computer from SEC?

    Pushing an install using SEC involves the Sophos Management Service (mgntsvc.exe) creating a schedule task on the remote computer to run setup.exe from the distribution point.  The specific subscription share chosen is defined in the linked updating policy to the group the computer resides in.  It's for this reason you can't deploy to a computer when it's in the Unassigned group as there is no linked updating policy to pull the config from.  Depending on what you selected when you went through the wizard the switches will vary but they are listed here: https://community.sophos.com/kb/en-us/12570.

    Of course you can bypass the hurdles of a push by simply running setup.exe from the distribution share.  You can consult the View->Bootstrap locations option in SEC for the available paths per subscription.   You can even just copy files, say S000 to a remote computer and run setup.exe from a local path - This is pretty much what the deployment pakager does.  This will install everything, the computer will become managed and it should then get the correct updating policy as defined by the group.

    Installations running setup can be interactive (to set the config in the UI) or non-interactively by passing the command line options as per the article. 

    Once setup.exe runs it first does a few checks and then installs AutoUpdate (SAU), which pulls down the packages, E.g. Remote Management System (RMS), SAV, SCF, etc... SAU installs them.  At the point RMS is installed, you should have management of the computer in SEC.  

    Main checks for management to succeed include:

    • The client can access TCP ports 8192 and 8194 of the server.
    • The client will address the server based on the values in the ParentAddress registry key (hklm\software\wow6432node\sophos\messaging system\router) as populated from the mrinit.conf file in the root of the deployment share.  BY default, IP, FQDN, Name where the management server had a static IP at install.  No IP is used if the management server used DHCP.
    • Ideally the server can connect to port 8194 of the client to speed up downstream message delivery.

    Is there anything just stopping you running setup.exe manually on these 2 computers as a one time event?

    Otherwise I would expect you to enter remotedomain\administrator in the deployment wizard in SEC.  This account should be able to logon to the computer where the management service is running such that the management service can impersonate this account to create the remote scheduled task.  When DCs are involved, by default, if I recall domain admins of other domains can't login to them unless explicity allowed.

    Regards,
    Jak

  • Update:

    i found some Agent logs on the client:

     

    C:\ProgramData\Sophos\Remote Management System\3\Agent\Logs

    I found these lines which are shown repeatedly:

    10.11.2016 10:14:10 1418 W MSClient::Connect: failed to get router's IOR from supplied address and port.
    10.11.2016 10:14:10 1418 W NoRouterIORException: Caught MSClient::Connect: failed to get router's IOR from supplied address and port.
    ClientConnection::Reconnect()

     

    i will try to check the port communication again

Reply
  • Update:

    i found some Agent logs on the client:

     

    C:\ProgramData\Sophos\Remote Management System\3\Agent\Logs

    I found these lines which are shown repeatedly:

    10.11.2016 10:14:10 1418 W MSClient::Connect: failed to get router's IOR from supplied address and port.
    10.11.2016 10:14:10 1418 W NoRouterIORException: Caught MSClient::Connect: failed to get router's IOR from supplied address and port.
    ClientConnection::Reconnect()

     

    i will try to check the port communication again

Children
No Data