Standardizing BIOS Settings in a Dell Shop

I recently needed to standardize the BIOS settings across my organization, and I found the perfect tool: the Dell Client Configuration Utility (DCCU). This powerful application lets you obtain or configure BIOS settings, flash the BIOS, and shut down or restart the system. I've used the DCCU to set Preboot Execution Environment (PXE), Wake on LAN (WOL), and administrator passwords, as well as upgrade and flash the BIOS.

Dell's documentation indicates that the DCCU is compatible with GX150 and later systems. However, I've used the utility on models as old as the GX1 to perform every function except setting BIOS passwords. The DCCU doesn't require you to install other Dell software (e.g., OpenManage) on the client PC.

You can search Dell's support Web site to find the DCCU. Make sure you download the latest version rather than an old version. The current version of DCCU is 1.2.1, which is available at http://support.dell.com/support/downloads/download.aspx?c=us&cs=555&l=en&s=biz& releaseid=r123761&formatcnt=2& libid=0&fileid=164480.

The DCCU interface is simple. The three main tabs correspond to the actions you can perform. You can collect information about current BIOS settings, change BIOS configuration settings, and upgrade or flash the BIOS. Select an action tab, choose the options you want, and click Create Package. The DCCU then creates a small executable package that runs in the Windows environment.

The DCCU Help files suggest using Dell OpenManage Client Administrator (OMCA), Altiris Client Management Suite, or Microsoft Systems Management Server (SMS) to deploy and execute the package across an enterprise. My organization doesn't have any of these solutions, so I wrote a Group Policy computer startup script, which Listing 1 shows, to deploy the package. This script is a batch file that copies the package to the local machine, then executes the package. You might need to modify the script for your environment.

Numerous options exist for storing the DCCU package. I stored the package that I created in a subfolder named \DELL in the Netlogon share. You can store the package in Group Policy and eliminate the need for the localserver variable, or you can store the package in a static location on a file server. The %logonserver% variable isn't available to computer startup scripts. If you have multiple sites with domain controllers (DCs) at each site, the best option is to store the package in Group Policy (in the same directory as the script) or in the Netlogon share, as in my example. This method ensures that the system copies the package from the local server.

When a package runs, it uncompresses several files, executes them, and creates XML log files. You can specify the log-file output directory during the package creation. The XML log files tell you which settings failed, which succeeded, and which weren't applicable because the setting doesn't exist in that BIOS. After a package runs, it cleans up after itself: The package deletes all the files it uncompressed and eventually deletes the package itself. Therefore, you need to use a copy of any package you create when you test and deploy the package.

The If exist line in the script prevents the package from needlessly copying and running at each reboot. One run is sufficient. During the package creation, I specified C:\BIOS as the location to store the XML log files. If C:\BIOS exists, the package has already run and the script jumps to the end and exits.

Although the packages are small (approximately 844KB), on large networks the copying can significantly increase traffic during peak boot times. Thus, you might want to apply the policy in phases to workstation subsets at various times.

If you want to create an image to deploy to new PCs, be sure to delete the output log directory (i.e., C:BIOS) before running Sysprep. This action ensures that new PCs run the script in its entirety.

See Associated Figure

End of Article