$oem$ Location Inconsistency

[Rambler]

Hi - after many hours of trial and error and searching these forums etc, i've encountered inconsistency in the distribution share structure description in the Unattended guide here at MSFN and Microsoft's documentation.

Where MSFN guide states:

As you can see on the left, the $OEM$ folder stays parallel to the i386 folder, not inside it.

Microsoft says:

You create the $OEM$ subfolder directly beneath the i386 folder. During setup, you can automatically copy folders, standard 8.3 format files, and any tools needed for your automated installation process to the $OEM$ subfolder

From what i learned, $OEM$ contents only get automatically copied over to the hdd if it resides in the I386 folder.

If you want to use it outside the I386 folder, you have to include the path in OemFilesPath variable in the Unattended section of the answer file.

As this might sound clear and trivial it is not, because the MSFN guide doesn't mention this anywhere (at least i couldn't find it anywhere in the guide) and it may cause confusion - like it did for me.

This is not meant as rant against the MSFN guide, rather as reminder which might help some people (noobs such as me) save hours trying to figure out why the content is not copied over.

[Yzöwl]

The reason being that you are not reading the correct information from Microsoft!

The information you linked to in for a Distribution Share installation.

If you read the previous page to it you will see that there are two methods highlighted, 'distribution /network share' and 'media', the MSFN guide uses 'media'

[SiMoNsAyS]

btw, i can say that i've used MSFN structure on more than a hundred of VM tests and CDs and always worked flawlessly

[Rambler]

Yzöwl: I see - the confusion probably comes from my (wrong) understanding that distribution folder structure would be the same for "media" and "network" installation, because I can't see any reason why it shouldn't be so - apparently I was wrong.

SiMoNsAyS: I'm not doubting your results or the guide, but I'm doing network installations, not ones from CD.

[Bâshrat the Sneaky]

For network installations, the $OEM$ folder should indeed be INSIDE the I386 folder.

[Alanoll]

Yzöwl: I see - the confusion probably comes from my (wrong) understanding that distribution folder structure would be the same for "media" and "network" installation, because I can't see any reason why it shouldn't be so - apparently I was wrong.

SiMoNsAyS: I'm not doubting your results or the guide, but I'm doing network installations, not ones from CD.

<{POST_SNAPBACK}>

I'll be sure to make sure it's noted the differences between Network and Media distributions.

In my mind when I hear shares, I think network. And the only reason it's WITHIN I386 and not on CD, is simply the way setup is started and how the paths are configured at that point.

[Bâshrat the Sneaky]

@Alanoll: a Distribution Share can also be the Share on your harddisk before you make an ISO of it and burn it to CD/DVD... At least that's how I've always understood it. (Check the Answer Wizard of MS in deploy.cab)

[Alanoll]

@Alanoll: a Distribution Share can also be the Share on your harddisk before you make an ISO of it and burn it to CD/DVD... At least that's how I've always understood it. (Check the Answer Wizard of MS in deploy.cab)

<{POST_SNAPBACK}>

And that is where people will get confused with the Microsoft docs They will be misled to believe that a share and on CD(media) is the same, when it's not. Darn that MS for making it just that little bit more confusing.

[Rambler]

Thanks guys for undestanding the "issue"

For network installations, the $OEM$ folder should indeed be INSIDE the I386 folder.

I just tried and it works also when it's outside the I386 folder, but you have to put the correct path in the OemFilesPath variable (in my case, i'm keeping $OEM$ alongside with, ie. on the same folder level, the I386 as the MSFN guide states - this is mainly for ease of use, because it takes few secs when going into I386 before the folder content is shown).

[os2fan2]

I actually use $oem$ and i386 to directories not on the cdrom, and not in the same tree. That is, you can point these to different shares, or different hard drives or whatever. These are only used in the copy stage of the install.

I set up an appserver partition, with the stable forms of the different windows in use, eg

K:\win2ksp4\i386    <-- win2k files
K:\win2ksp4\support  <-- support
K:\win2ksp4\autopatcher  

K:\winxpsp2\i386      <--- winxp files

You then can have some current form of the OEM tree, for different installs + machines. These can live anywhere, eg as follows. Note that the directory must have the name "$oem$". You can't call it OEMFILES, or W2kOEM or whatever.

x:\penning\2k\$oem$    <-  copied over $oem$
x:\penning\2k\i386        <-  stuff copied over the cd install
x:\penning\xp\$oem$

These directories don't need a lot of stuff there, because it's added to the directories.

If you are doing a lot of common stuff (eg drivers for 2k = drivers for xp, or common installs, you could use unattend.cmd to build (by xcopy) the \penning\$oem$ directory, eg by copying the modem, the video driver and the 2k oem stuff to the directory.

I use a rexx script that keeps all sorts of options present, so the one line to build the files will put the right things there based on selected options.

I then check under the bartpe that K and X are installed in their right places, because having things like Zipdrives and usb's plugged in can create holes in your drive letters. If these are plugged in, you should unmount them first. Use ntsubst from http://www.hhdsoft.com/ or mountvol to remove these extraneous volumes.

Check your unattend.cmd and unattend.txt, to make sure that the OEMFilesPath points to the correct directories.

Then, run unattend.cmd, and it will run. What happens is this.

/syspart:c: will create the hidden 6MB directory c:\$WIN_NT$.~BT . This must be on the drive with boot.ini and ntldr. So you don't need this switch at all, because the default drive is c:\ anyway.

/tempdrive:g will create the huge directory g:\$WIN_NT$.~LS, with the directories under it of I386 and $OEM$, viz

 c:                                        <-  where the boot.ini menu lives
  c:\TXTSETUP.SIF                  <-  copied here
  c:\$WIN_NT$.~BT
  g:                                         <- where the WINNT directory lives.
  g:\$WIN_NT$.~LS\I386         <-  source files copied here
  g:\$WIN_NT$.~LS\$OEM$      <-  oem files copied here

When you rerun the boot, the system will start, and start "looking through your hard disks". What is happening here is that it is looking for a drive with a $win_nt$.~ls directory to start the install.

This is why it suddenly stops: it's found the $WIN_NT$ directory

Using the /syspart switch

The only time you might want to use /syspart, is if you are setting up a hard disk that will end up in another box: eg you might want to put the boot block on hdb1 and the windows install on hdb5. When you install this, you point your directories to hdb1 and hdb5 directories (eg d:\ and r:\ drives).

When you take the second hard drive out of your box, and plug it into some other machine, then hdb becomes the hda, and partitions hda1 and hda5 become c: and d: respectively, and windows is set up on drive d: when it is booted.

W

[Takeshi]

Just to add that according to Win XP Resource Kit,

In a RIS distribution folder, the $OEM$ folder must be created at the same level as the i386 folder.

In all the M$ stuff that I've read, it seems they pay a lot more emphasis to network install so perhaps it explains their oversight for CD.

[johnbreton]

Hi Takeshi

For the RIS installation, you don't need the $OEM$ folder created at the same level as the i386 folder.

The $OEM$ can be anywhere, as long as you have your OEMfilepath in your unattend and you are good to go.

[Takeshi]

Thanks for pointing this out johnbreton.

To put the above quote in context:

http://www.microsoft.com/resources/documen....asp?frame=true

Hopefully now everyone is clear about it.