Mordac85

That's because you're actually booting off the CD. I'd recommend starting over and completely deleting the existing system partition before selecting it for the install. That way you'll ensure the MBR is copied and bootable.

Thanks for the ref, I'll check it out. I haven't had time to even install the Vista beta yet so it may be relased by the time I get around to it. I understand they're using a different method for unattended installs. So much to do, so little time.....

It shouldn't require quotes unless there is a sapce somewhere in the path. But then again, it doesn't hurt either.

I knew about the various HAL's being used to create hal.dll, but I never thought they did the same thing for the kernel. Are there any references, that you know of off the top of your head, for which one is used in a particular instance? So we'd have to include placing the correct kernel as well as the HAL? Doesn't seem like a major deal, unless there are other supporting files that follow the same concept. Thanks for the tip. I think the premise of making this switch via a script, or coded utility, is possible. Granted MS won't touch it, but I never bother with that avenue anyway cause it usually takes way too long to get a resolution. I think I have enough to get started, now I just need to find the bandwidth.

@Kelsenellenelvian From what I see in your post he just needs to escape the quotes, correct? like this: ...jre-1_5_0_07-windows-i586-p.exe /s /v\"/qn... and ...C:\jre.log\"" /f Or did I miss something else?

Yes it can. And you can also kill the periodic update function.

How about using the AutoAdminLogon key? You could have a script setup the Winlogon key and config a second script to run the moveuser routine via RunOnce. The end user runs the script which copies in files and sets up the reg keys Reboots and auto logs in under the local admin account Runs a script calling the util and can either shutdown or reboot Course the trick will be keeping the user's from killing something or trying to 'just check something' during the process.

You need to clear the existing partitions first, either by fdisk or something like Ghost's gdisk utility. To my knowledge an unattended install does not have the ability to wipe the drive but can only create partitions.

What do you mean extract all kernels? I thought there was only one so could you be more specific? And I take it the Longhorn Beta 2 that's out there now won't cut it, right? This is really an interesting topic for me. I know there are several commercial solutions out there, but I can't see paying the money for something that can be done just as easily w/a script or utility. Plus, I'm always intrigued by finding out how it works under the hood.

I started a new topic for discussion of adapting the P2V process here.

This is a topic split from another thread. In that thread, nivlacckw brought up a novel idea to adapt a physical to virtual (P2V) process to alter the HAL and add mass storage drivers to a system after an image has been laid down, but before mini-setup runs. The page he referenced is the Ultimate-P2V (http://www.rtfm-ed.co.uk/?page_id=174). On the site, there is a reference to Notorious_bdg’s “HAL_Update” script (http://www.rtfm-ed.co.uk/downloads/HAL_Update.txt) which seems to detect and change the HAL using devcon. This only appears to be written for 4 HAL's but either the script could be completed to cover all of them or, depending on the licensing, the devcon source could be altered to create a utility that provides only this very defined function. Maybe it could also include a function to detect the mass storage controller and pull from a predefined driver folder to inject the correct drivers as well as updating the HAL? He's making a similar inquiry on the BartPE forums. So I just wanted to see if anyone can see problems with this process or does it seem to be a valid use of devcon? If you boot from a PE CD and make these types of changes will there be any problems when you boot?

I was checking these links out and I think he's talking about changing the HAL with devcon. He's also suggesting adapting the physical to virtual (P2V) change of Mass storage drivers for a newly imaged system instead of a virtual one. So it adds an extra CD change/boot step to the system build process, but it may be worth it in the long run. Pretty novel way of creating your own UIU process, if it doesn't have any latent issues/limitations. Looks like I have more testing to do!

That's exactly what I was trying to illustrate. And you're always going to have those apps that don't handle imaging very well. Scripting the install of a few apps after an image is a small price to pay for the speed you gain over a fully unattended build, imho.

True, but at least on a car you can find the oil drain. I hate having to play Sherlock Holmes all the time to figure out what crap is floating around that I don't need.

The only references I could find were basically one liners admonishing folks to not use Ghost. The closest one is Corporate Soe, but even though it's more detailed, like his post above, it provides no details or specifics. I'll stick w/my hunch that he ran into issues trying to do too much within the image, instead of leaving it for GuiRunOnce or RunOnceEx, and got burned and/or frustrated with the limitations of an image. @molman Always keep in mind that the image must be generic and anything that would be configured on a per user or per HW type may cause issues. Drivers and the HAL are easy enough to handle. The SID, and other machine identification items are wiped by sysprep. Let me use TrendMicro AV as an example of the tricky issues you can run into. Using their corporate edition the client is installed, and periodically updated, from a designated server. The problem you run into is your image master (and any other client) is installed w/an identifying GUID on the Trend server. So 1,000 PC's w/the same GUID means only 1 will get the update (Hobson's choice too), remember the base is generic. Never fear, the vendors are aware of their shortcomings and, in this instance, provide a utility to run after the imaged system is online that resets it's GUID. Et Voilà! New system created from your master image w/AV already installed. QED, b/c I've already lost several hair follicles figuring that one out. But that's why these forums are so great. If there is no current solution, you move that to a GuiRunOnce/RunOnceEx item for your post configs. The hard part is not the OS, it's the customizations and other apps that cause most of the grief, at least for me.

While your post could be considered very inflaming and offensive, I pay it no heed b/c I think you did so only due to your own past experiences and aggravation over the problems you encountered. If not, I'll just assume you are strongly expressing your own heavily biased opinion, are welcome to do so. No one is forced to agree, but you can voice it. That's the beauty of the forum, molman can benefit from all the points brought out. However, common courtesy would ask that you refrain from the derogatory labels and speculation concerning other member’s abilities and motives where you have little or nothing upon which to base it. It’s immature and counter-productive. I'm not an amateur but support a corporate business unit environment of ~8500 systems that is part of a much larger global conglomerate. But I know there is always something else to learn or see in a new light, that's why I 'm here. Since Ghost first came out in '96, I'm assuming you've been and admin for 15 years rather than working on deployments for that long. I'll agree that Ghost is not a panacea, but it is a very good tool if used properly. Some things should not be part of the master image but customized after the image is in place and maybe that is the thrust of your point, once you filter out the nonsense. For a basic vanilla install and app deployment, what I recommended is the prudent choice. Granted, there may be situations that may preclude them from being a part of the image. Like I said, imaging is not an end-all-be-all solution, and the best way to build a system is w/an unattended install. In my opinion, it's just not a practical soultion in this instance. Everything has limitations and given his situation, I believe imaging is his best course of action. However, the topic question was how to get started w/little time to prepare. Not knowing what apps he has to include that may not have been mentioned, I would always recommend imaging over an unattended install simply b/c of the time differences. I am intrigued by your statement: In these instances, how did you verify that it was the image that caused the problems and not the process of applying the image to the system, or an event that occurred afterwards? There have been times that I strongly suspected an image had problems from the get go, but not that the image itself was faulty. That is not something that I have found can easily be proved. How did you do it? In the end, molman needs to decide which route to take that fits his environment, timeline and expertise level. And, if needed, I'm sure the forum members will assist him with whatever problems he will run into. That's will, not may, b/c we all realize that no one knows it all.

Not a problem, but we need to get hopping. You'll need the following up front to start development: A sample of each unit that may require a discrete HAL (Desktop, Workstation, etc) Ghost 8.0 Corporate at a minimum (Ghost Solution Center is probably overkill, but may be Symantec's only current offering) Server space to stage the images, drivers and user data backups Start w/a vanilla build of WXP w/SP2 & current hotfixes slipstreamed. Note the HAL and install your apps and other tweaks. Customize the default user profile and set any local policies as well. Consider your post install needs and script your GuiRunOnce or RunOnceEx to take care of it. Copy in your sysprep dir and setup your INF for your environment, run sysprep and image it. Now have someone else test your image to make sure it runs how you want while you move onto the next HW type. Try using the initial HAL type image for other platforms to save development time. The single image can cover a variety of system models if you can include the various drivers you'll need. Considering your time constraint a master unattended install would be nice, and a cleaner solution. However, scripting the unattended app installs may eat up more time than you have and, as IcemanND pointed out, will extend the rebuild time. Dropping an image only takes a few minutes whether pulling from a network share or a CD/DVD. Also, it will help your deployment if you have a standardized script/process for backing off user data. If you have any non-std apps that a few users will need, identify them up front so you know what you're walking into. The only major problem you will run into, beside drivers which can still be corrected later, is the HAL. Screw that up and you'll get a BSOD. Feel free to PM me for specific questions. I maintain our SOE's so I know what you're facing. Don't underestimate the time required to complete this either.

FYI and slightly OT: If you use Process Explorer and see a handle on a directory or file from winlogon and nothing seems to be using it, that's WFP monitoring it.

Like m3n70r asked, do you have the OS firewall on or are you behind a firewall that would block the request?

No problem, glad to help. Now migrating to Active Directory, that was tough.

about 20 CD's, 1674 MP3's (at last count) and i don't even know how many LP's, 45's & cassettes.

It's from Dilbert, Mordac is the Preventer of Information Services. It was given to me when I was working as a security admin and tightening up our group policy. (I was such a popular guy) Since the name's usually taken I added a numeric suffix.

43, married 21 years with 4 wonderful kids and apparently in the minority. But I'm loving every minute of it!

After checking out that link, you've got to be kidding me!

Outlook 2003 @home and work. I'd never find anything if I didn't have all my rules filtering out the non-essential stuff.