login details invalid when protecting some servers

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

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

Thanks for the fast answer.

You have two DCs in different domains to the Sophos management server that you want to protect/manage?

-> yes that is the case

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.

-> yes i uses the packager because the technician who installed our first server created it for deployment via GPO in a future project

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)?

-> right, the endpoint security and control was installed successfully V10.6 and seems to be working well regarding the logfiles on the client but the computer stays in unmanaged state on the sophos server

To rectify these failed/partial installs you are now trying to push an install to these computer from SEC?

-> right, because that was the workflow the technician showed me.

Am i right to say that normally there is no need to install the client with the packager AND the assistent?

I know the bootstrap directory because the technician copied that to the packager when he created the package.

Sure i can install the client with the Setup.exe via interactive Setup, so the real Problem seems to be why the installed client is showing in gray color.

The client can access TCP ports 8192 and 8194 of the server.

-> Both ports are configured in the windows firewall ingoing and outgoing (other installed clients can communicate with the sophos server)

8194 is configured in- and outgoing on both clients where the problem occurs

the mrinit.conf seems to be ok, the MRParentAddress and ParentRouterAddress has the right ip-address, servername+FQDN, servername

I will try to run the Setup.exe manually from these two clients. i used the packager files because it worked with 25 other clients.

When DCs are involved, by default, if I recall domain admins of other domains can't login to them unless explicity allowed.

-> i know so i uses the right admin accounts for the target domain

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

Hello Roman Gruneberg,

as jak has said, all the methods are equivalent and your package seems to be fine - no need to run setup.exe manually.

It looks like "just" communication (RMS) fails. Please open the NetworkReport %ProgramData%\Sophos\Remote Management System\3\Router\NetworkReport\ReportData.xml. Is there a Current parent address? If not, from one of the DCs telnet SECserver 8192. At least one of the ParentRouterAddresses from mrinit.conf should work, the response is an IOR string. Next steps depend on whether you get a response or not.

Christian

Hello Christian,

 i tried the Telnet Client before and it worked, the ports are open but when i double checked the ParentRouterAddress i saw that the address is wrong!!

Is it possible that the technician changed the address after installing the sophos server?

Where can i set the right address on the SECserver?

Roman

Hello Roman,

the ParentRouterAddress ... is wrong
in the NetworkReport? The addresses are taken from mrinit.conf and stored under HKLM\SOFTWARE\Sophos\Messaging System\Router during install. But apparently they are correct for other endpoints so the question is how they got there. Please note that for RMS to be able to connect it's sufficient that one of the "addresses" (IPv4, IPv6, NetBIOS name, FQDN) works.

Is the mrinit.conf on the DCs in %ProgramFiles(x86)%\Sophos\Remote Management\ System the same as the ones in %ProgramData%\Sophos\AutoUpdate\Cache\rms\ and in the CID?

Christian

yes it was wrong in the network report.

i changed the address to the right one in the mrinit.conf in the bootstrap path. i am checking right now.

i think the other clients worked because they are in the same domain than the SecServer and when the connection with the wrong address failed, it took the servername+FQDN and that worked with the right DNS entry

Hello Roman,

other clients worked ... with the right DNS entry
that was one possibility. BTW: An alias also works (provided of course it is correct). Furthermore, the addresses are only used to connect to port 8192 and retrieve the IOR. The IOR in turn contains the hostname to use for the RMS communication.

mrinit.conf in the bootstrap path
won't work - it's only used when RMS is first installed. It's changes are ignored even when RMS is updated. But please see Considerations when changing the IP address of the Sophos server, especially section B (but the rest might also interest you). Please see also under Important in section 1.2 of Enterprise Console: configuring message relay computers regarding mrinit.conf in the root of the CID (bootstrap location).

Christian

Thanks for all the support you two!

It is working now. I changed the address in the mrinit.conf file, built a new package for distribution and silent installation, uninstalled Sophos from the two machines and installed it again with the package. Everything installed correctly and the client shows correct in the sophos management console.