Deploying IGEL Business Continuity and Disaster Recovery Emergency Mode

In IGEL Business Continuity and Disaster Recovery (BC&DR), you can use IGEL OS Dual Boot and Emergency Mode to restore secure endpoint access during a security incident, outage, or Windows failure.

IGEL OS Dual Boot installs IGEL OS alongside Windows. For details, see How to Deploy and Use IGEL OS Dual Boot.

Emergency Mode in the IGEL Universal Management Suite (UMS) Web App lets administrators reboot dual-boot endpoints into IGEL OS during an incident. For details, see IGEL BC&DR Emergency Mode in the IGEL UMS Web App.

Use this article to plan, deploy, validate, and troubleshoot Emergency Mode for devices that run IGEL OS Dual Boot.

Why Endpoint Recovery Matters

Business continuity and disaster recovery plans often focus on restoring servers, applications, storage, and network services. Endpoint recovery can remain a gap. Even when core systems are available again, users cannot work securely if their Windows endpoints are compromised, corrupted, unavailable, or still under investigation.

How IGEL OS Dual Boot and Emergency Mode Work

IGEL OS Dual Boot installs IGEL OS to a dedicated, isolated partition on the Windows system disk. During installation, a UEFI boot entry is registered in the device firmware (NVRAM), making IGEL OS selectable from the firmware boot menu. At runtime, the IGEL partition is read-only; the Windows partition is never mounted by IGEL OS. This isolation ensures ransomware or compromises on Windows cannot affect IGEL OS. 

The recovery workflow is straightforward: an administrator triggers Emergency Mode from UMS, specifying which devices should boot into IGEL OS. Devices receive the command, reboot, present users with a warning, and boot into IGEL OS. From there, users authenticate their identity provider and connect to virtual desktops or SaaS applications using the same credentials and single sign-on (SSO) as they use from Windows. When the incident is resolved and IT confirms Windows is safe, the administrator exits Emergency Mode, and devices reboot back to Windows. Alternatively, the device may be re-imaged as required.

Planning Your Deployment: Prerequisites and Architecture Decisions

Before deploying, you need to make key decisions about:

• infrastructure size,

• UMS architecture, and

• security stack compatibility. 

Endpoint Requirements

Every endpoint must meet the following minimum requirements:

Before installation on each device, complete the following pre-flight checks:

1. Confirm that UEFI mode is enabled in the firmware.

2. Document the Secure Boot state and capture a baseline.

3. Check BitLocker status and capture BitLocker recovery keys.

4. Check whether the Windows Recovery Partition blocks free space at the end of the disk.

5. Disable the Windows Recovery Partition if it blocks the required disk layout.

6. Verify that at least 40 GB free space is available on the Windows drive.

7. Confirm that the graphics adapter is supported by IGEL OS.

8. Confirm whether TPM 2.0 is required for the organization’s security posture or VDI features.

Check Endpoint Security Stack Compatibility

The single highest risk to successful deployment is an endpoint security product that silently blocks the Dual Boot installer. Pre-flight discovery of your security stack is mandatory.

Products that may require coordination or temporary exemptions include:

• Absolute or Computrace

• Tanium Enforce

• HP Wolf Security

• HP Sure Recover

• Third-party disk encryption tools

• Firmware protection tools

• Products that block raw disk writes

The IGEL Dual Boot POC Playbook contains the full security stack risk register and mitigation strategies for each product. Identify your stack early in planning. 

Deployment Consideration - UMSaaS and Self-Hosted UMS

For most organizations, we recommend UMSaaS: cloud-hosted UMS managed by IGEL. You avoid infrastructure costs, patching, backups, and high-availability setup. UMSaaS integrates with IGEL Cloud Gateway (ICG), which bridges your firewalls and lets endpoints reach UMS even across geographically distributed networks. For organizations with strict data residency requirements or existing UMS infrastructure, self-hosted UMS on your data center is an alternative. 

Deploy IGEL OS Dual Boot

Deployment unfolds in three phases: foundation, pilot deployment, and Emergency Mode validation.

Phase 1: Foundation (Weeks 1-2)

1. If you use UMSaaS, set up your UMSaaS environment with IGEL. Configure the initial administrator users, IP allowlists if required, and identity provider settings for single sign-on.

2. Deploy the IGEL Cloud Gateway (ICG) in your network to bridge the firewall and route device traffic to UMSaaS. This is a one-time setup.

3. If you choose self-hosted UMS, provide a server, or servers for high availability, install UMS software, configure database backup, and set up network access.

Phase 2: Pilot Deployment (Weeks 3-6)

Select 5-10 pilot devices representing your user population and hardware diversity.

1. Complete the pre-flight checklist for each device.

2. Deploy the IGEL OS Dual Boot installer by using the SCCM Application Model.

3. Let the device reboot once to install IGEL OS.

4. Let the device reboot again to configure the Windows-side management components.

5. Confirm that the device boots into Windows normally after installation.

6. Verify that the device appears in the UMS console within a few minutes.

7. Confirm that the device is ready for Emergency Mode.

Phase 3: Activation and Validation (Week 7)

After the pilot devices are available in UMS, configure the Emergency Mode policies and run an end-to-end validation exercise.

To validate Emergency Mode:

1. Select a subset of pilot devices.

2. Trigger an Emergency Mode simulation from the UMS console.

3. Monitor the dashboard for command delivery and device boot progress.

4. Ask pilot users to sign in to IGEL OS.

5. Verify that users can access their required applications.

6. Document the timing from command delivery to productive application access.

7. Record any user or administrator friction.

8. Adjust the configuration or process before expanding to production.

For more information on Emergency Mode, see IGEL BC&DR Emergency Mode in the IGEL UMS Web App.

Validate the Deployment

Use this scorecard before expanding to production.

If all criteria pass, you are ready to expand to production. If any fail, refer to the troubleshooting section below. 

Troubleshooting

Devices Do Not Register in UMS

Check the following items:

1. Confirm that the device has network connectivity.

2. Verify that the UMS enrollment URL is correct.

3. If you use ICG, verify that ICG is online and can reach both the device and UMS.

4. Check firewall rules, proxy settings, DNS resolution, and required ports.

5. Restart the UMS agent or retry registration.

The IGEL Boot Entry Is Missing

The boot entry may be missing if the NVRAM write failed, the bootloader is corrupted, or Secure Boot blocks the bootloader.

To troubleshoot:

1. Open the BIOS or UEFI firmware settings.

2. Verify the Secure Boot state.

3. Confirm that the IGEL OS boot entry exists in the UEFI Boot Order.

4. If the entry is missing, run the IGEL OS Dual Boot installer with the /update parameter.

5. If Secure Boot is enabled, verify that the required certificate configuration permits IGEL OS to start.

The Emergency Mode Command Is Not Received

The device may be offline, unreachable, or unable to communicate with UMS or ICG.

To troubleshoot:

1. Check the device’s last contact time in UMS.

2. Restore network connectivity if the device is offline.

3. Verify HTTPS and WebSocket connectivity between the device, UMS, and ICG.

4. Retry the Emergency Mode command.

5. If the device remains unreachable, use the manual fallback procedure.

The Device Boots into IGEL OS but UMS Still Reports Windows

A short reporting delay is expected.

1. Wait up to 5 minutes.

2. Refresh the Emergency Mode dashboard.

3. If the device remains in Pending, verify the active operating system locally or through SSH.

4. If IGEL OS is running, verify communication with UMS or ICG.

5. If IGEL OS is not running, troubleshoot the boot entry.

Expand from Pilot to Production

After the pilot passes validation, expand the deployment in waves.

Recommended rollout path:

1. Expand to 50 to 100 devices across all major hardware types, user personas, and locations.

2. Repeat the validation scorecard.

3. Record installation issues, boot issues, network issues, and user access issues.

4. Update the operational runbook.

5. Train helpdesk staff on Emergency Mode status monitoring and manual fallback.

6. Expand to the full target population in controlled waves.

Your operational runbook should include:

• Emergency Mode start process

• Emergency Mode stop process

• Device status definitions

• Expected timelines

• Manual fallback steps

• Out-of-band access procedures

• Exit criteria for returning devices to Windows

• Escalation paths for devices that cannot be reached

Once Dual Boot is deployed across your fleet, you have established the foundation for resilient endpoint recovery. Optional next steps include integrating Emergency Mode with your incident-response playbook so SOC teams can trigger recovery automatically when ransomware is detected; adding forensics and attestation capabilities to capture evidence during incidents; and expanding to additional recovery paths such as IGEL USB Boot for devices that cannot boot into Dual Boot.