Moving SHIR binaries from C: to D: drive

Hi SC

It sounds like you’re weighing whether to move your Self-Hosted Integration Runtime (SHIR) install off your C: drive onto D:, especially in an HA auto-update scenario. Here’s a rundown of what you need to consider:

Is it advisable? • Officially, Microsoft doesn’t provide a supported “move-folders” procedure once SHIR is installed under Program Files. Auto-update and some service settings assume the default install path (C:\Program Files\Microsoft Integration Runtime\…). • If you really need the binaries on D:, the safest approach is to uninstall and re-install SHIR to D: in the first place (during the GUI setup you can pick a custom folder).

Pros & cons in HA: Pros – Frees up your OS drive (C:) for Windows/system files – Keeps large installers and logs off the smaller system volume Cons – Auto-update jobs may fail or not detect the IR service if they hard-code the original path – Complexifying your HA failover scripts: each node must have identical folder structure and service configurations – Troubleshooting might get confusing if logs, registry keys, or service definitions point to unexpected locations

Risks & limitations around auto-updates/patching/failover: • Auto-update leverages the Microsoft Integration Runtime Configuration Manager service and installer under Program Files. Changing that path can lead to “Upgrade now” not showing up or silently failing if the updater can’t find dmgcmd.exe or the service binary. • In an HA pair, one node might succeed in updating and the other might not, causing version drift. • Service-level failover scripts often reference the default path too, so you’d have to update any PowerShell or ARM templates that invoke the IR CLI.

Official guidance: • Microsoft’s docs don’t include a “move after install” procedure. They recommend:

1. Install SHIR where you want it (you get to change the folder on initial setup)
   1. Keep at least 10 GB free on the drive hosting SHIR for auto-updates
      1. In HA scenarios, keep all nodes identical (same OS patches, same IR version, same folder layout)
      Sample approach / PowerShell hint: There isn’t an “official” move script, but folks have used an NTFS directory junction:
      1. Stop the “Self-hosted Integration Runtime” Windows service on each node
         1. Copy “C:\Program Files\Microsoft Integration Runtime” to “D:\Microsoft Integration Runtime”
            1. Rename the original folder to something like “…_old”
               1. Run in an elevated cmd: mklink /J "C:\Program Files\Microsoft Integration Runtime" "D:\Microsoft Integration Runtime"
                  1. Start the IR service and verify it auto-updates/continues working Caveat: This is a community workaround, not officially supported.

Hope that gives you a clear picture. If you decide to move ahead or need more details, let us know:

• Which SHIR version you’re on?
• How many HA nodes and what OS version?
• Are you comfortable using directory junctions vs. pure re-install?
• Do you have any custom service-wrapper scripts or ARM templates referencing the old path?

The provided information does not describe or support moving existing self-hosted integration runtime (SHIR) binaries from one drive to another on the same VM. It only covers:

• How to install SHIR, including automation via PowerShell.
• How to add additional SHIR nodes for high availability and scalability.
• General installation and configuration best practices.
• How to use the D: drive as a data drive on a Windows VM, including pagefile relocation and attaching a new data disk.

From this content, only the following supported patterns can be stated:

1. For high availability and scalability, add additional SHIR nodes by installing SHIR on other machines (or VMs) and registering them with the same authentication key. Up to four nodes per SHIR are supported.
2. SHIR installation can be automated per node using the provided PowerShell scripts, which install and register a node with a given authentication key.
3. On Windows VMs, the D: drive is typically a temporary disk and must not be used for data that needs to persist; if an application must use D:, the documented approach is to attach a separate data disk and assign it the D: letter.
4. Installation best practices recommend installing SHIR on dedicated machines, keeping it close to the data source, and using auto-update.

The context does not provide:

• Any guidance or recommendation about relocating an existing SHIR installation from C: to another drive on the same VM.
• Any pros/cons, risks, or limitations specifically related to moving SHIR binaries between drives.
• Any official recommendation that SHIR should or should not be installed on C: vs. another data drive.
• Any sample script or procedure for moving SHIR binaries from one drive to another.

Because these details are not present, no statement can be made from the context about whether moving SHIR binaries from C: to D: is advisable, what the exact impact on auto-update or high availability would be, or how to script such a move. The only supported, documented approach for changing placement is to install/register SHIR on the desired drive/location as a node (or new node) using the standard installation and automation guidance.

References:

• Create and configure a self-hosted integration runtime
• Choose the right integration runtime configuration for your scenario
• Create and manage a self-hosted integration runtime
• Use the D: drive as a data drive on a Windows VM
• Self-hosted integration runtime for database migrations
• Automating self-hosted integration runtime installation using local PowerShell scripts