Leaving Servers at the logon screen

Dracula28

I have generally been working with multipurpose servers, which means that there has to be a user logged on to the servers at all times. Wheter it be DCs or other type of servers. But lately I have been working with single purpose servers, and I know that the practice at some companies is to leave such servers at the logon screen, as they will be providing the services regardless of a user being logged on or not.

But what is the recommended practice? What is Microsofts take on this? Are there any downside of leaving for example a Domain Controller or an Exchange server at the logon screen? I know that this practice has been used since the Server 2003 days at least.

xenodamus

What kind of server/service requires someone be logged on at all times? I'm not sure understand. I log off of boxes I'm not actively using as a general practice.

cruwl

DCs and exchange boxes do not require anyone to be logged in to them. Period.

Same with SQL and just about every other piece of Server grade software I have ever worked with.

Generally it is best practice to log out when you are done working on a server, that way your disconnected session does not take up one of the open slots when another admin needs to get in.

sratakhin

Adding to Cruwl's post. It's not a good idea to run any user applications on servers because an application failure may bring down the whole server. I usually log out of servers when I'm done but sometimes just lock it. If another admin disconnects my session, it's not a big deal.

ajs1976

Leaving a user logged on at the server console does not have anything to do with it being a multipurpose vs a single purpose server. There is some app that has a process that needs to run interactively with the desktop. I have two or three apps that need components that run at startup and I can't do anything about it because the vendor only supports it that way. If you have more apps on a server, it is more likely one of them may need to be logged on. If you don't have any apps like that, the best practice would be to log off when you are done work with it.

Dracula28

Thanks or the feedback. Does anyone have a link to an article that discusses this subject? I just don't know enough about it, and would like to know more about what services and processes are started when a user logs on and what services and processes are started during just startup of a server.

I can't remember seeing this being mentioned in any training kits or other books that I have read.

RobertKaucher

From the perspective of SQL Server and just about any other modern enterprise application there is no valid need to RDP onto a server to perform 90% of the normal administrative tasks. The creation of a Window station for an interactive log on will create overhead that can degrade performance on the system in question. Learn how to remotely manage your servers. There are some cases where you likely will have to log onto a server to perform a task, but don't allow that statement to make you lazy. It's not an excuse to do it just because you can. You should educate yourself as to how you can administer systems remotely. It isn't difficult in most cases. To understand why this is the case you should learn about how Windows manages memory and how sessions and Windows stations are created and managed by the OS.

Please see the resources on the basics of Windows Internals in this thread. Pay special attention to this TechNet article.

You might find this Twitter conversation interesting: https://twitter.com/BrentO/status/222367755012288513

As well as this response with a counter argument: Remote Desktop and the DBA - MSBI Administration

Just keep in mind that no one is saying never RDP into a server, we are saying this:

* Application servers need their RAM to service end users, not to make your job "easier"
* Interactive log on takes up this memory and so should only be performed as needed and then you should log out.
* Perform remote administration whenever it is possible. It is faster and less likely to cause an error that will crash a critical production system. I.E. a program that isn't executing on a server is not going to cause a blue screen on that server.
* You are less likely to make a mistake that might harm or crash the system as well when you are managing remotely. I.E. you can't accidentally fill up a critical drive that isn't shared if you are copying files or moving a backup remotely.

I have seen people make stupid mistakes logged in via RDP (not me of course - ::hides face in shame:: ). You will have multiple RDP sessions open and eventually get confused and perform an action on the incorrect server. If you perform the same action via the RSAT MMC, you would have to explicitly connect the appropriate MMC to the system in question, rather than switching RDP Windows that pretty much all look alike, and would thus be less likely to connect to the wrong server.

So don't use RDP unless you actually have to and in most instances, you probably don't. Be a professional; know your trade!

RobertKaucher

ajs1976 wrote: »

Leaving a user logged on at the server console does not have anything to do with it being a multipurpose vs a single purpose server. There is some app that has a process that needs to run interactively with the desktop. I have two or three apps that need components that run at startup and I can't do anything about it because the vendor only supports it that way. If you have more apps on a server, it is more likely one of them may need to be logged on. If you don't have any apps like that, the best practice would be to log off when you are done work with it.

We have an MS Dynamics SL system that runs a custom "process manager" that automatically imports transactions we receive via EDI. The process manager has to be logged in interactively. :-/

As a software engineer, this makes me want to cry. Why would anyone develop a system that requires data be entered via the GUI? Business logic should not be so tightly coupled to the GUI. Either it should have been encoded in the data-tier as triggers or procedure in the DB or it should have been abstracted out into a business logic service layer with an API. I would much rather that it be a separate tier, but putting it in the DB would be better than encoding the business logic in the GUI.

sratakhin

Good points, Robert. I learnt something new myself too.
I already use RSAT from my desktop but never really bothered with other snap-ins as it's almost always easier to use RDP.