RMS Question

If Remote Management System is not correctly install or is not there entirely, updates and management from the EC is non-existent - echo

Difficile est saturam non scribere - Juvenal

To begin with we have zero issues with SEC and RMS in the domain (250 computers)  and the 500+ computers administered by us. If there is a problem at installation time it's usually resolved by reprotecting the client and that's it then. And out-of-date computers also all have the red x - so not even an incorrect "connected" state. The rest of our clients (more than twice the number) is not under our control. An estimated 2 percent have issues with RMS-SEC communication, status reporting or general installation issues.

So - if you have full control over the clients and you have the suspicion they are not reporting correctly try to re-protect them. This should leave only a few dodgy cases where you need  to check the clients availability (installation timeout is an example). Of course if - for example - you change a firewall policy in AD so that the RMS ports are blocked there's nothing Sophos can do. It is even conceivable that a client is up to date, RMS is working but the client is not "visible" in your domain (except for the incoming connections).  

As mentioned above (and in other threads) sometimes client-internal communication fails. This can be seen in SEC - either there is an error indicator (as out of date) or one or more columns are blank when they shouldn't be. 

Sophos has improved RMS over time and I bet it will continue to do so. What you asking for is a failover management system. This not only will increase complexity but itself be prone to error. Although money could buy it the costs clearly outweigh the benefits.

Christian

---

QC wrote:

If Remote Management System is not correctly install or is not there entirely, updates and management from the EC is non-existent - echo

Difficile est saturam non scribere - Juvenal

To begin with we have zero issues with SEC and RMS in the domain (250 computers)  and the 500+ computers administered by us. If there is a problem at installation time it's usually resolved by reprotecting the client and that's it then. And out-of-date computers also all have the red x - so not even an incorrect "connected" state. The rest of our clients (more than twice the number) is not under our control. An estimated 2 percent have issues with RMS-SEC communication, status reporting or general installation issues.

So - if you have full control over the clients and you have the suspicion they are not reporting correctly try to re-protect them. This should leave only a few dodgy cases where you need  to check the clients availability (installation timeout is an example). Of course if - for example - you change a firewall policy in AD so that the RMS ports are blocked there's nothing Sophos can do. It is even conceivable that a client is up to date, RMS is working but the client is not "visible" in your domain (except for the incoming connections).  

As mentioned above (and in other threads) sometimes client-internal communication fails. This can be seen in SEC - either there is an error indicator (as out of date) or one or more columns are blank when they shouldn't be. 

Sophos has improved RMS over time and I bet it will continue to do so. What you asking for is a failover management system. This not only will increase complexity but itself be prone to error. Although money could buy it the costs clearly outweigh the benefits.

Christian

---

Agreed.  More features = more money, but the design of the SEC is that if you can't talk to the machine to update policies, run scans, implement time-critical exclustions to a group of machines because they have RMS issues, then it resorts back to local default policy settings, which may be bad.

In theoory, re-protecting them with the latest installer is a great solution.  In practice, it can be hands-on and time consuming.  Some of my re-protects, although result in a better proection experience both for SEC and end-user, typically have RMS issues where my techs have to manually replace a cac.pem and .conf file then re-run the RMS .msi.

I think that the fusion of all the .msi packages into a singular installer, not a custom standalone installer as some KBs note, could eliminate a lot of these "Error 1722" and "Error 1902" where separately installed packages can hit roadbumps.

Just my personal experience in the trenches, if you will.

FYI, nice latin.  Personal favorite: " Nolo contendere ".  :P

Primum non nocere would be a good maxim for Support guys (as well as doctors), as would its alternative primum succerrere, although one of the objectives of this (and any other online) community would be cura te ipsum. Sorry. Couldn't resist.

spike