Br4tt3

Here is a guy that is taking this approach seriously... http://ist.uwaterloo.ca/~etbain/RIS_Notes.html

Hi! First you need to pinpoint on what basis diffrent installations will take place, what is the criteria to have SOFTWARE X installed, rather than SOFTWARE Z. This could be, people working at the finacial department needs to have the Office suite that includes Access while people working in the Resception only needs Word... in other words, create decision making criterias for yourself. Of course these criterias can based on anything from HW, geografic placement and so on... From what I understand u want to be able to install the diffrent softwares, depending on what u tap in when pressing F12? Thats fine, then what u need to do is create a custom .osc screen which create an variable for u: e.g %Which-RunExOnce-To-Run% for example. This variable "lives" within RIS until the temp .sif file has been created. Once the file has been created, the variable has been translated into whatever on supplied for value during the .osc screen, e.g %Which-RunExOnce-To-Run% into FullOffice or something... We discussed these features in the following thread!

The operating will not be able to recognize digital signatures of signed software, drivers and so on... I would imagine!

Right click the "My Computer" icon, choose the "Hardware" tab, click "Driver Signing" and set your desired level of driver signing and what action the OS is to when facing this circumstance.

I totally agree with RougeSpear's last post, the only downside to using AD's MSI capability is patching (.msp assigning) according to me.

Well, from my standpoint, as long as all the RIS boxes present exatcly the same images, with patches and so on, I dont even care if they use 3 RIS servers on the same subnet, cause independent of which machine that answers the requesting client, they will obtain the same image.

Hi! Repartition=No <-- Only valid if using RIS, not ordinary unattended.txt installations! I would urge u to use WinPE to partition ur machines prior to the intended Windows setup. If WinPE is not within your license agreement, then use BartPE which will provide u with a much environment to acchieve what u want compared to MS-DOS thingy's... About the convert issue from FAT32 to NTFS, there is either an entry in the unattended.txt: [unattended] FileSystem = ConvertNTFS or u could perform the same actions from within WinPE/BartPE using the convert.exe command...

Hi! Sure there is, TXTSETUP.SIF method! I am not gonna say it's easier, but better (IMHO)! There are much info within MSFN, some good links to start of with if u thinking about this approach are: Gosh's site Raskren's guide My last issue.. Hope it helps...

RyanVM - u r most defintly correct about this I guess. I have now succesfully booted and installed one of the new x9xx Dell servers using the following bits and pieces: Within the TXTSETUP.SIF file I had to add the following info: [SourceDisksFiles] percsas.sys=1,,,,,,_4,4,1,,,1,4 [HardwareIdsDatabase] PCI\VEN_1028&DEV_0015&SUBSYS_1F011028="percsas" PCI\VEN_1028&DEV_0015&SUBSYS_1F021028="percsas" PCI\VEN_1028&DEV_0015&SUBSYS_1F031028="percsas" [SCSI.Load] percsas=percsas.sys,4 [SCSI] percsas = "DELL PERC5 RAID Controller Driver (Server 2003 32-bit)" I then had to add both percsas.sys and percsas.cat (signature file) to source directory (i386), which is really wiered I would say. Cause my WinPE and RIS installations didnt require this file, just the unattended CD/DVD installations. This of course is also true for the entries in the TXTSETUP.SIF file which worked with first post in this thread.... anyway! Last thing to do: Add the following into the DOSNET.INF file within the source directory (i386): d1,percsas.sys into the following sections: [Files] & [FloppyFiles.2] Still, it works but I dont know why it works with the other entries in some of the installations and yet not on the other. I have urged MS to provide some feedback on this issue and hand over some documentation, even though I am not convienced they will! Reporting back if they share something with me...

Then u need to be some kind of environment to run it from.. like WinPE, BartPE, MS-DOS and so on.

Not really, but then again... no to bright either! Anyway, I've done as suggested in ur post with no success... I have contacted MS on this one so lets see what they can come up with and I will post it back to this topic. Thanks for the time and suggestions folks! @ xian7479 - Tried that combo, but with the same result as earlier

I am not sure but, when I decided for which method to use for adding SCS/SATA/RAID controllers, when using this method, I could get the machine using a specific boot controller working by specifying it in the [MassStorageDrivers] and [OEMBootFiles] sections. However, none of the machines that were NOT using this controller would fail to install... cause of this (and from what I could gather when reading about the TXTSETUP.SIF tactic) I decided not use this tactic as it would force me to have multiple .sif's for deployment. I say: "One .sif file to rule 'em all, one image to rule 'em all"

Hi! We are running about 250 RIS boxes within our organization currently, all are Win2003 boxes. As long as there is a segmented/layered network at the sites (so that no intersite PXE detection will occur), everything works smoothly so far. The client uses / prefers the RIS boxes that services the client the fastest, so if u have 5 RIS boxes, the one fastest to pick up the request will be the winner. The issue u r addressing is: If someone has multiple sites to support through the usage of RIS deployment, how to deploy the clients using a single RIS server build, to ensure the same "image" is deployed everywhere? If this is the issue/case, I strongly recommend u to do the following: 1. Skip the tactic of having one mobile RIS server, that u can take under the arm or on the flight and script it.... 2. Basically u need to know some very basic vb or js scripting.. dont be scared, love it! 3. Script kicks of the sysocmgr.exe with parameter to install the native Win32 RIS component, both applicable to Win2003 and Win2000. 4. Once this has been done, the risetup.exe can be automated using parameters to add and configure the RIS box unattended. 5. Any specific customazations can also be done from the script... as creating or copying the $OEM$ folders and files for u and the .sif file. All this solution really requires, is access to the source files of the Win32 OS u r running to add the native Windows components. This way u will have a script (10K) instead of a laptop to carry (5 kilos). Or the really basic lazy tactic ( works on Win2003, Win2000 dunno ) : 1. Build ur master copy of the image on 1 RIS server, when finished 2. Copy everything below the x:\RemoteInstall\Setup\English\Images\<Your_Image_Name> onto a huge USB stick 3. Put the stick in the pocket and catch the flight 4. Install the RIS feature manually on the designated server, more or less, next next next finish 5. Delete the image added at this step.... 6. Connect the USB stick from step 2 7. Copy everything on the stick to the designated folder Since adding an image is basically a large file copy sequence, y not? I find myslef having more control over the installation when copying the files and folders into place on the RIS server than adding an image using risetup.exe. Personally, I am using a combination of method 1 & 2: 1. Split the RIS setup into 2 parts, Part 1 - Install and configure RIS, Part 2 - Adding image(s) 2. Part 1 - Using method 1 without step 5, when done wrapp the script in a .msi file so I get versioning and deployment capability with AD/SMS and so. Also, this solves the issue in case one wanna make an update that is important and that is to be spread all over the RIS boxes, just make a patch with the new modifications and it will update itself. 3. Part 2 - Take all the time in the world to manually create a master image with all the goodies, once satisfied, package into a .msi and of u go. Any new drivers to add/distribute to the all the RIS servers, I create a patch that will update the installations. Or maby that wasn't ur question?

Well... If I am not mistaken, the ability to add the driver offline is not a problem with old versions of WinPE, either using drvinst.exe or adding it manually, however, adding the driver while running online I think requires WinPE 2.0 and drvload.exe. Never used it yet though...

hahaha... I know what u mean! I guess ur gf doesnt though!

Mostly what one wanna acchieve... I would say it is better to have one script performing all of the installs but that is just me.

About that last thing, just make things clear: 1. The template .sif file for the image (base .sif file) would have to look like: [GuiRunOnce] Command0="wscript.exe MyScript.vbs %MY-VARIABLE-1% %MY-VARIABLE-2%" and so on... Once the screen input has been answered, the variables will be translated into the strings entered. Of course, the variable names of within the .osc must correspond to the ones used within the .sif file or else.. 2. Looking into the tmp unattend file (named with a GUID of the machine), it will look something like: [GuiRunOnce] Command0="wscript.exe MyScript.vbs Latitude 430 SWEDISH" or something.. 3. The script would then be excuted, acting on that info... Cheers!

YES! Well, Yes but, it is not very nice coding but it will work.. just so that I dont get blamed for this, only need do create WshShell object once within the script, as in: Option Explicit Dim WshShell, Command Set WshShell = WScript.CreateObject("WScript.Shell") Command = "C:\MyAppz\App1\RunApp.exe /param1 /param2" WshShell.Run Command, 0, True Command = "C:\MyAppz\App2\RunApp.exe /param1 /param2" WshShell.Run Command, 0, True Command = and so on.... horrible but it will work... Dunno, never used the RunOnceEx method, maby even better, who knows?

Hi again, I was thinking... What u could do is this ( variation of what I am doing with my RIS installs ) 1. Create a .osc file that will provide u the option to create an input parameter, that will be saved to the temp unattend file created on the RIS box during installation. In my case the code looks something like: <FORM ACTION="WARNING"> &nbspActivation Code: <INPUT NAME="ACTCODE" MAXLENGTH=255> </FORM> just replace the ACTCODE for something else (model or what ever..) 2. From the [GuiRunOnce section] launch a script that will be able to read the actual value of what was entered in the .osc screen input section and propagated to the temp unattend file. Once u can read that value, u can make ur own decisions on what is to happen with the installation, of course u can make it read multiple values, translated into for e.g: model (which applications to install), language (which language to install) and so on. In my case I read the specified parameter from the input screen like this: [GuiRunOnce] Command0="wscript.exe MyScript.vbs %MY-VARIABLE%" where the %MY-VARIABLE% value has been translated into a string, entered from the input screen. Of course, u prolly have to script abit to get it working. For installing, changing the language of a already installed machine, use either reg haxXxx or read this MS KB. In the first .osc screen, u would have to type in the correct computer model, e.g Dell Latitude xyz, next screen you type Swedish for example and from the script you would have to act upon that. Well, it is just thought!

Hi! I understand what u r aiming for but I dont think that the right way to solve is to the use of additional .osc screens as they are a bit "old school" and with limited functionality (IMHO). There are some MS websites that address the usage of creating ur own .osc files and so on if u search Technet. Microsoft actually supports a deployment framework that addresses questions that u r refering to, called BDD (Business Desktop Deployment). However, it is not as simple to just install it and everything is working.. u prolly need to work with it for a while before knowing all the scripts and stuff.. what I am aiming for is this: There is already developed scripts within this framework that take into account which model u r using/trying to install by the use of WMI scripting. The logic is very simple and more or less comes down to: 1. One common script will be executed, using WMI, the script will return which vendor the machine is supplied from (e.g HP/IBM/Dell) and which model of the machine that is being installed and if it is a laptop or desktop. 2. Once this information is determined, u can make decisions based upon that.... Example: If it is a HP Pavilion for example, then install OEM DVD software, If Dell Latitude then install OEM management application, and so on and so on.... BDD is free of charge and can be downloaded from the MS website for the public. Like I said, it will solve ur problem but it takes some time to get the hang of it. BDD requires WinPE, so all I would recommend u to do is to investigate which scripts that u can copy/snatch and what to edit to get it working...

lo again.. ****************************************** Thanks, that is a great help. By making the process invisible, will it silently install or do I need to control that with command line arguments? Steve ****************************************** First of all, I hasted, the 0/1 controls the visibility/silent features, the True or False, controls if it is to wait until process has been completed before continuing. There is 2 ways do it... either you control the quiet/silent installations via the .exe or .msi source binary or via the host that is performing the installation for you (wsh or any other). In other words: Ex 1. msiexec /I my_msi_app.msi /quiet (where the /quiet switch will inform the install that - show no UI) Ex 2. An MS KB fix: KB392012.exe /quiet /norestart (same as above.. more or less) A combination: Set WshShell = WScript.CreateObject("WScript.Shell") Command = "C:\MyAppz\App1\RunApp.exe /param1 /param2" WshShell.Run Command, 0, True Will install silently, because the script host will be informed due to the 0 that it is to invisible, to the UI. Set WshShell = WScript.CreateObject("WScript.Shell") Command = "C:\MyAppz\App1\RunApp.exe /quiet" WshShell.Run Command, 1, True Will be silent, because the command string indicates to the setup engine, that show no UI (rather than the script host in the other example) Set WshShell = WScript.CreateObject("WScript.Shell") Command = "C:\MyAppz\App1\RunApp.exe /quiet /param2" WshShell.Run Command, 0, True Totally unnecessary, but possible... I supplied the silent parameter both to the script host, and to the .exe binary setup engine. I recommend u start using one of the methods, so that u have a unified way of controlling the installation behaviours, I recommend the host method as NOT all binries support the silent features. Hope that works out for you...

Hi! Try using a single .cmd file or .vbs file for the whole [GuiRunOnce] section that will run the installation for u in a more structured way. If using a .cmd file, u can controll the installation sequence by using the Start /Wait as described @ this site, or if using a .vbs file u can control it even better when using this example code: Set WshShell = WScript.CreateObject("WScript.Shell") Command = "C:\MyAppz\App1\RunApp.exe /param1 /param2" WshShell.Run Command, 0, True Where the 0 stands for: "wait until the process ends and then continue... with the next one?" while if setting a 1 instead will kick of one setup and directly go to the next one. True/False, turns on/off visibility of the process. Hope it helps..

Hey... I guess, really read the earlier entries carrefully. The directory structure is to be like this: RemoteInstall > $OEM$ > TEXTMODE Check out this site for more info!

There is one thing (even though I dont think it will matter for the functionality)... Earlier in this entry u listed: OEMPnPDriversPath = TEXTMODE <-- To point out where to scan for the drivers, right? no need... as long as u have OEMPreinstall set to Yes, this dir will be scanned when using the other entries of the unattend file [MassStorageDrivers] & [OEMBootFiles]. The OEMPnPDriversPath is only used for the drivers that is scanned during Win32 bit mode which is later on. Also, use "" to enclose the driver paths later on... anyway, even if u list the folder from this entry, it will only scan directories below the $1 subfolder so absolutly no need for it within that entry! U got the TEXTMODE directory placed correctly right? directly below the $OEM$ folder? See what happens!

Hi! If the machine was succesfully installed into Win32 (logged on once for example), and it BSOD:ed when performing an additional reboot, my guess is that it was some kind of driver added late in process, like a kernel filter driver or something. Try installing the machine with just the drivers for the HW, if succesfull when fully installed and rebooted, then add something more and so on... then u will know where in the process it messes up. P.S I am also running Dell GX620's as one of the company's standard models if there is anything that u wanna check out...