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

Enterprise Console Migration

Hi all,

I've finally decided to bite the bullet and migrate Enterprise Console from an ancient Windows 2003 (32-bit) server to a slightly more up-to-date Windows 2008 R2 (64-bit) server, but am encountering a problem in this process.  The console is version 5.2.1 R2, and I'm following the migration guide linked to from http://www.sophos.com/en-us/support/knowledgebase/28276.aspx ( link leads to this document http://www.sophos.com/en-us/medialibrary/PDFs/documentation/sec_52_mgeng.pdf ).  The problem I'm encountering happens at point 4 of section 8 (on page 14) when attempting to restore the database to the new server.  The errors returned are in the attached text file, and contain an alarming amount of red text :smileyindifferent:

I notice it mentions the previous databases from 5.2.1 and before, which I'm not too concerned about as I just haven't removed them yet after the version upgrade, but it's not looking too promising for 5.2.1 R2 either.  Does anyone have any idea what I could be missing here?  I suspect it's something really simple which I've missed.

Many thanks for any help!

:49132


This thread was automatically locked due to age.
  • Hi,

    If you have the 4 backup files, I would just restore them with restoredb.bak utility.

    C:\sec_52\ServerInstaller\DB\Core\restoredb.bat

    Usage:

    RestoreDB backup_file_path [server_name\instance_name] [database_name]

    Once done, then run the ResetUserMappings.sql file against each database, e.g.

    sqlcmd -E -S .\SOPHOS -d SOPHOS521  -i "C:\Program Files\Sophos\Enterprise Console\ResetUserMappings.sql"

    sqlcmd -E -S .\SOPHOS -d SOPHOSPATCH52  -i "C:\Program Files\Sophos\Enterprise Console\ResetUserMappings.sql"

    sqlcmd -E -S .\SOPHOS -d SOPHOSENC52  -i "C:\Program Files\Sophos\Enterprise Console\ResetUserMappings.sql"

    sqlcmd -E -S .\SOPHOS -d SophosSecurity  -i "C:\Program Files\Sophos\Enterprise Console\ResetUserMappings.sql"

    Database names per version: http://www.sophos.com/en-us/support/knowledgebase/17323.aspx

    Then carry on.

    Regards,

    Jak

    :49136
  • Hi,

    Many thanks for your reply jak, and apologies to all for not updating this thread earlier.  The issue of migrating SEC did get pushed aside for a while and has only now come back to haunt me.

    Your suggestion of manually importing the databases did allow me to proceed, so thanks again for the advice.  However, it's not all quite plain sailing yet :smileysad:  If anyone has any advice for the following situation it would be much appreciated!

    Basically I'm now at the stage where everything has (allegedly) migrated over successfully, but when starting Enterprise Console on the new server for the first time the following error is displayed:

    Sophos.UIController.Extension.UIControllerException: Cannot retrieve session token after 8 retries. Please check that the Sophos Management Host service is running, otherwise see KBA 118513.
       at Sophos.UIController.IdentityServiceAbstracter.EndRetrieveSessionToken()
       at Sophos.UIController.UIControl.InitializeModulesDependencies()
       at Sophos.UIController.UIControl.<Initialize>b__b()
       at Sophos.UIController.Product.Logging.LogMethod(MemberInfo method, Action func)
       at Sophos.UIController.UIControl.Initialize()
    
    ----- [outer exception] -----
       -- error: 0x80004005 (Unspecified error)
       -- facility: Generic (System)
       -- source:   Sophos.UIController
    
       at class ATL::CComBSTR __thiscall UIControl::initialize(class ATL::CComPtr<struct IDispatch>)
       at class ATL::CComPtr<struct IDispatch> __thiscall bl::CReusingManagementServiceClientBroker::logIn(const struct util::UserName &,class Loki::SmartPtr<class bl::SubEstate,class Loki::RefCountedMTAdj<class Loki::ClassLevelLockable>::RefCountedMT,struct Loki::DisallowConversion,struct util::NoDereferenceNull,class Loki::DefaultSPStorage>,const wchar_t *,class bl::UIControllerBase &)
       at int __cdecl Run(int,class bl::CommandLine,enum bl::ConsoleType::Type)
       at int __stdcall wWinMain(struct HINSTANCE__ *,struct HINSTANCE__ *,wchar_t *,int)

    I've gone through all the steps listed in the knowledgebase article and have verified that the services are all running, and using the database account specified during installation.  The SophosSecurity database is present and online, and the database account is in the "Sophos DB Admins" group (I even tried testing the service with the domain admin account, just to verify permissions, and this also failed).  Networking on the server is all fine, and I've run out of things to try now.

    I'm assuming other people have managed to migrate SEC to a new server without these problems, and I've either missed something or am being incredibly stupid with the entire process?  If anyone has any ideas what I am missing or doing wrong, they'd be much appreciated!

    Thanks in advance.

    (Edited to fix typos)

    :54863
  • Hello RBGE,

    only one idea

    gone through all the steps

    did this include it is advisable to re-run the Enterprise Console installer somewhere in 4.? Searched for threads about the same error and it helped in a few cases (all of them had "different paths" leading to the problem).

    Christian

    :54877
  • Hi QC,

    Thanks for your reply.  I did indeed run the installer again, although as of this morning I've now decided to bin the Windows Server 2008R2 installation and start from scratch (again!) with a Server 2012R2 instance.  The theory being that since this migration process is such a nightmare, this should at least delay me having to go through it again for an extra 4 years.  Maybe in this time a proper migration tool will have been developed :smileyfrustrated:

    I also found a post from TheKiwiGeek ( /search?q= 54667 ) pointing out that the official instructions just do not work if you've ever upgraded the product, even if you use default installation options.

    I'll see if this method has any better results and update this post after.

    Thanks.

    :54878
  • Hello RBGE,

    :smileymad: rats.

    Dunno if I'm particularly lucky - upgrading whenever a new version came out (well, except for the 5.x minor ones) since, well, before SEC. First one then two production servers, five server migrations. One minor problem. A few more during Beta tests (and I did quite some unsupported and not recommended things) but none which couldn't be corrected.

    Good luck

    Christian

    :54879
  • This is really starting to annoy me now :smileymad:  Everything looked like it was working perfectly until restoring the SecureStore from backup (the last step in section 11, at the top of page 25) when the following error appears:

    c:\Program Files (x86)\Sophos\Enterprise Console>DataBackupRestore.exe -Action=Restore -DataSourceType=SecureStore
    Are you sure you want to Restore SecureStore in all? (Y/N)
    y
    Microsoft (R) Build Engine version 4.0.30319.33440
    [Microsoft .NET Framework, version 4.0.30319.34014]
    Copyright (C) Microsoft Corporation. All rights reserved.
    
    Build started 21/11/2014 15:04:30.
    Retrieving the COM class factory for component with CLSID {2C5339F1-B8D3-4D40-9245-E68E0F8C6380} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
    
    Build FAILED.
    
    Time Elapsed 00:02:00.18
    Process 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe "c:\Program Files (x86)\Sophos\Enterprise Console"\BackupRestore.proj /t:Restore /clp:NoSummary /p:SubSystem=all;DataSourceType=SecureStore;ExcludeDB=False;LocationSpecific=False;SlientMode=False;DBServerInstance=' returned Error 1

    Strangely enough, this part worked fine yesterday (albeit on the old 2008R2 server).  I think I may come back to this issue later after repeatedly banging my head off the desk......

    Thanks for the advice so far though!

    :54880
  • Woohoo, it worked! :smileyvery-happy:    I have no idea why it worked this time and not any of the other times - the only thing I did different from the previous attempt was using PurgeDB to tidy up the database a bit beforehand.  If it weren't for TheKiwiGeek's post mentioned previously though, I'd have migrated to some other vendor by now.  Still a few minor issues with the endpoint migration script not working and my local management console refusing to connect after updating the settings, but I'll work around those.

    Thanks for all the sugestions with this issue, and Sophos: please update your documentation.  Following the instructions exactly does not work if you've ever ugraded Enterprise Console!!!!  (due to the database paths)

    :54936
  • Just an update here, in case anybody else finds this post at a later date and has the same problem.

    As mentioned above, things fell over (again!) when trying to migrate client machines over to the new server.  The script generated by the Endpoint Migration Utility just did not work for me, even if I had the force option selected.  While manually reprotecting each machine from the console did work, this wasn't really practical as not every machine was on-line at the time, and there are lots of machines that get taken off-site for various reasons, so wouldn't know to look at the new server.  A simple DNS alias solved this problem for me:  oldserver as an alias for newserver caused the clients to at least contact the new server, and then it was just a case of waiting for the correct configuration to be deployed.  Obviously this only works for a successful migration - it doesn't if you install a new copy of Enterprise Console on the new server and set it up from scratch.  Yes, this was one option I tried in my many attempts to get it to work :smileyindifferent:

    With regards to the local management console which wouldn't connect even after updating the settings, this was a simple case of fully uninstalling it, rebooting my machine then installing again from scratch.

    Maybe these won't help for everyone, but hopefully it should help solve some problems for anyone else experiencing the same issues I did.

    Who knows, I may even end up finding this thread when Windows 2012 goes end of life.......... :smileylol:

    :54967