Skip to main content
InSource Solutions

TN - 1283 Troubleshooting Deployment Failures

Description

 

This article from InSource covers a deployment 'checklist' to go through when faced with a deployment issue

  • Author: Mario Meza
  • Published: 09/16/2022
  • Applies to: Application Server 2017 and above

Details

 

  1. Run Change Network Account Utility  “Run as Administrator” (even if you are an Administrator)   
    1. C:\Program Files (x86)\Common Files\ArchestrA\aaAdminUser.exe

    clipboard_e7afbf1f3c5de80a2a921abb7d41b0b51.png

 

  1. Run OSConfig Utility    “Run as Administrator” (even if you are an Administrator)

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

      clipboard_ee5fea6e6643b13e8a593e04c640ae7aa.png

  1. Validate Binding Order / Interface Metric of the primary NIC  (TN WW202)

 

  1. Relax System Management Server if possible or validate it is not being used

     Make sure to run Configurator with the option “Run as Administrator” (even if you are an Administrator)  

     clipboard_e0309e0dc0add738bf9a9655c954976c8.png

 

  1. Firewall Relaxed or Exceptions in place

     

  1. AV Exceptions in Place

 

  1. From Command prompt execute ping /a for getting through to DNS and to see what the return time is
    1. A DNS reply 5 second to DNS Server is no good. Per AVEVA you want reply 4 seconds or less for good deployment
    2. Best practice is to use a host file just need to make sure it’s updated should IP’s change.
    3. You need to ping by both host name & IP (the needs to be done from both sides of the connection)

 

       clipboard_e678652e8d61ab37e6207fe014fedd893.png

 

 

8. Validate Host File for accuracy  (TN WW208)

      clipboard_e5833325c41e58db78e0c2365260585a3.png

  1. Local Security Policy->Local Policies->Security Options ->     

               “System cryptography: Use FIPS complaint algorithms for encryption, hashing and signing” - Disabled

 clipboard_e353a5717a109ac59d1f726fccfde79f8.png

 

  1. Local Security Policy -> Local Policies -> Security Options ->  

                “Network Access: Let everyone permissions apply to anonymous users - Enabled

            clipboard_e169a5fa6d8393285b6d47ef4138525e5.png

  1. Apply TN 000022811 Troubleshooting Wonderware Application Server Bootstrap Communications

 

  1. Validate NT SERVICE\aaPIM is in Administrators Group and Service Logon are correct for the ArchestrA services

      (Ref TN 10225 New Accounts and Security Groups in Wonderware System Platform 2017 Update 3 and later )

     clipboard_ec0929c5bbc8178c76b80034fcc47cff5.png

  1. Logged in user is part of aaAdministrators and aaConfigTools group

     clipboard_e31d6aa398e9bbd6aeeb7ccc560d16a67.png

  1. Ensure any Installed KB is validated against Security Central Export  (One approach is outlined Step 3 of TN 10131)

                                               clipboard_e7a3e3888025a864ad9a5e7c846f90a42.png

 

  1. Test with a new object instance (Also applies to UDOs, Engines, Areas, Platforms etc)

  clipboard_e2f9ad733029784bb757c92492ee2c94b.png

 

  1. Try a deploy from another galaxy or create a test Galaxy (when possible)

 

  1. Run a Repair of the Software (ENSURE UNBLOCKED MEDIA is USED)

 

NOTE:   You may encounter an orphaned platform or a hung deployment while trouble shooting. This can result in a deployment conflict / mismatch.

Here are 3 options for dealing with them.

 

OPTION 1: Use the SMC

The preferred method to recover in these scenarios is to use the Remove Local Platform from the deployed client (NOT GR!

clipboard_ef7de9c2e54ace045596124fb617ea91d.png

Then in the IDE you would undeploy the node that was ‘Removed’ with the option ‘On fail mark as Undeployed’

clipboard_e7d049be400b4dd2753bdba04c7036e31.png

 

In some scenarios you may not see the 'remove local platform' option available in the SMC.

 

OPTION 2: Use the Killer / Remover Utilities

There are some utilities that remove platforms when run from the from the deployed client (DO NOT RUN ON GR!

Platform Remover (2016) WSP 2017 and above : https://insourcess.box.com/s/plik1oc6lgfrxbtfq0fjfv60nt82wjvt

A² Platform Killer WSP 2014 and below: https://insourcess.box.com/s/ijmjli3ddi06m0m85icbmonazvknx649

After running the appropriate utility for your version on the deployed client.

In the IDE you would undeploy the node that was ‘Removed’ with the option ‘On fail mark as Undeployed’

clipboard_e0663c6e73498a98e3f63b0fcec68c652.png

 

OPTION 3: Clean Up the Registry

Finally, there is a manual process which can be done by deleting orphaned entries from the registry.

MODIFICATIONS TO THE REGISTRY ARE DONE AT YOUR OWN RISK.

BEFORE MAKING ANY MODIFICATION ENSURE SURE YOU BACK UP AND TEST FIRST IN A SANDBOX

1. From the IDE undeploy the orphaned / hung node with the option ‘On fail mark as Undeployed’ (This should remove the node from registry of all nodes).

clipboard_eeae629cd78599faca95f03de9745b4cd.png

2. Go to RegEdit ->HKEY LOCAL MACHINE -> Software -> WOW6432Node -> Archestra -> Framework -> Platform -> PlatformNodes

clipboard_e5f5434147c67972dc2d18c439914ac1d.png

3. Verify that the remote node is gone from the list. If it’s not, it needs to be manually removed.

***Depending on size of galaxy this may be big task because you would have to do this on all nodes.

***Note on GR Platform0 and Platform1 should be the GR

 

Diagnostic Manager App

Nine times out of ten the above checklist list takes care of the issue, should it persist, the Diagnostic Manager App is a utility that (starting with 2017 U3) comes pre-installed with the product at: C:\Program Files (x86)\Common Files\ArchestrA\DiagnosticManagerApp.exe

 When run, there is a tab called useful tip. Once selected you can select the current issue from a drop-down list. When 'Deploy' is selected, components and relevant flags to enable will be listed. Enable these, try a deployment, and collect the log export filtered to the time of the deployment. These will be key when submitting a ticket with InSource.

clipboard_e7168b5278a1cc055a96dcfb1498dd56b.png