Forum Discussion

Christian_M_'s avatar
15 years ago

Moving Database from SQL 2000 to SQL 2005

Hello!

We need to move our Backupexec 12.5 Database from SQL 2000 to SQL 2005.

The sql server are in different domains with domain trust.

We tried to use BEUtility but i always stop with error message

error Access to remote registry key (i had to translate it from german to englisch / German message is Der Zugriff auf die Registrierungsschlüssel des ausgewählen Server .....)
see attachment

I think i know what the problem is

We installed backupexec with access to SQL with user sa but on the new sql the sa user has a different password.

so i think backupexec has simple no access to the new sql server but how can i change the SA password on Backupexec 12.5

In 10 there was a option to change this but i cann´t find it in 12.5

Any idea what i can do?
  • hi!

    So finally after i spent 12  hours work i finished migrating backupexec to the new domain and sql server. (we also migrated ev 8.0 and our fileserver. it was not just BE ;-) )

    We also have EV 8.0 installed on this server for file archiving so maybe some of the step are not needed if you only have backup exec installed.

    OS = Win2k3 R2 sp2 32bit
    BE = 12.5 SP3

    Here is what i did: (maybe this will help somebody have the some job to do)
    1.    First of all. Make a own instance for BE. I highly recommand to do this, because BE likes to restart SQL services and
           messing up with other database in the same instance
    2.    Stopping all BE services and changed them to manually startup
    3.    migrate the backupserver with admt computermigration (i used "Files and folders", "Local groups", "Registry", "Shares", "User Profiles" and "User rights"
    4.    Created in the new domain a new backup user (i made him domain admin) and added him to local admin group on the backupserver
    5.    Meanwhile you can make a backup of the database on the old server and restore it on the new one.
            If you restore the database make sure the filenames are identical to the old one. Otherwise BE won´t work
            In my case it was
            bedb_dat.mdf
            bedb_log.ldf
    6.    Add the new Backup user to have db_owner right to the BEDB
    7.    Open "Local Security Settings" on the Backupserver go to "Local Policies" - "User Rights Assignment"
           and add the new backup user to all places where i found the old one for example "Create a token object"
    8.    Open regedit on the backupserver and change following regkeys
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Adamm\Database Instance Name=new instance name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Adamm\Database Server Name=new server name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Catalog Database Instance name=new instance name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Catalog Database Server Name=new server name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Instance Name=new instance name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Server Name=new server name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Log Path= new path name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Path= new path name
    9.    Change all servcies backup to automatic and start them
    10.  Checking all backup jobs and changing Logon Accounts.

    One Warning message is left.
    it is in C:\Program Files\Symantec\Backup Exec\Logs\dbrecover.log

    Message is:
    File Exist Check: D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\master$4idr
    File Exist: FALSE
    WARNING: One or more of the following backup files are missing:
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\master$4idr
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\mastlog$4idr
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\model$4idr
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\modellog$4idr

    As far as i can see there is no problem. Maybe database maintenance job will fix this.

    I didn´t used the BEUtility because it didn´t worked well for me and as far as i can see it has a bug that it writes the wrong path name for the log file into the registry and
    don´t finish sucessfully.

3 Replies

  • Backup Exec will need to use Windows authentication to SQL because it is the service startup accounts that authenticate to SQL - as such you will need to sort out your domain trusts and add the account into the SQL security.

    Couple of things to be aware of:

    When Backup Exec is installed to a default SQL Express instance it does not use the sa account either.

    Symantec strongly recommend that the Backup Exec database is not installed into the same instance as that used by any Corporate critical databases - so should always be installed in it's own instance (as such I hope your reason for moving the database is not to move it into an instance containing another application.)

    I doubt if Symantec have ever tested Backup Exec in an environment where the database for Backup Exec resides in a different domain, you should be able to get it to work, however your may have issues with tech support if any ongoing problems are proved to be because of your installation environment. As far as I am aware the database location in a remote SQL instance in the same domain is tested.

    BEUtility might not be able to handle the cross domain movement because of credentials as such you might have to do a manual detach and re-attach of the SQL database files, along with editing the registry on the media server.

    If you currently use DLO on the server concerned - this will also give you domain credential problems as when a new user connects to DLO it is SQL that sets up the user folder access via an External Stored procedure library (a dll that you will have to copy to the remote SQL server) and the access rights may not therefore be passed correctly if the DLO users are in one domain and the SQL server is in another.
  • Hi Christian,

    Following up from what Colin mentioned above, if you want to go down that route, give this a read:

    http://seer.entsupport.symantec.com/docs/318321.htm

    And...

    http://seer.entsupport.symantec.com/docs/275658.htm

    Laters!
  • hi!

    So finally after i spent 12  hours work i finished migrating backupexec to the new domain and sql server. (we also migrated ev 8.0 and our fileserver. it was not just BE ;-) )

    We also have EV 8.0 installed on this server for file archiving so maybe some of the step are not needed if you only have backup exec installed.

    OS = Win2k3 R2 sp2 32bit
    BE = 12.5 SP3

    Here is what i did: (maybe this will help somebody have the some job to do)
    1.    First of all. Make a own instance for BE. I highly recommand to do this, because BE likes to restart SQL services and
           messing up with other database in the same instance
    2.    Stopping all BE services and changed them to manually startup
    3.    migrate the backupserver with admt computermigration (i used "Files and folders", "Local groups", "Registry", "Shares", "User Profiles" and "User rights"
    4.    Created in the new domain a new backup user (i made him domain admin) and added him to local admin group on the backupserver
    5.    Meanwhile you can make a backup of the database on the old server and restore it on the new one.
            If you restore the database make sure the filenames are identical to the old one. Otherwise BE won´t work
            In my case it was
            bedb_dat.mdf
            bedb_log.ldf
    6.    Add the new Backup user to have db_owner right to the BEDB
    7.    Open "Local Security Settings" on the Backupserver go to "Local Policies" - "User Rights Assignment"
           and add the new backup user to all places where i found the old one for example "Create a token object"
    8.    Open regedit on the backupserver and change following regkeys
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Adamm\Database Instance Name=new instance name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Adamm\Database Server Name=new server name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Catalog Database Instance name=new instance name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Catalog Database Server Name=new server name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Instance Name=new instance name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Server Name=new server name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Log Path= new path name
           HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase\Server Database Path= new path name
    9.    Change all servcies backup to automatic and start them
    10.  Checking all backup jobs and changing Logon Accounts.

    One Warning message is left.
    it is in C:\Program Files\Symantec\Backup Exec\Logs\dbrecover.log

    Message is:
    File Exist Check: D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\master$4idr
    File Exist: FALSE
    WARNING: One or more of the following backup files are missing:
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\master$4idr
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\mastlog$4idr
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\model$4idr
    -> D:\Microsoft SQL Server_BE\MSSQL.4\MSSQL\DATA\modellog$4idr

    As far as i can see there is no problem. Maybe database maintenance job will fix this.

    I didn´t used the BEUtility because it didn´t worked well for me and as far as i can see it has a bug that it writes the wrong path name for the log file into the registry and
    don´t finish sucessfully.