SG: how do I setup the TSAC on the TS server so that users cann access it?
-kw

Restrictions on the TS user sessions would normally be handled by using
Group Policy configuration at the DC (SBS), and the most common way of
handling that is to use Loopback Mode. Loopback Mode allows you to specify
both User and Computer Configuration settings that apply to any user session
on the TS, regardless of if you allow different Group Policy based
options/features for users/computers other than when using the TS. For
instance, I commonly disallow users to have the Shutdown command or to
access the Control Panel on the TS, even if I do allow that for them at
their local workstations. The loopback mode settings allows you to specify
restrictions that override normal user permisssions.

This concept can be a little confusing if you are not already doing Group
Policy work. Group Policy is a convoluted concept you don't necessarily
understand when you start. I think of it as "not being able to recognize
answers because you still don't know what questions to ask".

There's a whitepaper on using Group Policy with Terminal Server. You can go
to the MS site for Windows2000 Server, find the Technology guides for
Terminal Server and you will see a fairly brief and sensible paper on using
Group Policy with Terminal Server.

The only thing about using Group Policy in Loopback Mode that I find is
really poorly revealed is that when you choose to use it, you need to decide
if you want to use Merge or Replace in the Loopback. What I find to be the
most sensible approach for a newbie Group Policy Administrator is to set
Replace as the option ~only~ on the first Policy you create in the OU where
you place your TS Server object and make that policy the lowest policy in
that stack. The effect then is that all policies that normally apply to any
user or computer will be replaced entirely...essentially making the Loopback
Policy a clean slate at that point including only what is in that policy for
both Computer and User settings. You can then add additional policies in the
same stack above the first policy and these can include Loopback Mode as
Merge meaning that all the rest of the policies in this same OU ~add~ to the
first Loopback Mode policy in that OU. This is much easier to understand and
troubleshoot.

If you have more than one Loopback Policy that applies and both are set to
Replace, the second policy to apply effectively overrules the first one
making the first one server no purpose. This is because in normal policy
accumulation, policy items that have no preference indicated carry forward
as not changing a previously set condition in an earlier policy in the
stack, but with Loopback Mode set to Replace, this effectively forces "no
preference" on all items even if a previous policy had set a policy.
Therefore, Replace tell not to just replace items you have a preference for,
it's the equivalent to replace all previous items back to "no preference"
and then add only the preferences to that which are stated in the current
policy.

When you first attempt to do policy management, you will be tempted to
create a single policy that includes everything about everything....that's a
bad idea. Far better is to create a number of concise policies that do
specific tasks separately like "IE Settings", "Logon Scripts", "Desktop
Settings", and "Computer Security Policy" each in a different policy file.
If you do this, you will find that 'modular' policies like this can be used
in many locations in your AD tree, not just one specific location. It allows
you to use Loopback Mode very conveniently to Replace all previous policies,
but then simply apply the little once right about the Loopback|Replace
policy so that the User Logon script indeed does apply even though you just
use Replace to remove everything the user normally gets because of a policy
you configured on the User object elsewhere in the tree.

The explanation I've made here may well be confusing if you are a newbie, or
it may spark recognition of "oh, I see!" if you have played with policies a
bit and become stumped on the need/value/challenge of loopback or replacing
policies without losing things you want to always apply to a user session no
matter what computer they use, yet control things uniquely at a special
station like a TS in a way that overrides normal settings for a user at any
other station.