Avatar of archaic0
archaic0
Flag for United States of America asked on

Can I force the "log on to" drop down to permanately be the domain?

We have 5 terminal servers and our users are connecting with thin clients.  Every so often I get complaints that users cannot log on, and it turns out to be the log on to drop down has reverted to the local machine instead of the domain and while some users recognize this and fix it, most do not notice it and simply are stuck.

To fix it, I have to log in to the console of each terminal server with the domain selected and it then will remember that for everyone... until it breaks again.

If one of us admins logs in locally to a terminal server, I know that will break it unless we directly log back in under the domain when we are done.  However, we do this VERY rarely and this problem seems to crop up once every couple weeks.

I don't know if some scheduled process or what might be causing the machines to revert back to local logons, but can someone tell me if there is a registry setting that I can set that will permanently make the domain the default, even if an admin logs in to the console as the local admin.

Thanks in advance!
Microsoft Server OSActive Directory

Avatar of undefined
Last Comment
archaic0

8/22/2022 - Mon
badgermike

Not sure what you thin clients are for OS however you are looking for the defaultdomainname registry setting

http://support.microsoft.com/kb/310584
archaic0

ASKER
Can I set this on the server?  
oBdA

Either avoid logging on the TS with a local admin account, or try the solution described here:
How to change default logon domain name in the logon screen
http://support.microsoft.com/kb/555050
If you don't reboot your TS on a regular basis, you might want to try to run this script as a scheduled task.
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
archaic0

ASKER
Like I said, it is VERY rare to actually log in locally for us so I'm convinced that some automatic process is reseting this. We have these machines reboot every night and clear any profiles that happen to be left behind.

The KB you linked to seems to apply to windows client PCs, but  with a thin client does this apply?  Can the default domain be set ON the terminal server and affect all users?

I will look at the RDP setting on the thin clients to see if there is a domain setting there. I don't know why we wouldn't already have that set if it was available, but it could have been overlooked.
oBdA

The "client" in this case are the terminal servers (because that's where the users are logging on); in other words: you'd apply this script to the OU in which your terminal servers are.
archaic0

ASKER
Ok, that make sense. I'm mobile today, but when I get back to the office I'll see how it goes.

Will this setting override if an admin does happen to log in locally and forget to re-login tithe domain after?
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
oBdA

Not until the script is run again.
What you could do as is to implement this additionally as a logoff script through a local group policy (because it has to be applied to the local administrators). It will obviously error out when the users logoff because they may not write to this key, but it will run correctly when administrators log off.
archaic0

ASKER
Is there some way to entirely disable the ability to log on locally through RDP?  This is never needed or us.

oBdA

You could change the RDP permissions, but that might come back and haunt you if there should be an occasion where you actually need to logon with a local account.
Since there shouldn't be too many users with local admin accounts, it's easiest to explain to them that they should use a domain account on the terminal servers (it might help to rename all local accounts to something like IIRNTLL-Admin as an automatic reminder (for "It Is Really Necessary To Logon Locally")
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
archaic0

ASKER
There are only two of us who can log on locally, and we use a DRAC to do so an not RDP. The only time we use the console and local login is for certain large admin event like maybe a service pack install, or in the off chance the domain is broken and we're trying to troubleshoot the lack of domain conectivity. Or to join or disjoin from a domain.

We just don't log on often enough to remember when the last time even was. And yet, the local login keeps getting set. Thus my thought about disabling it through RDP.

Case in point, this morning all but one tserver wa set for local logins, but neither of us were even in the office yesterday or today. (off-site training). So some automatic process must be breaking this.  
jbennett11

For a different approach, you could try educating your users.  You could set the interactive prompt gpo settign to popup with a message stating that the user needs to select X domain.  That way everyone would have to read what the domain should be before typing in their user/pass.  

Here is how to set the gpo setting if you don't already know.

http://support.microsoft.com/kb/310430
ASKER CERTIFIED SOLUTION
Henrik Johansson

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
archaic0

ASKER
There we go!  That sounds like what I was after.  Thank you so much.

We'll see if this setting will override whatever is knocking the local machine back in the list.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.