Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral

About beatbox99

  1. Unattended 2008 Install

    Thanks leen2, this is a huge help in getting me pointed in the right direction!
  2. Am I correct in believing that the tried and true methods discussed here for an automated XP installation (which I've also used for Server 2003) no longer work for Server 2008 installations? Are we forced to use the Windows Automated Installation Kit now for building Automated/Unattended Server 2008 Deployments? If I've missed something...Can somebody point me at a getting started guide for Unattended Server 2008 deployments for dummies guide?
  3. Try replacing HKEY_CURRENT_USER with HKEY_USERS\.DEFAULT in your build process, this will replicate the key to all new profiles as they are created.
  4. I have an unattended build that I use for installing server operating systems. The build pauses at the disk configuraiton part of setup to manually have the user create the C: partition where the OS will be installed (I wish Microsoft would give us the ability to create a specific size partition for C rather than all or nothing in the winnt.sif answer file). Once the OS has been installed my configuration scripts kick off. One of the scripts calculates the appropriate size for the swap file, creates a primary partition on the first disk set (mirrored) and then allocates the remainder of the drive as another primary partition for log files. The next script forces the CDROM to operate as drive D: (I have relabeled this as Z: in a past life, but D: is our company standard drive for CDROM's at the moment). The next script creates an E: drive on the second physical disk (RAID 5 set) for applications/data. This works very well when run on virtual machine and physical servers, but only when run locally from the CDROM drive. Unfortunately our datacenter is at a remote location and I often have to build servers via the HP iLO remote control boards by mounting an .iso across the network via the virtual media applet. The problem I have when using the iLO boards is the Virtual Media applet creates a virtual CDROM drive that the OS sees as a second CDROM drive. Since the additional drive letters are not created prior to the OS installation, Windows assigns the physical CDROM drive as D: (which is fine) and the virtual CDROM as E:. This poses a problem later when my scripts try to create the disk drives. DiskPart will happily assign the E: drive to the disk partition that it creates, but since the OS has already assigned this drive letter to the 2nd CDROM, the OS gets confused and both the disk and CDROM become inaccessible. Since I need to do this dynamically (ie: only when installing via an iLO) I've written some logic into the script that creates the E: drive to detect the presence of the virtual CDROM drive, but I can't figure out how to assign a different drive letter to it before my script tries to crate the E: drive as a disk drive. I know that DiskPart sees hard drives as "Disk" and CDROM drives as "Volume". Currently I assign the CDROM drive letter by passing this text file to DiskPart: select volume 0 assign letter=d I was considering creating a second text file containing: select volume 0 assign letter=d select volume 1 assign letter=z But I'm not sure whether the OS sees the virtual drive as a volume or a disk, so I'm not sure if this would work. So my question is, how can I assign a drive letter from a batch script to a device that already has a drive letter assigned to it? ie: If the script detects the presence of the 2nd CDROM drive which the OS has already allocated as drive E:, how can I change this drive letter to Z: before proceeding with the DiskPart command? Does this make sense or am I over-complicating something easy?? Cheers Jeff
  5. 32bit vs 64bit registry updates

    WPI looks interesting and seems to be well documented, now all I gotta do is find time to read through it... Nois...Thanks for the tip. I was wondering if running reg files from cmdlines.txt was possible as I know that not all command line utilities are availabe at that stage. This looks like an excellent solution and the added benefit of hitting the default hive will come in very handy. The only piece remaining would be the final reg file applied after all the packages have been delivered to clear the auto-logon settings, which ditching the custom launcher I'm using now for WPI would seem to solve. Thanks for your help guys!!! Cheers Jeff
  6. 32bit vs 64bit registry updates

    Thanks K...I've downloaded the package and will take a look....Maybe you can answer a quick question though... I have a series of modular make files which compile the DVD's that we use for our server installs. At the moment, we support Windows 2000 Standard/Advanced, W2K3 Standard/Enterprise and W2K3 x64 Standard/Enterprise. The make files determine which i386/AMD64 folder to drop into the root of the DVD, but the "packages" for all 6 flavours are always included on each of the DVD's produced. Right now, my cmdlines.txt file which fires at T-13 executes three commands, the first applies all the hotfixes approved by our corporate security team, the second copies the OS files to a folder on the local C: drive and the third puts a .vbs script in the RunOnceEx key which fires on the first reboot after the OS is installed. The .vbs script determines the installed OS and then calls one of 6 different batch files from the DVD to extract the appropriate packages (all in .cab files), it then copies another batch file to the All Users/Startup folder and triggers a reboot to kick off the app launcher. Each of the packages installed is triggered by a .cmd file which contains logic to determine if it's running on a physical server or a virtual machine (ie: should I install the HP Management Agents or VMware Tools) as well as logic to determine if a 32bit or 64bit version of a particular package (ie: .NET framework) should be installed. One of the first commands in the batch scripts populate the registry to configure the automatic logon for the administrator account, so the scripts can reboot the server and pick up where it left off (as several of the packages require reboots), and one of the last commands issued is to clear the automatic logon, rename the administrator account and change it's password. I assume WPI can do the same thing? Meaning, can I create 6 unique "default" installs and call the appropriate one by passing a command line parameter to WPI on startup or would I need to create 6 unique DVD's which include only the packages for that particular platform? Cheers Jeff
  7. I have an unattended install for Server 2003 that works flawlessly for 32bit versions of the OS, but I've run into a problem with registry updates when applied to a 64bit install. I have a custom built application launcher (32bit) that accepts a text file as input with a line describing what is being done and the batch/cmd file to execute. Many of the items being applied are registry settings that I update to either tweak performance or configure the server to meet our environment requirements. On 32bit installs, it works flawlessly; however, when run on a 64bit installation, each of the commands gets processed, but every one of the registry entries gets put into the 32bit subkey, thus are never actually read by the OS when it boots up. I've tried using regedit /s to import .reg files as well as reg ADD/UPDATE in my scripts and the result is the same; however, if I run the .cmd file manually from a command prompt, it will properly insert/update the registry keys every time. I did some research and found that the problem is that there are both 32bit and 64bit versions of the cmd, regedit and reg commands on a 64bit OS and that because my launcher is a 32bit app, it will automatically call the 32bit version of these commands which then update the 32bit subkey of the registry even if you explicitly call the executables from the 64bit path. Apparently it has something to do with a 32bit process being unable to launch a 64bit process. When run manually from a command prompt when logged into the server, it will by default open the 64bit command processor when then calls the 64bit versions of regedit/reg which of course update the proper registry keys. I thought I had figured out a way around this...Figuring that by utiliziing the RunOnceEx registry key, it would automatically open a native 64bit command processor in which to execute all of the batch files, I rewrote all of my registry updates into a .cmd file called by my launcher to populate them in the RunOnceEx key. The key does get populated and when the server reboots, it does process through the key, executing each of the .cmd files with the registry updates; however, most of the updates (I haven't checked them all, but did try to verify a bunch of them) do not appear in either the 64bit or the 32bit registry keys. I'm desperate to find a solution to this problem...I have about 25 registry updates that need to be applied and of course I'm on a deadline at work to have a fully functional automated 64bit Server 2003 build ready before Friday morning. My fall-back plan is to write another batch file that applies all the registry entries and have the operators run this manually at the end of the server build, but this defeats the purpose of the automated build (and won't please my boss at all), as eliminating any manual intervention in the server build process, thus ensuring a consistent build every time was the entire purpose of this project. Does anyone has any suggestions on how to get this to work as it should? Cheers Jeff
  8. The beginning of my runonceex.cmd file for a Windows 2000 Pro install looks like this: @Echo Off SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx REG ADD %KEY% /V TITLE /D "Application Installer" /f REG ADD %KEY%\004 /VE /D "Extracting D620 Software" /f REG ADD %KEY%\004 /V 1 /D "C:\masters\extract.exe /Y /E /L C:\masters\ C:\masters\D620.CAB\" /f REG ADD %KEY%\009 /VE /D "Dell Notebook System Software" /f REG ADD %KEY%\009 /V 1 /D "C:\masters\D620\System\setup.exe -S" /f When I run this, I get an error message back saying: "Too many command-line parameters." for each REG ADD entry...Is the format different under Windows 2000???
  9. I'm working on a partial unattended setup for Win2K Pro. I'd like to automatically select and use the entire "C" drive for the install, but when I run my CD, it stops at the select partion screen....What am I doing wrong here???? [Data] AutoPartition=1 MsDosInitiated="0" UnattendedInstall="Yes" [unattended] UnattendMode=DefaultHide ;ReadOnly FullUnattended OemPreinstall=Yes OemFilesPath="..\$OEM$" OEMPnPDriversPath=drivers\IntelINF;drivers\NET\Broadcom;drivers\NET\Wireless;drivers\VIDEO DriverSigningPolicy=Ignore OEMSkipEula=Yes TargetPath=\WINNT ;FileSystem=LeaveAlone ;ConvertNTFS OverwriteOemFilesOnUpgrade=No KeyboardLayout="US" ;NTUpgrade=No ;Win9xUpgrade=No ;ExtendOemPartition=1