Inside your virtual desktops and RDSH servers, there is a registry key that shows all of the features available in the Horizon agent and whether they are available locally. Thanks to a tip from a couple of my colleagues, including William Uhlig and Dan Berkowitz, there is an easier way to see what was installed with the Horizon Agent. You could reinstall the agent or client to make sure the component you need is there. You want to try out something in Horizon that requires a change to the Agent or Client, but you can’t remember if it’s been installed. So you need to increase the TTL on the DNS RR entry.Let’s say you have a desktop pool or RDSH Farm.If at this point the TTL timed out on the DNS RR and it tries to resolve it will resolve the other site's IP and therefore give you the Access Denied as that is not the URL you initiated the session from. Also when the client opens up for the second time it is actually forced to redirect from the exact UAG URL that you set in the "Host Port Redirect Mappings" back to the DNS RR URL that you have set as default for the Reply URL section of the Enterprise application set in Microsoft Azure for Horizon (this can be clearly seen in the second set of logs that get created when the client opens up again). If your TTL is set to low on your DNS RR URL then during the time from step 1 to step 3 of the browser opening the client for you, the DNS entry for your DNS RR would have timed out.
Between step 2 and step 3 is where this fail occurs. This URL should really be the same URL as your LB/DNS RR. Within the Reply URL section of the Enterprise application set in Microsoft Azure for Horizon you would have a default url checked. This URL rewrite is used to push to the correct SAML portal on the UAG for auth as stated in step 2. within the UAG you should have "Host Port Redirect Mappings" set for each individual UAG to rewrite the URL from the LB URL to the actual Site UAG URL. Once successfully authenticated the client is then reopened and the session token is passed to the client. Client forwards Authentication to the SAML Portal on the UAG, which in turn closes the client and opens a browser to this portal. (One set of logs is created for the client) Client opens and you initiate the connection the to the LB/DNS RR. So from a high level look what you see is this: The issue we have really does revolve around DNS round robin and Microsoft Authenticator (Azure AD), but maybe someone can still get an idea from this. So I think I found the solution to this issue. There seems to be something with the browsers possibly holding a stale record of a previous session, and when the authentication is made and the session token is passed over to the Horizon Client, it may be sending the old stale token and not the new one, hence giving the user the Access Denied message On most occasions they forget.Īlso if a user signs into the HTML version of Horizon then closes that and opens the client it works. Clearing browser cache before logging in also seems to help with this issue, but we can't tell users that they have to keep doing this on their PCs just to connect in. We noticed that when we set the browsers to incognito mode the issue does not occur. the DNS Round robin address is only used at initial point of connection/authentication. These are passed back to the client when a successful connection is made (which is what the client uses going forward to keep the connection up). They sign in within a minute of making the connection to the UAG, after which, when they have been successful, there is never a disconnection, because on the UAG you have to set the exact DNS Entry of that UAG for the Blast External URL and the Tunnel External URL. TTL on DNS Entry is 10 minutes, so there is no chance that the TTL time out occurs during the User Sign in process. 
That is exactly how we have it set up already
0 kommentar(er)
