Missing server address

Hello to everyone!

We have strange behavior in some situations. Few users see <Missing server address. ''> error, when they try to press <OK> in target server address field. At the same time, their colleagues are able to connect with the same settings. Maybe someone has faced this issue? We can`t find anything in the log files. 

  • Hi orozdaibida,

    What version of SPP are you running?

    Please note, Desktop Client has been deprecated and we recommend upgrading to a supported version and using the Web UI for managing SPP

    Thanks!

  • Hi Tawfiq,

    SPP 7.0.1. Yes, we don`t use client starting from 7.x, only Web UI and RDP file downloading.

  • Could you check to make sure both all SPP and SPS nodes are using the same DNS Server IP to make sure all of these appliances can resolve the hostname of the target machine

    Otherwise, you can test with adding the Asset using the IP address instead of the hostname to see if that shows a different behavior?

    SPP and SPS will need to be able to resolve the hostname when using the FQDN in the network address and the error may be pointing to a DNS issue possibly.

    Thanks!

  • In this case, we use IP addresses. Moreover, other people can connect to the same server with the same settings. We tried to troubleshoot this from a particular user site, but the settings also seem similar. 

  • What are the steps that the user do before they see the error in comparison to the working one?

    Example: User logs into SPP > Creates a new request for an Asset Account for RDP > Error appears?

    or

    User logs into SPP > Creates a new request for an Asset Account for RDP > download .rdp > attempts to connect using RDP file > Error appears?

    Note: SPS will still perform a reverse lookup even if IP address is used if so it may be a DNS issue on one of the SPS nodes because SPP load balances the SPS used and if there are more than one in the SPS cluster then it may be intermittent if it is hitting a particular SPS with bad DNS?

  • User logs into SPP > Creates a new request for an Asset Account for RDP > download .rdp > attempts to connect using RDP file > see the screen with blank server address field and "OK" button > he try to press OK or write server address and press ok > Error appears

    But we have nodes in different locations and obviously, dns servers could be different. As I said, other users (from the same subnet, with the same policies and settings) can connect without issues.

  • This user can log in with his own credentials from another machine even.

  • If the error is consistent for some users, Is there a pattern showing which SPS node was handling the session attempt for those users failing to connect vs the other working users?

    If there are multiple SPS servers with different DNS configuration then you could use SPP Managed networks feature to restrict which SPS should be used for specific target machines network segment as a test, this way you may be able to isolate the issue if for example:

    if working users seem to be routing thru SPS1

    if failed users seem to be routing thru SPS2 where possibly the DNS server here can't reverse lookup \ resolve the target machine IP

    In this case you can configure SPP > Cluster > Managed Network > add new network segment with for example a particular target server with IP X.X.X.X/32 and choose SPS1 so that RDP sessions will always connect via SPS1 for this specific target machine to compare etc

    This would rule out if the intermittent issue is due to routing thru SPS1 or SPS2 etc..

    Thanks!

  • Hi Ahmad,

    How to prevent SPS from doing DNS reverse lookup?

    Because it makes slowness in sessions, although ip address is included in the target asset connection information.

  • Hi Mahmoud,

    For sessions related to SPP (Whether SPP-initiated or SPS-initiated) that depend on SPP for authorization, at this time this configuration requires DNS reverse lookup to work correctly. I would refer to the release notes of future releases as this dependency could change but no ETA at this time.

    There is a related issue that is resolved in 7.4 and above to allow slower DNS resolutions to connect successfully as per the KB below:
    https://support.oneidentity.com/kb/4372269/rdp-slowness-connection-breaks-dns-timeout

    Thanks!