Termianl Server Implementation Question

  • Thread starter Thread starter Chris
  • Start date Start date
C

Chris

Guest
Good Day Community,

I'm going to outline a scenario I have, and just want get some feedback on
what would be the best method to implement it.

Scenario

Server: Windows 2003 SBS Standard (DC)
Server: Windows 2003 Standard R2 - Terminal Server

Goal: I need to implement the terminal server for our remote sales staff. We
recently did a big push on our accounting software - which requires the
workstations to have amounts of RAM and atleast 2.0ghz. Most of remote sales
agents have laptops that do not qualify for the upgrade. Instead of replacing
5 laptops, we purchased the hardware to make a terminal server (Dual Quad
Core, 4gigs RAM etc). This will allow our sales team to VPN in and RDP to the
term.server. There will also be 3 users within the office that have desktops
here that will be permitted to remote into the TS.

AD Structure

Created Terminal Server OU, added this server to it. Mapped a GPO to the OU
and am using the Computer Policies only


I created a seperate GPO to lock down access on the terminal server, for a
group called Terminal Server users. This works fantastic, but I of course if
you move it to the root level of the AD Structure - it effects their Desktop
login policy as well.

Purposed Work Arounds:

Option 1

create a generic user names and passwords (i.e: Sales) and in the login
script include a VBScript to prompt for their real username and password to
be able map their user folder.

Pro: Fairly easy to implement, user cfg gpo applies
Cons: Not really able to tell who is logged in, not really secure login to
TS because username/password would have to be dumafied so people don't get
confused.


Option 2

create a new user account, jdoe is regular jdoe.ts is for terminal server.

Pro: GPO applies, matches criterial to know who is online when viewing
connections
Cons: Another username and password to remember - I don't beleive there is
away of important/synchronizing their normal user password with this account,
how would you map to their user drive - would u still need the VB script?


Any other suggestions welcome


Submitted to the following sections:

microsoft.public.windows.group_policy
microsoft.public.windows.active_directory
microsoft.public.windows.terminal_services
 
Re: Termianl Server Implementation Question

Chris wrote:
> Good Day Community,
>
> I'm going to outline a scenario I have, and just want get some feedback on
> what would be the best method to implement it.
>
> Scenario
>
> Server: Windows 2003 SBS Standard (DC)
> Server: Windows 2003 Standard R2 - Terminal Server
>
> Goal: I need to implement the terminal server for our remote sales staff. We
> recently did a big push on our accounting software - which requires the
> workstations to have amounts of RAM and atleast 2.0ghz. Most of remote sales
> agents have laptops that do not qualify for the upgrade. Instead of replacing
> 5 laptops, we purchased the hardware to make a terminal server (Dual Quad
> Core, 4gigs RAM etc). This will allow our sales team to VPN in and RDP to the
> term.server. There will also be 3 users within the office that have desktops
> here that will be permitted to remote into the TS.
>
> AD Structure
>
> Created Terminal Server OU, added this server to it. Mapped a GPO to the OU
> and am using the Computer Policies only
>
>
> I created a seperate GPO to lock down access on the terminal server, for a
> group called Terminal Server users. This works fantastic, but I of course if
> you move it to the root level of the AD Structure - it effects their Desktop
> login policy as well.
>
> Purposed Work Arounds:
>


If I understood you correctly, your work around is to use loopback
policy on the TS OU. That way, the GPO setting only affect
the user on the TS itself, not their desktop or laptop.

> Option 1
>
> create a generic user names and passwords (i.e: Sales) and in the login
> script include a VBScript to prompt for their real username and password to
> be able map their user folder.
>
> Pro: Fairly easy to implement, user cfg gpo applies
> Cons: Not really able to tell who is logged in, not really secure login to
> TS because username/password would have to be dumafied so people don't get
> confused.
>
>
> Option 2
>
> create a new user account, jdoe is regular jdoe.ts is for terminal server.
>
> Pro: GPO applies, matches criterial to know who is online when viewing
> connections
> Cons: Another username and password to remember - I don't beleive there is
> away of important/synchronizing their normal user password with this account,
> how would you map to their user drive - would u still need the VB script?
>
>
> Any other suggestions welcome
>
>
> Submitted to the following sections:
>
> microsoft.public.windows.group_policy
> microsoft.public.windows.active_directory
> microsoft.public.windows.terminal_services


moncho
 
Re: Termianl Server Implementation Question

This should help explain Loopback processing and how it will help solve
your problem:
http://www.dabcc.com/blogs/jeff/pos...oup-Policy-in-a-Terminal-Services-Environment

Jeff Pitsch
Microsoft MVP - Terminal Services

moncho wrote:
> Chris wrote:
>> Good Day Community,
>>
>> I'm going to outline a scenario I have, and just want get some
>> feedback on what would be the best method to implement it.
>>
>> Scenario
>>
>> Server: Windows 2003 SBS Standard (DC)
>> Server: Windows 2003 Standard R2 - Terminal Server
>>
>> Goal: I need to implement the terminal server for our remote sales
>> staff. We recently did a big push on our accounting software - which
>> requires the workstations to have amounts of RAM and atleast 2.0ghz.
>> Most of remote sales agents have laptops that do not qualify for the
>> upgrade. Instead of replacing 5 laptops, we purchased the hardware to
>> make a terminal server (Dual Quad Core, 4gigs RAM etc). This will
>> allow our sales team to VPN in and RDP to the term.server. There will
>> also be 3 users within the office that have desktops here that will be
>> permitted to remote into the TS.
>>
>> AD Structure
>>
>> Created Terminal Server OU, added this server to it. Mapped a GPO to
>> the OU and am using the Computer Policies only
>>
>>
>> I created a seperate GPO to lock down access on the terminal server,
>> for a group called Terminal Server users. This works fantastic, but I
>> of course if you move it to the root level of the AD Structure - it
>> effects their Desktop login policy as well.
>>
>> Purposed Work Arounds:
>>

>
> If I understood you correctly, your work around is to use loopback
> policy on the TS OU. That way, the GPO setting only affect
> the user on the TS itself, not their desktop or laptop.
>
>> Option 1
>>
>> create a generic user names and passwords (i.e: Sales) and in the
>> login script include a VBScript to prompt for their real username and
>> password to be able map their user folder.
>>
>> Pro: Fairly easy to implement, user cfg gpo applies
>> Cons: Not really able to tell who is logged in, not really secure
>> login to TS because username/password would have to be dumafied so
>> people don't get confused.
>>
>>
>> Option 2
>>
>> create a new user account, jdoe is regular jdoe.ts is for terminal
>> server.
>> Pro: GPO applies, matches criterial to know who is online when viewing
>> connections
>> Cons: Another username and password to remember - I don't beleive
>> there is away of important/synchronizing their normal user password
>> with this account, how would you map to their user drive - would u
>> still need the VB script?
>>
>> Any other suggestions welcome
>>
>>
>> Submitted to the following sections:
>>
>> microsoft.public.windows.group_policy
>> microsoft.public.windows.active_directory
>> microsoft.public.windows.terminal_services

>
> moncho
 
Re: Termianl Server Implementation Question

Chris,

Chris wrote:
> Created Terminal Server OU, added this server to it. Mapped a GPO to the OU
> and am using the Computer Policies only
>
>
> I created a seperate GPO to lock down access on the terminal server, for a
> group called Terminal Server users. This works fantastic, but I of course if
> you move it to the root level of the AD Structure - it effects their Desktop
> login policy as well.


This is exactly the scenario, you'd use "Loopback processing" mode for.
You basically configure the lockdown-user settings in a GPO that you
link to the OU with the TS computer objects. Enabling "Loopback" makes
the TS servers look at the user config settings in the GPs that apply to
it and enforce them (merging with the user config settings the user has
with his/her GPOs - or replace the user settings the user has):

http://www.frickelsoft.net/blog/?p=22
http://support.microsoft.com/kb/231287
http://technet.microsoft.com/en-us/library/cc757470.aspx

cheers,

Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste
 
Re: Termianl Server Implementation Question

Chris <Chris@discussions.microsoft.com> wrote:
> Good Day Community,
>
> I'm going to outline a scenario I have, and just want get some
> feedback on what would be the best method to implement it.
>
> Scenario
>
> Server: Windows 2003 SBS Standard (DC)
> Server: Windows 2003 Standard R2 - Terminal Server
>
> Goal: I need to implement the terminal server for our remote sales
> staff. We recently did a big push on our accounting software - which
> requires the workstations to have amounts of RAM and atleast 2.0ghz.
> Most of remote sales agents have laptops that do not qualify for the
> upgrade. Instead of replacing 5 laptops, we purchased the hardware to
> make a terminal server (Dual Quad Core, 4gigs RAM etc). This will
> allow our sales team to VPN in and RDP to the term.server. There will
> also be 3 users within the office that have desktops here that will
> be permitted to remote into the TS.
>
> AD Structure
>
> Created Terminal Server OU, added this server to it. Mapped a GPO to
> the OU and am using the Computer Policies only]


Ah, but you need user policies, too - with loopback processing enabled. See
KB 278295 for some good
lockdown suggestions. Also see MVP Patrick Rouse's articles at
http://www.sessioncomputing.com/articles.htm


>
>
> I created a seperate GPO to lock down access on the terminal server,
> for a group called Terminal Server users. This works fantastic, but I
> of course if you move it to the root level of the AD Structure - it
> effects their Desktop login policy as well.
>
> Purposed Work Arounds:
>
> Option 1
>
> create a generic user names and passwords (i.e: Sales) and in the
> login script include a VBScript to prompt for their real username and
> password to be able map their user folder.


>
> Pro: Fairly easy to implement, user cfg gpo applies
> Cons: Not really able to tell who is logged in, not really secure
> login to TS because username/password would have to be dumafied so
> people don't get confused.
>
>
> Option 2
>
> create a new user account, jdoe is regular jdoe.ts is for terminal
> server.
>
> Pro: GPO applies, matches criterial to know who is online when viewing
> connections
> Cons: Another username and password to remember - I don't beleive
> there is away of important/synchronizing their normal user password
> with this account, how would you map to their user drive - would u
> still need the VB script?
>


Neither of the above. They should log in with their own AD accounts.
>
> Any other suggestions welcome
>
>
> Submitted to the following sections:
>
> microsoft.public.windows.group_policy
> microsoft.public.windows.active_directory
> microsoft.public.windows.terminal_services


Actually, I don't see the crosspost to the AD group...but it isn't really
relevant here anyway.
 
Re: Termianl Server Implementation Question

Hi

I have same case, but now i just planning. Now our company have one server
enable for terminal server services, but i would like to know how to
improve the TS security setting, is need setup TS server with DC first after
enable terminal server services... help help.


"Chris" <Chris@discussions.microsoft.com> wrote in message
news:93BD410D-45C7-4801-BDDA-BA4D96A9D9EB@microsoft.com...
> Good Day Community,
>
> I'm going to outline a scenario I have, and just want get some feedback on
> what would be the best method to implement it.
>
> Scenario
>
> Server: Windows 2003 SBS Standard (DC)
> Server: Windows 2003 Standard R2 - Terminal Server
>
> Goal: I need to implement the terminal server for our remote sales staff.
> We
> recently did a big push on our accounting software - which requires the
> workstations to have amounts of RAM and atleast 2.0ghz. Most of remote
> sales
> agents have laptops that do not qualify for the upgrade. Instead of
> replacing
> 5 laptops, we purchased the hardware to make a terminal server (Dual Quad
> Core, 4gigs RAM etc). This will allow our sales team to VPN in and RDP to
> the
> term.server. There will also be 3 users within the office that have
> desktops
> here that will be permitted to remote into the TS.
>
> AD Structure
>
> Created Terminal Server OU, added this server to it. Mapped a GPO to the
> OU
> and am using the Computer Policies only
>
>
> I created a seperate GPO to lock down access on the terminal server, for a
> group called Terminal Server users. This works fantastic, but I of course
> if
> you move it to the root level of the AD Structure - it effects their
> Desktop
> login policy as well.
>
> Purposed Work Arounds:
>
> Option 1
>
> create a generic user names and passwords (i.e: Sales) and in the login
> script include a VBScript to prompt for their real username and password
> to
> be able map their user folder.
>
> Pro: Fairly easy to implement, user cfg gpo applies
> Cons: Not really able to tell who is logged in, not really secure login to
> TS because username/password would have to be dumafied so people don't get
> confused.
>
>
> Option 2
>
> create a new user account, jdoe is regular jdoe.ts is for terminal server.
>
> Pro: GPO applies, matches criterial to know who is online when viewing
> connections
> Cons: Another username and password to remember - I don't beleive there is
> away of important/synchronizing their normal user password with this
> account,
> how would you map to their user drive - would u still need the VB script?
>
>
> Any other suggestions welcome
>
>
> Submitted to the following sections:
>
> microsoft.public.windows.group_policy
> microsoft.public.windows.active_directory
> microsoft.public.windows.terminal_services
 
Back
Top