Troubleshooting

1. Login to the appviewx pods CLI to check communication
   1. On Prem : Login in to the appviewx CLI, go to the vendor pods.
   2. Saas : Login to the Cloud Connector, go to the platform pod.
2. After logging in, run the commands below in the terminal.

   nc -zv <Ip or hostname> <8999 or configured port>

   where,
   • <Ip or hostname> is the hostname or IP of the windows agent machine.
   • 8999 is the default port of Windows Agent (provide the configured port in case of any custom port).

Connection to 192.168.142.124 8999 port [tcp/*] succeeded!

• It is recommended to select Subject Name = Supply in CSR instead of Build from Active Directory when configuring the certificate template.

  If the error occurs/persists despite selecting Supply in CSR, the certificate enrollment error response will include a Request Disposition Message and Request Status Code. Execute resolution steps according to the disposition message and status code displayed.

  Alternatively, you can check the disposition message and status code manually. To do this:

  1. In the Certification Authority Desktop app, for the the required CA instance, go to Failed Requests.
  2. For more details on what triggered the error, for the corresponding Request ID, read the Request Status Code and the Request Disposition Message.

     You can sort the Request ID column/view the Request Submission Date to identify the correct request ID.

  3. Execute resolution steps according to the status code and disposition message.
• Ensure that the CSR parameters populated for certificate enrollment are in accordance with the template configuration requirement defined by Microsoft CA.
  To view the template configuration:

  1. In the Certification Authority Desktop app, for the the required CA instance, go to Failed Requests.
  2. For the corresponding Request ID, see the Certificate Template mentioned.
  3. For the the CA instance, right click Certificate Templates.
  4. From the menu displayed, select Manage.

     A list of certificate templates is displayed.

  5. From the list of templates, right click the certificate template used for this enrollment request and select Properties.
  6. In the properties dialog box, go through all the template tabs to view the requirement configured for each parameter of the template.

• Incorrect Network Path or Hostname: The provided hostname or shared path may be invalid or incorrectly formatted.
• SMB Share Not Available: The required shared folder may not exist or is not accessible on the target server.
• Permission Issues: Insufficient access rights to the shared resource
• Network or Firewall Restrictions: Network policies may be preventing access to the target system or shared path.

1. Validate network path accessibility
   1. Log in to the Windows Gateway machine.
   2. Open the Run dialog box (Win + R).
   3. Enter the network path:

      \\<target-server>\<share-name>

   4. Check if the same error (Network Name Not Found) is reproduced.

      If yes, the issue is at the network/share level and not specific to AppViewX.

2. Try using FQDN.
   Access the share using the Fully Qualified Domain Name:

   \\<server-name>.<domain-name>\<share-name>

3. Verify the shared resources on the target server.
   1. On the target server, run:

      net share

   2. Ensure the required share exists and is correctly configured.
4. Validate permissions.
   Ensure the user account used for the operation has:

   • Access to the shared folder
   • Required share and NTFS permissions
5. Check connectivity from the gateway.
   1. Try accessing the share directly through the File Explorer:

      \\<target-server>\<share-name>

   2. Provide credentials if prompted and verify access.

1. Verify the error.
   1. Run the following command from the Windows Gateway machine:

      Enter-PSSession -ComputerName <FQDN>

   2. Confirm the error: WinRM cannot process the request (0x80090322)
2. Check and fix SPN configuration.
   1. Run:

      setspn -q http/<FQDN>

   2. Ensure the SPN is associated with the target server’s computer account and not a different service account.
   3. If incorrect, update or remove the conflicting SPN entry.

• Microsoft Learn

• Username Format Issue: Using username or domain\username may not always be resolved correctly in certain environments.
• Authentication Context Mismatch: The domain context of the user is not properly identified during authentication.
• Logon Permission Restrictions: The account may not have the required access on the target machine.

1. Verify the issue.
   Attempt a remote session from the Windows Gateway:

   Enter-PSSession -ComputerName <FQDN> -Credential <username>

   The connection may fail due to authentication or logon-related errors.
2. Use UPN format for authentication.
   • Provide the service account in the User Principal Name (UPN) format:

     username@domain

   • In some environments:
     • username → may fail
     • domain\username → may fail
     • username@domain → succeeds
   • Using UPN format ensures that the correct domain context is applied during authentication and helps avoid ambiguity in user resolution.

• Missing Authority Key Identifier (AKI): The leaf certificate may not include the AKI field.
• Incomplete Chain Information: The gateway relies on both Authority Key Identifier (AKI) and Subject Key Identifier (SKI) to build and validate the certificate chain.
• Certificate Chain Validation Failure: The issuing CA cannot be correctly identified.
• Expired Certificate: The certificate used for authentication is no longer valid.
• Invalid EKU (Enhanced Key Usage): Required usages such as Server Authentication and/or Client Authentication are not present.

1. Verify the certificate.
   Inspect the certificate and ensure:

   • Authority Key Identifier (AKI) is present
   • Subject Key Identifier (SKI) is present
   • Certificate is not expired
   • EKU includes:
     • Server Authentication, or
     • Client Authentication, or
     • both (based on use case)
2. Request updated certificate.
   Check with the customer/CA team to re-issue the certificate with:

   • Both AKI and SKI extensions
   • Valid expiry period
   • Required EKU values
3. (Workaround) Enable thumbprint-only validation
   To unblock the operation, configure the Windows Gateway to validate only the certificate thumbprint:

   1. Stop the AppViewX CLM service.
   2. Open Notepad as Administrator and open AppViewX.CLM.WindowsService.exe.config.

• Kerberos Double-Hop Limitation: By design, Kerberos does not allow credentials to be forwarded from one remote system to another (second hop).
• Delegation Not Configured: The intermediate server is not trusted to delegate user credentials to downstream systems.
• Missing or Incorrect SPNs: Required Service Principal Names (SPNs) for the target services are not configured.
• WinRM Not Properly Configured: PowerShell remoting may not be enabled or properly configured for Kerberos authentication.

1. Verify the issue.
   1. From the Gateway server (ServerA), initiate a remote session:

      Enter-PSSession -ComputerName ServerB -Authentication Kerberos -Credential Domain\Username

   2. Execute operations that require access to downstream services (for example, Exchange/Active Directory).

      The operation may fail with errors such as: 0x8009030e (A specified logon session does not exist).

      This indicates a Kerberos double-hop limitation.
2. Enable WinRM for PowerShell Remoting.
   1. On both Gateway (ServerA) and Exchange server (ServerB), run:

      Enable-PSRemoting -Force

      Ensure:
      • WinRM service is running.
      • Firewall rules allow WinRM traffic.
3. Validate and configure SPNs.
   1. On the Domain Controller (ServerC), verify the SPNs:

      setspn -L ServerC

   2. Ensure the following SPNs exist:
      • HOST/ServerC
      • WSMAN/ServerC
   3. If the HOST/ServerC SPN is missing, execute the following command:

      setspn -S HOST/ServerC ServerC

      If the WSMAN/ServerC SPN is missing, execute the following command:

      setspn -S WSMAN/ServerC ServerC

4. Configure Kerberos constrained delegation.
   1. On the Domain Controller (or AD management system):
      1. Open Active Directory Users and Computers.
      2. Navigate to the ServerB → Properties → Delegation tab.
      3. Select:
         • Trust this computer for delegation to specified services only
         • Use Kerberos only
      4. Click Add and select ServerC.
      5. Add the following services:
         • HOST/ServerC
         • WSMAN/ServerC
   2. Optionally, verify the delegation using PowerShell:

      Set-ADComputer "ServerB" -TrustedForDelegation $true
      (Get-ADComputer "ServerB" -Properties TrustedForDelegation).TrustedForDelegation
      

5. Clear the Kerberos tickets.
   On the Gateway server (ServerA), run:

   klist purge

   Alternatively, restart the involved servers to refresh the Kerberos tickets.
6. Test the Kerberos Double-Hop.
   1. From the gateway server, execute the following command:

      Enter-PSSession -ComputerName ServerB -Authentication Kerberos -Credential Domain\Username

   2. From within the session, run the following command:

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      Get-ExchangeServer | ForEach-Object { $_.Name + ' -> ' + $_.AdminDisplayVersion }
      

      Successful execution of the command confirms that the double-hop authentication is working.