Monthly Archives: March 2026

How to open a root shell on the Veeam Software or Infrastructure Appliance

Posted on by
Reply

Introduction

Veeam’s Software Appliance (VSA) and Infrastructure Appliance are hardened by design out of the box. They’re secured, protected, consistent, and predictable, but they’re also unapologetically locked down. There is no SSH, no shell, no root, no sudo. Everything is protected via requests and explicit approvals.

That’s good for security. But it also means you need to understand the actual workflow for getting shell access, especially root access, when you might need it.

This post walks through the real‑world process, the UI flow, the approval logic, and the operational pitfalls. We’ll even cover the “I disabled the web console and need to fix that” scenario.

There are two ways to get SSH access. First, there is the Veeam Host Management console locally on the machine, the one that is available at first boot. After configuration, you will also have access via the web host management console over port 10443.

How to get root access?

Root access can be obtained through 3 pathways that are essentially the same. The first two are again the Veeam Host Management console, locally on the machine, and the web host management console on port 10443. Once you have SSH access, you can request root access via the Veeam Host management console over SSH as well. You can also restrict access via these interfaces.

Note

I also enable the security officer option in the lab. That can indeed be annoying during testing, but I like to train with the tools I will use when it’s for real. You learn and operate under the same restrictions as in production and, yes, suffer the same frustrations at times. That is the price of security.

The local Veeam Host Management console

At your appliance console, select Sign In.

Enter your username and password and hit ENTER.

When prompted, enter your OTP to login.

From that point on, everything you need lives under the Remote Access configuration.

To request shell access, you choose Enter shell.

As mentioned, we have a security officer, so approval must be granted by that person.

The security officer can now approve or decline your request.

FYI: the security officer sign-in is only available via the web console!

Note that the entry for the approved request does not disappear. The security officer can decline it at any moment. For example, when you notify the security officer that you have completed your work. If not, it will expire after 8 hours.

Anyway, the console message changed to “Press <Enter> to access shell” and “Press <F1> to disable shell access.”

Hit ENTER, and you have shell access with root privileges.

Note that this root shell access is:

  • Time‑limited / non‑persistent
  • Audited
  • The only supported escalation path

Enabling root shell access via the web host management UI

Navigate to the IP address or the FQDN of your appliance over port 10443 and log in.

Under Overview, you can request root access. Again, this triggers the security officer approval workflow.

Once approved, a warning is displayed indicating that access privileges have been elevated to root. Note that you can revoke these yourself at any time.

Once approved, the TUI will allow you to open a temporary, audited root shell.

Once shell access is approved, you can:

  • Choose Enter shell in the TUI on the physical or virtual console
  • or enable SSH and log in remotely

Note that you always authenticate as the Host Administrator, not root. Dropping into the shell is always as root. When logged in via SSH, you do not use sudo or su to become root. You have to launch the TUI manually. Just run:

/opt/veeam/hostmanager/veeamhostmanagertui

That is useful when you want to activate an already-approved root shell without returning to the physical or virtual console.

As you can see, you have the same interface and have to sign in again. You can then enter the shell only if approval has already been granted; otherwise, you’ll have to wait for your security officer to approve your request. For people without access to the physical or virtual console, requesting SSH access in combination with root shell access is the only option. SSH alone will never get you to root. Remember that. Because:

  • root login is disabled
  • SSH root login is disabled
  • sudo is restricted
  • No direct escalation paths exist outside the TUI, making it the only supported privilege‑escalation mechanism.

Turning off the host management web UI

The appliance also lets you turn off the host management web UI. Sure, it might sound great for even further hardening, but it comes with an ⚠️ Important catch: turning off the host management web UI can Lock You Out (unless you have physical or virtual console access).

If you disable the web console and you do not have shell access or SSH enabled, the only way back in is through the hypervisor VM console. The physical or virtual console is your last‑resort access path. If you lose that, you have basically lost the appliance if all other options are disabled.

Some operational tips

Use root access with care and only when needed

I hope this is self-explanatory.

Use the web host management console & enable SSH on demand

We handle normal operations via the web consoles and the full console. When SSH is needed, request it.

Never turn off the web console unless you have guaranteed VM console access

If your hypervisor is managed by someone else, for example, think twice. Silos and multiple layers of communication and responsibilities are productivity, efficiency, and support-killing factors in way too many “enterprise”- grade environments. For real people, “enterprise IT” is not the badge of quality and efficiency many think it is; quite the contrary.

The Security Officer must be on call

When you tie actions to a security officer, ensure they are on call and kept informed. Make sure these are people with a clue, not just someone who approves anything without knowing what or why. Also, make sure they are very well aware of what normal backup and recovery operations require and what constitutes an exceptional but valid request. Otherwise, you can’t approve shell or root requests when you need them, or everything gets approved. The technology is only as good as the people and the processes.

Conclusion

While root shell access may be needed in a real-world environment, it should be used only when necessary and with great care. That is why I advise you to enable the security officer in production. And if you are like me, use the security officer feature in labs to make sure you learn and know the processes where this approval is required. How to Open a Root Shell on the Veeam Software or Infrastructure Appliance is also documented on Veeam Backup Enterprise Manager Guide

How I Made Server 2012 R2 Love Hyper-V 2025

Posted on by
3

Introduction

Yes, Windows Server 2012 R2. Me, the most vocal proponent of keeping your environments up to date, to the level I barely have a Windows Server 2022 under my care anymore.

So what gives? Some people spun up a brand-new Windows Server 2025 Hyper-V cluster and migrated a truckload of their virtual machines over. I love modern infrastructure, so this all sounds very good until they reach out with a little issue. About a dozen of their virtual machines do not boot properly, but into the recovery console. My first question was what is the OS on those virtual machines? When the answer is Windows Server 2012 R2, maybe some Windows Server 2016, I had heard all I needed to know to help “fix” this. The real solution is not running those old out-of-support OS versions anymore, but we can “fix” it so your apps keep running while you upgrade or migrate.

Symptoms

Their older but business-critical Windows Server 2012 R2 VMs—and these were Generation 2, UEFI VMs, no less, but did not boot on their shiny new Hyper-V cluster. The migration itself went smoothly, they said, but when they started the virtual machines, the apps did not come up. So they checked the console logs of those virtual machines and saw STOP 0x0000007B: INACCESSIBLE_BOOT_DEVICE errors and recovery consoles. Rebooting did not help at all. This was a solid, reproducible crash loop, exactly at the point where the OS should hand off the bootloader to the kernel and find its disk. If you’ve been in the game for a while, you know that this usually spells one thing: a fundamental storage or bus driver issue. But why now?

The ACPI Identity Crisis

Windows Server 2012 (R2) and Windows Server 2016 are not supported on Windows Server 2025 Hyper-V. Upgrade or migrate before you move them.

This wasn’t just some random corruption. We were looking at a fundamental compatibility issue. To understand why, you need to understand how Hyper-V and the Guest OS communicate during the boot process.

Server 2012 R2 came out in 2013. Hyper-V 2025 is the latest of the greatest at the time of writing. In the decade between those releases, the “hardware signatures” (Hardware IDs, or HWIDs) that Hyper-V presents to a virtual machine have evolved.

In Gen 2 VMs, Windows relies heavily on the ACPI (Advanced Configuration and Power Interface) tables to find its critical components, especially the virtual machine bus (VMBus) and the storage controllers that attach to it.

When 2012 R2 boots, the kernel says, “Okay, ACPI, show me my storage bus.”

The Hyper-V 2025 host says, “Here is your storage bus, its ID is MSFT1000.”

The 2012 R2 kernel looks in its driver database and goes, “MSFT1000? I have no idea who that is. I’m looking for VMBus or nothing.”

Boom. It can’t see the bus, it can’t load the disk driver, and it can’t find itself so it suffers an Inaccessible Boot Device crash. As the guest has no clue what to do.

The “fix” is in some offline registry editing

Since the VM was in a crash loop and couldn’t boot to Windows, we had to perform some offline registry surgery. Luckily for them, the virtual machines could boot into their recovery environments, so they did not have to boot from an ISO to reach a command prompt and access the offline system hive.

We used a combination of reg load to “mount” the system registry from the VM’s disk onto our repair environment, and then some strategic reg copy commands to “spoof” the IDs.

Step by step

  1. Mounting the Hive:
    Code snippet
    reg load HKLM\TempHive c:\Windows\system32\config\SYSTEM

    (This assumes c: is where the VM’s Windows volume is mounted.)
  2. Map the VMBus to MSFT1000
    Code snippet
    reg copy HKLM\TempHive\ControlSet001\Enum\ACPI\VMBus HKLM\TempHive\ControlSet001\Enum\ACPI\MSFT1000 /s

    This is the core fix. We are telling the 2012 R2 system: “Look, if you ever see a device calling itself MSFT1000, don’t ignore it. Duplicate every single setting, driver binding, and service permission you have for ‘VMBus’ and apply it to this new ‘MSFT1000’ identity.” This essentially links the modern host’s ID to the older OS’s native VMBus driver stack.
  3. Mapping the Generation Counter to MSFT1002
    Code snippet
    reg copy HKLM\TempHive\ControlSet001\Enum\ACPI\Hyper_V_Gen_Counter_V1 HKLM\TempHive\ControlSet001\Enum\ACPI\MSFT1002 /s
    This maps the older Hyper_V_Gen_Counter_V1 identity—used for snapshots and consistency—to its modern equivalent on the 2025 host, MSFT1002. This is crucial for making sure integration services load properly.

After these commands, we had to run reg unload HKLM\TempHive to save our changes. We removed the ISO, rebooted, and… Bingo. The Server 2012 R2 boot screen appeared, and the login prompt followed shortly after.

This works because Server 2012 R2 has the necessary VMBus and storage drivers; it just doesn’t know they are compatible with the hardware IDs reported by Hyper-V 2025. This registry trick just creates that necessary driver-to-hardware binding.

But remember that this is an “unsupported” hack! While this gets the VM booting, moving 2012 R2 to newer hosts often means features might be degraded. Microsoft deprecated official support for 2012 R2 guests on modern hosts a while ago. Windows Server 2016 RTM without modern patching will suffer from the same issue, by the way.

Below is a complete script you can copy and paste into CMD.exe in your recovery environment to fix a virtual machine with this issue.

@echo off
echo.
echo ============================================================
echo   Hyper-V 2025 ACPI Fix for Windows Server 2012 R2 / 2016 RTM
echo   - Adds MSFT1000 (VMBus) and MSFT1002 (GenCounter)
echo   - Auto-detects ControlSet
echo   - Creates SYSTEM hive backup
echo ============================================================
echo.

:: --- Step 1: Detect Windows drive ---
echo Detecting Windows installation drive...
set WINDRV=

for %%d in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do (
    if exist %%d:\Windows\System32\Config\SYSTEM (
        set WINDRV=%%d:
    )
)

if "%WINDRV%"=="" (
    echo ERROR: Could not find Windows installation drive.
    echo Aborting.
    exit /b 1
)

echo Windows installation found on %WINDRV%
echo.

:: --- Step 2: Backup SYSTEM hive ---
echo Creating SYSTEM hive backup...
copy "%WINDRV%\Windows\System32\Config\SYSTEM" "%WINDRV%\Windows\System32\Config\SYSTEM.bak"
if errorlevel 1 (
    echo ERROR: Backup failed. Aborting.
    exit /b 1
)
echo Backup created: SYSTEM.bak
echo.

:: --- Step 3: Load SYSTEM hive ---
echo Loading SYSTEM hive into HKLM\TempHive...
reg load HKLM\TempHive "%WINDRV%\Windows\System32\Config\SYSTEM"
if errorlevel 1 (
    echo ERROR: Failed to load SYSTEM hive. Aborting.
    exit /b 1
)
echo Hive loaded.
echo.

:: --- Step 4: Detect active ControlSet ---
echo Detecting active ControlSet...
for /f "tokens=3" %%a in ('reg query HKLM\TempHive\Select /v Current') do set CS=ControlSet00%%a

if "%CS%"=="" (
    echo ERROR: Could not determine active ControlSet.
    reg unload HKLM\TempHive
    exit /b 1
)

echo Active ControlSet: %CS%
echo.

:: --- Step 5: Apply ACPI fixes ---
echo Applying ACPI fixes...

echo - Cloning VMBus -> MSFT1000
reg copy HKLM\TempHive\%CS%\Enum\ACPI\VMBus HKLM\TempHive\%CS%\Enum\ACPI\MSFT1000 /s /f

echo - Cloning Hyper_V_Gen_Counter_V1 -> MSFT1002
reg copy HKLM\TempHive\%CS%\Enum\ACPI\Hyper_V_Gen_Counter_V1 HKLM\TempHive\%CS%\Enum\ACPI\MSFT1002 /s /f

echo ACPI fixes applied.
echo.

:: --- Step 6: Unload hive ---
echo Unloading SYSTEM hive...
reg unload HKLM\TempHive
echo Hive unloaded.
echo.

echo ============================================================
echo   FIX COMPLETE
echo   You may now reboot the VM.
echo ============================================================
echo.
pause

Better to do this proactively; I have a PowerShell solution on GitHub that also includes the above .cmd script. The Invoke-TestAndFixHyperV2025ReadinessForLegacyVMs.ps1 script can handle virtual machines that are online, before you move them to Hyper-V 2025. https://github.com/WorkingHardInIT/Invoke-TestAndFixHyperV2025ReadinessForLegacyVMs

But I cannot migrate or upgrade yet!

I call bull shit on most of these in 99% of cases. And if it is not bullshit you really need to get your act together and work on fixing your apps/vendors to never allow getting into such a mess in the first place.

Conclusion

Tech debt. You know that thing every IT manager and department is preventing or solving for the last 30 years is still very much around. Despite all that ITIL, risk and change management, or maybe even due to all that talk and very little action.

Sometimes, saving the day isn’t about deploying the latest and greatest tech; it’s about diving into the deepest, darkest corners of the OS and tricking it into working just one more time. There are no guarantees, and this is a ticking time bomb.

I bought these people some time. Now they need to get working! I also kindly suggested they should read their backup vendors’ support statements 😉.