dandirk

I thought /audit put windows in audit mode at next boot? Also assume this is when the 2 audit passes are run... From: http://technet.microsoft.com/en-us/library/cc766514(WS.10).aspx "To apply the settings in auditSystem and auditUser, you must boot to Audit mode by using the sysprep/audit command.". I highly doubt I need to automate anything in the audit passes, just read that audit mode is required to do profile edits and add apps. Is this not the case? Could I just enable to admin account, login, install apps, updates etc then run sysprep /generalize /oobe and have my xml copy profile set? I also found a similar process HERE, where they run audit mode right away after install by using ctrl+shift+f3 in step 9. As of right now I don't want to boot to audit when I image PC, just when configuring the image (before image is taken). Am I off base here?

I am using guides on the internet to setup a unattended.xml for use with sysrep. These are great but I really like understanding the process a bit better then just following steps blindly... Currently we install XP, add drivers, apps, config etc then sysprep with mini setup option. Would sort of like to mimic this procedure. We do not have an imaging server etc, we image with ghost, and let mini-setup install drivers, name etc for a fresh PC/config. Been reading up on the AIK and XML passes. Microsoft's description here is what I am basing this process on... This is how I understand my use of sysprep and the unattended.xml process. Please let me know if I an wrong or off base. 1. Install Win7 on reference PC or VM. (install unattended.xml in sysprep folder if needed for audit modes) 2. Run "sysprep.exe /audit" to reboot to audit mode (this will activate the admin account, and run the 2 audit sections of the AIK IF I need them). 3 In audit mode (administrator account), add software, copy drivers folder to %windows%\inf, windows updates, GUI changes etc 4. Run sysprep.exe \generalize \oobe \shutdown \unattend:XXX.xml 5. Take ghost image. 6. Reboot and the mini-setup like will run and go through Generalize, Specialize, and OOBE passes at next boot, NOT running offline and PE????? I will have to tackle the joindomain issue, but I figure I will do that later, when I have everythings else working. I know there are bugs and issues with joindomain. I just want to understand which passes are being used so I can edit/test accordingly. Thank you for your time.

cool thanks - just like mdt...

Question about using DISM to inject out of box drivers for Win7. With XP/sysprep I just copied drivers to the computer and appended hklm\software\microsoft\windows\currentversion DevicePath key with each driver folder. Worked great for pnp drivers even printers etc. Driver Injection with XP had issues with drivers that had the same file names but were distinctly different (inf, sys etc were the same name but different HWids/versions etc). Does injecting with DISM have similar issues with multiple versions of the same driver? I am still playing around with all the robust tools for win7 (nth degree of complexity vs xp lol)... the MDT tool does seem to seperate drivers into individual folders, but I don't think mdt is intended for our needs (single universal image file to be deployed locally aka ghost image) Thanks

Well not really how to slipstream drivers (got that covered:)) But I figured you guys will probably know more so the general XP forums... Running into small quirks with intel graphics drivers after unattended install. Basically it comes down to configuring settings (like display clone, single display etc). Before I start reg monitoring, wondering if you gurus deal with graphics drivers configs. Does instal have some sort of admin profiles or something... Ran some google and didn't find much...

I know this is a really old post but it was helpful to me... The last poster is correct the StartButtonBalloonTip = 2 works for that annoying "Click on the Start Menu..." large Balloon that pops up on new installs/syspreped installs. It will only go away if you click on the start menu while the balloon is up. Not sure about the above notes regarding the runonce locations etc. I used a different approach. I deleted the key from HKCU and then ADDED it to HKLM so it would affect all users... Testing whether the change will hold through sysprep...

Like this?: http://www.guidebookgallery.org/pics/gui/s.../win2000pro.png Honestly I am not sure... About the title of the tweaks you found or how to get win2000 search exactly. I generally use reg monitors to find my reg settings, its generally faster then searching the net. I also can see what other changes are being make (HKLM vs HKCU etc) The XP advanced search screen is pretty darn close to the old Win2k version, so sorry I didn't look any further... EDIT OK I looked and tested the "Use Search Asst" reg and it does work, and provides the search window that I linked to above. Only this one key is needed for the classic search... It didn't work the first time I tried but I am chalking that up to a spelling error. I installed tweakui and performed the change, regmon only recorded that 1 key. I removed tweakui and retested to confirm. My testing wasn't of the caliber I usually test, I did not reimage. I ran and removed the tweak with tweakui before running regmon, so maybe there is another key that is required for this to work. I just did this quick and dirty at home. If this is not working for you, could it be a gpo conflict? I don't know just shooting in the dark

Try this to get rid of the dog and to enable advanced search by default. Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Search Assistant] "UseAdvancedSearchAlways"=dword:00000001 REM Sets the option to always use the advanced files and folder search config 0 = Disable 1 = Enable "SocialUI"=dword:00000000 REM - Sets the option to use the search assistant (dog) 0 = Disable 1 = Enable

Possibly in this extreme case... Maybe people didn't know how to edit the registry. Maybe people know how but would rather purchase an easy and fast tool to do it for them? There are many tweak applications out there that charge a fee yet do not provide a magic tweak but rather a collection of reg/script tweaks that are easy to set/unset? I can tell you if I had to do 20 tweaks, I would pay for a tool to do it.

There are many reasons people would want to do this... presetup for end users via image or script are just 2... This is the reg I use to enable the advanced search... Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Search Assistant] "UseAdvancedSearchAlways"=dword:00000001 REM Sets the option to always use the advanced files and folder search config 0 = Disable 1 = Enable "SocialUI"=dword:00000000 REM - Sets the option to use the search assistant (dog) 0 = Disable 1 = Enable

I assume you are using sysprep???? sysprep version before SP3 automatically copies the Administrator profile to the default users profile for you. The SP3 version of sysprep doesn't unless you use the UpdateServerProfileDirectory=1 line in sysprep.ini. If you are using the pre-SP3 version and DON'T want it to copy the admin profile to default users, then you will have to install a MS patch (sorry can't remember it). Then you can create another profile from scratch and copy it over to the default profile... No you don't need to create the default profile from administrator, just remember to create/add any shortcuts to the start menu from the profile you will be using. The only reason in my opinion that you wouldn't use the administrator acct to create a default profile would be if you want special shortcuts for local administration and troubleshooting. If you don't need this, just use the admin profile.

HAL issues are becoming less and less of an issue if you have a fairly modern environment (4-5 years life cycle). Having sysprep switch between ACPI Multi and ACPI Uni processor HALs is fairly simple I have found. If you have non-acpi HAL machines then yes hal issues will be tougher for a single universal image. We have a 4 year life cycle on our PC/laptops. Currently all 12 models we support are ACPI, most run Multiprocessor HALs. We have 1 Uniprocessor HAL machine (our oldest supported laptop model HP NC6220). For our image, I create the master image on our oldest desktop PC, which happens to be Multiprocessor. To support the uniprocessor laptop, I added the following line to the Unattended section of my sysprep.ini file. This command will check to see if the PC requires a uniprocessor HAL, if it does it will install. If it doesn't it will leave the Multiprocessor HAL. I have also read reports that this command automatically installs the uniprocessor HAL and windows itself re-updates it to Multi if needed. Either way this is working for MY companies situation. [unattended] ... ... ... UpdateUPHAL="ACPIAPIC_UP,%windir%\inf\hal.inf" I found the guides at http://www.vernalex.com and http://remyservices.wordpress.com/ (search for sysprep) to be very helpful with all things sysprep....

hmmm interesting... On my sysprep image the windows driver signing option is NOT set back to prompt and stays at ignore... Maybe you have a default profile issue or something. I only use the reseal/mini setup options when running sysprep, I do not use the -pnp switch. (I actually run sysprep from the GUI). My sysprep ini looks like this (this is SP3 version): [unattended] OemSkipEula=Yes InstallFilesPath=C:\sysprep\i386 DriverSigningPolicy=Ignore UpdateInstalledDrivers=Yes KeepPageFile=0 UpdateServerProfileDirectory=1 NonDriverSigningPolicy=Ignore UpdateUPHAL="ACPIAPIC_UP,%windir%\inf\hal.inf" I use the driver scanner from Vernalex.com to add all my driver paths to windows (http://www.vernalex.com/tools/spdrvscn/index.shtml). I like doing this over adding paths to sysprep.ini mainly because the drivers stay on the PC for techs to resolve issues and also I can include printer drivers etc that installs through automated pnp when the printer is attached. This has worked very nice for me. If you are still having trouble with signed drivers, you can always hunt down the .cat files so the drivers are signed. But this is a pain and should not be needed.

This is a pretty open ended question, much depends on the method of imaging/deployment is used and also the policies of device setup. IcemanND's quotes are pretty much in line with our time frames (his imaging methods are probably close to ours). Ours probably would be a bit longer though closer to 16 hours if there are no "catches". The huge determining factor like IcemanND said would be the type of model. If your shop is a dell/hp only type shop things will be faster because most of the time the hardware/drivers are very similar between models. Bugs/oddities are generally known already. Where as if you are a mixed brand shop things get much more complicated. We are an HP shop and have 12 models, 6 desktops and 6 laptops all running on 1 single image. Laptops usually are the problem due to special software like hotkey utilities etc. We don't install them just the drivers for limited functionality. This is easier though if you can deploy software based on model #(we can't yet!!!). HAL issues should be pretty close to being a thing of the past, at least for us. Only 1 model (our oldest laptop), uses a different HAL. But as IcemanND said, if there is a change this requires a bit more testing but is pretty easy to deal with if the image creator has seen it before. Just as an example this is our process for new models... 1. Setup a standard XP install on new model and install drivers as needed by device manager. During install we figure out if we can use previous SATA AHCI drivers, if not find proper ones. 2. Extract installed drivers using any one of the tools out there. Update driver directories (for sysprep) adding new drivers. 3. Load a pre-sysprep version of our master image, add updated driver directory, update sysprep.inf with new SATA driver path if needed and any addition HAL commands again if needed. 4. Run sysprep and image master image PC (after any clean up required before systeprep, delete inf cache, uninstall drivers etc) 5. Install new image on ALL models (you have a DHS don't you ) , note any driver issues and also record installed version of driver. Sometimes the drivers for the new models will be used on older models. 6. Update the driver directory with only used versions of drivers, phasing out older drivers if not used on any models. 7. Run steps 3-5 again with updated drivers directory to confirm no driver/imaging issues. 8. Test software deployment on new image and then deploy to limited test users until satisfied there are no issues.

How can I handle 2 different intel mass storage drivers with the same file names? Sysprep seems to be copying the files to somewhere and prompts me to overwrite during the reseal process... I am creating an image that requires massstorage drivers for an HP 6710b and a HP TC4400. Both have intel chipsets which use the exact same driver file naming scheme. Each of their iastor.inf files and iaahci.inf files are missing the proper deviceID for each other... The .sys files are fairly different in size, the older iastor.sys file is much larger. I downloaded a newer mass storage manager install from intel it could have the proper ICH7 driver... need to test but so does both my other inf files... There seems to be sooo many flavors of a chipset its hard to find the right driver... How do you thing I should handle this if I can't find 1 specific driver that works on both models? Do you think editing the newer inf file to include the deviceid of the older driver could work? Is there another solution? Thanks I am intergrating these drivers through custom [sysprepmassstorage] entries... EDIT: I would still like to know how to handle this but at this time it is not an issue... A HDD went bad on one of my test boxes so the image didn't take... problem looked just like a SATA driver issue but guess not...