Given: a terminal server based on Windows Server (in our case - 2008R2, but that's not really the point). Along with the terminal server, a default connection named RDP-Tcp is also created automatically.
In this connection you can specify certain properties, for example, logon parameters, session properties, client parameters (for example, disabling redirection of local drives, printers, or other things), and so on.
In most cases this all works perfectly fine with settings common to everyone - that is, one configured RDP-Tcp connection on the terminal server is enough. As a rule, the system administrator responsible for this server simply configures this connection once and that's it, then moves on to managing other parts of the terminal setup.
However, there are situations when, for a certain group of users, machines, or something else, you need to create separate conditions for using terminal sessions. For example, to forcibly disable printer redirection, or to restrict the color depth, or to disable redirection of local drives or the clipboard, and so on.
What should we do in this case? Well, the first thing that comes to mind is to tinker with the RDP shortcut given to the specified people, making the settings right in it. However, this is not very secure - one way or another, a person can still change this shortcut (or even just create another one next to it, with the settings they need) and your efforts will go to waste.
The second idea - what if we make special settings for this person on the server itself. Or rather - special settings for a group of people.
Let's settle on this idea.
Different RDP-Tcp settingsSo, on the server side, connection settings are made through the "Remote Desktop Session Host Configuration" console. To get there:
Start -> Administrative Tools -> Remote Desktop Services -> Remote Desktop Session Host Configuration
In the console that opens, we see a window with "Connections" written at the top, and in the connections area - a single "RDP-Tcp". This is exactly the default connection.
If you change something in this connection, it will apply to all subsequent logons to the server, i.e. this doesn't work for us.
A logical idea arises - what if we create a new connection, bind it, for example, to a separate IP address, configure it separately, and just give people a different shortcut - pointing to this separate IP address.
That's what we'll do, but first we need to take into account one point: RDP-Tcp connections are bound to a physical network card! Yes, that's not a typo - not to an IP address, not to a computer name, not to a port, but to a physical network adapter. This means that if you only have one network card (or only one is free for RDP connections), you simply won't be able to create a second RDP-Tcp connection!
The train of thought of Microsoft's engineers is not clear to me. More and more I notice moments in this company's OS that were apparently designed while extremely high or badly hungover, in "whatever, it'll do" mode.
But the fact remains a fact - as long as you only have one network card available for RDP in the OS, nothing will work. The logical solution is to add another network card - for example, if your server is virtualized, there's nothing complicated about this (at least if you're using a decent server hypervisor, such as Xen or XenServer, or even VMware). If a free network card already exists and can be used, then there's no problem - we use it.
Well, let's create another RDP-Tcp connection with a unique set of settings.
Creating a second RDP-Tcp connection1) Configure the second network card. Specify the IP address and default gateway. Yes, the gateway on the second interface needs to be specified too, otherwise traffic through the second RDP-Tcp connection will only go within the subnet where the server itself is located. If both IP addresses are from the same subnet and the gateway is, accordingly, the same... you still need to specify it on both network cards!
1a) Specify the IP, mask, and gateway. React calmly to the OS complaining that having two gateways isn't quite normal.
1b) Go into the TCP/IP properties, Advanced, and the DNS tab, and uncheck "Register this connection's addresses in DNS". Otherwise Windows Server will automatically register the IP address of the second network card as a second IP for its network name, and clients that access this terminal server via the DNS name (hostname) will randomly end up going either through the first RDP-Tcp connection with the "for everyone" settings, or through the second one, with the "for specific users" settings, which is not what we want.
1c) Specify a metric greater than one (for example, 100), if the second IP address is in the same subnet as the first.
2) Go into the "Remote Desktop Session Host Configuration" console.
3) Go into the settings of "RDP-Tcp" (the default one) - for example, by double-clicking it with the mouse.
3a) Go to the "Network Adapter" tab. Right now you most likely have "All network adapters configured for this protocol" set. Select the first network card from the drop-down list, the one through which people with the "for everyone" settings will connect, and save the changes.
4) Now, in the right part of the "Remote Desktop Session Host Configuration" snap-in, click "Create Connection".
4a) Enter a name for the new connection, for example, "RDP-Tcp 2" or something of your own choosing, this isn't very important.
4b) On the next tab of the wizard, specify the second network card, through whose IP the people "with special settings" will connect.
4c) Finish the wizard - and you'll have a second RDP-Tcp connection.
5) Go into the settings of the new connection and change what you need for connections "with special properties".
6) Reboot the server (yes, here we go again - Microsoft doesn't know how to make things work 24/7 - you'll have to reboot).
7) Create RDP shortcuts for users with "special settings", specifying the second IP address as the server.
That's it, from here on you have different settings for different people. Crude, clunky, but apparently Microsoft doesn't know how to do it any other way. Which is a shame.
Comments