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
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
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.
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?
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")
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/310584