mmarable

Well, all 3 machines are DVI to VGA (using the same make/model adapters). I just don't understand why the "cheap" onboard Intel video works better than the dedicated nVidia board.

Okay, I'm stumped. I have 3 computers, a Shuttle K45, an old Dell Demension and a custom built machine. They are all going through a KVM connected to a Viewsonic 23" LCD. The native resolution of the monitor is 1920x1080. The Shuttle and the old Dell both use on-board Intel graphics chips (a 945 for the Shuttle and a 915 for the Dell). Both of these drive the monitor at the 1920x1080, 32bit color at 60Hz beautifully. The custom machine started with an ATI 3450 that couldn't push it beyond 1680x1050 (32bit color @60Hz) without all sorts of what looks like "interlaced" video that gets worse towards the bottom of the screen. I replaced the ATI card with an nVidia GT240, but it does the same thing. I just don't get it. I'm using the latest drivers. What gives? Am I missing something?

You could very well use a specific set of tasks within you sequence for each model. You would put in logic that uses WMI to determine the model of the hardware and then run particular tasks based on that. A bit complicated, but doable. I would focus on the hardware that does not have the drivers installed correctly for. It could be that the hardware does not have a PNP driver but requires an installation of the software. The process is working, it's just not finding matching drivers for the hardware that it is skipping.

Are you getting any device drivers installed? I tried a quick MDT build using XP-SP2 and it worked for the most part. ZTIDrivers.wsf inventories the PCI IDs of the hardware it finds on the box and the compares that to the driver store in MDT. When it finds a match it copies it to the C:\Drivers (hidden) and updates the DevicePath in the Registry. PNP does the rest. What could trip it up is if the "Inject Drivers" task is disabled in the Task Sequence, or the drivers you have do not match up with the hardware (ie Vista drivers for XP machine). Do you have any drivers installing successfully? Do you have a hidden "Drivers" folder off the root of your C: drive? If so, what is in it? Are the paths found in C:\Drivers listed in the DevicePath key in HKLM\Software\Microsoft\Windows\CurrentVersion?

I'm looking to deploy a couple of Sidebar gadgets that we've developed to our workstations. Is there a way to silently install a Sidebar gadget, or am I going to have to get creative? I was thinking that I could extract the gadget file's contents and then do a simple file copy, but I didn't know if Vista's Sidebar would pick up on them then. I'm imaging a VM to test with, so I thought I'd ask while I wait on ImageX to finish. Thanks

I'm hoping someone might have some ideas here for me to try. A friend of ours bought a laptop from a big chain store. It has the English version of Windows XP (Home Edition I think), but the primary user speaks Spanish as their first language and very little English. Being "the guy who works in IT" they've asked me if there is any way of switching the language over to Spanish. Now, in the corporate world I could just install the Spanish MUI and switch it over, but I'm guessing that the laptop came with XP Home on it. I have not seen the laptop itself yet, but I'm expecting the worst. I don't think that there's much that can be done with the Home version other than buying the Spanish language version and reinstalling. Does anyone have any ideas or options that I can try? Thanks Mike

I'm working on the Vista images to replace the XP builds at work and have run into a bit of a snag (actually, one of many snags but that's a different story). With XP, we have Ghost images of sysprepped installs devoid of all 3rd parth drivers. We boot into WinPE, use Ghost to lay down the image, then we determine what hardware model we are running on. With that info, we copy down the drivers for just that model and then update the DevicePath entry in the Registry and reboot the box. Then, as mini-setup runs all the needed drivers are there for PnP. I've tried this on a custom, sysprepped Vista image but it doesn't work. After all is said and done, the machine isn't using any 3rd party drivers. The DevicePath is correct, and if I open Device Manager and have Vista update the video driver (for example) it'll find the 3rd party driver and install it no problem. If I trigger a PnP enumaration manually then it'll find all the proper 3rd party drivers and switch to them. So, the path is correct, it's just that PnP doesn't appear to be happening. I've been beating my head on my desk trying to find anything about this. I've found all sorts of info about adding drivers at the point of CREATING the image, but not a thing about adding drivers at the time of DEPLOYMENT. I've even picked apart the scripts that Microsoft uses in its Deployment Toolkit, but the script they use does the exact same thing I am, except that it appears to focus only on being used with Setup.exe and installing Vista rather than using ImageX to deploy a sysprepped image. Anyone have any ideas? Thanks

If you're getting a prompt for what version of Office you want to install it doesn't sound like you're working with the Enterprise version. Are you possitive you're starting with the Enterprise release of Office?

I would focus on the replacement Bliss wallpaper and the Winntbbu file, but you cannot rule out the things you're removing. Take things in sections. Try these tests: Addons + New Wallpaper Addons + New Wallpaper + New Winntbbu Addons + New Wallpaper + New Winntbbu + Remove 1 component Try the first combo and see if it works. If it does, move on to the second combo and so on.

The time zone prompt is a known bug in the Windows unattended process. It isn't a problem with nLite, but I just saw that in the nLite FAQ yesterday. If I remember right it has to do with the unattended mode switch being used. What exactly is going wrong with your themes? It's real straight-forward. As for the nVidia drivers, you first need to find out what type of installer they use and then use the automated parameters for that installer. For example, if it's an MSI you would run nvidia.mis /qb (basically). MSFN's Unattended Guide has all the info you'll need. Good luck.

I would look at the addons you may be adding. I was getting the same error except I was using RVM Integrator and a faulty post-SP3 update pack was causing it. Once I took that update pack out everything worked fine. You're best bet would be to start slow. Just get the addons working first, and then start tweaking and removing things. Working in VMWare it's easy to set up a VM session snapshot staged to boot from your ISO image. After you run a test, just revert back to the snapshot. What addons are you using?

We do something similar on our XP builds. You can use REG LOAD to load the Default User's profile and then modify it. Kind of like this: REG LOAD HKU\TEMP "C:\Documents and Settings\Default User\ntuser.dat" (Use the matching path for Vista) You can then make any modifications to the profile. Then unload it and your changes will be kept. REG UNLOAD HKU\TEMP The ".Default" hive in the Registry (KCU\.Default) is not the default user, but the user settings when the system is sitting at the login screen.

So, you're looking to modify the hidden Default User profile. It's going to be tricky. I've only worked with this sort of thing when preparing an image for deploying using something like Ghost, so I have the profile created and easy to modify. Doing this at an unattended installation level is going to be harder. At T-13, I believe that everything done will be incorporated in the Default User profile. I could be wrong though. So, if you have shortcuts or other Start menu changes you may be able to do them here. You mention changing screen savers, wallpaper and homepage. These are all going to be Registry modifications. You could, at first login of Administrator, mount the Default User's profile, make the modifications to the Registry (and any Start Menu or other file changes), dismount the profile and reboot. My post here is all a little crazy I'm sure. I'm just trying to take what I do before I sysprep an image, and work it into an automated install.

Installing in VirtualPC I don't get error messages thrown, but the same messages show up in SetupAPI.log.

I've taken a vanilla XP source, slipstreamed SP2 to start with. You're screen shot has the XPize setup screen, so I'm working from the belief that you used XPize to patch the binaries in i386. I did that as well, and although it did not generate the error during setup, at first login I got a "Device installer error" message: "Windows could not load the installer for Battery. Contact your hardware vendor for assistance." Taking a look at the SetupAPI log, this error jumped out at me: #E364 An unsigned or incorrectly signed file "D:\i386\NOTEPAD.EX_" for driver "Battery" blocked.... The exact wording of the error I recieved at first login shows up several times in SetupAPI, each time it followed this error: #E144 Loading module "C:\Windows\System32\Batt.dll" failed. Error 126: The specified module could not be found. Thing is, Batt.dll was being used to install a device called "Batteries", while the error message is reporting the device being names "Battery" Looks like there may be a problem. I'm going to try it on VirtualPC next.

Removed. Pointless suggestions. I was able to duplicate the problem. So, I'm going to take my foot out of my mouth.

Have you tried it without XPize before you confidently place the blame there?

DRVLOAD should work as well. Just make sure the driver files are accessable by your WinPE media (ie put them in a folder on the media or on a floppy). I don't believe that they'll require a reboot, so they should work just fine.

You can find them on the ISO file in your VMWare program folder. usually: "C:\Program Files\VMware\VMware Workstation". There you will find a file "Windows.iso". You can open it with WinRAR or mount it using virtual CD softare. You can find the drivers here: "\program files\VMware\VMware Tools\Drivers\vmxnet\win2k" Just use PEIMG to add the drivers to you WIM file and you'll be all set.

No, you have to make the move to WDS to deploy Vista.

Sure, you're basically going to take what you have and reverse the process. You can boot from the WinPE CD you've already created, partition and format your hard drive, and then use ImageX to apply your WIM file or files. The WinPE Users Guide had details on how to do this in the "Imaging Tools and Reference" section. This is included in the Windows Automated Installatio Kit (the WAIK). To do this from all one DVD, you'll have to recreate a new WinPE ISO, but add your WIM file to the "ISO" folder before you create the ISO (unless you just want to pull it from another machine over the network). You can script this, jazz it up with HTAs or just manually type in the commands.

You shouldn't have to reboot to apply a theme. They apply "on the fly". If you have to reboot, it sounds like maybe the Themes service isn't running initially. I'm guessing though. What happens when you select and apply the Luna theme manually? Do you get any sort of error or other message?

It sounds like your format and reinstall didn't go as you had intended. You're Boot.ini appears to be showing you both the original install (on one of the hard drives) as well as your new installation (on the other hard drive). From your description, that's what it appears to be.

No, you'll only use the SIF file to set up the first autologin and first script. Towards the end of the first script you'll do 3 things. First, modify the Registry keys to set up the second autologin. See the section "Auto-Logon" here: MSFN' Unattended Windows: Adding Users Second, set the Registry key for the second RunOnceEx See here: MSFN's Unattended Windows: RunOnceEx Third, reboot the box. The box will reboot, putting the new computer name into play. The autologin will then log in and execute your second script to join the domain, etc. You can do this over and over again. In our case, the second script joins the domain and does other domain work, then sets things up for a third script. This way our GPOs are in play when we script the install of software and such in that third pass.

Yes, we do a similar thing here. We image our machines, a first script renames it (among other things), it reboots to kick the new name into play and a second script joins it to the domain.j At end of the first script, we set the auto login to use a local admin account and then repopulate the Run key in the Registry so that the second script executes after the reboot.