Enterprise Console 5.2.2 not seeing changes.

Hello ShirleyPulsipher,

migrated ... using instructions
variations in the procedure are nevertheless possible. Did you use a new name/IP and did you export/import the certificates? If I understand correctly you also restored the database. Did you reprotect the endpoints or redirect them by some other method?
workstations shows that the settings have change
which settings - the updating policy?

Are (most of) the endpoints shown as disconnected? If you select the Computer Details tab in the Endpoints view and check the Last message time column - are there endpoints with timestamp after the migration or have (almost) all an older timestamp? Please check the Network Communications Report on an endpoint (the link from the Programs menu has been removed but you can open the XML with a browser).

Christian 

Dude you look a bit chilly there!!! Thanks for the reply.

Yes stepped through the migration process and all went well. but the console showed no activity or contact from endpoints from the point of the backup to move it. I did however edit one of the endpoints update settings to point to the new system and it did eventually show up so I decided the console was actually working. I support a number of schools with Sophos and my lead tech normally handles this he has always found it easier to just do a new install and redeploy but this install handles users that roam in and out of a number of offices in a wide area so I really wanted it to heal its self. the last step of the migration was to apply the new server settings to the policies on the computers via the new console, I don't know exactly how the communication happens to the endpoints, I assume via the messages, using the route_table.txt etc.  After most of the day and no apparent change and no response from support I decided to try a few things.

I have a habit of kind of a shotgun approach so I ended doing several things, the first being I tried to just do a protect on the devices, I would get an hour glass and after a bit a failure to install with it pointing at the old server so then I download the script utility and created a ReInit script while on the new server and used GP to deploy as a start up script, after a number reboots and RSOP checks to make sure it was at the endpoint I went to bed, woke up at 3 am with the bright idea to go back and fire up the services and shares on the old server (something they warn against) and pointed the policies on that server to the new server, I had also noticed that somewhere in the process of rebooting, back handing and cussing that the firewall on the domain network on the new server had been turned back on, I am sure probably when I changed the advanced file sharing. I kept feeling the server just wasn't making contact with the endpoints and turned on the advanced file sharing not sure if its needed or not. which engaged the firewall I'm sure and dozed back off, this morning some 16 out of 50 machines have hooked back up and I got to do my happy dance. The balance are primarily the roaming machines hopefully they connect up also. Not sure which or combination of which helped but I'm moving forward! need to go turn off the old server again at some point here. Anyway thanks for the input and ideas, I have a small brain and can use all the help I can get!!

Shirley

Hello Shirley,

so you're "reusing" the certificates, aren't you?
First and foremost - as far as management (RMS) is concerned it's always the endpoint that decides whether it wants to be managed at all (by installing the RMS component) and when it wants to be managed (by connecting to and disconnecting from the management server). Thus SEC can't manage - and therefore apply policies to - an endpoint which hasn't established a connection (that SEC attempts to establish a connection to the endpoint to push policies and commands doesn't make a difference as it does so only after the endpoint has logged on).

The endpoints obtain information about their server (certificates, name and/or address) from the CID (cac.pem, mrinit.conf). Matching certificates provided they will apply a new mrinit.conf.from an appropriately configured CID. So, in order to talk to the new server they have to fetch the new mrinit.conf. To do so they have to update from the new CID. To download from the new CID they need a new updating policy. To get a policy they have to be connected to a management server. See [:)]?
Apart from reprotect, GPO/script and other big guns you have a number of options (and some require either preparations before migration or both servers to be active - it's not as dangerous as one might think).

• change the updating policies while old still manages the endpoints
• change mrinit.conf on the old CID 
• assign old's IP to new (or give new the same name - you can't rename it after SEC installation though)
• create a DNS alias for new

Over time I've used all of them (the last one takes care of both update location - unless the CID structure has changed - and RMS and is, well, appealing: Had a number of endpoints which apparently gather dust for months, some even years, only to come to life again after all this time). Hope with this information you'll be able to rope in the remaining endpoints. Size doesn't matter, BTW. But take my advice - don't form a habit of waking up at 3 am, bright ideas or not.

Christian

Chilly? Naw, just below zero degrees. And snow and ice actually make a good insulation - if you're wearing a beard.

Thanks Christian, big help.

I had my finger on changing the mrinit.conf on the old server and didn't pull the trigger. Figured I might dig the hole deeper. Had I followed my original plan the other options on ip and name would have worked. The Sophos as loaded on the sole server in one of the remote offices, a domain controller no less running 2003. We were moving the Sophos to upgrade the server. The original plan was to make a backup of the sophos configs reload the server to 2012 and reinstall in retrospect may have saved some grief. Somewhere along the way I decide to put the Sophos on its own machine as a virtual thinking I could get it up and going before having to commit to destructing the old one which didn't pan out because as soon as a few machines moved then I was left straddling the fence. Being a DC makes changing the name or creating an alias a bit complicated and to make it worse its on entirely different subnet so changing the IP won't work either.

I can't speak to reusing the certs but I ass-u-me I am because of the backup and restore process but to be honest I don't know that for sure. I started to edit the mrinit.conf on the old server originally by changing the MRParentAddress and the ParentRouterAddress because the rest of the file references and keys etc. appear to be identical. the new one does reference IPv6 in it other than that name and IP are about the only things different. But I changed my mind. Sounds like it might have been fine.

Anyway down to about a dozen or so that are still lurking which I can deal with if needed. Not sure what is moving them my script or if the policy changes are finally migrating. I know in the back up and restore process the instructions make it sound like the router txt file would take care of it. they don't offer any real explanation We have about three other installs we have to move off of 2003 so this info will be a great help so thanks for taking the time..

BTW I have a similar beard despite the name,, boy name Sue I guess.