whichDoctor
Contributor
Contributor

SSO issue Win7 and Wyse P20

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.

Any suggestions?

0 Kudos
10 Replies
whichDoctor
Contributor
Contributor

I should add, msgina.dll or wsgina.dll are not used after XP so perhaps that is why the reg key does not matter. However there must be some other substitute not functioning.

0 Kudos
admin
Immortal
Immortal

That's strange, Please use the DCT function to create a logfile package at the Agent. In the logfile you should find more details about the error. Please set the logfilelevel to DEBUG.

Regards,

Christoph

Don't forget to award the points if this answer was helpful for you.

Blog:

0 Kudos
kenhutchinson
Enthusiast
Enthusiast

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:

nltest sc_query:DOMAINNAME

You should receive a trusted DC Connection status.

Forget about ginadll, no longer used from Vista onwards.

0 Kudos
whichDoctor
Contributor
Contributor

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

0 Kudos
admin
Immortal
Immortal

The PCoIP log shows all protocol related information. Could be in there. You should also check the Agent logfile.

0 Kudos
whichDoctor
Contributor
Contributor

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

and

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

0 Kudos
Hypnotoad
Contributor
Contributor

Did you ever resolve this issue? I have the same problem and am searching for a fix.

--Patrick

0 Kudos
whichDoctor
Contributor
Contributor

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.

http://msdn.microsoft.com/en-us/library/ms814164.aspx

Disable CTRL+ALT+DEL requirement for logon

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Description

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.

0 Kudos
Hypnotoad
Contributor
Contributor

Perfect! That solved my problem. Thanks for getting back to this thread.

--Patrick

0 Kudos
whichDoctor
Contributor
Contributor

Awesome, I consider this answer solved and my own answer deserves the points :smileyblush:

0 Kudos