How to organize the work of users in a bunch of WS2012r2 + zero-clients?

Question

System administration

What was before:
Two ws2k3 servers with terminal services up, ~60 diskless no-name thin clients running thinstation 2.1. Depending on the vlan in which the thin client lives, dhcp distributed a different thinstation config (depending on the vlan, the user logged in either to the first or to the second server, which differed in users, access rights and applications). AD was not in the office then.
What now:
AD is opened. The old railroads are dead. They brought one new one, potentially coping with the entire zoo of applications and users. WS2k3 refused to be installed on it, but WS2012r2 was installed. With a whole zoo of innovations in remote desktop services, I did not manage to figure it out.
What do you want:
1) Avoid purchasing new thin clients and/or software. The license for WS2012r2 + CAL + MS Office is already flying into too much money.
2) Be able to configure two separate "pools" from the server side with settings, shortcuts, browser bookmarks and more. Roughly speaking, so that the user Vasya from the sales department could not see the files or use the specific software of the user Petya from the advertising department. Ideally, it would seem to the end user that they are on different computers.
3) Maintain the ability to download shopping malls over the network and ensure maximum transparency of the entire process. Previously, it looked like this: the user presses the power button on the thin client, observes black letters on the screen during boot, [after establishing an rdp connection] enters his account information and works (or observes an access error if, for example, he tries to log in from the thin client your department).
4) Be able to forward USB flash drives to your remote desktop.
Offhand solutions:
1. "Classic" terminal server. Thinstation or equivalent is loaded over the network to a terminal server. Absolutely all the software is installed on the terminal server and absolutely all the files of both "pools" are located. Group policies go down settings, shortcuts, browser bookmarks ANDaccess-lists are configured to block access to files of a "foreign" department.
Problem:yes, I have no idea how to raise this classic terminal server. Session-based RDS brings with it a bunch of obscure services such as session broker host, rds getaway and a web interface, on which, according to Microsoft, terminal users should connect through a file. The problem is that a thin client cannot do this, and when trying to connect to the server directly (by ip or hostname, for example), the user receives an error like "you must be in the remote desktop user group." An option like loading a super-light linux with a start-up script that opens the browser on the desired page in full screen is too complicated for the end user: a) enter a username / password, b) poke into a certain shortcut on the page, c) wait for the connection and enter your login/password again - screams will start immediately"
2. VDI. Here, from the server side, everything is simple and clear: two pools of virtual machines are created, each of which uses its own pre-configured OS image with its own specific software and other delights.
Problem: as far as I understand, it is impossible to forward usb to a virtual machine without additional gestures like usb-over-ip. Changing the registry to the session broker host, as mentioned in the previous paragraph, will kill the ability to create two different types of virtual machines, because. session broker host will redirect all connections to one collection of virtual machines without question. That is, all the advantages of the solution are killed.
There can be more or less pitfalls - I am very poorly versed in all the innovations regarding terminal services. I would be very grateful if someone could tell me how best to organize such an infrastructure. Well, or at least push in the right direction, otherwise the eyes run wide from the abundance of various software solutions in the field of terminal / virtual desktops.

Answer 1

Six months later, I myself answer my own question: we create a regular RDS server (for a single server, you can click "quick deploy" and get a working solution, for two or more servers - transferring the RDS Gateway and Connection Broker roles to separate servers, RDCB High Availability and DNS Round Robin It is well written about this here: blog.it-kb.ru/2014/08/24/windows-server-2012-r2-re... and on technet)
A basic set of software is installed on the session host ( what both departments use in my case), for "specific" software, use a RemoteApp farm (or a single server) and differentiate access rights at the level of Active Directory security groups.
For thin client software, use Thinstation 5.X with the freerdp package or ready-made software like PoniX (www.t-sol.ru/about )

Answer 2

There is an option to install Hyper-V, and raise WS2k3 on it. But I would advise you to understand the new features of Win 2012 R2 terminal servers. The connection is not working because you have not added any users to the Desktop Users group. This can be done in 2 ways - either locally on the server or when creating a collection through the RDS snap-in