Video Screencast Help

Direct image create for server in subnet

Created: 29 May 2006 • Updated: 21 May 2010 | 3 comments

my requirements:
GSS-Server should start a schedule job (create image) but the ghost client create the image direct to the share at the local fileserver.

the GSS-Server should only initialized the image create (copy and start the virtual ghost disk)

correct proceeding for my requirement?

our infrastructure:
1. Subnet
Server1,Server2,Server3,GSS-Server(Ghost Solution Suite),FileServer1 (for Ghost Images)

2. Subnet
Server4,Server5,FileServer2 (for Ghost Images)

3. Subnet
Server6,FileServer3 (for Ghost Images)

Subnet 2 is connected 10Mbit to Subnet 1
Subnet 3 is connected 2Mbit to Subnet 1

GSS-Server (ins Subnet 1) start image create job for Server6 (Subnet 3)
Server6 should create the image on FileServer3 (Subnet 3)
no trafic between GSS-Server and Server6 (only 2Mbit connection)

sorry about my english

Discussion Filed Under:

Comments 3 CommentsJump to latest comment

Nigel Bree's picture

With GSS 1.1 this is not a configuration we can support directly in the console. We do have some experimental tools which relate to possible solutions, but each addresses a different solution to the problem (and each has subtle restrictions). Which might apply - if any - depends a lot on some other questions about your network and what you want to do with GSS.

- Are the 2Mbit-connected subnets on a physically remote site? For instance, is the connection a broadband WAN link of some kind - Frame Relay, DSL or something like that? If it's a WAN link, is it firewalled, or are you using some form of tunneling?

- Do your subnets have multicast connectivity between them? This depends on what router you use to connect them, and how it is configured. The issue here isn't bulk imaging traffic, but the control traffic between the subnets.

- What operating system are your client machines using? This determines whether using Windows PE is a possibility.

- What images are you going to be deploying to the client machines in the subnets, and where are they prepared? If you mainly intend to use GSS for sending out preprepared images, how do you plan to get the prepared images out to the remote subnets?

Ronald Obermayr's picture

Is it possible to start the virtual ghost disk with parameters (image name and server share where the image can be create) ?

The GSS-Server should only start scheduled copy virtual ghost disk to server
This virtual ghost disk should start the image creating from local to network share (fileserver in same subnet)

At this time we start manually an "ip dos disc" and ghost.exe from a network share - I only want to do this scheduled (one time per month) and automatically for server system disk.

Our subnets for example the 2Mbit connection is an ethernet over fiberoptic link (~20 km) from our "electricity provider" between 2 cisco routers with qos for voip

The operating system from the servers(=client machines) are W2k and W2k3

We only want to create server systemdisk images and no deployment (only manually with my ip ghost disc for disaster recovery and this is time critical, so we need to restore the clone in the local subnet - performance)

Nigel Bree's picture

The main issue with this in existing Ghost is that the Lan Manager code for DOS does not play well with others. In order to get mapped network drives over TCP/IP you have to use the Lan Manager TCP stack, and it wants to be in change. That's why at present you can have either a Multicast boot disk or a mapped network boot disk, but not both. In GSS1.1 since the management client has its own TCP stack like Ghost, it can't use mapped network drives.

Now, one of the clever guys here has worked out a way around this, and so we're trying to overcome this limitation for GSS 2.0. Mostly we'd been thinking about this in terms of the Ghost Boot Wizard, but your situation shows that it'd be really useful for the Virtual Partition as well. So, we're going to try to get this into the next version.

Still, that does leave you stuck for now. One possible way to deal with this in GSS1.1 is to use the Virtual Floppy system to replace the existing physical boot disk. If you can create an executable to set up the virtual floppy and restart the machine, you should be able to schedule it using the Windows task scheduler. This won't give you as much debug tracing and central manageability as running it through the GSS console, but it will at least be able to be automated.