I have configured a Windows 2000 Server and joined it to an existing Windows NT Domain, hence Active Directory has not been setup.  I have configured terminal server in application mode (without licence server) in order to try out this feature.  I successfully connect using a client but I would like to restrict access for this user as he is able to use internet explorer, and any other apps on the server running TS.  I have looked into Domain Group Policies but this is not running Active Directory and I do not want the changes to affect the users local machine only his TS session.  With local server policies the changes applied affect the Administrator aswell as the users.  Any information would be grately appreciated.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nader alkahtaniConsultantCommented:
How to Apply Group Policy Objects to Terminal Services Servers :
Applies To :
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server

This article was previously published under Q260370
Microsoft Windows 2000 Terminal Services servers are installed for users in Application Server mode. When the Windows 2000 Terminal Services servers are in a Windows 2000 Active Directory domain, the domain administrator implements Group Policy Objects (GPOs) to the Terminal Services server to control the user environment. This article describes the recommended process of applying GPOs to Terminal Services without adversely affecting other Windows 2000 servers on the network.
There are 2 methods for applying GPOs to Terminal Services without adversely affecting other Windows 2000 Server computers on the network.
Method 1
The first option is to create an organizational unit (OU) specifically for the Terminal Services servers in Application Server mode. This OU allows specific GPOs to be applied to only those Terminal Services computers, creating a tightly controlled Terminal Services experience for the users without affecting the other servers in the Active Directory domain. This OU should not contain users or other computers; therefore domain administrators can fine-tune the Terminal Services experience. The OU can also be delegated for control to subordinate groups such as server operators or individual users.

To create a new OU for the Terminal Services servers, follow these steps:
On the taskbar, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
Expand the left pane.
Click domainname.xxx.
On the Action menu, click New, and then click Organizational Unit.
In the Name box, type a name for the Terminal Services server.
Click OK.

The new Terminal Services OU now appears in the list in the left pane and contains no default objects. The Terminal Services servers reside in either the Computers OU or the Domain Controllers OU.
Locate and click the Terminal Services server or servers, click Action, and then click Move.
In the Move dialog box, click the new Terminal Services server or servers, and then click OK.
Click the new Terminal Services OU to verify that the move has successfully taken place.
To create a Terminal Services Group Policy object, follow these steps:
Click the new Terminal Services OU.
On the Action menu, click Properties.
Click the Group Policy tab.
Click New to create the New Group Policy object.
Click Edit to modify the group policy.

NOTE: Most of the relevant settings are under Computer Configuration, Security Settings, or Local Policies. For example, under User Rights Assignment in the list on the right, you find Log on Locally, which is required for logging on to a session on Terminal Services; and you also find Access this computer from the network, which is required to connect to the server outside of a Terminal Services session. This is also where you can prevent users from being able to shut down the system. The Security Options folder is where many of the restrictions should be made and where there are similar settings to the NTConfig.pol file in Windows NT 4.0 Server and Terminal Server Edition. Settings for the user part of the policy should not be applied here because the users have not been placed into this OU with the Terminal Services server. This article is written for machine policy implementation.
When modifications are completed, close the Group Policy editor, and then click Close to close OU Properties.
Method 2
The second option is to apply GPOs to Terminal Services servers exclusively with the use of a GPO Loopback policy. This policy directs the system to apply the set of Group Policy objects for the computer to any user who logs on to the computer affected by this policy. This policy is intended for special-use computers, such as those in public places, laboratories, and classrooms, where you must modify the user policy based on the computer that is being used. Without Loopback, the user's Group Policy objects determine which user policies apply. If this policy is enabled, the location of a users's computer object is the main factor in determining which set of Group Policy objects are to be applied.

This implementation is described in the following Knowledge Base article:

231287 Loopback Processing of Group Policy

System Policies in Windows NT 4.0 Terminal Services Edition are also implemented differently than on other Windows NT servers, as described in the following Knowledge Base article:
192794 How to Apply System Policies to Terminal Server

When possible, Terminal Services should be installed on Windows 2000 member servers instead of on domain controllers because the users need Log on Locally user rights. When the Log on Locally right is given to domain controllers, it is given to every domain controller in the domain because of the shared Active Directory database. Windows 2000 Member Servers are granted Log on Locally user rights by default in the Local Security Policy when Terminal Services is installed in Application Server mode.

For additional information about Log on Locally rights, click the article numbers below to view the articles in the Microsoft Knowledge Base:
247989 Domain Controllers Require the 'Log on Locally' Group Policy Object for Terminal Services Client Connections

234237 Assign Log On locally Rights to Windows 2000 Domain Controller

Windows NT 4.0 Terminal Services Edition has the same concern with Log on Locally rights to domain controllers because of the common Security Accounts Manager (SAM) database replicated from the primary domain controller (PDC) to all backup domain controllers.

For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
186529 Local Policy Does Not Permit You to Log On Interactively

The machine account of the terminal server should be added to the security properties of the GPO being created for loopback. To do this, follow these steps:

Select the Security tab of the GPO created for Loopback.
Click add.
Select the machine account from the domain list.
Select the "Read" and "Apply Group Policy" rights from the permissions field.
Click OK to close and save the policy settings.


see also http://support.microsoft.com/default.aspx?scid=kb;EN-US;186529


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
nader alkahtaniConsultantCommented:
briganteAuthor Commented:

Thank you for your prompt response to my question.  The extensive information you provide has helped me understand how Group Policies should be setup with an Active Directory Domain which i plan to implement soon.  At present though I have the TS server within an NT4.0 Domain so active directory will not be setup on the Terminal Services Server.  This unfortunately means that the solution you provide via active directory users and computers cannot be implemented.  I have applied basic local server policy restrictions so that users cannot see Start - Programs,  icons on desktop etc.  But they do have access to the Start - Run so they can run pretty much anything.  The most annoying this about this is that it affects the Administrator so if i need to access programs from the start menu i have to remove the policies temporarily.

Thanks again for your efforts!  If you can think of anything else I would be very grateful.
Howdy mate, here is my suggestion, alas it's not gonna be worded quite as well as Nadir's as this is just streaming from memory, but here we go.  Basically the scenario you're describing is the same as when I first installed TS here at Princess Yachts.

Ok so based on the fact that you don't have an active directory we'll be using the NT4 System Policy Editor instead (POLEDIT.EXE).  You might wanna pull down some extra template (ADM) files off the NT4 resource kit for customising the look of your 'exported desktop'.

The basic jist of it is to add/create a group within POLEDIT that's a Global group on your NT4 domain.  You can then apply your 'desktop' settings to a selected group of user(s).
Log onto your server as an administrator account, customise your applications, setting in Word and whatever just the way you want them.  Then log off as the account and log back onto the server as another administrator account. Create a folder on a shared resource (this can be in your NETLOGON folder on your DC as it needs to be read-only to users).  Right-click on My Computer, go into user profiles and 'copy' the profile of the administrator user account you've just customised to the folder on NETLOGON (make sure you've changed the permission so you as a Domain Admin can write to the locale).  When you've exported the profile, navigate to that location and rename the NTUSER.DAT file to NTUSER.MAN

Now you can load up POLEDIT again, add your 'group' for Domain admins and remove ticks from the options to block inheritance of your 'lock-down' policy that you're gonna apply to your TS users.  Then as I mentioned before create the group for the TS users and customise the policy.

In User Manager for Domains set the TS user profile path to the location where you've exported the profile to.  you might wanna share this location so the path is a bit shorter, also 'cos you need to specify this path in POLEDIT and there is a finite restriction on how long it can be.  If you also create a share for the desktop, and change the permissions you can stop users from creating their own shortcuts... bit draconian... but there you go.

The only thing remaining is to save you're POLEDIT policy file to NETLOGON, and then load up POLEDIT on your TS box, and set the policy path to \\pdc\netlogon\ts.pol (or bdc) alas you can't use %logonserver% in this field.

Sorry that this is so wordy, it's a bit of a ramble-a-thon... but what the hell.  Perhaps it'll help you out, or you'll just have a laugh of the strange and confused way that I first setup TS here... it does make sense... well to me anyway. and it worked for 100 users for 3 years until I upgraded the domain to active directory earlier this year.

Good luck.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.