Program in remote desktop environment won't activate for one local user--extremely odd.

We have a client that's running a piece of software called Phoenix Project Management.  https://www.phoenixcpm.com/  We've got it installed on a Windows Server 2012 R2 box running RDS.  Here's the backstory:

A trial of Phoenix was installed on a User A's computer.  User A liked it and the client decided to buy a license.  In order for multiple users to have access to the program, it was installed on a RDS server.  Initially, each user was logging into the RDS server with their own account.  Phoenix phones home to activate, and it activated fine.  However, when subsequent users logged into the RDS server, they would get prompted to activate, which would then fail.

At that point, we created a user called Phoenix.  We were able to log into the RDS server as Phoenix and run the Phoenix software.  We logged in from several different remote computers and in each circumstance, Phoenix indicated that it was activated and ran as expected.

Then we logged into the RDS server as user Phoenix from User A's computer.  Phoenix indicated that it was not activated.  We logged into the RDS server as user Phoenix from another device and deactivated Phoenix.  We then activated it while logged into the RDS server from User A's computer.  Phoenix would then run properly while logged into the RDS server from User A's computer.  

However, at that point, when logging into the RDS server from other devices (whether as user Phoenix or a different user account), Phoenix indicated that it was not activated.  Deactivating Phoenix when logged in from User A's computer allowed it to be reactivated from another device, but once again resulted in Phoenix reporting that it was not activated when logged in from User A's computer.

We logged into User A's computer as the domain administrator and then logged into the RDS server as user Phoenix.  Phoenix indicated that it was activated and worked properly, so the problem does not appear to be computer specific.

We then logged into another device as User A (with roaming profile disabled) and then logged into the RDS server as user Phoenix.  Phoenix indicated that it was activated and worked properly, so the problem does not appear to be tied to User A's user account itself.

We then re-enabled the roaming profile for User A, logged into another device as User A and then logged into the RDS server as user Phoenix.  Phoenix indicated that it was not activated, so the problem does appear to follow the profile for User A.  

Lastly, we deleted the locally-cached copy of the User A profile on User A's computer, turned off the roaming profile, and then logged into User A's computer as User A, creating a new local user profile.  When we logged into the RDS server and ran Phoenix, it indicated that it was activated, so creating a new user profile for User A does appear to resolve the problem.  

It seems clear that there's something in the profile for User A that the RDS server can see, which is causing Phoenix to throw the activation error.  To that end, we uninstalled the trial version of Phoenix from User A's computer,  deleted all mentions of Phoenix from the registry on User A's computer, and then deleted all files with the name Phoenix in them, also at User A's computer.  None of that had any effect.  We then turned off redirection of printers, smart cards and drives in the RDS client so that the RDS server wouldn't have access to any resources on User A's computer.  That also had no effect.

This brings me to my question--how is it possible that the RDS server is able to see anything on User A's computer that could influence a program that's installed on the RDS server?  We'd like to avoid having to recreate the User A's profile in order to make Phoenix work for him on the RDS server--that really seems like the shotgun approach.
LVL 1
SINC_dmackAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Robin CMSenior Security and Infrastructure EngineerCommented:
Run Process Monitor as an administrator on the RDS server. Pause logging, clear the results.
Get the user to log on to the RDS server. Once their session has finished initialising start Process Monitor logging, get the user to launch the application, wait for it to complain about licensing and stop the logging.
Now you just (!) have to look through everything that's been logged for any references to the user's PC.
You can get Process Monitor from here: https://technet.microsoft.com/en-us/sysinternals/bb795533.aspx

To answer your "how can the RDS server access the client" question, AFAIK it can't. Citrix used to have a mechanism for doing this, you could use \\client\c$ from the server to get to the client, but even then the client had to authorise it. I'm not aware of this being present in RDS though. There is an environment variable that gets created within RDS session that doesn't exist on a regular PC, CLIENTNAME so perhaps your application has been coded to check for and use this, e.g. it might be trying \\%clientname%\c$\users\%username%\<some path> which might work if your user has admin rights to their own client PC.
0
SINC_dmackAuthor Commented:
I'd thought that this issue was resolved, but it turns out that more user accounts are being affected with the same issue.  I'll try your suggestions and report back.  Thanks!
0
SINC_dmackAuthor Commented:
We ended up deleting and recreating the local user profiles for all of the affected users, as described in the original question.  We didn't end up trying robincm's suggestions, but they may well have been helpful so credit will be given accordingly.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SINC_dmackAuthor Commented:
We ended up relying on the somewhat-inconvenient method of recreating the local profiles for the affected users.  It was a sure-fire solution, as the client didn't want us to spend any time trying to find alternatives.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Remote Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.