IGEL BC&DR Field Experience and Best Practices

IGEL Business Continuity and Disaster Recovery (BC&DR) helps organizations prepare endpoints to remain operational when Windows becomes unavailable because of a security incident, malware infection, or system failure. This article summarizes field experience and best practices for deploying and operating IGEL OS Dual Boot and Emergency Mode.

🖊️

This article is a work in progress and will be expanded as additional information becomes available. The content currently published reflects the guidance available at this time.


Configuration and Best Practices

For detailed configuration of UMS features, Emergency Mode policies, and device management, see the related IGEL UMS and Emergency Mode documentation. The following best practices can help you prepare for a reliable deployment.

SCCM Deployment

Use the SCCM Application Model to deploy the IGEL OS Dual Boot installer.

Do not use a Task Sequence. Task Sequence reboot handling can interrupt the two-phase installation process.

Validate uninstall behavior on a test device before redeployment. Confirm that uninstall removes the IGEL program folder and registry entries. Remaining uninstall artifacts can block redeployment on some devices.

NVRAM Timing

The IGEL OS Dual Boot installer creates a UEFI boot entry in device firmware NVRAM. Some enterprise devices need additional time after NVRAM modification before the boot entry persists.

If a device reboots and the IGEL Boot Menu does not appear, firmware latency may be the cause. Configure the installer with an appropriate reboot delay. For device-specific tuning, see the IGEL OS Dual Boot technical documentation.

Dashboard Visibility

Emergency Mode uses command batching to protect UMS and network infrastructure during large-scale incidents.

The dashboard may show a short visibility gap between the time an administrator triggers Emergency Mode and the time devices appear as targeted. This delay is expected. Communicate the expected timing to administrators so they do not interpret the delay as a failed command.

Offline Device Fallback & Pre-Incident Checklist

Emergency Mode requires network connectivity to the UMS or ICG to deliver commands to endpoints. During an incident that affects network availability, some devices may not receive the command or may become unreachable.

Complete the following preparations before an incident to ensure that you can recover devices that cannot be managed remotely.

Pre-Incident Checklist

  • Test manual boot selection on a representative sample of Dual Boot devices.

    During startup, use one of the following keys to verify that the boot menu opens:

    • F4: Open the boot menu.

    • F5, R, or Numpad +: Boot directly into IGEL OS.

  • Document out-of-band access procedures.

    For devices without local keyboard or monitor access, document how administrators can remotely restart the device and access its boot menu.

    Depending on the hardware, this may require:

    • A baseboard management controller (BMC)

    • Intelligent Platform Management Interface (IPMI)

    • A serial console

    • Another out-of-band management solution

  • Store recovery files in a secure offline location.

    Keep copies of the following files available outside the affected production environment:

    • The Dual Boot installer in EXE or MSI format

    • The IGEL OS base image ZIP file

  • In a severe incident, these files may be required to reinstall Dual Boot or repair the boot configuration.

Manual Fallback Limitations and Critical Devices

Manual fallback is not available when both of the following conditions apply:

  • The device cannot be reached through the UMS or ICG.

  • The device cannot be accessed through a local or out-of-band console.

Plan for this limitation before an incident. For devices that must remain recoverable during a network outage:

  • Place them on monitored network segments with redundant connectivity.

  • Provide and regularly test BMC, IPMI, or another out-of-band management method.

  • Identify devices that have no manual fallback option.

  • Record these devices as at risk during network outages in the incident-response playbook.