Within my current project we ran in to a situation, where we build a Xenapp 6 farm. When we started an published desktop everything was fine. But after publishing an application and starting it did not start the published application, but the whole desktop was presented.

After some troubleshooting we discovered that newly created users were not affected by this problem so I started to look for differences between our existing test user accounts and and new created ones. In the end I concluded that it had to be the script that ran the other day. That script was executed by the AD guy’s to set some user account attributes (HomeDrive, TS Profile Path, etc). So I ordered the AD guy’s to reset the settings that were changed. After the user account changes had been reset, It still did not work.

While searching some forums I found these documents which outline the exact problem and deliver some “solutions” and workarounds.

CTX120831
KB969851

Basically there is a bug within the Windows 2008 “Active Directory Users and Computers” console which cripples the user account when changing the “Profile Path” on the “Remote Desktop Services Profile” tab. Even when changing back the Profile Path to the default. The user account is still affected by the bug. To fix the user account you have to run this vbs script

Const ADS_PROPERTY_CLEAR = 1
Set objUser = GetObject _
(“LDAP://cn=MyUser,ou=MyOU,dc=MyDomain,dc=com”)
objUser.PutEx ADS_PROPERTY_CLEAR, “userParameters”, 0
objUser.SetInfo

The bug it self is resolved within a Microsoft hotfix and can be downloaded here

 

TIP: To easily  discover the user LDAP path you can use:  dsquery user -samid “UserLogonName”.

After clearing the existing user attributes I was able to start a seamless published application  and no longer the whole desktop was displayed. This BUG also appears when connecting to a Published Application that is hosted on Windows 2003 (running XenApp)