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:
- Stop all Sophos services. You may only need to stop the Update Manager service, but I stopped all just in case.
- Open SQL Management Studio
- Go to the database SOPHOS521 (or equivilent) and navigate to the table dbo.SDDMLocations.
- Remove any rows with path references to the old server. For the current server path and the share location, note the PublisherIdentityTag.
- Go to the dbo.SDDMServers table and locate the row entry with the same IdentityTag as what was seen in the SDDMLocations table.
- 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.
This thread was automatically locked due to age.
