cluberti

The sound mute value is set in two locations: HKLM\System\CurrentControlSet\Control\Class\{4D36E96C-E325-11CE-BFC1-08002BE10318}\0005\Settings "MasMM" = 0/1 (REG_DWORD): 0 = Enabled, 1 = Disabled HKLM\System\CurrentControlSet\Control\DeviceClasses\{6994AD04-93EF-11D0-A3CC-00A0C9223196}\##?#PCI#VEN_8086&DEV_24D5&SUBSYS_<SUBSYS OF YOUR SOUND CARD VALUE>{6994ad04-93ef-11d0-a3cc-00a0c9223196}\#Wave\Device Parameters\Mixer\0\Controls\1 "Channel0" = 0/1 (REG_DWORD) 0 = Enabled, 1 = Disabled "Channel1" = 0/1 (REG_DWORD) 0 = Enabled, 1 = Disabled Note that you will need to know the SUBSYS_ value of the soundcard in question, as this value is populated in by your soundcard driver upon installation. It wil always be PCI#VEN_8086&DEV_24D5, but the &SUBSYS_<value> will change with the card or driver in use. If you know the SUBSYS_ value you can set this programmatically. ============================================ Now that I've scared all but the most hardcore WMI guys in here... ============================================ Download the tool mute.exe (from http://ed.mullen.home.comcast.net/utility.html) to mute the volume on or off. Place the mute.exe file in the system32 folder, and simply call "mute on" from your script and the system should mute immediately. Note that I've tried this during and after Windows setup, and it only seems to work properly after Windows setup, not during. So, if you've got a script that runs in GUIRunOnce or a RunOnceEx batch, call it there.

Can't seem to open that guide, either from the page directly or downloaded locally...

Sonic, if you've got a domain (or a workgroup with machines to which you can add registry entries) you could always install WSUS to handle Microsoft security updates. But yes, if you're updating an already installed system and you don't have WSUS, you'll have to do it with a batch or some other method. It might not be a bad idea to copy the updates down to the systems and use RunOnce to install the updates on a working system - it's a prettier way than a batch file . If you are able, a WSUS server is the easiest way to get updates to your machines.

All Windows XP updates post SP2 have the /integrate switch option. Why even bother manually installing them when you can add them to your installation source? For each update (including the SP3 updates), just download (which you've already done) and run the .exe with the /integrate switch, pointing it to your Windows XP installation source. For anything that won't integrate properly (and there is at least one that I know of), you could use nlite to integrate it. If you do it this way, all of the integrated files get checked and updated as necessary at the T-13 stage, which would be before your applications get installed via SetupParams or GUIRunOnce.

Also, I was able to recreate your issue by trying the exact steps you had taken with my own XP source. This source works just fine when doing an install directly from the CD, but when I boot to DOS and manually invoke setup, I get the complaints about those exact three files - seems like you've already gotten around this, but I thought I'd let you know as well. With or without smartdrv, installing using winnt.exe from a dos prompt gives these errors, every time. Making the CD bootable and doing a normal CD installation with the same files, no problem.

Incorrect - if you have a WINNT.SIF file in your i386 source, it doesn't matter where you're installing from. Unattend.txt is still a good way to go, just an FYI. However, since you said you're installing over the network, you will need to have the $OEM$ folder INSIDE the i386 folder for it to be copied over. It needs to be alongside i386 from bootable CD, but inside the i386 folder for network install. You can point the install to your $OEM$ folder in the unattend.txt or WINNT.SIF file, too, if you want to leave it where it is.

Amitri is correct, SP1 then SP3 with Office 2000. If you go to the link amitri provided, you will be instructed on what to download, and how to install the updates as well. Like I said before, you'll have to go to the toolbox site and read to become a pro

Hm - if you're getting errors after doing everything in order, I'm not entirely sure what's going on. There are a few hotfixes that don't necesarily integrate properly, but that's normal. If you still have an RTM Windows XP source, I may suggest that you restart - slipstream SP2, then integrate all of the hotfixes again to that source and see what happens. You may also want to do the install using the CD rather than from DOS (see the "Bootable Windows XP installation CD-Rom (with SP1) [updated! dec 17, 2002]" section from http://www.nu2.nu/bootcd/ for making your CD bootable), because I know for sure you shouldn't attempt the install with any type of hard disk TSR software, especially smartdrv. If you need help with this, let me know.

"I certainly will want to use stuff like that, but remember, at this stage I'm not using any winnt.sif input at all, just applying the /integrate form of hotfixes, nothing else, over a virgin image of XP pro SP2 [VRMPOEM]. This is why I asked if I need to do anything else, i.e., doing just the hotfixes themselves is perhaps inadequate to a viable result?" It depends on what a viable result is, I gues. The stuff listed below (minus bootvis, powertoys, and the recovery console) are all listed on Windows Update, but cannot be easily integrated into the install source, and that's why I put them there. "I did not use anything but the numerical order slightly modified to achieve less conflicts, so clearly this is wrong and likely part of the problem, so I need to re-order the hotfixes, etc. A question: Can I use the digital signature date inside of the fix itself [properties shows it] as the basis of the sort?" More than likely this is the root cause of your problem, and yes, using the release date in the digital signature should be good enough. The date is also on the download page for each hotfix on the MS site as well, and I went by those without any problems. "Also, I see mention of a hotfix tool apparently to force things regarding interaction with I believe 885835 and at least one other fix it doesn't "like". Can I assume the purpose of the tool is to get the entries in SVCPACK.INF to happen when the /integrate switch doesn't work and play well with the others? But if it gets into SVCPACK.INF it *will* work? If so, then this tool is a good way to avoid manual additions to SVCPACK the directory and svcpack the .inf file and nothing else? [is that correct?]" It's worth a try , but just make sure you are integrating (or forcing) hotfixes into the install source in the proper order. I've never tried it (I just let WSUS install the updates post-install), but I've heard it works properly. There are at least two hotfixes known to have trouble integrating into the XP source. "...is there any reason why my way is inherently "wrong" for testing?" Not necessarily, but without actually testing it through a "real" install, there's no way to be 100% sure it works. Assuming you have a decent procesor in there, you should be easily able to run a VM. You would only likely need to be running one machine at any one time, and if you can spare 256MB of memory to devote to the VM whilst it is running, this is more than enough for VM testing. "So, is the creation of this I386\UPDATE directory "normal" and merely an ignorable artifact, or is its mere presence indicating I screwed up? [As I said, it seems to ignore the files even though I am quite early into the install in the text screens, before anything would involve actually installing the hotfixes themselves, which in turn seems to itself be ok, etc.] It cannot be a concidence that the very files that get these early error messages are all three the only contents stored there, etc." Yes, the update directory SHOULD be there. And those are the three files that should be there as well, so your integration was most likely simply done out of order, and paying attention to the dates on the download site for each update (or the internal signature date) will help when you re-integrate the hotfixes on another clean SP2 source. Just let me know if you need more assistance, and I'll try to help.

Did you add the hotfixes in order? If you integrate hotfixes out of chronological order, you run the risk of having mismatched files. This is probably what you are experiencing - I've found it easier to install a virgin XP SP2 machine in a VM, go to Windows Update and check the box. Download the full version of each and every update listed under both the critical and suggested sections, and note the release date (do not do it by the article number, as these are NOT chronological). Integrate patches from oldest release date -> newest release date, and you should be fine. I've had problems before, and I've found that integrating in the proper order really does matter. Slightly OT but still of value, here's a script that I made to get the oddball suggested applications that can't be integrated installed - it's called from [setupParams] section of WINNT.SIF (T-9min): ---unattend.cmd--- :// Install Journal Viewer. msiexec /i %sourcepath%\unattend\jrnlvwr\jrnlvwr.msi /q :// Install HighMAT CD writing update. %sourcepath%\unattend\hotfix\HMTCDWizard_enu.exe /qn :// Install .NET Framework 1.1 with SP1 and SP1 hotfix. %sourcepath%unattend\dotnetfx\dotnetfx.exe /q:a /c:"install /l /q" %sourcepath%unattend\dotnetfx\867460.exe /q %sourcepath%unattend\dotnetfx\886903.exe /q :// Install Media Player 10 and Windows Media Connect. start /wait %sourcepath%unattend\wmp\MP10Setup.exe /q:A /c:"setup_wm.exe /Q /R:N /DisallowSystemRestore" %sourcepath%unattend\wmp\wmcsetup.exe /q :// Install BootVis (the .mst was created by me). msiexec.exe /i "%sourcepath%\unattend\bootvis\bootvis.msi" TRANSFORMS="%sourcepath%\unattend\bootvis\bootvis.mst" /qb! :// Install Windows Messaging Components (Messenger 5.1, Office Communicator 2005). msiexec.exe /i "%sourcepath%\unattend\winmess\messenger.msi" /qb! msiexec.exe /i "%sourcepath%\unattend\winmess\communicator.msi" /qb! :// Install XP PowerToys. "%sourcepath%\unattend\xppower\deskman.exe" /v/qn "%sourcepath%\unattend\xppower\taskstch.exe" /v/qn :// Install recovery console. %sourcepath%i386\winnt32 /cmdcons /unattend /dudisable :// Change boot.ini timeout to 3. bootcfg /timeout 3 :// EOF ---unattend.cmd--- Have fun, and good luck.

Sure. If you do the following, you should have a basic custom Office 2000 installation: 1. Visit the Office 2000 Resource Kit site (http://www.microsoft.com/office/orkarchive/2000ddl.htm) and download the file "ORKTools.exe". 2. Install the Office 2000 Resource Kit core tools, which includes the Office 2000 Custom Installation Wizard. 3. Create an administrative installation point of Office 2000 by running "setup.exe /a" from your Office 2000 media. Note the location of your administrative installation point that setup is creating. 4. Run the Custom Installation Wizard, answering all questions. When prompted, save the resulting .mst file to the location of your administrative installation point. That is it, in a nutshell, on how to get started. There are lots of options that you will learn about when reading the resource kit and toolbox websites for Office 2000, but what I've explained above is the basics on getting started. Now, to install your new custom installation unattended... 5. Execute the following command from a command prompt or script, substituting the proper paths to your administrative installation point and custom .mst file where appropriate: "<path to Office 2000 administration point>\setup.exe" TRANSFORMS="<path to your custom .mst file created in step 4>" /qb! Good luck!

Ironically, that error message is usually an error with the NIC drivers rather than the hard disk (go figure). Make sure that you've integrated the latest drivers for the NIC you're using to PXE boot the machine into the i386 source of your RIS install (as per http://support.microsoft.com/?kbid=315279). That should fix it.

You cannot add drivers to the boot floppy, period. As for GBLan NICs, if the NIC card supports PXE, you can use it. Since the driver will probably not be included in the Windows source, simply do the following to make it work: http://support.microsoft.com/?kbid=315279

You can't add NICs to the boot disk (as you already know), and you can't access the RIS server without booting to the network via PXE (or another network boot ROM, like the 3COM boot ROM). Thus, you HAVE to have a network card that is either on the floppy, or (better) can PXE boot. Those are the only options. Pick up a few PXE-capable NIC's and put them in the machines with the non-compatible NIC's.

You'll need to visit the Office 2000 Resource Kit site (http://www.microsoft.com/office/orkarchive/2000ddl.htm) and download the file "ORKTools.exe" (do a search on that site for the downloadable file). This will install the Office 2000 Resource Kit core tools, which includes the Office 2000 Custom Installation Wizard. You will use this to create the transform to be applied to your Office installation. First, you will need to create an administrative installation point for your Office 2000 source - manually run office setup from the command line with the /a switch. This will create an "administrative install point", either on your local hard disk or on a network drive. Second, you will need to run the Custom Installation Wizard to create a transform. Follow all of the steps in the wizard, and save the transform to the administrative installation point location you just created. The Custom Installation Wizard will also tell you what command line you will need to use to install Office 2000 with the transform you just created. You will not need to use the original Office 2000 source files anymore - simply copy the administrative installation point to your network or to a CD and you should be good to go. I strongly suggest you visit the Office 2000 Resource Kit site and do some reading before you try this. It's not the easiest thing to do, but it isn't difficult either once you know what you are doing. Good luck!

Since you already have Windows preinstalled on these machines, you won't be able to bypass this automatically, as you have no control over the Windows installation by the vendor. It would be wise, if you can, to create your own retail XP CD with your own WINNT.SIF answer file and wipe these machines out once they come to you (hey, if you've got an AD, you could probably use RIS for even easier setup via PXE boot). There certainly is a way to skip the OOBE portion of a retail XP setup if you do a new install - you need to add the value "UnattendSwitch = YES" in your [unattend] section to skip the OOBE though. Here's a full WINNT.SIF file that works on retail, MSDN, and VLK XP Pro CD's: [Data] AutomaticUpdates = YES AutoPartition = 1 MsDosInitiated = 0 UnattendedInstall = Yes [unattended] Unattendmode = FullUnattended UnattendSwitch = YES OemPreinstall = YES OemPnPDriversPath = drivers\audio;drivers\chipset;drivers\misc\wireless;drivers\modem;drivers\network;drivers\RAID;drivers\touchpad;drivers\video OemSkipEULA = YES TargetPath = WINDOWS Filesystem = ConvertNTFS DUDisable = YES Hibernation = NO WaitForReboot = NO DriverSigningPolicy=Ignore Repartition = Yes [GuiUnattended] TimeZone = 035 AdminPassword = * EncryptedAdminPassword = NO OemSkipWelcome = 1 OEMSkipRegional = 1 AutoLogon = YES AutoLogonCount = 2 [setupParams] UserExecute=%systemdrive%\temp\unattend.cmd [userData] FullName = USER OrgName = ORG ComputerName = * ProductKey = XXXXX-XXXXX-XXXXX-XXXXX-XXXXX [Display] BitsPerPel = 32 Xresolution = 1024 YResolution = 768 [identification] JoinWorkgroup = WORKGROUP [Networking] InstallDefaultComponents = Yes [NetOptionalComponents] Beacon = 0 [Components] Accessopt = Off CertSrv = Off CertSrv_Client = Off CertSrv_Server = Off Chat = Off Deskpaper = Off Dialer = Off Fax = Off Fp_extensions = Off FP_Vdir_Deploy = Off Freecell = Off Hearts = Off IIS_Common = Off IIS_Doc = Off IIS_FTP = Off IIS_HTMLa = Off IIS_Inetmgr = Off IIS_NNTP = Off IIS_NNTP_Docs = Off IIS_Pwmgr = Off IIS_SMTP = Off IIS_SMTP_Docs = Off IIS_WWW = Off IIS_WWW_Vdir_Printers = Off IIS_WWW_Vdir_TerminalServices = Off IISDbg = Off Indexsrv_system = Off LicenseServer = Off Media_utopia = Off Minesweeper = Off Mousepoint = Off Msmsgs = Off MSMQ_ADIntegrated = Off MSMQ_Core = Off MSMQ_HTTPSupport = Off MSMQ_LocalStorage = Off MSMQ_MQDSService = Off MSMQ_RoutingSupport = Off MSMQ_TriggersService = Off Msnexplr = Off Netoc = Off Pinball = Off Solitaire = Off Spider = Off WMAccess = Off zonegames = Off [PCHealth] ER_Display_UI = 0 ER_Enable_Applications = None ER_Enable_Kernel_Error = 0 ER_Enable_Reporting = 0 ER_Enable_Windows_Components = 0 ER_Force_Queue_Mode = 0 ER_Include_MSApps = 0 ER_Include_Shutdown_Errs = 0 [shell] DefaultStartPanelOff = YES DefaultThemesOff = YES [systemFileProtection] SFCQuota=0 [systemRestore] MaximumDataStorePercentOfDisk = 5 RestorePointLife = 7 [branding] BrandIEUsingUnattended=Yes Home_Page = http://www.google.com Search_Page = http://www.google.com/ie_rsearch.html://http://www.google.com Search...ie_rsearch.html AutoConfig=1 If you put WINNT.SIF in the i386 directory of your XP install source, setup will use that file. Otherwise, place WINNT.SIF on a floppy when the XP setup starts, and it will read that file. XP setup will check for the existence of a WINNT.SIF file on a floppy disk, and if it doesn't find one it uses the one in the i386 directory. Just an FYI.

It may be dangerous. However, if you know the IP addresses or IP address range of the machines that will be connecting remotely, you can add this in a script to run via RunOnceEx, or GuiRunOnce, etc: netsh firewall set service type = remotedesktop mode = enable scope = <whatever scope> That'll punch the hole in your XP firewall for remote connections, but only for the IPs or IP ranges that you want to allow.

Heh - I forgot I was a member . I do have lots of suggestions for unattended installations, as I've been doing them for years. I also did a stint with a certain company not too long ago, and I gleaned quite a bit of information during that tour as well. Thanks for the compliment, too!

It is fairly easy to do what you want to do, but it's not entirely obvious. I do something similar to what you are attempting to do, and after lots of crawling the newsgroups and poking and prodding test setups, I've found a way to make this work. Try the following: In the [GuiRunOnce] section, call a batch file and pass it the %ASSET% variable in the command line of the batch file, like so: [GuiRunOnce] Command0 = "c:\windows\temp\asset.cmd %ASSET%" Your "asset.cmd" file should do something like this: echo %1 > c:\windows\temp\asset.txt The OSC variables are still available at this point, so this should work, and your variable should survive (via the text file) into Windows post-setup. Using a batch file or a vbscript, you could do something based on the contents of that text file, like add it to the registry (either a reg add statement from a batch or objReg.SetStringValue from a vbs).