Rapid Evaluation Methods for Visual Studio .NET
Visual Studio Team
Created: July 2001
Revised: July 2002
Summary: This article provides technical details for the rapid evaluation of Microsoft® Visual Studio® .NET using either Windows® 2000 Terminal Services or disk imaging. (16 printed pages)
Terminal Server Architecture
Installing Visual Studio .NET on a Terminal Server
Sample Terminal Server Configuration
Disk Imaging Method
Appendix A. Installing Terminal Services
Appendix B: Additional Terminal Services Information and Considerations
Appendix C: Additional Resources
Terminal Services and disk imaging offer developers two alternatives for the rapid evaluation of Visual Studio .NET, while ensuring the integrity of their production-development environment.
Terminal Services — a component of Windows® 2000 Server, Windows® Advanced Server, and Windows® Datacenter Server — is a technology that allows users to remotely execute applications on a Windows 2000-based server over virtually any type of network connection. By means of Terminal Services, developers can use and evaluate Visual Studio .NET without installing it on their individual machines. This paper details common methods of deploying Windows 2000 Terminal Services, and the installation method required for Visual Studio .NET.
Note In this document, the phrase "terminal server" refers to a Windows 2000 server with Terminal Services enabled in application-server mode, which is the traditional terminal server mode. We will not discuss Windows 2000 Terminal Services in remote administration mode. For further information about this subject, see Terminal Services.
Drive imaging is another method to ensure the integrity of your production-development environment. It provides an easy and efficient way to duplicate your basic installation on a new partition. It also makes it easy to restore your operating system to its original state. Drive imaging requires the use of Power Quest Drive Image Pro® or Symantec Ghost® duplication software. Using the driving duplication methods described in this document allows the developer to take a snapshot of their current system state prior to installation of Visual Studio .NET, in case a roll-back is needed.
Note Compliance with the Microsoft Visual Studio .NET EULA is still required with the use of the above methods. Additionally, the appropriate Windows 2000 Terminal Services licensing requirements (stated later in this document) must be met when using Terminal Services to host Microsoft Visual Studio .NET.
This document offers a detailed outline of how to deploy both of these methods and guidelines for managing the deployed environment. The major categories in each scenario will include, but are not exclusive to:
- Network architecture
- Server configuration
- Terminal services configuration
- Visual Studio .NET installation
- Load balancing
- Disk imaging process
This section details the procedure for deploying Terminal Services in a structured environment. Before proceeding, ensure that the hardware (including network adaptors, disk controllers, and video cards) is on the Microsoft® BackOffice® List and Windows 2000 Hardware Compatibility List (HCL).
Terminal Services can provide access to Visual Studio .NET if you do not have an extra machine on which to evaluate Visual Studio .NET. Terminal Services also provides access to remote users. The screen, mouse, and keyboard information sent by Terminal Services typically uses less bandwidth than an application that must be downloaded and then run locally on a remote user's machine, or which requires significant network bandwidth for data transfer.
In addition, you can install Visual Studio .NET on just one server that can be accessed by multiple users. As additional evaluation versions of Visual Studio .NET become available, only the terminal servers will need to be updated, rather than multiple individual machines.
Developing the physical design involves planning the position of Terminal Service within the Windows infrastructure. Three principal domain structure alternatives apply to a Terminal Services installation. You may use any of the following alternatives and leverage the existing environment:
- Use no domain structure. Without domain architecture, users will need separate accounts on every Windows 2000 server running Terminal Services. This limits scalability and makes it more difficult to administer groups of users.
- Implement Windows 2000 Terminal Services in the existing Windows NT® 4.0 domain environment. This allows you to take advantage of the new features available in Windows 2000 Terminal Services, without impacting the production user environment. However, keep in mind that the existing security account manager (SAM) limitations of the Windows NT 4.0 domain model will apply under this approach. Administrators can add Terminal Services-specific attributes to users' accounts. This adds a small amount of information, typically 1K or less, to a user's entry in the domain's SAM database.
- Leverage the Microsoft® Windows 2000 Active Directory™ infrastructure. It leverages the ability to host thousands of users in its database. It also gives you the option of applying group policies to control the user experience when connected to Terminal Services.
Note With any of these alternatives, do not run Terminal Services application server mode on a server that is also a domain controller. Instead, use remote administration mode for a server that is a domain controller.
The following pre-installation considerations exist for Visual Studio .NET being deployed in a Terminal Services environment:
- Terminal Services must be set to install mode prior to installing any application.
- Microsoft does not support any application that uses a hardware security key on Terminal Services, because these devices are designed to limit the use of the software to one system only.
The majority of desktop applications, including Visual Studio .NET, install and execute correctly on Terminal Services.
Note For IP address-dependent applications, Terminal Services cannot pass the IP address of individual clients to an application. Multi-user applications that require each user to have a unique IP address will not work properly, because every user will appear to originate from the IP address of the server itself. Certain security applications, such as firewalls, are designed to require unique IP addresses in this way. You may need to alter plans to use Terminal Services to support any such application.
Microsoft Visual Studio .NET can be installed just like other applications on a terminal server. The installation is accomplished at the console of the server (session 0). Visual Studio .NET cannot be installed from a remote session. Microsoft Visual Studio .NET includes an .msi file for installation.
The following is required to put the terminal server into installation mode:
- From the Add/Remove Programs in Control Panel, click Add Programs. Then simply select the CD or floppy option, and point to your installation location.
Terminal Services is changed from a virtualized mode of operation that allows multiple users to have separate sessions or virtual machines. Once the installation is completed, the terminal server is returned to the virtualized, execute mode.
An additional method exists for installing applications without using the Control Panel. It can be accomplished manually by executing from a command prompt, as follows:
- From a command prompt, type change user /install.
- Once the application has been installed, prior to starting the application, type change user /execute.
These commands are used to switch the terminal server from the virtualized execute mode to the non-virtualized installation mode for application installation.
Users should be configured as power users to allow the greatest flexibility in application development. This user designation allows developers to access the Microsoft® Internet Information Server (IIS) services and other system services on the terminal server, especially for Web-based development. However, if a stronger security model is required, user access can be restricted, and the appropriate level of access granted on a group or individual basis.
Visual Studio .NET creates two groups, VS Developers and VS Debugger Users. Visual Studio .NET users should be added to these groups.
Once in operation, the terminal server configuration is limited to having only one debugging session per service. For example, one user can run the debugger for IIS at a time.
Configure Default Profile Path
The default profile path typically copies all user profiles to the C: drive. Depending on the number of users, this action could deplete the free space on the drive. In this case, the default path for user profiles will be moved to another drive by changing or modifying the following registry keys.
Note The profile path must be located on the same physical disk as the C: drive.
The following table shows the registry key values that must be changed to move the profiles to another drive. For more information, see Knowledge Base articles "Q214653: How to Set the Path for the All Users Profile" (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q214653) and "Q214636: How to Set the Path for the Local Default User Profile" (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q214636).
|HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\DefaultUserProfile||REG_SZ||Default User|
|HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory||REG_SZ||<Drive>:\Documents and Settings|
To facilitate the utilization of user profiles, plan ahead and identify where they will be stored and how they will be managed, as follows:
- Identify a location on a file or print server that has enough space to store the profiles and that is readily available to Terminal Services users.
- Create a Windows 2000 share that users can gain access to with read/write privileges. We suggest that you hide this share so users cannot easily gain access to it. To hide the share, append the "$" symbol to the end of the share name, as in "Profiles$". Note that profiles should be stored in a different location from user home directories.
Unless you manage user profiles correctly, they will tend to grow in size. The following two methods to prevent the growth of user profiles:
- Create mandatory profiles for the terminal server environment. By using a mandatory profile, you can control profile size, which affects logon performance.
- Use quota management and group policies included in Windows 2000 to manage the size of the user profiles.
Note User profiles are cached each time a user logs on to the terminal server. You can delete cached profiles after the users log off.
Terminal Services Configuration
In this section, Terminal Services configuration and options are detailed. Windows 2000 Terminal Services management requires three tools:
- The Terminal Services Configuration snap-in allows for configuration of the Remote Desktop Protocol (RDP) connection parameters (timeout, encryption, and auto-execute applications) and connection permissions.
- Application Security permits application executables to run when a user establishes a Windows 2000 terminal server connection.
- Terminal Services Manager provides a real-time, browser-like view of Windows 2000 terminal server-connected users and their session status, as well as a view of user-spawned processes.
From Administrative Tools, choose Terminal Services Configuration. Then, in the Connections folder, configure the RDP connection. The server settings apply server-wide.
From the Terminal Services Configuration window, expand the Connections folder, and then click RDP-Tcp to access the RDP-Tcp properties. The default RDP connection protocol encryption level is medium. This affects clean installs only, and applies to both remote administration and application server modes. All RDP messages exchanged between the client and server (both keystrokes and drawing data) are protected with 40-/56-bit encryption. Encryption levels can be set to low (40 bit), medium (default 56 bit), and high (128 bit). The encryption level is set server-wide on a per connection basis, rather than individually for each client. For optimal performance, use the default level of encryption, unless every client connecting to Terminal Services will be running on Pentium or higher microprocessors.
If you must accommodate older processor or users outside the United States and Canada, but still want to provide enhanced encryption to users who can take advantage of it, consider deploying two or more similar servers with different encryption levels. Users with low-performance hardware could connect to the server running low encryption, and users with higher-performance hardware would connect to a server running medium or high encryption.
Note Select the Use standard Windows authentication check box on the RDP-Tcp properties page.
Windows 2000 Users Permission
During setup and after selecting Terminal Servers, the Windows Components wizard allows you to select the default permissions for application compatibility and type of security to use. Visual Studio .NET is certified for Windows 2000 and follows the Windows 2000 security model. The terminal server should be configured for "Permissions compatible with Windows 2000 Users" mode.
By default, all RDP connections must prompt for a password. This applies to both remote administration and application server modes. However, Internet Connector licensing will continue to log on the TSInternetUser account without prompting for password. The Client Connection Manager can be used to pre-configure server connections that include a <Domain, Username, Password> combination.
Windows 2000 Server Terminal Services requires access to a Terminal Services license server. If there are two or more Windows 2000 terminal servers on a LAN, the Terminal Services license server should be configured on a server other than a Windows 2000 terminal server. Because only one Terminal Services license server is required to support multiple Windows 2000 terminal servers on a LAN or WAN, this allows you to take a terminal server down for maintenance without affecting any of the other terminal servers. Also, in a Windows 2000 Active Directory environment, the license server needs to run on a domain controller, and as discussed earlier, a Windows 2000 terminal server should not be a domain controller.
In a Windows NT 4.0 domain, the Windows 2000 Terminal Services license server must run on the Windows 2000 member server. However, it will need to be moved to a domain controller when the Windows NT 4.0 domain is upgraded to Windows 2000 and Active Directory. Therefore, it is highly recommended that the Terminal Services license server be installed on a server that you intend to promote to a domain controller when you convert your Windows NT 4.0 domain to Windows 2000 Active Directory.
Windows 2000 Terminal Services servers can only work with Windows 2000 license servers within 90 days after the first client connects to a Windows 2000 terminal server. The Terminal Services licensing service needs to be installed on a Windows 2000 domain controller, either in a domain that is using Active Directory, or on a Windows 2000 server in an NT 4.0 domain or workgroup.
The appropriate number of Terminal Services Client Access Licenses (TS CALs) must be obtained through your sales channel for every non-Windows 2000 licensed device that will connect to a Windows 2000 terminal server. Temporary TS CALs will be issued to non-Windows 2000 devices if no CALs are available on the license server. This will allow connections to the Windows 2000 terminal server for another 90 days, after which the client will be denied access until a TS CAL is available from the license server.
Note In large implementations of Windows 2000 Terminal Services, at least two licensing servers should be deployed for fault tolerance.
For more information, visit Terminal Services and Microsoft Windows 2000 Terminal Services Licensing. For information about licensing for Terminal Services in Windows 2000, visit Licensing for Terminal Services in Windows 2000.
Scaling and capacity planning is especially important when deploying Terminal Services, as computing power is relatively centralized and bottlenecks can have a significant performance impact when there are a number of concurrent users. When weighing whether to scale up or to scale out with Terminal Services, many factors need to be considered:
- Number of concurrent users that will be accessing the terminal server or terminal server cluster
- Type of user accessing the server: knowledge worker, structured task worker, or data entry worker
- Network bandwidth requirements
- Redundancy and fault tolerance requirements
Also, consider the applications to be hosted on Terminal Services. Determine whether the applications are CPU-intensive or memory-intensive. If an application is memory-intensive, then performance measures on page and non-page pool memory is important, and more server memory is not necessarily going to help. In this case, an additional server may be required to share the load of user requests.
Note that the typical developer is considered a knowledge worker, so in this scenario, scaling should be based on the metrics for a knowledge worker environment. Server scaling is also important for properly satisfying the terminal server requirements. The amount of hardware and type of hardware can be determined by performing scalability tests as outlined in the scaling white paper at Windows 2000 Terminal Services Capacity and Scaling. The utilities used to perform these tests are available with the Windows 2000 Resource Kit. The scripts and updated utilities will be available for downloading at Terminal Services Scaling Scripts and Utilities.
Note Installing such BackOffice applications as Microsoft® SQL Server and Microsoft® Exchange Server on Terminal Services in application-server mode is not recommend. This mode is designed and optimized for desktop applications; installing BackOffice applications may severely impact the performance of the application and the terminal server.
The following table shows an example scenario of a Terminal Services implementation that is used within a Microsoft Corporation development and test lab. The figures in this sample configuration are only estimates and are provided as a base-line configuration to offer users a starting point in estimating their own system requirements. These performance numbers and specifications were specific to one specific environment and may change in different environments based upon hardware, network configuration, and user load. Performance may also vary depending upon individual usage.
|Hardware Configuration||Number of Concurrent Users||Disk Configuration|
|Two Pentium II 400mhz processors
One gigabyte (GB) of memory
|18-22||One 9.1 GB boot drive (core OS)
One 9.1 GB data
In the following chart, notice that memory consumption increases more rapidly than available memory decreases. This is expected, because rarely used pages of memory are swapped to the page file and aren't needed in RAM. Available memory is the critical factor, for if available memory gets too low, pages of frequently used memory will be swapped to the page file, and this will negatively affect performance.
Chart 1. Sample terminal server performance
The use of disk imaging is another method for individual users to install Visual Studio .NET on their development workstations without adversely affecting their original production environment. The following describes how a typical workstation can be imaged and quickly restored to its original state. In this scenario, a Windows 2000 Professional machine is used, though it also applies to Windows NT 4.0 or Windows® XP.
- One workstation with Windows 2000 Professional, Windows NT 4.0, or Windows XP
- One equally partitioned hard drive (or, if the workstation is equipped with multiple drives, another drive can be used to store the image, if enough space is available)
- One licensed copy of either PowerQuest Drive Image Pro (http://www.powerquest.com/driveimage/) or Symantec Ghost imaging software (http://enterprisesecurity.symantec.com/products/products.cfm?productID=3)
Using the instructions included with the imaging products manuals, create an image of your existing Windows installation. The image in this scenario will be stored on the second partition of the current, imaged drive. The imaged drive can be either file allocation table (FAT) or NT file system (NTFS) file format; however, the partition in which the image is to be stored must be FAT or FAT32. The typical size of the image, using high compression with the imaging software, can be from 50 to 60 percent of the original imaged partition.
Once the image has been created and stored on the second partition, simply boot as usual and install Visual Studio .NET on the first partition, which should also be your boot partition. Now you are ready to evaluate the product.
In the case of a workstation with multiple drives, the image can be stored on any available FAT or FAT32drive with sufficient space for the image.
To get back to the original system state prior to installation, simply follow the instructions provided by the imaging software manufacturer, and restore the original system image to the workstation.
While Windows 2000 Server, Advanced Server, and Data Center Server all have Terminal Services included, Advanced Server and Data Center Server are the only versions that support Network Load Balancing (NLBS) and clustering. Windows 2000 Advance Server and Data Center Server are best suited to large implementations involving many users. These offer the greatest scalability and flexibility to support large user requirements.
The following steps detail the installation of Windows 2000 Server with Terminal Services in application mode. These are the typical steps necessary to setup and configure a basic Windows 2000 terminal server.
- Boot from the Windows 2000 Server CD. The setup process will load hardware support files.
- At the disk selection step, select the first disk and use all space to create the system partition. Accept the partition size suggested by Windows 2000.
Note Do not change the default partition size suggested by Windows 2000. The small amount of unpartitioned space will be required later to enable disk mirroring. This configuration will provide a server environment that is more highly available and fault tolerant.
- Select the option to format the partition as NTFS, which will allow for greater security. The server will copy files to the hard disk and re-boot to begin the installation.
- The Windows 2000 Server Setup wizard appears. Click Next.
- On the Regional Settings page, click Next and then OK.
- Complete the Name and Organizational fields and click Next.
- In the Licensing dialog box, click Per seat and click Next.
- Type in an appropriate name for the computer and type in an appropriate password for the local administrator account. Click OK. A list of components to be installed is displayed.
Note If the computer name has underscores, an error message stating "The computer name 'NAME_SRV1' contains one or more non-standard characters" will be displayed. Click OK. You do not need to remove the underscores.
- In the Time Zone dialog box, select the appropriate time zone, and check that the date and time displayed are correct. Click Next.
- Click Application server mode for the operational mode of the server and click Next.
- In the Network Settings dialog box, click Custom Settings and click Next.
- Click Internet Protocol; click Properties.
- Click Use an IP Address from your subnet.
A static IP address is required for the use of Network Load Balancing (NLBS). If NLBS is not used, either a static or DHCP IP address is sufficient. Check with your local network administrator.
When using a static IP address, enter the following information on the property page for TCP/IP settings:
- IP address, which is the unique number for the server
- Your subnet mask
- Your default gateway
- Your preferred, or primary, DNS
- Your alternate DNS
- Click Advanced. On the IP Settings tab, add the Terminal Server cluster address as a secondary TCP/IP address. Click the Add button.
- In the subsequent dialog, enter the TCP/IP address of the cluster. Click Next.
The cluster IP address should appear as the second address in the list.
- Click the WINS tab, click the Add button, and type in the WINS server (if one exists on your network).
- Click the DNS tab and click Next. Type in the DNS server and additional DNS IP addresses. Click OK.
- Click Next. Select the Yes, make this computer a member of the following domain check box and type in the name of your domain or workgroup.
- Type in an administrative user name and password to add the computer to the domain. Click Next.
- Wait while files are copied to the hard disk and the server is configured, and then click Next.
- Restart the server and log on to the domain. Verify that networking is operating correctly by browsing the network neighborhood.
- Right-click the C: drive and choose Upgrade disk to dynamic.
- Reboot the server to complete the drive conversion. If the unpartitioned space was not retained, then the upgrade to dynamic is not possible, and consequently, disk mirroring is not possible.
The following sections discuss additional Terminal Services considerations.
Terminal Services by Remote Access Service (RAS)
Remote users who must use a dial-up connection to access Visual Studio .NET can benefit from Terminal Services thin-client technology. Applications that perform better on a LAN/WAN may not perform well over a slow dial-up connection; therefore, hosting Visual Studio .NET on a terminal server offers the best performance for the developer. However, applications that have off-line capabilities and synchronization should be given additional consideration, if in fact they can be used. No off-line synchronization is performed while hosted on the terminal server. Also, users with an unreliable connection can quickly access data and applications, and, if the link is dropped, reconnect to the session once the link is re-established.
Terminal Services over the Internet
Users can take advantage of the Terminal Services Advanced Client (TSAC). TSAC provides a connection through any browser that supports ActiveX® on an X86 processor. This solution eliminates the need to install the traditional Terminal Services client.
This is available on the Windows 2000 Service Pack 2 CD (\i386\Valueadd\TSAC), and also on the Web at Terminal Services Advanced Client. For more information, see the MSDN article Scripting the Terminal Services Advanced Client.
Users can also take advantage of Layer-2 Tunneling Protocol (L2TP) or Point-to-Point Tunneling Protocol (PPTP) to gain access to Terminal Services over the Internet. By using encryption, either of these tunneling options provides secure access to a private network for users operating over a public medium. Encryption requires the traditional installation of the Terminal Services client on the target workstation.
If your organization uses a firewall for security, remember to keep port 3389 open for RDP connections between the client and server. For best results, use a firewall that employs user-based authentication. A firewall that grants access based on IP address will allow access to a user of a server running Terminal Services if the IP address of that server has been granted access.
There are two traditional categories of firewalls:
- Packet filtering firewalls
These can differentiate traffic based on the network address (source or destination) and the session and application-level protocols used to carry data. For example, the firewall may allow traffic from a certain network address while dropping all other traffic. Or, it may open a certain TCP or User Datagram Protocol (UDP) port to allow DNS zone transfers or queries to complete successfully. Most commercially available routers come with packet filtering capability. RDP uses port 3389.
- Proxy firewalls
These act as intermediaries between client computers located on a private network and the Internet. All traffic from clients is sent to the proxy, which, as its name implies, then acts on behalf of the client over the public Internet. Direct connections between client computers and the host residing on the Internet are never established.
Both types of firewalls have advantages and disadvantages. When in doubt, contact your firewall vendor. Security requirements vary considerably from one organization to another. Therefore, a qualified security specialist should review any plans for connecting a private network to a public network, and then to your implementation.
Note The RDP protocol port can be changed if necessary, but requires the modification to be applied to both server(s) and clients. This only applies to the full Terminal Services Client and not the TSAC client. Refer to the Microsoft Knowledge Base article Q187623: How to Change Terminal Server's Listening Port.
You can assign data transfers between the client and server at one of three different levels of encryption.
Note The RDP Protocol is encrypted by default and cannot be turned off. Therefore, performing advanced network operations, such as using Network Monitor to look at packets generated by an RDP session, will result in unusable data.
The three available levels of encryption are as follows:
- Low encryption
With low encryption, traffic from the client to the server is encrypted using the RC4 algorithm and a 56-bit key (40-bit key for RDP 4.0 clients), whereas traffic from the server to the client is unencrypted. Low encryption protects sensitive data, like password entry and application data; the only data sent from the server to the client are screen refreshes, which are difficult to intercept even when unencrypted.
- Medium encryption
With medium encryption, traffic in both directions is encrypted using the RC4 algorithm and a 56-bit key (40-bit key for RDP 4.0 clients). This is the default security level at installation.
- High encryption
Traffic in both directions is encrypted using RC4 algorithm and a 128-bit key in the North American version of Terminal Services only. In the export version of Terminal Services, high encryption uses RC4 and a 56-bit key (40-bit for RDP 4.0 clients).
You can use the Network Load Balancing feature of Windows 2000 for load balancing to distribute work between two or more identical servers. You can accomplish this by using NLBS, in which a single name record resolves to a virtual name and IP address. For more information about NLBS, see Network Load Balancing Technical Overview or the Microsoft Knowledge Base article Q243523: Using Terminal Server with Network Load Balancing. You might also refer to the Windows 2000 Server Deployment Guide, chapters 16 and 18 (available through Microsoft Press in the Windows 2000 Resource kits).
You should disable session disconnect on servers running Terminal Services that are part of an NLBS cluster. Because a client could connect to any of the servers, it might connect to a server other than the one on which a disconnected session was left typically can be accomplished through either IP affinity or Class C affinity.
Note A cluster is limited to 32 hosts in an NLBS cluster. Multiple clusters can use DNS round-robin; however, to extend clusters beyond 32 hosts, providing greater scalability.
Adding and Removing Machines
With the use of NLBS, upgrades can be accomplished seamlessly. These are known as rolling upgrades. Because the NLBS cluster handles load distribution, a terminal server can be taken out of the cluster, and either upgraded or maintenance can be performed on it, and then it can be re-added to the cluster.
With the use of NLBS, Windows 2000 terminal servers can be added and removed from the cluster — transparently to end users. Simply ensure that no users are connected with active sessions on the terminal server you wish to remove, and then remove it from the cluster. To add a terminal server to the cluster, follow the instruction for this from the procedures for creating a cluster.
The addition of terminal servers is outlined below in the section on backing up terminal servers.
Backing up the Licensing Server
It is important to back up your license server to ensure that you can recover your licensing information easily in the case of a system failure. Backup needs to be done on a regular basis, and must include at least the system state, plus the Lserver directory. By default, this is %windir%\system32\Lserver.
The Licensing Service must be running while you restore a computer. Restoring the database and system state to the original license server (one with the same ID) restores all historical and active license information.
If you restore a backed-up licensing database to a different license server, the license server restores only the historical information about licenses issued. Licenses that have not been issued are not restored. However, information about the licenses not issued is posted to a system log that can be viewed in the Event Viewer. The information in the system log will include the number and type of licenses not issued that were not restored.
To restore the licenses not issued, install those licenses using the telephone installation method. The customer service representative can reissue lost licenses.
Delivering Terminal Server Applications to Clients
The ActiveX client allows users to connect to a terminal server from a Web page with Internet Explorer. Thus, installation of a Terminal Services Client is not required.
Security Note The sample default Web page includes a password box. The password is cached on the Web page, exposing a potential security risk. This password field should not be exposed on the default Web page.
The ActiveX client can be installed from the TSAC Web Page or from the Windows 2000 Service Pack CD. IIS must be installed on the Server first. After installation, the default Web page can be modified with Microsoft® FrontPage®.
Identifying and obtaining resources, scheduling training classes, and purchasing reference materials are also important tasks. The following offer additional Microsoft product and training information.
General Microsoft Reference Materials and Software Tools
- Microsoft Consulting Services.
- Microsoft Developer Network (MSDN), which provides tools and product information about Microsoft technology
- Microsoft TechNet, which provides technical information on Microsoft technologies.
- Microsoft Technical Support—Premier Support and Technical Account Manager (TAM)—basic and enhanced supportability review. Consult your MCS liaison or TAM for additional information: Microsoft Business Web site, and the Microsoft for Partners Web site.
- Microsoft BackOffice Resource Kit, which provides tools and white papers that assist with application development and management.
- Microsoft Online Support, which provides updated product information and technical support offerings for all Microsoft products. From here you can also search the Microsoft Knowledge Base — technical information based on 50,000 detailed articles on Microsoft products, bugs, and fix lists, including documentation errors and answers to the most commonly asked technical support questions.
- Microsoft Press.
- Microsoft Internet Services Network (ISN) for technical and marketing information on Microsoft technologies for the service provider industry.
- Windows 2000 General Information/Active Directory Architecture.
- Deploying and Planning Windows 2000.
- Windows 2000 Server Resource Kits.
- For group policies resources, see Introduction to Windows 2000 Group Policy.
- Implementing Common Desktop Management Scenarios.
- Group policy management tools at FullArmor.
- Q227369: Default Behavior for Group Policy Extensions with Slow Link.
- Q233548: Organizational Unit Controller Cannot Edit Group Policy Objects.
- Q203607: How to modify the Default Group Policy Refresh Interval.
- Q227448: Using Secedit.exe to Force Group Policy to Be Applied Again.
- Q247989: Domain Controllers Require the "Log on Locally" Group Policy Object for Terminal Services Client Connections.
- Office 2000 Resource Kit (ORK).
- Installing Office 2000 in a Terminal Services Environment (ORK Reference).
- Windows 2000 Terminal Services Home Page: Terminal Services: Providing the Benefits of Remote Application Execution.
- Windows NT Server Terminal Server Edition.
- For the most current information, refer to Microsoft.com Search.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, Backoffice, NetMeeting, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries/regions. Other product and company names mentioned herein may be the trademarks of their respective owners.