Jump to content

cluberti

Patron
  • Posts

    11,045
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    country-ZZ

Posts posted by cluberti

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. "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.

  8. 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.

  9. 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!

  10. 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.

  11. 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!

  12. 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.

  13. 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.

  14. 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).

×
×
  • Create New...