• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About bmusgrove

  1. Dumb Questions... The Section [OEMBootFiles] iaahci.inf iaStor.sys iastor.inf txtsetup.oem Is the same no matter which chipset / raid chipset you have. Unfortunately, the actual content of those files is different. Example: One version of the files may cover the 82801 chipset, but a different version of the files is needed for the ICH8R. How would you integrate that into a generic Multi-systm RIS? When you have to copy the INF and SYS files to you I386, you are suddenly faced wtih needing to copy two different versions of the same file.....2 different SIF's would not work here. I know there is something blindingly obvious I am missing.... Something simialar wold occur for Dell otpiplex or latitude series AUDIO chipset.. There are many different models, all from the same manafacturer, same file names , but the INF/CAt/SYS files are model specific.......
  2. Stupid question..... I am having problems with a generic RIS install in that E6400 notbooks, identical configuration (all were ordered off the same, single, Dell Equote), will sometimes pick up and install all of the correct drivers, and some times they will not. Of the 5 I am working on at this moment 2 installed correctly, 2 did not install the Dell (CreativeLabs) Webcam, Intel AMT, Intel Serial over LAN Rico Smart Card Reader, Intel video and the IDT Audio drivers 1 bombed in RIS saying it could find no harddrives in the system. I am scratching a bald spot in what little hair I have left. Theories? Resolutions? Please??????
  3. What about a chained install using the Setup.ini file of office 2003? It does not appear to inherit the display options of the MS office installer as it should, nor does the DISPLAY parameter in the [Chained Install] section appear to work . Has anyone managed it? I am about to try it using a batch file
  4. If you are running RIS be sure to read the release notes. RIS is replaced with Windows Deployment Services . Supposedly this will run in a legacy (RIS) or mixed (RIS and Windows Deployment Services ) mode BUT ever since I installed SP2, I keep getting a RIS error that tells me I do not have the rights to add a computer account to the domain. I have yet to track down the source, as it appears all the permissions are correctly set on the surface.
  5. As I just experienced this problem , and I searched for along time to find a solution, I thought it may be useful to post it. I gleaned this from several Broadcomm posts on this forum. Hopefully it will help another user and they will not have to search as long. I re-installed RIS while trying to trouble shoot TFTP problems in the PXE boot. While rebuilding a a new unattended WinXP slipstreamed image, I could not get the Broadcomm drivers to work. They worked fine during the Text mode part of the setup, but failed to load at startup. I had to reinstall the Broadcom drivers after the first time starting windows on each machine. I used the drivers from the Broadcomm ZIP file I had downloaded (version, copied to a flash drive) and it worked fine, so I was sure it was not a driver After much research. I discovered the instructions for modifying the Broadcomm driver files had changed, and had not read them close enough. I basically did it from memory, using the old method that had worked before I had re-installed RIS and rebuilt the images. After carefully reading the instructions, I realized I should have copied a modified INF file to i386 and a unmodifierd inf file to the NIC driver directory, instead of a modified file to both. Note : The instructions by Microsoft in Microsoft Knowledge Base Article 315279 "How to Add Third-Party OEM Network Adapters to RIS Installations." are not entirely correct for Broadcomm drivers. You must follow the instructions provided by Broadcom, exactly as they are written. Don't be a dummy like I was and just skim through them , assuming you already know them . These can be found at . Here is a synopsis 1) Make a backup copy of the INF file so you have a unmodified version of it. 2) Modify one version per Broadcomm instructions ( ) . Basically this is changing %BRCM% = Broadcom, NTx86.5.1, NTamd64 to read %BRCM% = Broadcom.NTx86.5.1, NTamd64 in the [Manafacturer] section 3) Copy the modified INF file to to the I386 directory 4) Copy the unmodfied, original INF file to the $OEM$\$1\drivers\NIC directory. 5) Stop and Restart the BINL service In the past (using 7x and early 8x version drivers)I had always copied the modified INF file to both directories and it had worked. I also noticed that stopping and restarting the BINL service did not create the PNF files as I expected. Instead this was done the first time the image was used in a RIS install. Is this a new change for Windows 2003 RIS?
  6. For WM10, use the MS Enterprise deployment tool for Media player to repackage the WM10 download. You can add the WM10 security patch into it. For DotNet 2.0, I got past the warning by starting the install from a command box SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx REG ADD %KEY% /V TITLE /D "Installing Applications" /f REG ADD %KEY%\090 /VE /D "Installing Dot Net Framework 2.0" /f REG ADD %KEY%\090 /V 1 /D "cmd /c start \"dOTneT 2.0\"/wait %systemdrive%\install\dotnetfx.exe /q /c:\"install /q\"" /f
  7. I have a similar problem trying to install the .Net 2.0 and Windows installer 3.1 redistributable. The message occurs if the files are located on a server share or on the local harddrive. An interesting twist...... If I run it at t12 from cmdlines.txt (using Batch.cmd), it works great. Same command line and switches. If I run it from a batch file after windows starts, it works great. It only gives the warning when running using the RUNONCEEX method
  8. Needa little help understanding a software install issue. MY inexperience in MSI file is killingme here. I have asoftware install package that basically copies a bunch of OCx and DLL files, then is supposed to make entries for these files in the HKEY_Classes_root section of the registry. Installer works great EXCEPT the pacakge only works for the person who installed it. Each new user has to reinstall the package. The person who created the MSI pacakge did set the install mode to PER USER instead of PER MACHINE in the MSI file. This appears to cause the file registry information to be written to HKEY_Classes_root and to Hkey_current_User\software\classes. This is what confuses me . Since the information is designed to be written to HKCR, and (if I have this right) HKCR is merged with HKLM, shouldn't this information and the files be available to all users on a per machine basis? Or is there somehing about being written to HKCU\software\classes that overrides the entries in HKCR?