Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently setting up a Server 2008 domain for one of my clients. The client has requested that some of the Thin-Clients being used to connect to the domain are setup in certain rooms and logged in all the time.

What's the best procedure for setting up a domain "client computer" in a "room" that needs to be logged in all the time. Using a user account created for that room? Or should I simply request that all users log in to the room using their own domain username and password?

share|improve this question
What do you mean by thin-client? – Zoredache Mar 1 '12 at 2:05
I mean thin client... All applications it uses will be run on the domain controller (Server 2008) – Christopher Wilson Mar 1 '12 at 2:12
So the Windows box is a terminal server and all the clients will be connecting over RDP? – Zoredache Mar 1 '12 at 2:17
You realize it is generally considered a very BAD idea to have a Domain Controller act as a terminal server? – Zoredache Mar 1 '12 at 2:24
No I did not realize this? Is the reason behind this, the fact that Terminal Users will be logging into the Domain Controller? – Christopher Wilson Mar 1 '12 at 2:32

What domain-level services does would a generic user in that room need to access?

If they only need to login so they can use a browser or do some basic kiosk-style local things, then creating a generic shared guest account might be reasonable.

Though if the account really doesn't need any domain-level resources it might be even better to simply create a local account on the system.

If the computer will be used to access shared file-systems or any network resource that requires some level of security, then you should require them to authenticate with a unique account.

share|improve this answer
Network resources will be accessed as well as some cloud based applications, so the account will need to access domain-level resources. Looks like I will need create some new user accounts and ask users to sign into the relevant systems. It's just difficult when the client doesn't specify users just "rooms". Thanks – Christopher Wilson Mar 1 '12 at 2:08

You generally want all users to have their own account. But, if users will be random and not returning often, or if they aren't storing their own files or every logging into anything, then maybe a "generic kiosk account" could be used. Kiosk accounts are often used for labs, or pubic places but this really has nothing to do with terminal services. There are lots of pros and cons to each way so it really comes down to your planned usage and requirements, which you didn't specify above. I recommend you restructure your question with details on why users need terminal services, their usage patterns, why they must be logged in always, etc. and we can help with answering the opinion of kiosk or no kiosk account.

share|improve this answer

My recommendation would be to build a separate Terminal Server for the thin clients. These systems would be configured to invoke a Remote Desktop / Remote App login as soon as they come online, giving the illusion of a Windows Desktop that is actually an RDP session.

This way, the users can log into their own accounts (perhaps with a roaming profile as you stated) but the desktop session on the thin client would actually run on the terminal server rather than on the local system. If they log into their own machine, the domain will recognize that they're logging in interactively, rather than a terminal session.

One could also create "kiosk" accounts for guests, that can also be logged into as terminal sessions; these can be locked down more rigorously, perhaps not allowed as interactive (local) login, restricted to thin clients only, etc.

And yes, it would be Considered Bad to run terminal services on a DC, especially with guest accounts active. Your DC is going to be the central hub for all administrative access, so keeping it at arms length from the terminal sessions is highly recommended.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.