This article has now been updated Remote Desktop for Thin Client… Part 2! - Blogs - EduGeek.net
Sorry @Cache - I wasnt getting notifications on blog comments. Now sorted (I think - with ZH). Right...your questions...
Yep... the security filtering is something that is so often done wrong. DO NOT mess with the Security Filtering section on the Scope tab. Instead, use the delegation tab to and edit the settings here. Remove the Checkbox for Apply GPO settings for Authenticated users, and then add the usergroup you want and ensure that check box is set. I will do a blog post with screenies as its one Ive seen a few times...
Ive not seen the Run in users context used before...I generally dont use it. Will look it up (and poke the GPO and RDS team at MSFT to get an answer for you).
Finally...many thanks for using my posts. I hope they have been useful. If you have any suggestions for more topics...please let me know. Im trying to post as much as possible about the setup to help others.
There is an update to this article in progress - as I now use NTLM as the users logon to the Thin PC as their own user, it still triggers the RDP, but then autologs in to the RDP.
It was just a standard limited account. Group policy locked out to prevent anything other than a "Cancel" box showing from a CTRL - ALT - DEL.
Using Shelly to replace the shell to use the script calling an RDP file (yes with the domain prefix included - as highlighted by other comments), prevents any access to the account itself. It has no desktop, user home folder, or even profile. All it is is a network access account, to allow calling of the RDP with the GPO for "ignore certificates" set.
Hi Pal, what restrictions did you place on the network account ?
Incidentally we get the user problem that edugeekdan outlined on our older CE4.0 terminals, not found a solution yet.
Beautiful, thank you very much! I'll give that a shot with my thin-client machine hopefully today.
Originally Posted by simpsonj Do you have a link to the Shelly utility? Try this... @simpsonj www.insidetheregistry.com/content/authors/user177/file/shelly.zip
Just out of interest this is a USER policy so placed in the student or staff OU.
How do you deal with different locations? e.g. In the library students need a different start menu to the ICT Suite.
Currently with have loopback processing enabled and a GP in the COMPUTER OU for that group?
Is there a better way? GPP ?
If you run the following command Code: Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue in a standard shell, you can then run the above Quest cmdlets
Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue
I'm going to ask probably what is a really stupid question, but I'm trying to improve our setup again (after several modifictions of other bit's you've posted).
I notice in the Top Screenshot you have 3 User Policy Settings, management, staff and Students.
What is the security filtering on the policies to make the changes to the different user groups? Does just removing all users and adding the Server and the relevent user group do that filtering?
(and not really relevent to this but might as well ask here - what difference does having the Run is User's secuirty context have? I've never ticked that on any of my printer deployments yet....)
Do you have a link to the Shelly utility? Looks like InsideTheRegistry has had an update, and I can't find the program as all links point to a dead page.
@Browolf - the latency you mention is the hazard of using a network path for the redirect. I actually use a local path - with some scripts that keep this up to date. I will do an updated copy of this post with the changes I actually use...
Man, we've been suffering with this for so long, it's such a pain, having to do this, and guess what, if they actually roam a lot, then you need to clear their profile from all machines just in case a slow log on or duff network, means they pick up the old local profile! Add to that the fact that we had switch user feature enabled, so you could never be sure they were logged out of everywhere, and it's a nightmare. Caused no end of issues with SIMS too, as some reports didn't want to run, well, resetting the profile seemed to help, not sure why yet.
One possible suggestion here..
When you created your "controlled" desktop/start menu - did you disable the shortcut tracking on the PC which you copied the shortcuts up to the shared folder?
We found that with the out-the-box setup, you would end up with shortcuts that look like:
but was really pointing to
We disabled the shortcut tracking, and it worked after that.
You can also - if memory serves - use shortcut.exe to strip the "clever" redirect out of the shortcuts.
we have redirected start menus but we have constant issues with delays over the icons appearing. In the worst cases this can be 20 seconds. Even when users only have read access to the shared folders. Icons sometimes mysteriously disappear or the target ends up directed to a random machine on the network. The later really slows things down. Considering making a system to maintain local icons as that's a lot more foolproof.
We've used what appears to be this method for a good while, but with one variation..
The local workstation has an environment variable %WSDIRALL% which points to the location, and the GPO just points to %WSDIRALL%
We did it this way because our environment has multiple "controlled" desktops with different applications in each room.
Oddly enough, our IT dept balked slightly at the thought of having hundreds of GPOs so doing it this way kept us in their good grace.. And it's child's play to update the environment variable locally/remotely.
This does of course mean we have multiple desktops/start menus, but it reduces the HD calls of "I'm trying to run appx in room123 and it isn't working" (when appx isn't in room123)
The only slight drawbacks:
1. Some MSIs appear to HATE having the common desktop/start menu redirected, so if we're deploying anything I tend to add a couple of lines of code which temporarily puts it back to "factory default"
2. You need a GPO which gets applied to non-locked down PCs which puts the common start menu/desktops back to normal otherwise moving a PC out of the locked-down GPO would still leave it with the registry changed to the locked down state. If you're doing this with 7, then you need 2 since 7's normal start menu/desktops are in a different location.
This may be the mickey-mouse method we used as I'm talking about the MACHINE level (all users) start menu/desktop.. And our method is straight-out reg hacks since the days of NT4
Originally Posted by TheScarfedOne what you could do is call a vbs script which displays a message box with a timeout in it Yep, that's exactly what I do - only with AutoIt instead of VB as I prefer using AutoIt
The only problem I had was that on XP, running as a scheduled task, you were not guaranteed to see the message screen pop up because of (I believe) the restrictions applied to Task Scheduler.
I ended up running psexec included in the same folder as my AU3. The AU3 then calls PSEXEC which would then interact with the desktop..
A complete dog's breakfast which I would probably do completely differently nowadays if I had the time, but at least it worked (works)
Rather than directly running shutdown.exe, what you could do is call a vbs script which displays a message box with a timeout in it (I use these kind of scripts for other things - like updating Start Menus), which then calls shutdown.exe.
What burgemaster said
Our current scheduled shutdown is a self-written AU3 script so that the users get a countdown to abort.
Unfortunately it doesn't appear to work on Win7 so this might be very useful if you can get a warning/cancel message..
Could an additional task be added previous to the shutdown to display a warning / cancel message?