Tam 11/Terminal Service Bug

[cgrasso1]

We have TAM running on a Terminal Server 2008 R2, and for some reason that server is not applying TAM security. Our producers cannot alter current applications, and when a producer logs on in the office, sure enough they can't.  However, when they connect through terminal services, they can.  Applied has no official answer....

Thanks

[Jim Jensen]

Welcome to AU, is it Chris? That seems really odd, but I'm no terminal server tech. I'll let others with more knowledge chime in, but wanted to at least welcome you to some new, but possibly familiar grounds.

[cgrasso1]

Thanks Jim, it's Chris...

[Bob]

We do this just fine..  Not TAM..  Would think either security/rights/GPO.   Hard to tell but nothing to do with TAM that I can confirm.  Many of us are doing this.

Through trial/error and feed back some might be able to help you identify problem.   Can confirm it is not TAM issue.

Welcome to AU! 

[Mark]

Are the producers logging in with the same TAM credentials on the terminal server vs. their desktop in the office?

[Mark]

Can confirm it is not TAM issue.

Sure sounds like a TAM issue to me, Bob.  TAM security settings are done via TAM -- NOT windows...  Can you elaborate on why you think it's not a TAM issue?  We are also running 2008 R2 Sp1 TS without this issue.

I need an example to accept your confirmation! 

[Bob]

Because I can do it!   

Many using that setup besides me so another reason..   Using bugging 11.0 version.   

If I can and other can you can, can't just be a tam issue can it?  My logic!

[Mark]

Well, my logic was that TAM security settings have nothing to do with Windows Server at all, so how could it be a windows server issue? Must be something wonky, like TS is not pointing to correct TAM db or something else TAM related.

Does TAMSTART check out?

[Bob]

That's just it, I'm a bit lost on question can and can nots.

If they can on site, and can't offsite, then something over looked.  Makes me think server whether configuration/security..  I can't pin point without more feedback as again unsure the question as presented.   Can remotely but can't in house or is it can in house but can't remotely?   I can say not TAM because MANY are doing so without this problem.     Not to say TAM is less than perfect app.

[Conan_Ward]

Well, my logic was that TAM security settings have nothing to do with Windows Server at all, so how could it be a windows server issue? Must be something wonky, like TS is not pointing to correct TAM db or something else TAM related.

Does TAMSTART check out?

Either it's not pointing to the same data or its not the same credentials, for better or worse, TAM doesn't use Windows security and Windows security doesn't have a way to block edits to an application. Unless they're getting some sort of windows error/tam exception error citing access is denied (i'm assuming not and assuming they use the same domain credentials on both TS and workstation).

[Mark]

I'm with Conan on this.  We'll need more details.

[Bloody Jack Kidd]

Is there only a single instance of TAM in the environment? As in, no test / dev etc.

If g: h: got mapped to some other TAM instance with alternate security settings, this could happen.

[Jeff Zylstra]

Hi Chris, and welcome to AU!  I didn't see if this was a new TS installation, if this just started happening, or just what the timeline of events was here.  My guess however, is that a quick run though of the TAM installation steps for Terminal Server will produce a Homer Simpson-like "Doh!" moment where something simple but important was missed or mis-configured. 

I don't know if the "SET" command at a command prompt of different user logins would show drive mappings and environment variables for these users or not, but it's quick, easy and free.  My 3 favorite things!  Let us know what you find.