TN - IT09112608 - Troubleshooting AVEVA Bootstrap Errors

• Document Version: 001 
• Applies to Version(s): AVEVA System Platform 2020 and later

Description  

Bootstrap errors typically appear when the Galaxy Repository node or deployment process cannot communicate properly with the target node’s Bootstrap service. This usually points to a communication, DNS/name resolution, Windows security, network binding, or Platform installation issue.

Error Messages:

These errors may appear during object deployment or in the OCMC Logger in one of the following forms:

• Failed to get Bootstrap version
• Failed to create a remote interface for the version information from Bootstrap
• Platform Communication Error
• Can not communicate with remote node
• Bootstrap service is not found on the remote machine

You may encounter this issue when:

• Deploying a Platform, AppEngine, or another object to a remote node
• Redeploying after changing network settings, domain accounts, firewall rules, or service credentials. 

Before Starting the Troubleshooting Checklist:

This article provides general troubleshooting guidance for Bootstrap communication and deployment issues in AVEVA System Platform. We recommend following the troubleshooting steps in the order presented. Some steps modify Windows networking or security settings. If your organization manages these settings through corporate IT policies, coordinate any changes with your IT department before proceeding.

Troubleshooting Checklist:

Step 1: Verify the Bootstrap Service Is Running

Confirm that the Bootstrap service is running on both the Galaxy Repository node and the affected remote platform node. The service should be set to Automatic startup and in a Running state. This service can revert to Disabled after a System Platform repair, specifically when repairing or reinstalling Platform Common Services.

On both nodes, open services.msc and verify the following services are set to Automatic and Running.

• AVEVA Bootstrap - core bootstrap service for communication
• AVEVA Bootstrap Proxy - Required in System Platform 2023 and later. Must be running alongside the Bootstrap service.  

If either service fails to start, check the Windows Event Viewer Application and System logs for related errors before proceeding to the next step. 

Step 2: Run Change Network Account and OS Configuration Utility

If the System Platform network account has changed, has an expired password, or was not applied consistently, run Change Network Account on the affected node. 

Change Network Account (CNA) is located at:

C:\Program Files (x86)\Common Files\ArchestrA\aaAdminUser.exe 

Right-click → Run as administrator

After updating the network account, run the OS Configuration Utility. Run this utility anytime you experience issues connecting to a Galaxy, deploying a node, or launching the IDE. This utility corrects communication settings, registry settings, ports, and other OS-level configuration automatically.  

The OS Configuration Utility is located at:

C:\Program Files (x86)\Common Files\ArchestrA\OSConfigurationUtility.exe

Recommended order:

1. Run Change Network Account - Confirm the same user account type, username, and password are used consistently across System Platform nodes.
2. Run OS Configuration Utility
3. Reboot the node.
4. Confirm the affected System Platform services are running.
5. Retest deployment from the IDE.

Step 3: Verify Hostname Resolution Between Nodes

From both the Galaxy Repository node and the affected remote platform node, confirm that each computer can resolve the other by hostname and IP address. Run all commands from an elevated PowerShell or Command Prompt. Replace the placeholder values (for example, <TargetNodeName> and <TargetNodeIP>) with the hostname and IP address of the appropriate System Platform node.

From the Galaxy Repository node, test communication to the remote platform node:

ping <TargetNodeName>
ping -a <TargetNodeIP>

The first command tests forward name resolution (hostname → IP). The second uses -a to test reverse name resolution (IP → hostname). Run both to confirm resolution works in each direction. 

The output should show the node's fully qualified domain name (FQDN) or hostname and IP address, for example:

If the hostname or FQDN is missing, incorrect, or does not match the expected node, reverse resolution may not be working correctly.

Then run nslookup to confirm that DNS resolves the hostname to the expected IP address:

nslookup <RemoteNodeName>

Expected output:

From the remote platform node, test communication back to the Galaxy Repository node:

ping <GRNodeName>
ping -a <GRNodeIP>                                    

Then confirm DNS resolution to the GR node:

nslookup <GRNodeName>

Note: nslookup queries the configured DNS server directly and does not use the local HOSTS file or DNS resolver cache. If nslookup returns the expected address but ping resolves the name to a different IP address, verify that the HOSTS file does not contain an incorrect entry, and clear the resolver cache with ipconfig /flushdns. Use ping or Test-Connection to verify the address Windows is actually using. 

Step 4: Check the Windows HOSTS File

If DNS resolution is unreliable, incorrect, or affected by multiple network adapters, verify the Windows HOSTS file on the Galaxy Repository node and the affected remote platform node. In workgroup, non-domain, or isolated environments where DNS is not reliable, HOSTS file entries may be required.

Warning: Entries in the HOSTS file take precedence over DNS. An incorrect or outdated entry can cause name resolution to fail even when DNS is configured correctly. Always verify existing entries before adding or modifying HOSTS file entries. 

The HOSTS file is located at:

C:\Windows\System32\drivers\etc\hosts

To edit the HOSTS File:

1. Right-click Notepad → Run as administrator
2. File → Open → navigate to C:\Windows\System32\drivers\etc\hosts
3. Open the file, make edits, then Save. Do not use Save As, as this may append .txt to the filename, causing the HOSTS file to be ignored by Windows.

Review the existing entries and confirm there are no stale or incorrect mappings from previous IP address changes, renamed machines, cloned virtual machines, or old lab environments.

If needed, add entries for the Galaxy Repository and remote platform nodes at the bottom of the file using the following format:

192.168.10.20     LAB-GR01     LAB-GR01.aveva.lab
192.168.10.30     LAB-VIS01    LAB-VIS01.aveva.lab

Example:

Add both the short hostname and fully qualified domain name if both are used in the environment.

For initial troubleshooting, update the HOSTS file on the Galaxy Repository node and the affected remote platform node. In a production environment, ensure name resolution is consistent across all System Platform nodes.

After saving, flush the DNS cache on each node:

ipconfig /flushdns

Then retest name resolution:

ping <RemoteNodeName>
ping <RemoteNodeName.domain.local>

The returned IP address should match the expected remote node IP address.

Step 5: Review Firewall and Antivirus Settings

Confirm that the Windows Firewall or third-party security software is not blocking System Platform communication. Verify that the required System Platform ports are open on both the Galaxy Repository node and the affected remote platform node.

If testing requires disabling the firewall or antivirus temporarily, re-enable it after testing and configure the required exceptions instead of leaving protection disabled. 

For the complete list of System Platform ports, see:

Ports used by System Platform products
https://docs.aveva.com/bundle/system-platform/page/686254.html

For antivirus, review and apply AVEVA's recommended exclusions for ArchestrA services and directories. AV software scanning ArchestrA processes in real time is a known cause of communication and deployment failures. 

Refer to AVEVA's antivirus exclusion guidance below. 

AVEVA Antivirus Exclusions
https://softwaresupportsp.aveva.com/en-US/knowledge/details/000032662?lang=en_US

Step 6: Confirm Network Interface Priority

On all AVEVA System Platform nodes, ensure the ArchestrA network adapter is the preferred network interface. This prevents Windows from routing ArchestrA traffic through a secondary or lower-priority network adapter, which can cause intermittent Bootstrap and deployment failures. 

On both the Galaxy Repository node and remote platform node, navigate to: 

Control Panel → Network and Internet → Network Connections

Right-click the ArchestrA network adapter and select Properties.   

In the Ethernet Properties window, navigate to:

Properties → Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced

In the Advanced TCP/IP Settings window:

• Uncheck Automatic metric
• Set Interface metric to 1. In Windows, a lower metric value indicates a higher routing priority, so setting it to 1 gives this adapter priority over other network interfaces with higher metrics.

Leaving Automatic metric enabled allows Windows to decide the priority. In System Platform environments, this may cause ArchestrA communication to bind to the wrong adapter or route traffic unexpectedly.

Disable IPv6

AVEVA recommends disabling IPv6 on all System Platform nodes. With IPv6 enabled, Windows may attempt to resolve hostnames over IPv6 before falling back to IPv4, causing unexpected communication failures.

In the same Ethernet Properties window, uncheck Internet Protocol Version 6 (TCP/IPv6) on the ArchestrA network adapter. Apply this setting on every System Platform node. 

Note: This is not necessary for VMWare adapters. 

Step 7: Review DCOM/RPC Communication

Bootstrap communication relies on Windows DCOM/RPC communication between the Galaxy Repository node and the remote platform node. If the previous checks do not resolve the issue, verify that DCOM/RPC traffic is not blocked and that Distributed COM is enabled.

Open Component Services:

dcomcnfg

Navigate to:

Component Services → Computers → My Computer → Properties → Default Properties

Confirm that Enable Distributed COM on this computer is checked.

If the system has been hardened by IT policy, also review DCOM Launch and Activation permissions and Access permissions under the COM Security tab, and confirm the ArchestrA network account has the necessary local and remote permissions. 

Note: Compare with a working node before modifying machine-wide DCOM permissions.

Step 8: Check for Node Configuration and Machine Role Conflicts

One of the most common and overlooked causes of Bootstrap communication errors is a node configuration issue introduced during installation or maintenance. A node may appear healthy but still be misconfigured in a way that prevents it from communicating with the Galaxy correctly.

Common configuration mistakes that can cause these failures include: 

• The node name was changed or does not match the network address configured for the Platform object in the IDE.
• The node was previously part of a different Galaxy and is still carrying stale registry keys or Galaxy association. 
• There are duplicate node names on the network.
• Duplicate Platform IDs (commonly introduced by cloning or incomplete cleanup) may prevent Bootstrap registration.
• A remote platform node was incorrectly assigned the Service Repository role during installation. Only the Galaxy Repository node should have this role. 

On the remote platform, run a Common Services Portal scan from C:\Program Files (x86)\AVEVA\Platform Common Services\Portal\Pcs.Portal.exe and confirm the platform is configured as a Runtime node with no configuration errors.

If the machine role has been incorrectly configured, see Troubleshooting Service Repository Errors in Additional Resources below for the correction procedure. 

Step 9: Repair the System Platform Installation

If the Bootstrap service is missing, damaged, will not start, or continues to fail after completing the network and permission checks above, repair the System Platform installation.

Run the main System Platform installer (Right-click setup.exe → Run as Administrator) and select the Repair option:

After the repair is complete:

1. Run through the configurator if prompted and confirm all required components are configured.
2. Re-run Change Network Account and the OS Configuration Utility on the repaired node.
3. Confirm the AVEVA Bootstrap and Bootstrap Proxy services are running. 
4. Retest deployment from the IDE. 

If you experience additional issues, please contact technical support. 

Additional Resources:

OS Configuration Utility
https://docs.aveva.com/bundle/sp-appserver/page/579035.html

Change Network Account Utility
https://docs.aveva.com/bundle/sp-appserver/page/324753.html

Troubleshooting Deployment Failures
https://knowledge.insourcess.com/aveva-application-server-tech-notes/tn_-_1283_troubleshooting_deployment_failures

Common Platform Errors During Deployment
https://knowledge.insourcess.com/aveva-application-server-documentation/common-platform-errors-during-deployment

Industrial Application Server Deployment Checklist
https://softwaresupportsp.aveva.com/en-US/knowledge/details/000022923?lang=en_US

Troubleshooting Service Repository Errors
https://knowledge.insourcess.com/aveva-application-server/troubleshooting-service-repository-errors