Creating headless systems
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
*Note - this particular article also had contributions from one of the Embedded Windows team members, Peter Felts.
A growing number of connected devices work without direct interaction with a user. In most cases they also do not have the normal human machine interface devices: monitor, mouse and keyboard. These so-called headless devices require some planning when building a suitable operating system image.
One of the first questions to answer is how there can be some form of interaction with such a device for both normal use, or for dedicated usage scenarios like maintenance. Headless devices that still have a “remote” user interface are quite common. Examples are DSL routers, NAS storage devices or even products like “Windows Home Server”. In these cases the browser or another application replaces the classical man-machine-interface and offers a remote user a limited set of functionality on the device. This approach is very beneficial for smaller devices, because offloading the display capabilities to a remote device, e.g. a desktop PC, leads to significant savings on image size and hardware requirements.
If embedded devices are required to offer richer functionalities to the extent where additional display requirements can be integrated without spoiling the overall device requirements, standard desktop remoting technologies such as Remote Desktop come into play. Their benefit is to offer easy and well-known management functionality to system with additional development or training efforts.
In Windows Embedded Standard 2009 the support for headless devices starts with the availability of null-drivers for the standard MMI devices. Of course, the BIOS needs to support this kind of configuration, as well, but this should not be a problem on recent systems. The generic keyboard and mouse drivers in Standard are still present as well, when no hardware is connected, but the null driver for the VGA adapter needs to be added to the configuration. This requires the following components:
VGA Save could be left out, if there really is no VGA compatible chip on the board. This will create a dependency error, which in this case can be disregarded. Nevertheless, the benefit of having VGA Save in the image is that any time a graphics adapter card is plugged into the system VGA Save gets loaded instead of the Headless VGA driver. This enables screen output e.g. for field personnel troubleshooting the device. The VGA Boot Driver is required by NTLDR at boot time.
As another option the Terminal Services Core component could be added to the image. It enables similar functionality, but pulls in a lot of infrastructure into the image, which makes it a less compelling alternative in low footprint scenarios.
Avoiding local screen output
Message Boxes or other user notifications popping up on a headless device are not desirable. They may interrupt application execution and may never be seen by anybody. Therefore the OS image needs to be configured to close and redirect all message boxes to the event log, which can be accessed remotely. This is done with the help of the Message box Default Reply component, which offers several verbosity levels, as well.
It needs to be taken into account that in this case the default answer to a message box will be acknowledged, which might not fit to all scenarios. Additionally, this interception mechanism only works for message boxes created via the corresponding API in User32.dll. If an application creates a custom form as its type of message box, this form will still be displayed on the device.
Additional forms of notifications are balloon popups in the application tray. These can be turned off using this registry value:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\EnableBalloonTips
It is of type RegDword and should read “0” to disable all tips.
If one needs to disable the appearance of a certain form window, then this can be achieved by writing a Win32 service scanning the OS desktop for this window. There is a great article on how to do this in the MSDN library, including a code sample to get you started.
Headless maintenance
I hope you get the pun in the heading. When talking about maintenance all forms of remote access to a system can be leveraged for a headless device, as well. This includes:
- HTTP pages, either static or dynamic
- Telnet
- Remote usage of the MMC
- FTP
- RDP
- System Center Configuration Manager
- WSUS
- Device Update Agent
Depending on the desired functionality, corresponding components need to be added to the image. The Telnet Service or IIS are often used to enable remote administration or remoted applications.
When working with more sophisticated technologies, such as SCCM, maintenance packages need to be composed to run unattended on the embedded device, leveraging the available the local infrastructure. Therefore, having the Windows Installer Service and the Windows Management Instrumentation (WMI) on the image is always a good idea.
In addition to the need for a remote management method such as RDP, IIS, or Telnet, a headless device will need to support a method of connection when the device isn’t even booting, also known as an “out-of-band” situation. This type of support is outside of Windows, but is necessary to diagnose boot problems that prevent a headless system from booting to a point where it can start one of its “in-band” remote administration methods. A scenario here would be a device that is remotely administered via RDP, but that cannot even boot past POST because of a hardware problem.
OEMs that develop their own BIOS or EFI firmware will have the option of supporting BIOS serial port redirection to address this. If the OEM enables this support, a technician will be able to connect to a headless device with an RS232 cable and monitor/interact with the hardware boot process, in order to diagnose a problem, and access information that would otherwise not be visible to a headless device user.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,Standard 2009,Embedded