In-place upgrade Windows Server 2022 → 2025 on Azure VM hosting Self-Hosted Integration Runtime (ADF) — impact on SHIR configuration/credentials?

K Yogesh 0 Reputation points
2026-08-26T13:14:45.8433333+00:00

We're planning an in-place OS upgrade of an Azure VM from Windows Server 2022 Datacenter to Windows Server 2025 Datacenter, following the documented procedure at learn.microsoft.com/en-us/azure/virtual-machines/windows-in-place-upgrade.

Environment details:

  • Azure VM (Gen2, managed disk, non-zonal, Central India region)
  • Currently running Windows Server 2022 Datacenter
  • The VM hosts a Self-Hosted Integration Runtime (SHIR) registered to an Azure Data Factory instance, used to connect ADF to an on-prem/IaaS Oracle database
  • The VM also runs Python scripts and generates Power BI report files that other processes depend on
  • This is a single-node SHIR (no HA pairing configured)

What we already know:

  • The OS Upgrade Assessment Tool currently reports a disk space failure (only ~27 GB free of 128 GB; documentation calls for meeting the storage requirement before proceeding), which we'll resolve first
  • We understand the in-place upgrade is designed to preserve apps, settings, and data, and that Windows Server 2025 is listed as a supported target
  • We understand SHIR is documented as supported on Windows Server 2025
    • We understand the upgrade causes a data-plane/control-plane disconnect afterward (Auto guest patching, Auto OS image upgrade, Hotpatching, Azure Update Manager become unsupported for this VM)
    What we could NOT find clearly documented:
    1. Is there any official Microsoft guidance specifically confirming that a Self-Hosted Integration Runtime installation survives an in-place Windows Server OS upgrade without requiring re-registration? We understand SHIR encrypts its configuration using Windows DPAPI tied to the local machine — does an in-place upgrade preserve the machine's DPAPI keys, or is there any scenario where the SHIR service fails to start or loses its registration after the OS version changes underneath it?
      1. Are there any known compatibility issues or required post-upgrade steps specifically for ADF Self-Hosted Integration Runtime after an in-place OS upgrade (e.g., manual re-registration, reinstalling the IR package, .NET Framework dependency changes between Server 2022 and Server 2025)?
        1. Since antivirus/firewall software must be disabled during the upgrade process per the documentation, could this affect the SHIR's outbound connectivity to Azure Data Factory or leave it in a broken state if the upgrade fails partway through?
          1. Is there a recommended validation checklist specifically for SHIR nodes post in-place-upgrade (beyond the generic OS-level "verify VM boots correctly" guidance)?
            1. Given this VM is a single SHIR node with no HA pairing, is Microsoft's official recommendation still to proceed with in-place upgrade, or would Microsoft's guidance favor deploying a second SHIR node for HA before attempting the upgrade, to avoid a hard dependency outage during the maintenance window?
    Any pointers to official documentation, known issues, or field experience from Microsoft engineers who've handled SHIR + in-place upgrade together would be greatly appreciated. We want to avoid an unplanned SHIR outage on a production ADF pipeline that connects to Oracle.
Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Allan Solomon Mejia 7,585 Reputation points
    2026-08-26T19:40:57.3733333+00:00

    Hello @K Yogesh

    Your understanding is mostly correct, but I would not treat preservation of the Self-Hosted Integration Runtime (SHIR) registration and locally stored credentials as guaranteed by the Windows in-place upgrade documentation.

    Microsoft documents that an in-place Windows Server upgrade preserves settings, server roles, and data, and Windows Server 2022 → 2025 is a supported upgrade path. However, the Azure VM documentation doesn't specifically state that an existing ADF SHIR registration/credential store is guaranteed to survive the OS upgrade.

    For SHIR specifically, Microsoft documents that credentials stored locally are encrypted using Windows DPAPI and stored on the SHIR machine. Microsoft also provides a supported SHIR backup/restore mechanism that includes the node key and data-store credentials.

    Because this is a single production SHIR node with no HA, I would take the following precautions before upgrading:

    1. Resolve the Upgrade Assessment Tool disk-space failure first. Don't proceed while the assessment reports a blocking condition.
    2. Take snapshots/backups of the OS and applicable data disks. Microsoft specifically recommends disk snapshots before an Azure VM in-place upgrade.
    3. Back up the SHIR configuration/credentials using the documented SHIR backup functionality and securely retain the IR authentication key.
    4. Record the installed SHIR version, service configuration, Oracle client/driver versions, DSNs/environment variables, Python version/packages, service accounts, and firewall/proxy settings.
    5. Perform a representative ADF → Oracle pipeline test immediately before the maintenance.
    6. After the upgrade, verify that the SHIR service starts and the node shows Online in ADF, then test linked-service connectivity and run an actual Oracle-dependent pipeline.
    7. Also validate the Python/Power BI automation separately, since those dependencies aren't covered by SHIR compatibility.

    I would not manually re-register or reinstall SHIR after the upgrade unless it's actually necessary. First, check whether the existing installation comes online normally. If the local SHIR configuration or credentials don't survive, use the documented backup/recovery procedure rather than rebuilding the configuration from memory.

    Regarding antivirus/firewall: Microsoft does instruct you to disable them during the Azure VM upgrade and re-enable them afterward. That doesn't imply that SHIR loses its registration, but after re-enabling them verify the outbound endpoints/ports required by SHIR.

    For a production dependency, I would also strongly consider deploying a second SHIR node before the upgrade. Microsoft supports multiple SHIR nodes for high availability, and credentials are synchronized between nodes. That gives your ADF pipelines somewhere to run while this VM is unavailable or if the upgraded node needs remediation.

    One additional Azure-specific point: Microsoft warns that after an Azure VM in-place OS upgrade, Auto guest patching, Auto OS image upgrades, Hotpatching, and Azure Update Manager aren't officially supported for that VM, because the Azure control-plane image metadata still represents the original image. If retaining those capabilities matters long term, deploying a new Windows Server 2025 VM and adding it as another SHIR node is the cleaner architecture.

    So my recommendation for this production workload would be:

    Second SHIR node → verify synchronization and Oracle connectivity → back up the existing SHIR → snapshot the VM → perform the upgrade → validate SHIR and pipelines → remove the temporary node later if HA isn't required.

    That avoids making the Windows upgrade itself the single point of failure for your ADF → Oracle pipeline.

    Sharing these references with you:

    In-place upgrade for Windows Server Azure VMs

    Create and configure a Self-Hosted Integration Runtime

    Integration Runtime concepts

    Azure CLI – SHIR credential synchronization

    Please "Accept the Answer" if this information helped you. This will help us and others in the community.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.