I have a standard view 4.5 deployment with vSphere 4.1, followed the standard install guide. I have created a linked clone pool and built a Win7 image. My problem is that though I install the VMware tools and then the agent on the virtual, it will not do a single sign on from my Wyse P20. I have to log in to the Wyse P20 view portal, and then login again to the desktop.
During install of the agent, I have noted it will not copy/install the wsgina.dll file to c:\program files\vmware\vmware view\agent\bin nor make the necessary registry entry. Thus I think this creates my problem with single sign on. However, even if I manually copy over wsgina.dll to the right location and make the proper registry entry I still cannot get a single sign on. These are the only suggestions I have found on the KB, besides removing the legal and login banner from the Winlogon registry key which does not help.
If I install the agent on a Windows XP box, it does copy wsgina.dll and create the correct registry entry.
I used a standard Win7 desktop image we deploy first, and I had thought that maybe Symantec Endpoint Protection was the issue, but I created a very base Win7 desktop, joined to domain, and then loaded tools then the agent. After creating my linked pool I tried logging in and still do not get a SSO.
The workstations are in an inheritance blocked OU with no settings applied to them. As I said even a very basic build of Win7 will not SSO.
Assuming you've tried from a FAT client using the Win32 client and it works? You should defo try this. Make sure you don't have the remote desktop policy to force "ctrl-alt-del" at login.
Also check if the workstation has a secure channel open to the domain. From cmd prompt type:
You should receive a trusted DC Connection status.
Forget about ginadll, no longer used from Vista onwards.
I have generated the support file, would you have any idea of the single sign on error code or reference area (IE in the PCoIP log, ws_diag, etc.)
For the tweak with killing ctrl-alt-delete, that is already off and I get a successful link to the domain via the nltest
The most concerning error is this one, and I am not sure what to do about it:
Sesson CONNECTED (PCOIP) with CHANGED CREDENTIALS: expected DOMAIN\u.name, got DOMAIN\u.name
It matches my username exactly, but thinks it is not a match and thus probably why it won't login via SSO. I checked my Wyse settings and View settings and they both indicate our domain properly. It is calling it by the standard name and not the FQDN but not sure it matters as long as they match?
2 other errors jumped out at me:
wssm started in session 2 whilst missing logon notification
wsnm session created in PENDING state: id=3, winstation=Console
I searched the KB and saw some comments about permissions to RD blocked by a firewall and another about issue with the display. I have confirmed RD is not blocked and the display adapter is the same that VMtools installs.
I've watched the virtual machine via the vSphere console and watch the screen flash black and then the Wyse system is sitting at the login screen. I see no errors or odd behavior when watching via the console.
I built a WinXP virtual pool identical to the Win7 pool and SSO works just fine
Actually yes we did, and I never came back to this post. SSO would not work on Windows 7 virtual desktops. You would arrive at the login window where you need to enter your username and password to gain access. To have SSO work, a group policy needs to be changed because the view agent assumes a CTL+ALT+DEL is presented. If it is not, SSO doesn’t work.
Disable CTRL+ALT+DEL requirement for logon
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Determines whether pressing CTRL+ALT+DEL is required before a user can log on.
If this policy is enabled on a computer, a user is not required to press CTRL+ALT+DEL in order to log on. Not having to press CTRL+ALT+DEL leaves the user susceptible to attacks that attempt to intercept the user's password. Requiring CTRL+ALT+DEL before logon ensures that the user is communicating by means of a trusted path when entering their password.
If this policy is disabled, then any user is required to press CTRL+ALT+DEL before logging on to Windows (unless they are using a smart card for Windows logon).
This policy is disabled by default on workstations and servers that are joined to a domain. It is enabled by default on stand-alone workstations.