Video Screencast Help

Ghost clients connect but incorrectly show old server name after Ghost Console migration

Created: 24 Mar 2011 | 5 comments

Hi guys,

We have migrated our GSS 2.5.1 server from Win Server 2003 32bit across to a new Win Server 2008r2 64 bit machine.

Process for the most part seemed to go pretty smooth, after following the migration documentation from Symantec :)

The old server is decomissioned and we are running off the new one successfully, we are able to see all existing clients which is great - image tasks work as normal.

There is just a tiny issue i would love to get resolved. The Ghost clients installed on user machines are connecting fine to the new server "ISUTIL" but

If you hover the mouse over the ghost sys tray icon it states that it is succesfully connected to "ISAPPS" however, which is the decomissioned ghost server. The IP address displayed is that of the new server.

I exported the ghost database, privkey.crt and pubkey.crt from the old server and imported to the new one - and would not be surprised that is where the issue lies. But how do i go about creating a new privkey and matching pubkey with the new servers details?

I realise a deployment of the pubkey to the clients would be required afterwards but thats not an issue.

I have run nbtstat -a against the new server ISUTIL and indeed there is an entry there with the name ISAPPS  <2D>  UNIQUE  Registered

Any insight would be fantastic.

Kind regards,


Comments 5 CommentsJump to latest comment

Nigel Bree's picture

You DO NOT need to create a new keypair (despite some clueless Technical Support people claiming otherwise, despite my numerous explanations to the contrary over the years). Since Connect's search is so broken, it's probably time to reiterate how all this works once again.

The first thing is that the keypair not only establishes the security of the connection between client and server (as the clients perform a challenge-response verification of the server's private key as part of discovery) but as well the hash of the public key is also the primary name of the server. In any properly configured network, both the server discovery and the challenge-response verification are done with a single multicast packet, and **at no point does a server's name matter at all**. This mechanism was designed by me for the first release of the management system in 1999 and remains the primary one.

Much later, I added a fallback system for people with incorrectly configured networks that did not support IP multicast. Since customers without working multicast often didn't have any alternative service that we could rely on either, the fallback protocol with the highest probability of working at the time was NetBIOS, and so additional data was added to the server and client certificates to embed the server's NetBIOS name and to allow matching up that way (this design was also picked up by Ghost and the GhostCast server to perform matchmaking for manual sessions on non-multicast-capable networks).

[ Note that this fallback is used only to get a potential IP for the server; the challenge-response iteraction to prove the server's identity still takes place, it's just done in separate exchange over unicast instead. ]

The problem with using names for this - and why I consciously chose the primary design to not need them - was the problem of server moves. This problem is even harder when you realise that thanks to Ghost winding back client machines in time, when a server is moved then the old name is embedded in every single client image. To cope with this, when the server machine's name changed I made the server still recall its original machine names and the server continues to register itself under the NetBIOS name used when it was first created, thus allowing older clients to continue to be able to contact it.

At some point - probably around GSS 2.0, from memory - I made the DNS name of the server (as embedded in the PUBKEY.CRT file along with the NetBIOS name) visible to end users in the notification applet. Unfortunately, by making the embedded names visible, a lot of GSS users took this as a basis to assume that the names were what the system actually used behind the scenes, leading to some confusion (including the aforementioned incorrect advice promulgated by Technical Support) about how server moves work.

So the next iteration of this was to ensure that, as part of the normal client upgrade processing done whenever a task is run against a client, the clients were explicitly sent a new PUBKEY.KEY file from the server if it had changed. So what should be happening in GSS 2.5 is that when the server detects its machine has been renamed it will generate an updated PUBKEY.CRT, and then as tasks are run against clients that updated certificate will be sent out - the new certificate won't take effect immediately but it will be read the next time the management client starts.

This means that over time (exactly how long depending on the frequency with which tasks are run, machines reboot and how long the machine images with old certificates stay in active use) the clients should converge on displaying the new server name. This also helps with a corner case in the old scheme, of how many old NetBIOS names to retain on the server to cope with multiple renames.

Roger Schroder's picture

Thanks Nigel,

Excellent explanation :).

In short - clients are successfully connecting to our single ghost console freshly installed on a new server with a new server name.

Clients are incorrectly displaying the old server name but function as normal still.

We are to expect over time, that machines will update the pubkey.crt with the new and correct server name as tasks are performed and the localised ghost image on clients are overwritten.

Im imaging up some brand new machines now to test.

Nigel Bree's picture

It's possible my memory of this isn't quite correct, given how many versions I had to work on concurrently, so it's possible that some of the auto-updating of the certificate data was something I'd done for GSS 3.0 before development was shut down.

[ GSS 3.0 was adding certificates for the clients as well, to enable tasks to verify their identity, along with also adding support for a full Diffie-Hellman key exchange. This enabled not just link encryption, but more importantly that the clients could be trusted to receive sensitive data such as administrative credential sets- that's a feature that was one of the explicit design elements in my choice of the certificate design; the fact it took 10 whole years to be allowed to implement a feature that I'd planned for even before the first release should tell you a lot about our funding and staffing levels. ]

So, just in case that work never did make it into a release you can verify what's in the certificates using the "-ioprint" switch.

Here is an earlier discussion from the GSS 2.0 era which outlines that switch; in GSS 2.5 there definitely was a separate field in the certificate which provided the server machine's DNS machine name for display purposes, and it was also GSS 2.5 where I added a lot of file replication checks to the standard upgrade preamble for task execution to copy across various executables and files like PUBKEY.CRT to make sure this happened as I described above.

The part I'm now not completely sure about is the server automatically re-generating a new PUBKEY.CRT for itself. There are all kinds of circumstances where the server does do that - if the file is invalid or missing, for instance - but it may be that doing it on name change wasn't automatic in the released code line. Using the -ioprint switch you can easily verify whether that's the case or not.

ICHCB's picture

A round of thumbs up for Nigel.   Thanks Nigel.

If you find this post helpful please give it a thumbs up!
If you find that this solves your problem please mark it as the solution!