Video Screencast Help

moving ghost to a new server

Created: 10 May 2006 • Updated: 21 May 2010 | 14 comments

We are in the proccess of replacing the server that GSS is running on with a new server. I have complete the install and registration of ghost on the new server but I am having an issue trying to copy the database to the new server. The Win32 Configuration server service will not load with the old database. The event log shows the following error

Event Type:Information
Event Source:Application Popup
Event Category:None
Event ID:26
Time:10:14:13 AM
Application popup: Symantec Ghost Configuration Server : 28000 Invalid user ID or password

For more information, see Help and Support Center at

When i restore the defualt database it loads fine.

The old server was running Server 2000 with SQL Server installed, ghost was installed on the D: on the old server.

The new server is running server 2003 without SQL server installed and ghost is installed on the C:.

Anyone have any ideas before i start rebuilding our database from scratch?

Discussion Filed Under:

Comments 14 CommentsJump to latest comment

Frank Kish 2's picture

Hi Shane ,

Just to clarify . When you finished copying the "old" DB to new location what is happening when you try to open the Console ?

Are you getting the same error message as it is in the event log?

Can you manually start the Win32 Config server service?

What is happening with Ghost DB service?

Are you using the same version of GSS?

Regards ,

Ethan Hunt's picture

there is a knowledgebase article about how to move ghost console to different machine. This might be helpful to you.

Nigel Bree's picture

Actually, the existing KB article seems to have been overtaken by some of the changes in GSS1.1 - it's no longer quite that easy to move a database from one machine to another because of the fact that installations now use unique, randomized credentials.

We'll start the work of updating the knowledge base for this, and come up with a simpler procedure but in the meantime there is a manual procedure you can try.

This does involve editing the registry, so it's not for the faint of heart and all the standard warnings apply.

- On the original machine, be logged in as the machine administrator
- open a command prompt use Start -> Run and enter "cmd" then press return
- change directories to the Ghost installed program directory, e.g. "cd c:\program files\symantec\ghost\"
- enter "ngserver -export"
- enter "regedit" to launch the Windows Registry Editor.
- exit the command prompt with "exit"

After the above, a special area of the registry is populated with the internal credentials used by the console and configuration server, located at HKEY_LOCAL_MACHINE\Software\Symantec\Symantec Ghost\NGServer. This registry key will not exist until you use "-export" as above, and it will be erased the next time the Configuration Server is run. You can use the "regedit" tool to export this data to a .REG file, which you can transfer to the new machine by using the "Export" context menu.

This data includes the master key for the database, so take appropriate care with it to avoid disclosing it.

On the new machine, be logged in as the machine administrator. Stop the Configuration Server service and load the old server's database over the top of the freshly installed one. Before you restart the Configuration Server service, merge the saved .REG data you captured above into the registry (double-clicking the .REG file can do this).

If you now start the Configuration Server service, the saved credential information will be copied out of that registry location (and then the registry keys will be erased) and the configuration server should be able to log into the database and proceed as normal.

Provided it all works, you should take care to remove the exported credential information from both the old and new systems to avoid inadvertent disclosure.

If you try this, do let us know how it works out, whether the instructions don't seem to work for you or could be clearer.

Shane Liptrap's picture


Your instructions worked like a charm and were easy enough to follow. Once i imported the reg key the services started right up and all my configuration data carried over to the new system perfectly! Thanks!

Just as a side note i did put in a call to tech support and they told me there was no way to fix the issue so you might want to inform your phone agents of this issue :)

Thanks agian.

Nigel Bree's picture

Don't be too hard on the phone guys; the entire fault for this omission is my personal responsibility.

I'm glad that you're able to proceed now and I must offer my apologies for inconveniencing you.

HLCbsgbmm's picture
I tried this when upgrading to version 2.0.
After restarting the Configuration Server I receive three pop-up messages - the first two are identical
First Two: Long paragraphs - the last line reads [Sybase][ODBC Driver][Adaptive Server Anywhere]Column 'DefaultDosTemplateName' not found
Third:Long paragraph - the last line reads 42S22 Sybase ODBC Driver Adaptive Server Anywhere Column UUID not found
Nigel Bree's picture

That error message means that you're running the GSS2 code against an older version of the database, perhaps a GSS1.1 database. The upgrade process to GSS2 has to move the data from your old database to a newer one with additional features, and has a special tool built into it to do that (it's not a piece you can use separately outside of the installer, as far as I'm aware).

If you're moving servers around you need to have the old and new installs be at the same version, so either upgrade the old one before moving, or the new one after moving, and then all should be fine.

jb_nvctr's picture
I followed the instructions listed but I am still getting the  "28000 [Sybase][ODBC Driver][Adaptive Server Anywhere]Invalid User ID or Password" error. I have also tried looking at the database but when I hit test connection it tells me "Database server not found" so I browse to it under the database tab and then try test connection with the same result. I've tried several different times to copy the Database, but the only one that seems to work is the one initially installed on the computer (default) and not the one from the old computer. Both are running same version of ghost.
One computer is Windows XP Pro and one is Windows 2000 Pro.
Ben Evans's picture

I am having the same issue. I have succesfully copied the database file to the new server after stopping the Ghost service, and have successfully exported from the old server and imported to the new server the registry key containing the username and password for the Ghost database. However when restarting the server I get the same invalid username and password error.

The original Ghost Console server was running Windows 2000; the new one is running WIndows Server 2003. Both are running, though they have both had test build 1536 of ngserver.exe installed in order to resolve the problem with apostrophes in usernames.

Ben Evans's picture

Further to my last post, I've done some investigation and thought I'd post my findings.

When exporting the security info to the registry, six values are generated: DAN, DAP, DBA, DBP, AccountName and Password. All six are included in the .reg file when I export the key HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Ghost\NGServer. When I import the .reg file on the 2003 server, all six keys appear in the registry correctly. When I restart the server or run the Console, however, I get the "28000 [Sybase][ODBC Driver][Adaptive Server Anywhere]Invalid user ID or password" error when restarting the database. If I then export the keys from the database on the new server, only the first four - DAN, DAP, DBA and DBP - appear.

Is it deleting the AccountName and Password keys because they've been marked as invalid? Or are they not being read correctly, which is why the invalid message appears? I'm not sure if this issue is confined to Windows Server 2003, though it's the only reason I can think of for it not to work. I have checked the accountname and password and they are definitely correct (or at least, the same as in the source server), and I have already copied the database and certificate files across.

JAC014's picture
What is your procedure for restoring a .db when the old system cannot be booted.  Our ghost server HD has died and we have backups of the .db and keys.  How can we restore from this?  I am getting an invalid userid and password, 28000 msg.  We are attempting to rebuild from the same 8.3 enterprise version. Please let me know.
Romeyn's picture

I am having this same issue.  Here's my story:

Due to a network glitch that's preventing me from Multicasting, I had to blitz a lab intra-switch.  Since my Console's on a bulky desktop, I decided to follow the instructions here to copy my console to a laptop which I could then take to the Lab in order to Ghost it.  This worked flawlessly.

However, now my original Console generates the error described in this thread!  I'm at wits' end, as I don't want to have to re-create this data from scratch!  I have tried everything detailed here multiple times, including exporting everything from the still-working laptop back to the original Console, copying the database and certs, all to no avail.  Tech Support hasn't been able to help me.

I can't BELIEVE A) that this database is "locked" and B) that there are no analysis/repair options available.  Or even Export/Import!!  The really aggravating thing is that I have the information about which I am most concerned already in another data source.  (MAC addresses, Computer Name, Domain, etc.) and could easily export it if only there were some way to import it into GSS.  Does anyone know of a way to do this?  Or have anything else I could try?


jendelui's picture

I am also having this issue with database access moving from Win2000 to Win2003. Have followed the instructions including importing the registry file, but am getting the same error: 28000 [Sybase][ODBC Driver][Adaptive Server Anywhere]Invalid User ID or Password

Nigel Bree's picture

Try using the database backup and restore scripts I have written, which you can get from by registering with a Google account; the scripts have a workaround for a small bug in build 1533 that was stopping the procedure given in the KB article from working, and they are much more convenient in general.