How To: Troubleshoot a Management Gateway New Install

Version 19

    Verified Product Versions

    LANDESK Management Suite 9.6

    The Comprehensive Guide for Troubleshooting a Management Gateway New Install

    Description

     

    These two documents give a quick list and/or method for validating install

     

     

     

    Applies to LDMS 8.7 - 8.8, LDMG iso 05/02/07, LANDesk Management Gateway Appliance.
    This guide was designed to pinpoint the area causing the problem without unnecessary troubleshooting steps. This guide assumes that the Gateway and Core have been configured based on the Deployment Guide but for whatever reason it is not working correctly.
    Follow each step in order and follow the hyperlinks when prompted or when they apply.
    For help with Gateway Activation click here.

     

    Troubleshooting

    I: Test SSL and Network Connectivity 1) Open a web browser on the core server to https://gatewayname/gsb where gatewayname is the gateway’s hostname or inside IP address. If this fails see Network Connectivity
    2) Open a web browser on a machine on the internet to https://gatewayname/gsb where gatewayname is the gateway’s public name or public IP address. If this fails see Network Connectivity

     

    II: Ensure the core has established its service level connections 1) Once connectivity is established then determine if the core launches its 6 broker_service connections.
    Go to https://gatewayname/gsb click on reports and then click on the gateway connection table. There should be 6 total service level connections. If there are not then see Service Level Connections.
    2) On the Configure Management Gateway page: If gateway service stops after test is ok and post is ok then see Service Level Connections.
    If test fails then recheck the information ensuring the service account on the gateway is not locked. The service password is the one used on the Configure Management Gateway page, it does not change when the admin password is changed.
    If the "test" continues to fail but the service password matches then see Network Connectivity

     

    III: Prove whether or not the Gateway handles remote control connections (These steps can be taken from any machine on the internet)
    1) Download an rcclient.exe and rcviewer.exe from any management gateway.
    If port 80 is closed on the end user’s, then use ours  http://ldmg.landesk.com/client/index.php http://ldmg.landesk.com/client/tools.php
    2) Launch the rcviewer.exe and let it install, clicking “yes to all” if prompted to overwrite.
    3) When prompted enter in the gateway public name or IP of the end user's gateway and enter in a gateway account, either admin or a newly configured user. Ensure the organization is * for this user.
    4) Next stop your issuser.exe process from running(in task manager) and then launch rcclient.exe. When prompted, type in the end user’s public gateway name.
    5) From the viewer you should now see your own client connecting. If your connection does not appear see Troubleshooting On-Demand Remote Control.

     

    IV: Client Configuration and certificates (This step is designed for LD Support, Partners, and users with a second working core. This step can however be followed on the affected user's machines to ensure the correct steps have been taken).
    1) Get the “service” user password from the gateway
    2) On a lab core open up the “Configure \ Management Gateway” tool
    3) Fill out the public name & IP (if 3rd party) or both public and private name & IP (if first party) as well as putting in the service account password.
    4) Click test, if this is ok then post a certificate to the gateway on the next tab. If the test fails, recheck the information entered.
    5) After successfully posting a certificate, run brokerconfig.exe exe found in the C:\Program Files\LANDesk\LDClient\ folder on a lab client.
    6) Click on the gateway information tab and enter in the end user’s public IP or name for their gateway. Click update and then close.
    7) Reopen brokerconfig.exe to ensure the information is updated on the certificate request tab. Wait one minute to allow the core to establish connections. Enter your console credentials and click send.
    If the request is successful then it is proven the problem is likely a client side or certificate problem, see Client Certificates.
    If the request fails, then the gateway configuration needs to be looked at closer and the problem isn’t necessarily just a client certificate issue. The advanced steps below can be followed for further troubleshooting.

     

    -  -  -

    Advanced Troubleshooting


    1) Network Connectivity:  Ensure port 443 is open bi directionally for traffic going to the gateway, if this has been done see below for configuration tips.
    A. Single NIC:
    In LDLinux console under Network Configuration Configure E0 to the private IP with the Default Gateway as the public Default Gateway
    The network department will need to configure a 1 to 1 nat so when public traffic hits the edge firewall destination (public IP), it is translated to (internal IP) and goes to the gateway.
    In configure management gateway enter in the publicly resolvable name, and public ip in the top section This is how the clients talk to the gateway when on the internet.
    Check use seperate internal ip and put in the resolvable hostname and internal ip This is how the core talks to the gateway.

     

    B. Dual NIC:
    In LDLinux console Configure E0 to the public IP with the Default Gateway as the public Default Gateway. Eth1 would be assigned a private IP and have no default gateway configured.
    In configure management gateway enter in the publicly resolvable name, and public ip in the top section This is how the clients talk to the gateway when on the internet.
    Check use seperate internal ip and put in the resolvable hostname and internal ip This is how the core talks to the gateway.

     

    For Dual NIC configurations, if the core is on a separate subnet then the gateway internal IP; Then a route must be configured so traffic can reach the core server from the gateway instead of bouncing back and hitting the public default gateway. See Adding Routes:(these commands are available to the admin LDLinux user)

     

    The gateway certificate script can now be deployed to the clients or run broker config manually on the client.

     

    C.If just Public Connectivity fails:
    If the gateway management page will not open under https from the public internet then try opening it with http(requires port 80 to be open)
    Make note of the error code or what fails when browsing to the gateway. If a credentials popup comes up or a certificate popup appears then we are hitting the gateway.
    If the page simply never loads and is not found, then either routing is set up incorrectly or our SSL traffic is not being allowed.

     

    2) Service Level Connections
    Open the gateway administration web page (https://gatewayname/gsb).
    Click on "Users."
    Unlock the service account if it is locked.
    Ensure the correct password is being used in the Gateway Information tab before posting the certificate. This is the service account password, the same password that was used when setting up the gateway. If you cannot remember the password, set the password through the gateway adminstration web page (listed in steps 1-2). Click on "Reset," then set the new password. Do not us a dash in the password.
    Post the certificate to the gateway.

     

    If after testing settings and posting to the gateway, the service stops:
    The Management Gateway service checks to see if you have a management gateway appliance setup and running. If not, the service will shut itself down.
    Ensure that the .0 file listed on top alphanumerically points to the .key file that was generated during install. Can be crosschecked by looking at the default web in IIS under directory security. Also the install keyname is listed in the registry under hklm/software/landesk/managementsuite/setup.
    Make sure that protect.ini references this same correct hash file.

     

    3) Troubleshooting On-Demand Remote Control
    A. Ensure the gateway user account you use has a * for organization
    B. See that the correct public name or IP was entered in the rcclient prompt when it asks for the gateway.
    C. Check to make sure a proxy is not blocking the RCClient from contacting the gateway. If this occures an error should appear on the client saying connection failed.
    D. Check for multiple instances of issuser.exe in task manager - processes. End these and try again.
    E. Put a unique name or email into the id codes section on the rcclient. Leaving this blank can actually connect to the gateway but the rcviewer operator will not see the client.

     

    4) Client Certificates.
    A. The LANDesk agent should be installed on the client machine after the Core has been configured for the Management Gateway. Otherwise the client will not have a stamped .0 file with the gateway's information. A reinstall of the agent will update this information if the agent was deployed prior to configuring the Gateway.
    B. What to do if running Brokerconfig.exe fails immediately, test fails immediately, there are no communication messages? Click here
    C. Requesting a certificate from your machine using the end user’s .0 file.(This step is designed for LD Support, Partners, and users with a second working core. This step can however be followed on the affected user's machines to ensure the correct steps have been taken)
    1) Get a copy of the .0 file that the hash matches the posted gateway certificate as well as a console user and password from the end user.
    2) On your machine with a LANDesk agent, temporarily remove the existing .0 file(s) and place the end user’s .0 file into the C:\Program Files\LANDesk\Shared Files\cbaroot\certs\ folder
    3) On this same machine temporarily remove the contents of C:\Program Files\LANDesk\Shared Files\cbaroot\broker\
    4) On this same machine run brokerconfig.exe found in the C:\Program Files\LANDesk\LDClient\ folder.
    5) Check the name of the gateway it is trying to connect to, enter in the console username and password provided by the end user and click send.

     

    5) Adding Routes If the core is on a separate subnet then the gateway internal IP; Then a route must be configured so traffic can reach the core server from the gateway instead of bouncing back and hitting the public default gateway.  See article How to add a persistent static route to the Management Gateway for a walk through on adding routes.   #uptop