It's healthy to be deeply suspicious of any flag-waving standards advocates, particularly when one vendor is driving the bus. But we put skepticism aside to test shipping products, including LANDesk Desktop Manager, WfM-compliant PCs and NICs in our Savannah, Ga., labs. While we found full WfM 2.0 support in many desktop systems and NICs, not all common management platforms (like Novell's ZENworks or Microsoft's SMS) fully support it--even Intel's own LANDesk falls short.

Still, WfM is compelling and growing; even today's solutions can be useful. Combined with technologies such as disk duplication and directory-enabled remote control, WfM can greatly reduce your support costs burden.

Nuts and Bolts
WfM builds on established frameworks and adds pieces to form a coherent whole. This makes a lot of sense--why reinvent a framework to retrieve workstation statistics when you can use existing standards? For example, a WfM-compliant PC needs some sort of informational management agent, but it makes no difference whether it's CIM (Common Information Model), DMI (Desktop Management Interface) or SNMP.

WfM incorporates many acronyms into its whole, and rather than consider them all at once, it's useful to group WfM into four layers: preboot management, power management, information management and support agents. (See "Building Blocks of WfM" to the right.)

When purchasing WfM software or hardware, bear in mind that WfM specifies only minimum levels of compliance; vendors are free to improve it. Furthermore, the spec designates recommended features as opposed to required features. Marketing literature rarely gives a detailed description of WfM compliance, so nudge vendors for full disclosure before you buy. Intel does no compliance testing, but it lists recommended buying practices on the Web at www. intel.com/tech/work/initiatives/ wfmspec.htm.

If They Build It, You Can Boot
WfM's preboot management is geared toward lights-out workstation management. PXE (the Preboot Execution Environment) encapsulates ways for a network administrator to "wake up" an otherwise powered-off PC and boot it from the network. PXE is mandatory in the WfM spec, and must be supported by a PC's BIOS and its NIC for the PC to be considered compliant. (See www.intel.com/tech/work/ network_cos.htm.)

A PXE workstation typically has a jumper connecting its NIC to the motherboard, which keeps it linked into the LAN even when the power is off. This lets the NIC continually listen to the LAN for a "magic packet"--the station's MAC address repeated six times. When the PC's NIC hears its magic packet, it powers up the system.

But the station has no IP address while it is powered off, so how can it deal with anything but data-link constructs? During our LANDesk testing, we discovered that magic packets try crossing bridge groups using directed broadcasting. A router doing a directed broadcast will use a data-link broadcast address to send the packet to the subnet, so the station can hear the magic packet even though it has no IP address. Will this create broadcast storms? It depends at what rate your management software wakes up PCs to perform maintenance (see "Rise and Shine With Wake On LAN" to the right).

Once the PXE workstation wakes up, if network boot is enabled in the BIOS, the PC's IPL (Initial Program Load) will use the UNDI (Universal Driver Interface) to start the network card and configure itself. If the user turns off PXE in the BIOS, you're out of luck, so this is one case where BIOS password protection is a good idea.

PXE specifies DHCP extensions that won't work on some DHCP servers, so packages that support PXE come with a "proxy DHCP" service. It doesn't offer IP addresses, but allows DHCP operation and supplements the DHCP server's DHCPOFFER.

The DHCP server provides a boot file name, which the workstation then downloads from a TFTP server. The image can populate a hard drive using drive duplication over the network or load a disk image into RAM. This operates almost identically to RPL or TFTP boot services. A disk network boot image lets you throw the user into an OS that supports network boot (like early versions of Windows 95), or image the workstation's hard drive and reboot, by using tools such as Norton Ghost.

Part of the new WfM 2.0 spec calls for PXE 2.0; improvements from the PXE 1.x spec define an authentication scheme for PXE boot files called BIS (Boot Integrity Services). In a nutshell, a BIOS that supports BIS will only execute a boot file signed with a certain certificate.

BIS can only be used for IPL--a waste, considering BIS authentication requires a certificate infrastructure. For example, it would be nice if PXE defined a remote method of configuring the BIOS--say, via a telnet interface using certificates or ssh authentication. WfM notes that vendors are free to implement value-added features.

An improved remote boot facility combined with Wake On LAN (WOL) is a powerful combination for desktop administrators. WfM finally standardizes what had been a hit-or-miss technology.