$OEM$ folder structur moved in RDP 1.40 integration module

[Jeff Mathews]

As far as I can tell, HP is no longer using the i386\$OEM$ folder structure, and is instead using the compaq\ss.640\w2k\$OEM$. This folder is then copied to the c:\ drive of the server being deployed.

Simply copying this folder structure to the C:\ drive and then leaving it there after the install seems armature to me. By default, the Microsoft Unattended process looks for this $OEM$ folder structure to reside beneath the source install location (i386). Not only that, certain files in the unattended install are expected to be there, like cmdlines.txt or the bmp file used to brand the install. I have yet to find an alternate location that this file will be automatically picked up by the install process.

Now files I have created under the i386\$OEM$ don't get picked up by the install, or copied to the specified locations like $1 (system32). I have to setup a manually procedure to take care of this. Am I doing this wrong?

One last thing, if you are going to copy a folder to the C:\ drive of the server, why call it $OEM$? I mean, choose your own name so it is less confusing. How about c:\support. That way people won't expect that they can drop files and directories into the $OEM$ folder and have them work like any other unattended install.

Feedback on why this was done would be great. If I am not accurate in my findings, I would appreciate the correction as well.

Jeff

[Jason McGee]

RDP uses two unattend.txt parameters, OemFilesPath and OemPnPDriversPath, to point to a $OEM$ folder that is not nested in the I386 directory. Below is info on these parameters from the UNATTEND.DOC file that is in the support CAB on the W2K CD.

This directory cannot be renamed, it is simply an alternate location that the instalation process looks to foir drivers that are not on the Windows media.

OemFilesPath
Value:
Specifies the path to the \$OEM$ folder (containing OEM files) if it does not exist under the i386 folder of the distribution share point. The path can be a UNC name.
For more information about the \$OEM$ folder, see the Microsoft Windows 2000 OEM Preinstallation Kit (OPK) User Guide if you are a computer manufacturer. Otherwise, see the Microsoft Windows 2000 Deployment Guide.

OemPnPDriversPath
Value: ";; ???"
Specifies the path to folders that contain Plug and Play (PnP) drivers that do not ship on the Windows 2000 CD. The folders must contain all the files necessary to install the particular devices???catalog files, .inf files, and drivers.
For example, if you have a folder called \Drivers with subfolders called \Audio and \Net, you would specify OemPnPDriversPath = "drivers\audio;drivers\net" in the answer file. Setup adds:
??? %systemdrive% to each of the folder names
??? the path for each subfolder to the PnP device search path.


Note When using this parameter, be sure that the folders are available during GUI-mode Setup or Mini-Setup???you can use the \$OEM$\$1 folder structure mechanism for this. For best results, make sure your drivers are signed.

[Jeff Mathews]

Thanks for your reply. I am familure with the Unattend process as it was designed by Microsoft. My questions were aimed more at HP and why they have moved the $OEM$ structure from the default location (under the i386 source location), to under the ss.xxx\%os%. Not only that, but the $OEM$ folder doesn't really exist there, it is created through the w2k.bat or wnet.bat file that is called during the whole process. Its then left behind on the servers root drive after the install is completed. Why would you call a folder $OEM$ if it isn't used as such??

I did get my custom scripts integrated with HP's new way of doing things, I was just curious as to the reason for the change.

Jeff

[Richard Mouser]

Jeff,

The reason for keeping the $OEM$ drivers in a different folder from the OS files is that the $OEM$ files change very often to get new driver versions that support the latest ProLiants. The Microsoft Windows files don't change (or only change if you slipstream in a new service pack).

For example, RDP 1.30 had the ss.630 drivers, RDP 1.40 had the SS.640 drivers. Some customers don't want to change the deployment scripts for all their existing servers just because they need new support software to deploy the latest ProLiant. This arrangement gives them that ability.

As we release new versions of the ProLiant Integration Module (PIM), you can retain your customized jobs that use older version of the drivers, or modify the "ss" variable in the deployment jobs to point to the new "ss" tree.

Does that help?

Richard

[Jeff Mathews]

Thanks for the response Richard. I realize that the drivers and such can change on a regular basis, but can you not upgrade the $oem$ directory just as easily in the \i386\$oem$ folder as you can in the ss.xxx\w2k folder? In the end it really doesn't matter where the folder is, but what is the point of leaving the $oem$ folder on the server when the install is complete?

Thanks again for the explanation though.