Resolving error code 1722 when OPSWAT ONTAP Connector tries to connect to ONTAP AV Connector

Overview

This document describes a troubleshooting and resolution procedure for a scenario where the OPSWAT ONTAP Connector receives RPC_S_SERVER_UNAVAILABLE (error 1722, 0x6BA) when connecting to a named pipe on a hardened Windows Server, even though the pipe is confirmed to exist on the server.

The issue was observed against a server running NetApp ONTAP AV Connector, where the OPSWAT ONTAP Connector connects to the pipe \\127.0.0.1\pipe\ntapvscp. The same pattern applies to any same-host RPC-over-named-pipes integration that uses an SMB-style pipe path (\\127.0.0.1\pipe\..., \\localhost\pipe\..., or \\<hostname>\pipe\...).

Symptoms

The OPSWAT ONTAP Connector logs an entry similar to the following when the registration call fails:

Additional indicators:

• The Win32 error code 1722 (RPC_S_SERVER_UNAVAILABLE) appears in the OPSWAT ONTAP Connector log.

• The named pipe is confirmed to exist on the server (visible under \\.\pipe\).

• The connection target is the loopback interface (127.0.0.1), so no network device or external firewall is involved.

• The host has been hardened according to a security baseline (CIS, STIG, or vendor-specific hardening).

Root Cause

Named-pipe access through an SMB-style path (for example \\127.0.0.1\pipe\ntapvscp) routes through the SMB redirector and requires:

1. A listener on TCP 445.

2. A valid inbound firewall rule allowing the connection.

3. SMB Server bound to a network interface (which is what creates the listener).

On a hardened host, all three of these layers are commonly disabled to reduce the attack surface. The combination produces the observed failure chain:

Note that the AV Connector itself, the named pipe, and the local RPC subsystem are healthy. Only the SMB transport layer used to reach the pipe is broken.

Diagnostic Procedure

Run the following commands in an elevated PowerShell session on the affected host.

1. Confirm the named pipe exists

2. Confirm RPC over the local NPFS path works (bypasses SMB)

A successful result (Completed 1 calls in N ms) proves the pipe and the local RPC stack are healthy.

3. Reproduce the failure over the SMB path

A failure with Exception 1722 and an inner status of 0x40 (ERROR_NETNAME_DELETED) or 0x3B (ERROR_UNEXP_NET_ERR) confirms the SMB path is broken.

4. Test TCP 445 reachability on loopback

TcpTestSucceeded : False indicates nothing is listening on TCP 445.

5. Identify which layer is broken

A typical hardened-host signature is:

• LanmanServer is running.

• Get-NetTCPConnection -LocalPort 445 -State Listen returns nothing.

• Get-SmbServerNetworkInterface returns nothing.

• The File and Printer Sharing (SMB-In) firewall rule is Enabled: False.

• Get-NetAdapterBinding -ComponentID ms_server shows Enabled: False on the active adapter.

Resolution

The fix restores SMB inbound on the host while keeping the customer's hardening intact for everything except loopback.

Run the following in an elevated PowerShell session:

If the active adapter is named something other than Ethernet, substitute the correct name from Get-NetAdapterBinding -ComponentID ms_server.

Verification

After applying the fix, run the following to confirm each layer is healthy:

Once rpcping succeeds against the SMB path, reproduce the original failure with the OPSWAT ONTAP Connector. The connector should now open the pipe and complete the RPC call without RPC server is unavailable, and VS_Registration2 should complete successfully.

Why This Happens on Hardened Hosts

Common hardening baselines disable inbound SMB to reduce lateral-movement risk. Typical changes include:

• Disabling the File and Printer Sharing (SMB-In) firewall rule for all profiles.

• Unchecking "File and Printer Sharing for Microsoft Networks" on every network adapter, which removes the binding the SMB Server uses to create its TCP 445 listener.

• Stopping or disabling the LanmanServer service.

Any one of these disables inbound SMB. The hardened host in this case had two of the three applied (the firewall rule and the adapter binding). The Server service was still running, but with no adapter binding it had nothing to listen on, so port 445 was effectively closed even on loopback.

Recommendations

For the customer

1. Document the exception in the host's hardening baseline. A subsequent hardening sweep applied through GPO, Intune, or a hardening tool will revert these settings unless the exception is encoded in the baseline.

2. Keep the firewall rule scoped to 127.0.0.1 only. This restores SMB exactly enough for same-host named-pipe IPC and does not expose port 445 to the network.

3. If an EDR product is present, verify it does not re-block SMB at the session layer. Some EDRs flag SMB sessions as lateral movement and reset them even when the OS allows the traffic.

Reference: Error Codes Encountered

Reference: rpcping Endpoint Syntax

When -s already specifies the server, the -e argument must be the bare endpoint name without server prefix: