Managing Multiple .SIF files and $OEM$ folders

[cog]

I was wondering if anyone has setup a network install using different .SIF files and $OEM$ folders for differnt workstation configurations?

I know that I could put all the drivers for every configuration into one $OEM$ folder, but I'd rather not have all of the unnecessary drivers installed on machines that do not need them.

I've been able to successfully create a .SIF and a $OEM$ directory for each type of workstation configuration.

Now, my problem is this:

If I have the multiple $OEM$ structure for the drivers unique to each configuration, how can I manage the files common to all of the configurations? (i.e. monitor/print drivers, patches, apps, etc.) I don't want to have to manage 15 copies of the .Net framework install in my source.

I've tried putting the "common" files into the default $OEM$ structure under the I386 directory and then using the OemFilesPath= to point to different $OEM$ structure in hopes that they would somehow merge.

Just wondering if I've missed something or if anyone else has had this kind of dilema?

[Br4tt3]

Well... if u r set to use several images, all with diffrent folder structures and driver sets.... there are not much to do as i can see it except, associating an (1) image with several sif files.

My recommendation is to keep it simple (dont over work yourself )... one basic image with all drivers $OEM$ and so on... if u want diffrent config for the machines. then just associate the diffrent sif files to the one image...

keep truckin...

[knewman01]

I don't know if this is exactly what you are after, but here's my setup for managing different systems:

Directory structure:

XPCD

-------->BASE

            -------->i386

            -------->$OEM$

                        -------->$1

                                    -------->Install

-------->CUSTOM

            -------->HADES

                        -------->i386

                        -------->$OEM$

                                  -------->$1

                                                  -------->Install

            -------->HERMES

            -------->APHRODITE

            -------->ZEUS

            -------->SIFS

That's the general layout. Under the base directories, I have any files/folders that are going to stay the same no matter what machine I build the UI for.

Under custom, I put ONLY files that need to change.

Pay attention the the SIFS directory. I name each sif winnt.sif.machinename.

At build time, I have a batch file that handles the assimilation.

c:\build_ui HERMES

The cmd file takes the name of the machine as input, copies the base dir and the machine's custom files into a holding directory, copies and renames the winnt.sif into the holding directory, builds the image into an ISO, and deletes the holding dir.

At one point I was really getting tricksie in the build. I was appending text files into txtsetup.oem based on which SATA drivers were needed.

It takes a while to get it set up, but it worked great.

I'd give you better examples, but I went back to using a single install source for all my machines. I'm working on a .vbs that will take the machine name as input, and install apps based on that.

[edbro]

Setup will only install drivers for the hardware it sees. Just because you have drivers in a folder doesn't mean they will get installed. You don't have to have them in $OEM$ either. You tell setup to look in a certain folder with the "OemPnPDriversPath=" statement in winnt.sif.

[cog]

Yeah, I know that the setup will only install the drivers it needs. But if I'm putting all of the drivers (approx 80MB) for all the configurations into a single $OEM$, a single machine may only use about 10MB of those.

I think I'm going to need write script like knewman01 did in order to merge a common base $OEM$ folder with a specific configuration $OEM$ folder.

I might also play around with my source server and see if I using some NTFS Junctions will work. I'm just not sure managing the junctions will be to much of a pain.