Is there a way to get around Ghost's OOBE sysprep switch in Vista?

[Migration User]

I'm creating a new Vista image that I'd like to run sysprep on via a Ghost task. I have a fairly meaty, good working xml file & a large number of drivers for a few Dell models. Currently I update the non-sysprep'd version of the image, make sure everything is in order, then I manually run a bat script that calls sysprep, throws a few switches, and feeds it the answer file. I run the bat script every time so that I consistently run sysprep with the same switches and don't leave something out.

 

What I usually end up doing is booting the computer back up into BartPE, then capturing the drive via Ghost32.exe, and storing the image on the server. A task on the server is then responsible for cloning the image back to whatever computer is in the target group.

 

The full sysprep command I use is:

%systemdrive%\Windows\System32\sysprep\sysprep.exe /audit /generalize /quiet /unattend:%systemdrive%\<folder>\sysprep\sysprep.xml

where <folder> is the name of the department I'm in...

 

So, what I want to do is to forgo running the bat script and just run a create task that includes running sysprep. The problem is that my sysprep command relies on /audit, and sysprep via Ghost runs /oobe . This destroys /audit . So my question, at last, is this - Is there any way to get around /oobe when it's initiated by Ghost?

 

I came across this topic:

 

https://forums.symantec.com/syment/board/message?board.id=109&message.id=4054 

 

which echoes the same problem. Any help is greatly appreciated. 

Message Edited by Luman on 10-08-2008 11:53 AM

[Migration User]

you have a bad link

[Migration User]

https://forums.symantec.com/syment/board/message?board.id=109&message.id=4054

 

try that. 

[Migration User]

Hi Luman,

 

Thanks for bring this in here.  I can't think another better way to do this.  Although Sysprep does allow you to run audit mode after executed oobe pass, but it will end up go through the oobe pass twice (oobe pass -> audit system pass -> audit user pass -> oobe pass).  When running the second time OOBE pass, the oobe pass settings in the answer file will become unavailable as it has been used in the first oobe pass and has "true" tag.

 

I believe this is something that GSS should consider in the future releases.

 

Just curiously, what Dell models do you use?

 

Thanks,

Jenny

[Migration User]

I have drivers lined up for Optiplex GX280's, GX620's, 745's, 755's, Latitude D630's and M1330's. I'm working on getting drivers in place for Bootcamp - i.e. all of Apple's Macs, sans the XServe.

 

I cannot stress how much different Vista's sysprep is to XP's. It's a point that I do not think follows through to how Ghost handles XP versus Vista. It can be customized to such a higher degree that I really think Symantec should do away with automatically invoking certain switches for Sysprep under Vista.

 

It would be fitting if there were check boxes for each different switch, and a corresponding text field box for each switch that was checked - for instance if someone checks "unattend", then there's an option to use either a Sysprep config stored in Ghost or to manually type in a path. If someone checks off 5 boxes, Ghost would be smart enough to know what order those must be followed in. If Symantec can get to that level of customization while still having it in the GUI, I think you'll get a balance between the more GUI-oriented users, and the diehard code monkey types.

 

In other news, I did figure out a way around all this. It's somewhat of a compromise. Before, again, I was running this:

 

%systemdrive%\Windows\System32\sysprep\sysprep.exe /audit /generalize /quiet /unattend:%systemdrive%\<folder>\sysprep\sysprep.xml

 

 Now, however, I'm running this:

 

%systemdrive%\Windows\System32\sysprep\sysprep.exe /audit /generalize /quiet /quit /unattend:%systemdrive%\<folder>\sysprep\sysprep.xml

 

If I throw the /quit switch, Sysprep just simply stops once it's done processing everything while I'm logged in. The next restart would start WinPE / Setup / etc of course, but now this leaves me with a running system.

 

I found that I had to change the client's Virtual Partition PreOS to PCDOS once I've done this. If I leave it at WinPE, Ghost is unable to update the client files, namely unattend.xml, on the server. It makes sense somewhat - Ghost is trying to get a clue about the client and it can't since I've just run sysprep. However the PCDOS client is so simple, Ghost doesn't care.

 

I'm able to launch, even from the client, a create image task once I've run that bat script up above. The image has been created successfully three times now. Once the image has been created, I can switch the client's Virtual Partition PreOS back to WinPE. So while I can't get Ghost to run sysprep the way I'd like, I think I'm about as close to zen as I'm going to get with the current version.

 

Oh, and btw I'm running GSS 2.5, build 2113, running on an '03 server.

Message Edited by Luman on 10-10-2008 06:11 AM

[Migration User]

Hi Luman,

 

Thanks very much for the updates. These information are really help us to know the real scenarios and how our customers use the GSS. That will definitely help us to improve the features of product as well as the user abilities.

 

We have released GSS 2.5 LiveUpdate 2. But it does not have any changes in the area that we’ve discussed in this thread. Please ref https://forums.symantec.com/syment/board/message?board.id=109&thread.id=16038 for the major fixes. You can update your console via menu help->LiveUpdate. Then run refresh task to upgrade all clients.

 

Thanks,

Jenny