Ghost Solution Suite

Howdy all,

I followed the directions for moving a console to a new server. I'm running Server 2003 on the "Old" server and Server 2003R2 on the new server. The Symantec Ghost Solution Suite is version 1.0 and the Ghost Console is version 8.2.0.1117.
I installed the Suite on the "New" server. I stopped the service on the "old" server and copied the .crt files and SymantecGhost.db files. I stopped the service on the "new" server" and copied the files to it. I also copied the "different" files located under the "All Users" from the old to the new. I restarted the "new" server, and it looks like all the data from the old server is there. The images, tasks, and machines etc. However, none of the machines were connected to the new server. I "pushed" a client from the "new" server to a machine that had an old client on it, restarted the machine and it kept saying it couldn't start the Symantec client service. I had to uninstall the old client from the machine and reinstall the client from the "new" server for it to show up as "connected" in the new server console. That's all well and good, not too much troulble, however, when I cast an image onto the machine from the new server, (using the copied images from the old server), the machine lost communication with the server after the SID change item while it was in the "to client" stage.
I assume this is due to the fact that the images were initially "pulled" using the "old" server so the .crt files are from the old server.
My questions are thus:
Do I have to recreate all the images I have stored for various machines by "pulling" them with the new server?
Is there an easy way to get all the clients to connect to the "New" server without having to uninstall and reinstall the clients?
NOTE: These images have been "pulled" from the machines without sysprep as I use Ghost Walker to remove SIDS during the push to new machines. This due to ongoing problems with sysprep.
The new server says it has 110 machines "known" to it when looking at the Help>About screen but the only machines connected to it are those I have manually unistalled and reinstalled clients to.

Thanks in advance,
Brian MusickMessage was edited by:
Brian Musick

The 3rd time I copied the pubkey.crt and privkey.crt to the new server, some of the clients started showing up. I haven't recovered all of the clients as of yet. However, now when I push an image, the client reports back to the new server and the image process completes normally. I'm not sure why it didn't take the first 2 times. Each time I stopped the ngserver service and restarted after copying the files. Chalk it up to one of those "unkown glitches"! Seems to be working fine now, will let you know if something else comes up.

It sounds like the certificate files didn't some across for some reason; the contents of those files are what matter when the clients and servers get in touch with each other, and pretty much all that reinstalling the clients does for you is copy down the pubkey.crt

As long as both the *.crt files were copied when you moved the servers, the clients should be happy. I'd just double-check the contents of those to ensure that they really did come across properly from the old system.

Nigel,

I show about 1/3 of the clients are connected, the rest show not connected. Images are pushing fine now, so I assume the .crt files copied fine since some of the clients are showing up. I'll check out some of those clients "not connected" this week and see if I can connect to them. Thanks for the reply, I'll let you know what the final outcome is.

Nigel,

I took a look at the pubkey.crt file with notepad. It does have the info from the original server it was copied from, however I noticed something a little peculiar. Apparently (before my time w/ company), the Ghost suite was installed on the original server while it had a different name, then the name of the server was changed. I noticed in the pubkey.crt file that it had that server's "old" name and not the name it currently has.
Question: Can I edit that file and make a change to that portion that shows the "old" name and replace it with the "current" name of the original server?
Would this then show the 2/3 clients I'm missing and drop the 1/3 that I'm currently connected to? OR would I lose connectivity to all?

Thanks,
Brian

Interesting. What should be happening with the client's discovery of the server is that at the same time it tries to authenticate the server using the public key, and it uses the public certificate to do that - the name in the CRT file is primarily there for display purposes.

The name only comes into actual play if you don't have multicasting enabled properly on your network. Not having multicasting sometimes is a conscious decision, but it also often happens to people through oversight - lots of folks don't realise that if they have a Layer-3 switch, they need to enable a thing called an IGMP Querier to generate the IGMP traffic for the switch to "sniff". Without an IGMP querier, switches time out multicast addresses from their tables in about 3 minutes or so.

If the client can't get in touch with the server via multicast, it tries an alternative method using the classic Windows workgroup protocol WINS (which is basically a subset of DNS with an extension to allow broadcasting if no actual server is assigned). In this case, it does try looking for the name in the public certificate.

However, the server tries to deal with this too - if the name of the machine it's on now is different from the one on which it was first installed, it registers both names - it has to do this because of old certificates stored in images and the like. So, things should still be working.

When the client sees that it's working with an old name for the server, it makes a note of the fact and uses that name (because it's mainly used for display). However, if they have to fall back to WINS that's possibly the wrong thing to do in this case because the server always registers the very first name it was ever installed to and not any name in between. So, the first server rename seems to work fine but the second one doesn't, because some of the clients will have current certificates pointing to the second of the three names the server has had.

So, a pretty pickle.

> Can I edit that file and make a change to that portion that shows the "old" name and replace it with the "current" name of the original server?

Not at present (it's a binary file with some delicate stuff) although I could probably write a rename utility for you. What concerns me more is any old certificates that are sitting around lurking in your client images. If the second server name was in use for long enough, probably your images will mostly refer to that and a rename should be fine.

What intrigues me more is whether your network is meant to be multicast-enabled or not, because if it is then the clients should be discovering the server regardless of the names the server machine has. Do you happen to know if your network is using Layer-3 switches and if you have a router configured to act as an IGMP querier? If not, then some multicast operations appear to work because they involve short-lived multicast groups, but the server's discovery group needs to live for a long time.

If you don't know the answer, I can work it out from a packet capture but that's more involved. If there is something up at the low level that is causing the clients to fall back to WINS sooner than they should, it's definitely worth fixing.

Still, writing a rename utility for you (and perhaps also a tool to temporarily register an additional WINS name entry) seems like a good idea. I'll just have to run that past The Management.

Nigel,

I think you are right about the multicast (IGMP) traffic. I have about 50% of the clients back showing connected in the console screen. As I have brought systems back to the office and connected them to the network in the office, they show up, and then stay connected when they return to their original location on the network (other subnet's).

All the imaging tasks are running appropriately. It appears that they may be timing out before they can make a connection to the new server, until I either re-push the client out to them, or they get back to the office network. Either way, they show up and stay connected from that point on.

That being the case, it's easy enough for me to re-push clients out and then cast images as needed. (Most times I pull the systems in to image to avoid any problems should the network go down).

I also agree with NOT changing the name in the pubkey.crt file since the stored images have the original .crt files in them which would cause a problem in finishing the image cast and reconnection.

Thanks for all your help. It appears things are running fine now, so since it isn't "Broken" I'm not going to attempt to "Fix-It". It's easier just to re-push the client and go from there.

If your management decides to write a file that includes a secondary WINS entry, let me know and I'll give it a try. It might be something beneficial to anyone that relocates to a newer server, but for now, I'm fine.

Thanks again and have a MERRY CHRISTMAS!!!

Brian

Ok - how about using the new GSS 2.0 ghost explorer in the old images and remove the old CRT file and replace it with the new server CRT file.

Good suggestion Mark, that will work for GSS2 until I create a more permanent fix (which I'll do, although I want to also re-jig the discovery process more comprehensively in the next version).

I do still want to do something for GSS1.1 customers that doesn't involve mixing and matching pieces of the toolchains.

> If your management decides to write a file that includes a secondary WINS entry, let me know and I'll give it a try.

I'll try and get that done sometime over the next week as I can fit it in, then - management agree it'd be useful; it's just that I did have to ask. I'll post once I have something ready to try.

> Thanks again

Hey, you're welcome - thank YOU for bringing it to my attention so I can improve the design in future.

Mark,

My GSS version says 8.2.0.1117.

I know I can browse and extract files from the images, but I haven't found a way to "insert/import" any files into an image. I had originally thought of trying that when I had problems reconnecting during an image push. I attempted to find a way to import the .crt file, but didn't find it. I assume that capability is only available in a newer version than I'm running.

If there is a way, I'd sure be interested in finding out how. That could make my life simpler when we need to add a new .pcf file for VPN connections etc. Then I wouldn't have to "pull" an entire image from every model to keep my image repository up-to-date.

Brian

You can go here to download a trail version of GSS 2.0 (I think it is 30 days).
http://www.symantec.com/enterprise/products/trialware.jsp?pcid=1025&pvid=865_1
To test to see if it will work for you. The ghost explorer enhancement to modify NTFS images was just added in GSS 2.0.

The version of Ghost you have is 8.2 I think that version is GSS 1.0.

Hmm, y'know I can't remember - even if I did finish it I can't remember what I did with it since it's not where I normally store this kind of thing. I do so much stuff it's hard to keep track of it all; for small things like this I wish I could open-source them and be done with it but being an employee means it's excruciatingly hard to get stuff like that available (except by breaking the rules).

What version do you have? If it's GSS 2.0.1 there might be an alternative process you can use which can change the NETBIOS machine name stored in the pubkey.crt file that the client tries to use, and/or the privkey.crt file which contains the original name that the server had when it was first installed, and that it tries to register in WINS if it's not the same as the current server machine name.

With 2.0.1, you ought to be able to run from a command line something like:

c:\Program Files\Symantec\Ghost> ngserver -ioprint pubkey.crt

and then it should write a file pubkey.crt.txt which is a printable form of the binary data in that file. It mostly won't be meaningful since it's a big bunch of large numbers used in the cryptographic mathematics, but there's a field in there which will be the NetBIOS name of the machine the GSS server was originally installed on.

Similar data is present in both the privkey.crt and pubkey.crt files - the privkey file has some extra fields which need to be kept secret, and the privkey.crt is set to be admin-readable-only for this reason. The clients tend to generate their own pubkey.crt file with the name of the server machine used during client installation, while in the server case if the privkey.crt file has a different name from the machine's current name it also registers that in WINS so that client machines restored from old images can still find the server.

It might be possible for you to edit this data and get it converted back into the binary file format, which would be a more permanent solution (especially with Ghost Explorer, which will let you put an edited pubkey.crt into your old images).