In the first bit of your post it sounds like somebody had already configured a "Restricted Groups Policy" for the "Remote Desktop Users" group, which explains why it "emptied out". That's not a stock OS feature-- somebody configured that at some point. You got around it by either modifying the GPO that was "emptying out" the group, or by making a new GPO that applied after the existing "Restricted Groups"-containing GPO to override the setting.
The next bit-- the "You do not have access to logon to this session" bit is a bit more confusing. I've been trying to repro it on a Windows Server 2003 SP2 32-bit Std. machine for a bit now, and I can't come up with a repro condition.
If you would, open the "Terminal Services Configuration" tool on the machine, highlight the "Connections" node in the left pane, and bring up the "Properties" of the "RDP-Tcp" object in the right pane. Have a look at the "Permissions" tab and see that "Remote Desktop Users" is granted "User Access" and "Guest Access" (the stock permission).
Failing that, I'm not sure w/o being able to repro it. What service pack level are you running of W2K3?
(BTW: I've got a similiar background to you-- I started on Unix and moved over to Windows grudgingly. Group Policy is incredibly useful once you get over the quirks. I script Windows machines like a mad man because I can't stand to do the same work more than once. The built-in Windows command shell is utterly inferior to any Unix shell, but it can be coaxed into performing most tasks...)
Edit:
Oh-- they're Windows XP machines. I didn't realize that. That changes things. I thought these were servers you were trying to access w/ RDP.
My psychic powers say that you're seeing the "You do not have access to logon to this session" message because there is someone already logged-on to the PC and the user logging-on with RDP doesn't have "Administrator" rights on the Windows XP machine. Windows XP can only host one RDP / console session at a time, and if someone is already logged-on only an "Administrator" user can remotely "bump them off" with RDP. All other users attempting to logon w/ RDP will receive the message you described above.
How does that look?
To investigate the "Restricted Groups" policy more, run the RSoP tool on the WinXP clients and see if there are any GPOs enforcing a "Restricted Groups" setting on "Remote Desktop Users". In a network I setup, for example, there would be. It's a common way to grant groups access to RDP on clients.
If you're talking about laptops or desktops that are checked out/assigned to people, then simply do not give them administrator access. This will still allow them to install programs (Assuming they were written properly) to their home folder, and then when they leave, you need only delete their profile/user account to remove any programs they installed / changes they made. This will also limit the damage that a virus can do - simply quarantine & clean their documents on any system which they have not logged into, delete & recreate their account, restore their cleaned documents. Virus gone.
It's quite hard to actually create a "white list" of approved executables based on the fact that executable code need not even have a name, simply reside in memory on a page marked as executable. Your best bet is to simply make it easier for you to remove the unwanted applications when the user leaves.
If this is a security issue and not a "cleanup" issue, how did they get the programs onto the system in the first place?
Best Answer
Remove local admin rights, remove local power user, spend hours debugging crappy and ill-architected software with access problems using sysinternals software to manually work around access issues.
Set up software shares for home directories, profiles, etc. and redirect select subdirs (like my docs) to a network share. Then use something like Faronics Deep Freeze to "reset" the computer back to a pristine state after each restart.
I think they also have software that can whitelist executables, but it will be a pain to set up and maintain if you have a large number of systems with diverse needs to attend to.
Get systems without CD drives and use a portable USB drive for installation of software.
Get HR to support policies that make it crystal clear what's allowed and what isn't on systems, that they're company property and that there's no expectation of privacy on them.
Use filtering software to monitor web use and you can block out downloads if need be.
How draconian do you want to get?
You could also use images of your systems and periodically re-image your computers to a clean state. Still takes maintenance though, as an image a month out of date needs a month of patch-tuesdays installed, plus users still need their own data accounted for on the server or if they're managing to "accidentally" save things locally you're going to hear grumbling.
You'll need to examine your policies and balance usability with how much of a PITA you're going to make it for employees to get their work done and how miserable you want to make your employees feel, if the employer expects a lot from the employees and at the same time won't give them any sense of empowerment or freedom at all...employees that feel a foot on the back and eyes over their shoulders have wonderfully creative ways of making your life more miserable and they won't feel bad in the least for it if they feel justified.