Ghost Solution Suite

Does anyone know if it is possible to push a package with cached logon info saved? I would like the logon cache saved so we don't have to log on to laptops that will be out of our domain. Let me know. Thanks.

I'm not even sure I understand the question.  By package, do you mean an application package? Or do you mean an operating system image?  What O/S ?  What exactly are you trying to achieve?

First of all though, can we establish that this is a question about Ghost Solution Suite, and if so, which version you have?

When I push an image to a laptop using symantec ghost solution suite 11.5.1, I cannot figure out a way to make the logon cache information to stay cached. I would like to create a profile, let's say test profile, and have the image replicate that the machine has logged in.

When people take the laptops out, they use the test profile account to log on. They are not able to log on outside of our domain without the logon information cached. Therefore, they or I have to log on to the machine before they leave the building. I was just seeing if anyone knew if it was possible to have the image retain that cached logon info. I know it sounds knitpicky but when I have to logon to all 600 imaged laptops it seems worth the question.

Are your images sysprepped before deployment?  Would it not be possible to automate a post imaging process where the machine is automatically rebooted and then automatically logs onto the network using a predefined test account set up in the "Autologon" registry keys (I am thinking XP here in the absence of any O/S information) - this is a standard feature where you can also specify the number of autologons before the operating system reverts to normal operation without you needing to do anything else.

I have not been using sysprep. I will definitely think about it if this is an option. Our laptops are now all windows 7 64 bit but there is some value to having our desktops "autologon" as well. I will look into this and give it a try. 

Can I set that info on the image itself and then send a task to have the machine reboot? Or will that registry info be reset by the imaging process?

I was also trying to figure out how to create a batch file that logs in with a certain account and run it through ghost.

There is a lot that you can do with a "build" process, and a bit of research with Google will no doubt fill in any gaps in your knowledge. For example, this Microsoft KB describes how you can control the number of times the autologon process will run before resetting itself back to normal logon:

http://support.microsoft.com/kb/221477

You need to set a default username and password, but this technique is ideal in automated build processes, as you can set up something in the HKLM RUNONCE key of the registry which will start a process next time the machine boots, using autologon parameters you have set. Your process can then put another entry in the RUNONCE key before rebooting the workstation, and another autologon process can then run yet another configuration process for you, before once again rebooting the workstation.

So you can have operations completed such as machine customisations, domain joining, installing management clients, defragging the hard disk - in fact whatever you need that cannot be incorporated in the base build for some reason.

In one of my past projects, we needed a single build that would support around 20 different desktop and laptop machines, and of course, each laptop had a long list of different utilities that were model specific, which therefore had to be installed after the image had been deployed to the PC. WMI was used to detect the exact model, and then a control program installed all required programs and utilities for that model, rebooted the machine, then completed tasks such as renaming the machine to its final computername, joining the domain, then removing the install account.  As all the models we used supported asset tagging, we would code the machine name into the asset tag and read that during the post imaging processes, so no manual configuration was ever required.

Microsoft's Windows Automated Installation Kit and the MDT provide many of the tools to simplify build engineering, but there is always scope for additional fine tuning to meet individual requirements.

I will test it out this week. Thanks a bunch.