Is there a Multiple User login method when remoted into a Window 2008 R2 Server?

Question

I have configured a Windows 2008 R2 Server for many users to connect to - but right now I have them all logging in with one account which is bound to our domain. The purpose of this server is for imaging other computers with a Ghostcast session. A user would login with the generic administrator account, create the session, then terminate the remote session. Seeing as that user terminated the remote session - not logged out - the ghostcasting would continue. If I had independent logins for every user connecting to my server, the server will log out the 3rd last user who logged in.

(Example: I log in with my individual admin account, create a ghostcast session and terminate the remote session. User2 logs in with their individual account, creates a ghostcast session and terminates the remote session. Once User3 logs in with their individual admin account, I get logged out completely and my ghostcast session is terminated.) (OR if three users happen to remote into the server at the same time with the same generic account, one user will be denied /logged out)

My question is, How can I have the ability for multiple user logins without logging the 3rd person out or is there a setting in the server I have missed?

I understand - depending on how many users there are - this will use up a considerable amount of server memory keeping many users logged in at the same time.

It would be better if I could have the ability for multiple users to remote in at the same time, rather than using a generic account so I can micromanage folder permissions.

Answer 1

You will need to enable and license Terminal Services. Two can log on at the same time with different accounts without licencing. So you could have many users but only two can be logged on at the same time. If you license, you can have many. Just be sure the server can manage multiple sessions (RAM, CPU, DISK I/O will all be impacted)

Answer 2

Dave M's answer above is basically the right thing, but I thought I'd just contribute an observation that on the Ghost side, having the GhostCast operation run as an application on your server is really the main problem.

Unfortunately, although GhostCast works well, the underlying code was a real mess; there's no way it could be made to run safely in a multithreaded context like a Windows service, which is why the Ghost Solution Suite management system runs GhostCast on your behalf when launching a task.

In 2008, once we had been reorganized under Altris and it was made clear to us that the management part of Ghost Solution Suite was to be phased out, I wrote this lightweight wrapper for GhostCast as an alternative to my full management system; this was a handy way to start exercising the Javascript engine I was working on and to made our internal continuous build and test system work more effectively, and I had hoped that it would be picked up and productized - since Altiris Deployment Solution actually is just a task engine that knows almost nothing about the specifics of deployment, this multicast service was my solution for integrating Ghost properly into Deployment Solution (rather than the lame approach they actually used and is all that is available at the moment).

In the event our time ran out and Ghost Solution Suite was cancelled and dev team disbanded ahead of time in early 2009, so although this tool was never productized and given a front-end configuration UI, it nonetheless exists and gets used daily as it's still part of the continuous build and test system, a copy of which is run by the current maintenance team Symantec set up to handle the support contract duties after the original dev team was laid off. So it's there, it works, and just needs a little bit of UI to help you configure it.

Just recently, it seems that Ghost may have been uncancelled after several years and although I wouldn't put too much store in that - Ghost has been in contract-maintenance-only mode for a long time now with a tiny team, which won't be easy to ramp up to the size it needs to be - it nonetheless represents a window to get various bits and pieces Symantec are sitting on released.

So, if you are a customer with a signficant relationship with Symantec, then you should probably try and contact the new PM Jon Sharp and let him know about your needs so that in case a 3.0 release does happen, something like this is released; although Symantec's investment level in Ghost won't extend to productizing this fully, at least it should be possible then for a third-party UI to be created for it to let you configure the available sessions.