View 1.6 and 1.7 on both OS X 10.6.8 and 10.8.2 can login but not show desktop

[D43m0nz]

Yesterday I tried using View 5.0 for the first time with a Mac. I used the 1.6 client on a Mac with 10.6.8 and connected succesfully. Later on that day I tried to connect again: I opened the client, entered username and password, waited a few seconds for the text message with additional challenge on my cellphone and logged in. But all I see is the gray window of the View client and a spinning circle. I've waited several minutes, but no change.

Today I tried the same thing again and after logging in I get the same gray window of the View client and a spinning circle. After a reboot of the Mac, there was no change in behaviour. After that, I upgraded the View client to 1.7 on the Mac with OS X 10.6.8. Again, no change in behaviour.

Then I tried another Mac, but then with the latest version of the OS: 10.8.2. This Mac had no View client installed so I installed the latest client for Mac (1.7). All seemed well, after entering username and password and the additional challenge from the text message the gray window stayed with the spinning wheel in it. A reboot had no effect either.

I have attached a log file of the attempt to login with client version 1.7 on OS X 10.8.2. I have replaced the servernames to protect the innocent. There are 2 things in this logfile that lead to question whether it's correct:

1. the broker server principle name is represented like this: viewserver$@domain.com. Why would there be a $-sign behind the servername and is the @-sign also logical in this place?
2. Around lines 1946 until 1982 in the attached log file there are a lot of listener notifications that seemed to have failed. In the following lines a few other tasks have been marked as DEAD and there's a message saying the file descriptor for a socket to a tunnel is bad, resulting in a tunnel that's not being established.

Is the name representation of the broker principle correct? I assume it is, since the windows clients have no problem at all.

Is this solely related to the client on the Mac and if so, does anyone have suggestions to get the client working? Workarounds are also very welcome.

Not unimportant perhaps, I'm using PCoIP.

[wally]

We have the exact same issue, the connection seems to go wrong after the "TunnelProxyReadHex: Invalid number character: 60", we see this in all failed connection logs. Only with MacOS clients and only with 2-factor authentication (we use radius btw). We currently have an open case with VMware support for this.

[wally]

According to support there is a bug in the MacOS client, which seems plausible since this issue only occurs with MacOS (we don't have this issue with Windows/iPad/Android). But telling our traffic-manager to do IP-based session persistence instead of plain round-robin  to our security servers does seem to have a positive effect on this issue, we'll have to wait a few days to see if it is a decent workaround but so far things look good.

[D43m0nz]

Setting a session persistence sounce very reasonable to me, but why this only affects the Mac client and none of the others is weird. Have there been any (recent) changes on your (Mac) client version or View setup or this traffic-manager? Because it used to work fine on my site, but in a period of time (can't really tell when) the Mac clients stopped working (they are heavily outnumbered, compared to Windows as a client).

I do wonder how much the IP-based persistence will prove a working solution if there is more than one client behind a NAT router (offsite of course).

Thanks for the update