Remote site takeover with SEC

Hello Matt,

I think that the requirement that the management servers use the same credentials still stands. Thus a reprotect should install the new version but RMS will still contact the old one (or refuse to talk to the new one). Now I think - unless you use SAUconf.xml in the new CID - they will keep the previous updating policy (or re-fetch it from the local server) and although the re-protect installed the new version they might also downgrade immediately afterwards.

Might not apply in your case but I've seen something like that with 7.6/9.0 during tests.

Christian

Hi Christian,

My thought train here is to replace the MRInit.conf and cac.pem in the local remote management system directory and then restart the RMS service. I'm thinking that this might make the client jump over to our SEC and then pick up our policy and begin updating from the new CID.

There must be a simple way though of doing this, surely branch takeover is a new 'black' art? I'm a little puzzled why though a protect doesn't just work since that's supposed to deploy the removal tool which runs first and then the AU to run from the primary CID location. The uninstall should surely disconnect the client from the current SEC?

Matt

Hello Matt,

My thought train here is to replace the MRInit.conf and cac.pem

Yup, very close but ... of course the removal tool doesn't remove Sophos. Then, Protect Computers - although it does an uninstall - doesn't "completely" uninstall. I think the concept behind it is to avoid a client being "ripped" from its management server. Apart from one or two registry keys you might encounter a file named mrinit.conf.orig in the Sophos %ProgramFiles% folder which - under certain circumstances - might also come in the way.

RMS is constantly reworked and improved but I can see a good reason why it's not that easy to direct a client to a "foreign" management server. Dunno if there will be anything new in this area with 9.7 but I'm pretty sure that the take over a managed installation problem will be addressed rather sooner than later.

As you sure know there are unofficial remedies - so just in case you should have turned on PM (no I haven't one for you). And please look which forums you have access to ...

Christian

Oops, PM's back on Christian.

HI,

When you say:

"feed in sufficient credentials........nothing"

What exactly is nothing :)

Does the scheduled task to deploy get created on the machines?

Does setup.exe run?

If you bootstrap a client from the 9 distribution point does that work, does the machine become managed?

It's not clear to me if it's the act of protection or the install itself which is not quite working.  

Does SAU get installed, start pulling down the new packages, it is then at the install of the RMS package it fails?

The client mrinit log file and RMS MSI log in \windows\temp, will give you the best clue.

When the machines were managed by SEC 3.1 at the remote site, were custom mrinit.conf files added to the CID?  If not you shouldn't have a mrinit.conf.orig file as this is only created when a custom mrinit.conf is used.

Thanks

Jak

Hi Jak,

"When you say:

"feed in sufficient credentials........nothing"

What exactly is nothing "

Exatly that. I see in the SEC 4.0 console, the standard orange arrow which never goe green. On the client, no task is created though I can hppily create a task myself remotely, run it and see the results. After standard 5 minutes, the SEC 4 console returns the standard error "'the installation didn't start, the computer may have been shut down.......". It's almost like it realises it's controlled elsewhere and aborts the task deployment but there's no logs to show this.

"If you bootstrap a client from the 9 distribution point does that work, does the machine become managed?"

No, it happily installs the new version and updates RMS and AU too but then continues to notify the local SEC 3. As I've removed the machine from any local SEC groups, it appears in the unassigned section of that, in blue and showing correctly the new CID update points but obviously as unknown policy compliance.

"When the machines were managed by SEC 3.1 at the remote site....." no, no custom mrinit.conf so only the cac.pem and mrinit.conf would be changed if I follow my ow logic.

Obviously to crack this, I can simply uninstall the entire suite from the clients and reinstall but I can't think why I shoul not be able to do this locally. Security wise it's nonsense, I've got administrative credentials to install so should be able to take on or shift machines at will. Can't imagine larger installations not facing this issue i.e. person moves from one branch office to another but new office cannot capture the user into their own SEC without having to completely reinstall.

Matt

Hi,

It sounds like there are 2 problems:

1. SEC creating a task on the clients which will run.

2. The RMS package not re-configuring itself to point to the new parent, even when you run setup manually.

For the first, the SEC server addresses the client using the NetBIOS name.  When you are at the SEC server and you do:

\\<remoteclient>\

Go into the scheduled tasks and create a task, are you using the IP, FQDN or NetBIOS to reference the remote client?

Are you doing this as the same account as the one you enter in the protection wizard?

If you need to use a FQDN to address the client, you may need to add the other domains in the domain suffix list on the SEC server.

As for the second, i.e. running setup manually doesn't point the machine at the new SEC server, even though:

1. The parent address value in the mrinit.conf in the root of the CID does point to the new SEC server.

2. There is no mrinit.conf in the rms sub directory of the CID that points elsewhere.

3. There is no mrinit.conf.orig file in the clients remote management system directory.

I can only assume that when the clientmrinit.exe runs, the installer helper exe the RMS installer launches to configure the router on the client it takes exception to the registry keys that are all ready on the machine.  If you could paste the contents of the last clientmrinit log file (\windows\temp) it would help.

Otherwise, I'm sure deleting the following registry keys on a client prior to installing woukd work:

pkc and pkp of the router and the agent.

cac

the 3 certidentity keys,

the parent address key.

I would think the reinstall would work then work.

Thanks,

Jak

Hi Jak,

"For the first, the SEC server addresses the client using the NetBIOS name.  When you are at the SEC server and you do:

\\<remoteclient>\

Go into the scheduled tasks and create a task, are you using the IP, FQDN or NetBIOS to reference the remote client?

Are you doing this as the same account as the one you enter in the protection wizard?"

Yep, way beyond you there Jak. Task schedule works fine. Same credentials kicks off task no problem. Can remotely create, run and view results of tasks on remote machine (have full domain admin rights over it). RPC all fine, remote registry all fine. Seems to be built into SEC that it must query remote machine first (possibly why it needs remote registry access) and check if it's already managed and then simply reject at that point not bothering to deploy the install task.

The initial reject maybe because it's querying the registry keys you describe so I'll try this bit by bit and if I figure out why, report back to this thread. Might be as simple as deleting the key then reprotect from the console. Tech support have got nowhere with this, their solution is uninstall everything then protect - not particularly great response but predictable.

Matt

There is no check, it blindly creates the scheduled task.  

The clientmrinit log file is the way to go.  The registry keys in question are the ones that clientmrinit.exe sets, along with some others but those are the ones it is most likely to take exception to.

Jak

Ok, more information....

After several exchanges of ideas with tech support, their option was to remove keys from registry along the lines of Jak and then deposit a new mrinit.conf and cac.pem into the RMS folder and run the setup from the central CID. Was going to take ages to do this and although I could script it, I found a significantly easier method:

To move a machine from one managed SEC to another, you need to grab a copy of mrinit.conf and cac.pem from a new CID from the new SEC and place these files in the client RMS folder. Then, I manually edited the client autoupdate configuration file iconn.cfg which is in c:\program files\sophos\autoupdate\config (xp) or c:\programdata\sophos\autoupdate\config (vista/7) and changed the update location (ConnectionAddress) in the primary section to point to the new CID location created in the new SEC. Once this was set, go to the original SEC console and 'kick' the client to do an update ('update now'). It downloads the updates from the new CID and jumps right over to the new SEC. Once you've done one, just get a copy of the three file mrinit.conf.cac.pem and iconn.cfg and copy to the next client and the next and the next etc.

Just did this on one branch office and sucessfully took over 20 clients. The only issue I had is that the move also upgraded clients from v7.6 to v9.5 and as a result on or two had an issue reinstalling AU but this is soved by rebooting the client and then creating a task to install again from the CID or manually having the user run the setup themselves. Now got a larger branch to do so I'll script that task and probably shoot it over in a logon task.

Matt