Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 4 subscribers
  • Views 31628 views
  • Users 0 members are here
Options
Suggested
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

Helpful information for migrating Enterprise Console from Server 2003 to Server 2012 R2

TheKiwiGeek

I've just spent 2 days migrating SEC 5.2 from an old 2003 server to 2012 R2. I ran into a number of issues along the way, so I want to post this to document what worked for me in case anyone else runs into similar issues. 2003 to 2012 migrations are probably going to happen a lot in the next few months since Microsoft is ending 2003 support soon.

Also, just a note: I have no idea how we all survived so long without virtualization. I saved a boatload of time by having the ability to snapshot and revert at different steps to figure out exactly what was going on. If you are in a virtualized environment, snapshot often... You can always delete them later.

First, a little about my environment. A few items of note were that was moving from a 32-bit to 64-bit OS and that SEC on my source server were installed to a non-default location. I also needed to keep the same host name as the old server, something else not techincally supported by the docs. I gave the new server a temporary name until I was able to take over the old host name, but had to get SEC installed first. It's not a huge deal and can get worked around, but if you need to keep the same name as the old server then you'll have an easier time if you can decommission the old server and build up the new one with that hostname, rather than changing it after SEC has installed.

Old server:

Windows 2003 32-bit

Installed to a non-default location. THIS IS IMPORTANT since the docs and tools provided by Sophos rely heavily upon default locations being used in both environments.

This environment started on a 4.x version and was upgraded many times to the current 5.2.2.

New server:

Windows 2012 R2 (64-bit only)

Installed to default location

Installed .net 3.5 and SQL Express Mgmt Studio 2008 to resolve migration issues with the database.

FIRST AND FOREMOST: Ensure that the version and revision precisely matches on your source and destination server. I was running 5.2.0.x on the source and assumed it would be OK to just migrate directly to the new server with 5.2.2. There are, however, some important differences, just enough to throw off the migration. For one, the database name changes from SOPHOS52 to SOPHOS521. Once I upgraded the source server to 5.2.2, about half of my problems went away. If you are unable to upgrade your source environment for some reason, then I believe Sophos has a page where you can download legacy versions so that you can use to install that to your destination environment for the migration. You should then upgrade to the latest version once the migration is complete.

  • As noted above, I ran into additional problems because the source server install was in non-default folders. The steps and tools provided by Sophos for migration are heavily dependent upon the assumption that everything will be in default folders. To further complicate matters, the default folders on older versions of SEC/SQLEXPRESS are not necessarily the same as new versions. If you have upgraded from older versions, those folder names do not change, meaning you will be out of 'default' status for, in this case, 5.2.2 even if you've upgraded according to the proper instructions every time. This will most likely affect your SQLEXPRESS db file location, in particular. As a result, you will need to perform some extra steps. The problem mainly comes into play when restoring the database files.
  • For my situation, everything was pretty routine until Step 8.4 in the SEC 5.2 migration guide, which is where you restore the database using DataBackupRestore. Before running step 8.4, you will need to create directories that precisely match the location of the database files on the source server and then set proper permissions so that DataBackupRestore can do its job. Otherwise, the tool will give you a bunch of output followed by "Build Failed", with little information as to why. In my case, the original database files on the source server were located at  "C:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\Data". To resolve this, I created that precise file path on the new server and then granted RW access to account 'Network Service' for the directory that was created (I granted it to the MSSQL.2 directory and all subdirs). Then you can complete step 8.4 succesfully and some of the db files will be dropped into that location. You can then detach the databases associated with the files in the temporary folder you specified and move them to the proper location and reattach them if you like.

Just a note about that particular issue and resolution. I found another thread here on the Sophos forums where a user resolved this issue by modifying the trs.bat file to restore the database using the WITH MOVE sqlcmd option and specifying your new server's db file location. This may work for you, and for me it allowed the build to succeed, however I still had other issues. By using the method I listed above, you won't need to edit any scripts to allow it to succeed and is the 'cleanest' way to handle it IMO since you're allowing DataBackupRestore to do what it wants -- restore to the last location it was aware of.

  • After that was completed, I had one database that was placed into the old server location, which was SOPHOSENC52. I opened SQL Mgmt studio and simply detached that database, then moved the underlying files from that MSSQL.2\... directory I created into the default directory with the rest of the database files, then attached it back. Fairly straightforward. You can run a dbcc checkdb query on the database after moving it if you wish.
  • I then continued on with the steps as listed. Stop before doing step 11.1 and open the registry. Search out any additional keys or values that contain the old server path for any Sophos components and change them.
  • If you are changing the host name after installing SEC, then you'll need to also search out the Sophos registry keys for any reference to the host name and change it. These may be references to the update server URL, share path, etc. You'll also need to edit the EnterpriseConsole.exe.config file in the Enterprise Console program folder for references to the hostname as well as the server.xml file in the Update Manager program folder.
  • I also ran into a strange issue with Update Manager. After restoring the db in step 8.4, and finally starting the services and running the Console, I wasn't able to update at all. I noticed in the Console when viewing the Update Managers that there were now two of them listed. One appeared to think that it was on the old server while the other appeared to be on the new one. Neither were functioning and both seemed to believe they controlled the default update share location (\\<servername>\SophosUpdate). To resolve this, I had to edit a few tables in the database:
  1. Stop all Sophos services. You may only need to stop the Update Manager service, but I stopped all just in case.
  2. Open SQL Management Studio
  3. Go to the database SOPHOS521 (or equivilent) and navigate to the table dbo.SDDMLocations.
  4. Remove any rows with path references to the old server. For the current server path and the share location, note the PublisherIdentityTag.
  5. Go to the dbo.SDDMServers table and locate the row entry with the same IdentityTag as what was seen in the SDDMLocations table.
  6. Edit the table and copy the column data from that row over to the lowest numbered row. Once complete, delete all rows except the first, lowest numbered row.
  • After that's completed, you can restart all of the Sophos services. Load Enterprise Console, you should be greeted with the Update Manager wizard to set up your update server. Make sure to have your update server login info from your Sophos License Schedule to reconfigure the information.

At this point I had a fully functioning Sophos Enterprise Console environment up and running on the new 2012 server and All Was Well.

:54667


This thread was automatically locked due to age.
Parents
  • 0

    I have finally bite the bullet and migrated from 2003 to 2012 because 5.4 no longer support 2003. Everything was smooth because I have used the default locations, except that the Endpoints are still pointing to my old server. I know that the easiest way to work around this is to retire the old W2003 and rename the new W2012 to the old server name. But I still need the old server running for other services.

    The instruction (http://sophos.com/kb/116737) to use VB script doesn't work in my environment. I suspect that VBS has been disabled due to ransomware issue. Is there any other method to update the Endpoints to the new server?

    btw, I notice that for the older version 4, you could select all endpoints and click on protect computers (see this https://community.sophos.com/kb/pl-pl/117150). Unfortunately, in version 5, once you select all, this option is no longer select-able. Why is this useful function removed when select all is used?

  • 0 in reply to Boon HongWong

    Hello Boon HongWong,

    once you select all, this option is no longer select-able
    it still works on 5.4.0 but I presume you have one or more computers in the Unassigned group (which has no policies assigned and thus no update/install location).

    I assume you have imported the certificates (i.e. old and new use the same) and updating is via UNC?
    any other method
    is the old server still able to manage the endpoints, i.e. SEC still installed and running? -or-
    Are the CIDs still present and is it possible to give the new server write access to the CIDs on old?

    Christian

  • 0 in reply to QC

    Thanks Christian!

    You are right! We do have computers in the unassigned group and the option did work once I exclude them.

    And yes, I have imported the certificates and updating is via UNC. The Sophos services at the old server have all been stopped but I have not uninstall SEC as I want to confirm the new server is working well first before doing so.

    The CIDs are still present and the new server is able to write to the CIDs excluding the local CIDs on the old server as I didn't add that. (Jonas is the old server and Netman is the new server) 

    After I run protect all computers, only one get updated to the new server.

    I have also tried the Sophos endpoint migration utility and manually run the script in CMD on a few computers: cscript C:\SophosReInit.vbs

    However, the local endpoints are still pointing to the old server. They didn't get updated to the new server at all. What could be the possible cause?

  • 0 in reply to Boon HongWong

    Hello Boon HongWong,

    first of all, the Update Manager screenshot shows that Software delivery failed. It looks like it has initially worked (otherwise Last updated would say Never). The strange thing is that JONAS is on the list - how did it get there? The new server, when it processes the restored database during migration, should AFAIK put itself in place of the old one.

    Anyway, I see you have a second share - is it used as secondary location (perhaps published as WebCID) or as primary for part of the endpoints? You did amend the updating policies, didn't you?

    run protect
    the hourglass appeared on all the computer icons and then vanished and no errors are shown (please check tab Alert and Error Details)? Are these all your endpoints (as I can't see NETMAN)? The easiest way to check if the install (Protect) took place is to view the update configuration on an endpoint - it should point to NETMAN (provided the group's updating policy and thus initial install location is correct). If the thirds screenshot is from one of the endpoints you've tried to reprotect then either it didn't work at all or the old CID has been used.

    the local endpoints are still pointing to the old server
    the SophosReInit,vbs just redirects the endpoints (the endpoints' RMS component) to a new management server (which could even have a different identity, i.e. use different certificates). The endpoints should connect to the server and then receive the new policies. Apparently they don't connect (one possible cause could be the Windows firewall on the management server - but at least one endpoints connects so this is likely not the case). Please view the NetworkReport (%ProgramData%\Sophos\Remote Management System\3\Router\NetworkReport\ReportData.xml), check if Parent addresses is indeed pointing to the new server. If it isn't then either ReInit encountered some error or the wrong mrinit.conf was used. Otherwise test that NETMAN can be reached with telnet NETMAN 8192 and telnet NETMAN 8194 (the latter should connect but doesn't display anything and shortly afterwards disconnect).

    Christian

Reply
  • 0 in reply to Boon HongWong

    Hello Boon HongWong,

    first of all, the Update Manager screenshot shows that Software delivery failed. It looks like it has initially worked (otherwise Last updated would say Never). The strange thing is that JONAS is on the list - how did it get there? The new server, when it processes the restored database during migration, should AFAIK put itself in place of the old one.

    Anyway, I see you have a second share - is it used as secondary location (perhaps published as WebCID) or as primary for part of the endpoints? You did amend the updating policies, didn't you?

    run protect
    the hourglass appeared on all the computer icons and then vanished and no errors are shown (please check tab Alert and Error Details)? Are these all your endpoints (as I can't see NETMAN)? The easiest way to check if the install (Protect) took place is to view the update configuration on an endpoint - it should point to NETMAN (provided the group's updating policy and thus initial install location is correct). If the thirds screenshot is from one of the endpoints you've tried to reprotect then either it didn't work at all or the old CID has been used.

    the local endpoints are still pointing to the old server
    the SophosReInit,vbs just redirects the endpoints (the endpoints' RMS component) to a new management server (which could even have a different identity, i.e. use different certificates). The endpoints should connect to the server and then receive the new policies. Apparently they don't connect (one possible cause could be the Windows firewall on the management server - but at least one endpoints connects so this is likely not the case). Please view the NetworkReport (%ProgramData%\Sophos\Remote Management System\3\Router\NetworkReport\ReportData.xml), check if Parent addresses is indeed pointing to the new server. If it isn't then either ReInit encountered some error or the wrong mrinit.conf was used. Otherwise test that NETMAN can be reached with telnet NETMAN 8192 and telnet NETMAN 8194 (the latter should connect but doesn't display anything and shortly afterwards disconnect).

    Christian

Children
No Data
Unfiltered HTML