3

On a Windows 2008 R2 server with the Remote Desktop Services role installed, I have used a local group policy to start a program automatically. How do I log into the console session to manage the server using Remote Desktop in this scenario? In other words, how do I log in to manage the server without having the program start? The /admin switch doesn't work. It did when connecting to Windows 2003 Terminal Service servers.

BoogieKnight
  • 33
  • 1
  • 5
  • What program, what group policy? It would help if we knew how it would start? Is it in the Start>Startup, or is it running via the \run key in the registry. – KCotreau Jun 05 '11 at 20:15
  • The program is a medical practice management software that supports Terminal Services. As stated in the question, we used a local group policy Remote Desktop Services setting to start the application automatically upon a remote desktop connection. This setting starts the application using a path to the executable. It does not start the application when logging on locally, at the console. – BoogieKnight Jun 05 '11 at 20:35
  • Group policy does not start anything directly. It makes changes to a local computer or user profile so it starts. Now that you said that, I get it. Is the policy set to run against user profiles or that entire computer? – KCotreau Jun 05 '11 at 20:42
  • I think you are on to something! I set the policy in the "Computer" section of the local group policy. Having some of these settings available in the "user" section is new in Server 2008 (I believe). I'll try changing the setting to start the program automatically into the user section and then I'll try connecting to with the /admin switch again. – BoogieKnight Jun 05 '11 at 20:54
  • Unfortunately, this made no difference. The program still started automatically so I could not get a desktop. – BoogieKnight Jun 05 '11 at 21:03

3 Answers3

3

Starting the program with Local Group Policy isn't, probably, the best way to do what you're looking for.

In Terminal Services environments generally one uses Loopback Group Policy processing (in either Merge or Replace mode) to apply a set of user policy settings to users logging-on to the Terminal Server computer. For "Administrators", typically one would "Deny" the "Apply Group Policy" right to the GPO containing the settings that aren't appropriate for "Administrator" users (like starting a program automatically on logon).

The Multiple Local Group Policy object (MLGPO) functionality can accomodate what you want, as well, but I discourage people from using it in Domain environments. Generally it's better to put your GPOs in the Directory because, in the future, you may have a different (or multiple) server computers in the Terminal Server role. Using GPOs in the Directory means that you need only put new Terminal Server computers into the correct OU to have them "do the right thing", as opposed to having to manually replicate MLGPO settings "by hand" between machines. (In general, you should only want to do a given thing once...)

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • This makes sense. It's a simple environment but I see your point and if setup the way you describe, it appears like I'll be able to log into the console (physical) session and get a desktop rather than have the application start automatically. I'll give this a try. – BoogieKnight Jun 05 '11 at 21:19
  • What if the domain controllers are Windows Server 2003 (only the Terminal Service/Remote Desktop Service server is 2008 R2)? In order for this to work, would I have to install/turn on RSAT on the 2008 R2 box to configure this as you suggest? – BoogieKnight Jun 05 '11 at 22:20
  • I installed the GPMC feature on the R2 server and configured the GP settings in the directory but I still have the same problem, even when denying the policy for administrative accounts and the administrative groups. – BoogieKnight Jun 06 '11 at 00:56
  • @BoogieKnight: Without seeing more detail about where your user accounts, server computer account, GPO contents, and GPlinks are in your Directory I can't say much about why you're not getting the expected performance. I use this type of security group filtering in production at several Customer sites so I know it *can* work fine. – Evan Anderson Jun 06 '11 at 11:26
  • @Evan: If it helps, here's how this directory is setup: An OU for Domain Controllers (2 Win 2K3 servers), an OU for Terminal Servers (1 Win 2K8 R2 server), an OU for "Computers" at the main office, an OU for "Computers" at the branch office, an OU containing all "users" and an OU consisting of a Security Group of users at the branch office. The Group Policy I set to control Terminal Services is linked to the Terminal Servers OU and has "Computer Configuration" policies. I tried "User Configuration" policies but it didn't help (I did not try using Loopback on this policy). – BoogieKnight Jun 06 '11 at 14:44
  • @Evan: Well...you were right. Once I created a Directory based "user" policy, turned on Loopback processing, denied the policy from administrators, it worked! Thank you for your insight. – BoogieKnight Jun 07 '11 at 06:08
2

I think you are on to something! I set the policy in the "Computer" section of the local group policy. Having some of these settings available in the "user" section is new in Server 2008 (I believe). I'll try changing the setting to start the program automatically into the user section and then I'll try connecting to with the /admin switch again

Sorry it took so long to understand, but when you see it, you just soak in all the details, but to me, it was just not coming across.

Yes, now that I had enough information to even understand the problem, I was getting to that. I would make it a user policy, and just move the users, administrator for example, to a different OU, so it is not affected by the policy that starts the program. If you already create a separate OU for your users (I highly recommend this anyway), at least administrator in the default users OU won't have to be touched. Any other users you want to exempt, you should move out too.

I will keep the rest of the answer for reference.

2008 Server no longer supports connecting to the console:

http://support.microsoft.com/kb/947723

http://www.techrepublic.com/blog/datacenter/windows-server-2008-drops-rdp-console-option/434

KCotreau
  • 3,361
  • 3
  • 19
  • 24
  • Actually, to expand on this, we can no longer connect to "Session 0", but we can connect to the session that is physically logged onto at the server (see the 2nd bullet point in the "Why the /console switch is no longer needed" section of the link you provided. Previously, it didn't matter whether we already had the console session (session 0 in that case) open or not. – BoogieKnight Jun 05 '11 at 20:31
  • So then the real question is how do you stop a specific program from running, but you have not told us anything about the program. – KCotreau Jun 05 '11 at 20:34
  • See my comment above for an answer to your question about the program. – BoogieKnight Jun 05 '11 at 20:40
  • In my comment above, the reference to "we can connect to the session that is physically logged onto at the server" refers to what we "should" be able to do, but that's not happening in my case. – BoogieKnight Jun 05 '11 at 20:43
  • Keep in mind, the policies I'm changing are "local" policies on the 2008 R2 server, not "domain" policies; thus I don't think there's a way to separate the administrator users from domain users. – BoogieKnight Jun 05 '11 at 21:15
  • I did not realize that. If not, you would have to apply that to each user profile. Are you not running a domain? – KCotreau Jun 05 '11 at 21:33
  • Yes, a Windows Server 2003 based domain. – BoogieKnight Jun 05 '11 at 22:24
  • Then have you considered just ditching the local policy, and move it to an OU that encompasses the users you want to have that start for? – KCotreau Jun 05 '11 at 22:43
  • I'm actually trying that now; per your suggestion and another persons suggested answer. – BoogieKnight Jun 05 '11 at 23:03
  • This doesn't work either. If the policy is set under "User Configuration" and linked to an OU that contains the server and/or an OU that contains users, the policy is not applied because the application doesn't start upon logon. If I change the policy and set the setting in the "Computer Configuration", I have the same problem as the original question: can't remote in and receive a desktop for administration purposes. I also tried blocking the policy from applying to administrators but this made no difference. – BoogieKnight Jun 06 '11 at 00:54
  • @KCotreau: Thank you for your help and suggestions. Between you and Evan (below), I got this to work! – BoogieKnight Jun 07 '11 at 06:08
0

Which version of RDP uses the client you are connecting from? Try to use the /console switch.

duenni
  • 2,939
  • 1
  • 22
  • 38
  • Tried 6.0 and 6.1.7600 (both from an XP workstation). Version 6.1 supports Remote Desktop Protocol 7.0, if that matters. – BoogieKnight Jun 05 '11 at 19:48
  • 1
    The switches changed in W2k8 and Vista SP1. I thought the /console switch will still work if you have an older version on the client but after digging around I found this: http://blogs.msdn.com/b/nickmac/archive/2007/11/28/mstsc-console-switch-in-windows-server-2008-and-windows-vista-sp1.aspx – duenni Jun 05 '11 at 19:54
  • 1
    Ya, the /console switch is only for older versions of Remote Desktop. I should be able to use the /admin but with the application set to start automatically, the /admin switch is not taking me into administration mode. – BoogieKnight Jun 05 '11 at 20:37