App-V Client Authentication Problem when you Install Live Essentials or Office 365 client components on the same windows client

When you install Live Essentials or Office 365 Single Sign in Assistant they install Security Support Providers of their own, “liveSSP” and “msoidSSP” respectively. These value are added to the “Security Packages” key in: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\”

Removing the “liveSSP” and/or the “msoidSSP” entry from the security packages key does temporary fix the problem, but if an update to office 365 or live essentials is applied then the SSP values are written back to the Security Package key and the issue occurs all over again.

Msoidssp is a SSP used to align the SSPI interface with the client so that the client can connect with the server in the secure channel, more information about this SSP in the following link: http://community.office365.com/en-us/w/office/534.aspx

In office 365, it’s already using the secure channel, msoidSSP was a second secure channel from the windows 7 client for it to drop back on to like a safety net if the it was unable to secure communicate using the normal method. Removing the registry should not impact the usage of office 365 services as long as it is able to communicate successfully without the need to drop back to the second SSP.

The bug fix should be available in App-V client 4.6 SP2.

App-V 4.6 SP2 Release notes, please read before updating to SP2: http://technet.microsoft.com/en-us/library/jj729866.aspx

Download Link: http://www.microsoft.com/en-us/download/details.aspx?id=35513

Thanks.

Techtonis.

Advertisements

3 responses to “App-V Client Authentication Problem when you Install Live Essentials or Office 365 client components on the same windows client

  1. Thanks for the great post. Were you able to confirm this was fixed with SP2? I am still having this issue even with App-V client 4.6 SP2. Removing msoidSSP from the security packages key remains my workaround although I’m not pleased with this solution. Thanks again.

    • Hi,

      Sorry for the delay in replying, we have been really busy and haven’t had much chance to check the blog.

      No sorry we haven’t had chance to test the solution, although will try to find someone and some time to test to find out whether it has fixed the problem or not.

      Thanks

      Techtonis.

      • Thanks for the reply. As a different workaround we were able to resolve this by setting the Application Virtualization Management Server service to log on as the Local System account instead of the default which is the Network Service account on the AppV server.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s