1 Reply Latest reply on Feb 5, 2020 9:07 AM by Fabien Carmagnolle

    The device cannot be reached - Things to check

    Lucas Emberstone
      Share This:

      I'm posting this here in the hope I can save some poor soul an inordinate amount of time figuring out why a roll out is failing. Please note that I'm using BCM via the bolt-on for Track-It so it was initially installed/configured via the Track-It interfaces.

       

      I recently had to get BCM working in an environment with three domains at three different physical locations all linked by VPN tunnels. The domains are all setup with a trust relationship and generally everything else is working fine. Trouble was the Client Management server could not roll out agents to networks other than the one the server itself was located in. Trying to verify the roll out in the management console simply reports the error "The device cannot be reached". Pinging the workstation from the BCM server (and vise-versa) was successful.

       

      What I've learned is:

      1. Device discovery will add workstations and set the "Name" to the IP address (10-10-10-2) if reverse DNS is not configured on the network.
        • This is odd because device discovery (via WMI) has access to the host name and could easily set the "Name" correctly on the device properties in BCM.
      2. Roll outs can ONLY connect to workstations via host name (not by IP address).
        • Through trial and error I was able to determine roll outs use the "Name" field of a device for connections.
      3. Roll outs AND agents do NOT use fully qualified domain names.
        • Insanity.
        • Device discovery sets the names of devices only to the "short" name (when reverse DNS is working).
        • Roll outs use only the "Name" of a device for connections. Manually editing only the "Name" to be a FQDN will allow verify/roll outs to work.

       

      Things that you should check:

      1. Your BCM server needs to be able to reverse resolve any networks where you have workstations.
        • You can verify this is working from your BCM server by running "ping -a xxx.xxx.xxx.xxx" (replace x's with a workstation IP) from a command line and ensuring the host name of the workstation is returned.
        • If this test fails you will need to look at your network DNS configurations to ensure reverse resolution is configured for the local network and is also available for remote networks (Zone Transfers can help you with remote networks).
      2. Your BCM server needs to be able to resolve the "short name" for all of your workstations.
        • You can verify this is working by running  "ping xxxxxx" (replace x's with workstation short name such as OFFICE05). and ensuring you get a ping back.
        • If this test fails for remote networks you can configure your BCM server to include additional DNS suffixes (via the advanced TCP settings for the NIC in Windows).
      3. Your workstations also need to be able to resolve the "short name" for your BCM server
        • You can verify this is working by running  "ping xxxxxx" (replace x's with the short name of the BCM server)
        • If this test fails from workstations on the same network as your BCM server you should check your DNS configuration on that network.
        • If this test fails from remote network workstations, a quick solution is to add a "CNAME" record for your BCM server to the remote DNS servers so workstations on those networks can resolve (translate) the "short name" to a FQDN.