cancel
Showing results for 
Search instead for 
Did you mean: 

*Urgent* Server NETBIOS name change results in BE12.5 not starting services

Johnny_Corona
Level 3

I simply changed the server name of our BE server from HUBBLE2 to HUBBLE and now BE won't start (except for the Remote Agent).
I get the following EventID:

Log Name:      Application
Source:        Backup Exec
Date:          8/27/2009 2:46:09 PM
Event ID:      58068
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      HUBBLE.ourdomain.com
Description:
The Backup Exec Device and Media Service could not start because the database recovery has failed.  Refer to the database recovery log for details.

I looked online for the Event as well as other KB articles and performed the following:

1) I tried to use the BEUtility as one of the KB articles pointed out, and it displays my current server name with no info.  If I try to reconfigure it or change the system account it fails trying to start the services.  I'm afraid to delete it and it it back.

2) One of the articles I found suggested modifying the registry.  Sure enough, there were several hardcoded paths with the old server name.  I modified the registry (after exporting the HKLM\Software\Symantec\Backup Exec\ key) to change all instances of HUBBLE2 to HUBBLE.  Tried BEUtility and no change.  Tried to start the services manually and no change.

This is a very simple setup.  The media server and BE (along with everything else in the suite) is installed locally, in the default folders.

Someone please help!  I've spent months configuring this and I would have to uninstall/reinstall.  Thanks in advance!

Here is what the databsae recovery log shows (dbrecover.log):

-----------------------------
Backup Exec Database Recovery
08/27/09 14:57:14
-----------------------------
Initializing...
BEGetComputerName = 'HUBBLE'
GetBeVirtualServerName = ''
Using node name for media server
Data for BE database:
Structure size: 6500
Media Server  : HUBBLE
Node, if clust:
SQL Server    : HUBBLE
Instance Name : BkupExec
SQL Instance  : HUBBLE\BkupExec
SQL Service   : MSSQL$BkupExec
Database      : BEDB
App Data Path : C:\Program Files\Symantec\Backup Exec\Data
Database Path :
Database Log  :
Database File : C:\Program Files\Symantec\Backup Exec\Data\BEDB_dat.mdf
Database Log  : C:\Program Files\Symantec\Backup Exec\Data\BEDB_log.ldf
Backup File   : C:\Program Files\Symantec\Backup Exec\Data\BEDB.bak
Base File     : C:\Program Files\Symantec\Backup Exec\Data\BEDB_dat.bak
Base Log File : C:\Program Files\Symantec\Backup Exec\Data\BEDB_log.bak
Is Local      : TRUE
IsDatabaseMgr : TRUE
Recover database using best method..
GetDatabaseStatus
OpenFromInitializationString Connection String = Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=HUBBLE\BkupExec;Locale Identifier=1033;Application Name=BEWS DBUTIL hr=0x80004005
Error connecting to master database: hr = 0x80004005
OS ERROR: 0x80004005 (-2147467259)
Status of database BEDB is unknown
Fixing up any database linkage problems for 'BEDB'
Execute command: declare @@stemp as varchar(32)
select @@stemp = isnull(convert(varchar,databasepropertyex('BEDB','status')),'NOT EXIST')
print 'Database status: ' + @@stemp
if @@stemp <> 'ONLINE' and @@stemp <> 'NOT EXIST'
begin
print 'Forcing database detach'
EXEC sp_detach_db 'BEDB'
end

OpenFromInitializationString Connection String = Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=HUBBLE\BkupExec;Locale Identifier=1033;Application Name=BEWS DBUTIL hr=0x80004005
Error connecting to master database: hr = 0x80004005
Execute command failed: 0x80004005
Drop database BEDB
Execute command: drop database BEDB
OpenFromInitializationString Connection String = Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=HUBBLE\BkupExec;Locale Identifier=1033;Application Name=BEWS DBUTIL hr=0x80004005
Error connecting to master database: hr = 0x80004005
Execute command failed: 0x80004005
OS ERROR: 0x80004005 (-2147467259)
GetDatabaseStatus
OpenFromInitializationString Connection String = Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=HUBBLE\BkupExec;Locale Identifier=1033;Application Name=BEWS DBUTIL hr=0x80004005
Error connecting to master database: hr = 0x80004005
OS ERROR: 0x80004005 (-2147467259)
Status of database BEDB is unknown
File Exist Check: \\HUBBLE\C$\Program Files\Symantec\Backup Exec\Data\BEDB_dat.mdf
File Exist: TRUE
File Exist Check: \\HUBBLE\C$\Program Files\Symantec\Backup Exec\Data\BEDB_log.ldf
File Exist: TRUE
Attach database BEDB
File Exist Check: \\HUBBLE\C$\Program Files\Symantec\Backup Exec\Data\BEDB_dat.mdf
File Exist: TRUE
File Exist Check: \\HUBBLE\C$\Program Files\Symantec\Backup Exec\Data\BEDB_log.ldf
File Exist: TRUE
Execute command: sp_attach_db 'BEDB','C:\Program Files\Symantec\Backup Exec\Data\BEDB_dat.mdf','C:\Program Files\Symantec\Backup Exec\Data\BEDB_log.ldf'
OpenFromInitializationString Connection String = Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=HUBBLE\BkupExec;Locale Identifier=1033;Application Name=BEWS DBUTIL hr=0x80004005
Error connecting to master database: hr = 0x80004005
Execute command failed: 0x80004005
OS ERROR: 0x80004005 (-2147467259)
Deinitialize...

-----------------------------
Process completed
08/27/09 14:59:21
Status: DBU_ERROR_DATABASE_ATTACH_FAILED
-----------------------------

 

1 ACCEPTED SOLUTION

Accepted Solutions

Johnny_Corona
Level 3
The issue is now closed.  After spending four hours with emergency enterprise support, I noticed that reviewing the MSSQL SVR registry keys that a component was using TCP port 49821.  

In addition to changing the NETBIOS name, it also assumed it's predecessor's role of being an internet gateway for some public apps.  We're using RRAS for IPv4 filtering, excluding all incoming ports on the outside adapter except for certain applications. 

Who the hell knew that MSSQLSVR needs to leave and reenter the building at 49821?  After exposing all ports briefly the service fired right up.  I then locked it down to the specific port and all is now merry.

I get my logs, my catalogs, and my backup jobs.  I hope this info helps someone in the future.

View solution in original post

8 REPLIES 8

Johnny_Corona
Level 3
Edited original post.

Johnny_Corona
Level 3
Does anyone have any suggestions?

Hemant_Jain
Level 6
Employee Accredited Certified

Please go through the following document:
http://seer.entsupport.symantec.com/docs/274102.htm
Please post the errors you receive on this. Change the path in the commands as per your current path where bedb_dat.mdf and bedb_log.ldf files are located.

Thanks

Johnny_Corona
Level 3
Unfortunately it did not work.  There were absolutely no errors, and I modified the path properly.

If I manually try to start the BackupExecDeviceMediaService I still get the following:

"If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 536928979"

The eventID is 58068 "database recovery has failed"

And the first hint of a problem in the recovery log is as follows:

Name=BEWS DBUTIL hr=0x80004005
Error connecting to master database: hr = 0x80004005
OS ERROR: 0x80004005 (-2147467259)
Status of database BEDB is unknown

I've even tried reinstalling (not allowing BE to remove my data files on the uninstall), and I still get the exact same problem.

Help!!!


Hemant_Jain
Level 6
Employee Accredited Certified
It appears to be an issue with MDAC. What OS is this? Please download and apply the latest MDAC software from Microsoft website.
Thanks

Ken_Putnam
Level 6
Have you used BEUTIL to tell BackupExec that the name has changed?

See http://seer.entsupport.symantec.com/docs/300838.htm

Johnny_Corona
Level 3
 Yes, I've been all over that utility, and no matter what I try it always comes down to the same error when trying to start the BEMediaService.

This does *not* have anything to do with MDAC.  The server simply went through a name change.  

I'm running Windows 2008 Enterprise Server.

Johnny_Corona
Level 3
The issue is now closed.  After spending four hours with emergency enterprise support, I noticed that reviewing the MSSQL SVR registry keys that a component was using TCP port 49821.  

In addition to changing the NETBIOS name, it also assumed it's predecessor's role of being an internet gateway for some public apps.  We're using RRAS for IPv4 filtering, excluding all incoming ports on the outside adapter except for certain applications. 

Who the hell knew that MSSQLSVR needs to leave and reenter the building at 49821?  After exposing all ports briefly the service fired right up.  I then locked it down to the specific port and all is now merry.

I get my logs, my catalogs, and my backup jobs.  I hope this info helps someone in the future.