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
