Sort of, kind of.
I asked for help with the following scenario involving Terminal Services in Admin mode, the RDP client provided with XP by Microsoft and this scenario
A fellow named 'Rob' - no email, but he appears to hail from a small computer company called Microsoft in Redmond replied
Close but no cigar.
It works as advertised. But, the reason we must use console mode is because the application requires it. Log the user out and the application just stops. Five minutes after that we have people calling in and asking why their work orders stopped flowing from ERP to the legacy shop floor applications.
K-L-U-D-G-E. No, not the policy edit, the application.
So. Authenticate with RDP client, with the above policy enabled, authenticate with the credentials of the currently logged in user and ... Client A is disconnected.
The policy edit does solve a problem we've never had - namely 'someone with admin credentials' logging in and knocking the service account off. So that's ok.
Don't even get me started on the idea of using a Windows server for a 24x7 critical enterprise application. Yes, it works but - in my humble opinion - if you have a choice between 'unix' and Windows for that operation the former is preferred.
I asked for help with the following scenario involving Terminal Services in Admin mode, the RDP client provided with XP by Microsoft and this scenario
Client A connects, starts doing his thing. Client B, hearing about a problem with the application, connects and knocks out Client A. No warning, it just happens.
A fellow named 'Rob' - no email, but he appears to hail from a small computer company called Microsoft in Redmond replied
Try this group policy: Administrative Templates – Windows Components – Terminal Services – Terminal Server � Connections � Deny logoff of an administrator logged in to console session.
Close but no cigar.
It works as advertised. But, the reason we must use console mode is because the application requires it. Log the user out and the application just stops. Five minutes after that we have people calling in and asking why their work orders stopped flowing from ERP to the legacy shop floor applications.
K-L-U-D-G-E. No, not the policy edit, the application.
So. Authenticate with RDP client, with the above policy enabled, authenticate with the credentials of the currently logged in user and ... Client A is disconnected.
The policy edit does solve a problem we've never had - namely 'someone with admin credentials' logging in and knocking the service account off. So that's ok.
Don't even get me started on the idea of using a Windows server for a 24x7 critical enterprise application. Yes, it works but - in my humble opinion - if you have a choice between 'unix' and Windows for that operation the former is preferred.
