Terminal Server in Windows Server

Microsoft Pre-Release Software WinFX Runtime Components - Beta2

2006-05-24T00:47:00.000-07:00

Overview
"Windows Presentation Foundation", "Windows Communication Foundation", and "Windows Workflow Foundation" are the names for three strategic developer technologies that Microsoft plans to ship in 2006 as part of the Windows Vista operating system. In addition, Microsoft is making these technologies available on Windows XP and Windows Server 2003. The WinFX Runtime Components Beta 2 enables developers to continue experimenting with early builds of these technologies, get acquainted with the development experience, and provide Microsoft with feedback. More details about these technologies are below.

Please note that the License Agreement in this pre-release version of WinFX Runtime Components does not allow usage in a live operating environment. Information about Go-Live possibilities for WinFX Runtime Components can be found here.

Note: This is a beta release. Therefore, do not install these builds on machines you depend on. If you have a previous version of Avalon ("Windows Presentation Foundation"), Indigo ("Windows Communication Foundation"), or pre-released versions of .NET Framework 2.0 installed you must read this before download.

"Windows Communication Foundation" is the name for Microsoft’s unified programming model for building connected systems, formerly known as code-name "Indigo". It extends the .NET Framework 2.0 with additional APIs for building secure, reliable, transacted Web services that interoperate with non-Microsoft platforms and integrate with existing investments. By combining the functionality of existing Microsoft distributed application technologies (ASMX, .NET Remoting, .NET Enterprise Services, Web Services Enhancements, and System.Messaging), Indigo delivers a single development framework that improves developer productivity and reduces organizations’ time to market.

"Windows Presentation Foundation" is the name for Microsoft's unified presentation subsystem for Windows, formerly known as "Avalon". It consists of a display engine and a managed-code framework. "Windows Presentation Foundation" unifies how Windows creates, displays, and manipulates documents, media, and user interface. This enables developers and designers to create visually-stunning, differentiated user experiences that improve customer connection. When delivered, "Windows Presentation Foundation" will become Microsoft's strategic user interface (UI) technology.

"Windows Workflow Foundation" is the name for Microsoft's strategic programming model for building workflow enabled applications. It consists of a managed-code framework and designers for Visual Studio .NET. Windows Workflow Foundation includes both system workflow and human workflow. It supports a wide range of scenarios including: workflow within line of business applications, page-flow, document-centric workflow, workflow for service oriented applications and workflow for systems management. The Windows Workflow Foundation developer experience is consistent with existing WinFX technologies and includes support for VB and C#, debugging, a graphical workflow designer and the ability to write your workflow completely in code. Windows Workflow Foundation also provides an extensible model and designer to build custom activities which encapsulate workflow functionality for end-users or for re-use across multiple projects. Windows Workflow Foundation will be used across many future Microsoft products including Office “12”, BizTalk Server and the Microsoft Business Solutions. Most applications can benefit from the asynchronous state management features of the workflow model, the rapid development features of the designer, the potential for end-user flexibility, and the increased visibility into run-time code execution.

To start the installation process, you will need to run the download file; this will initiate the installation of the WinFX Runtime Components Beta 2; If you have troubles with the download manager, you can download the entire package for x86 or for x64 which are both .EXE files.

This Beta release supports Visual Studio 2005 RTM and the .NET Framework 2.0 RTM. The Microsoft® WinFX® SDK contains documentation, samples, and tools designed to help you develop managed applications and libraries using WinFX. You can install the SDK that corresponds to this release here.

Are Terminal Services Vulnerable?

2006-04-26T00:36:00.000-07:00

Are Terminal Services Vulnerable?

Access and security are always at odds in the networking world. Any feature or technology that provides a new way for authorized users to access a system remotely will also present a potential way for unauthorized users to gain access. Because Terminal Services is used in administrative mode in Windows 2000 (and Remote Desktop is used in Windows Server 2003) to allow administrators to perform such tasks as creating user accounts and setting permissions, changing system configurations, and other highly sensitive tasks, it is logical to question the security of a terminal services session.

Your terminal server is vulnerable to the same exploits that can be used against any Windows server, so it is important first to ensure that all current security updates and patches have been applied. Security vulnerabilities specifically related to Windows 2000 Terminal Services have also been reported. For example, SecuriTeam describes a vulnerability that can cause Group Policy to not be applied to terminal users if the number of user licenses installed is less than the number of current connections. See http://www.securiteam.com/windowsntfocus/5QP0D006US.html for more details.

Using terminal services across the Internet will require that you open port 3389, used by the Remote Desktop Protocol (RDP), on your firewall. Every additional port that is opened exposes the network to the possibility of exploit. An RDP-TCP connection is configured for the terminal server’s network adapter, to allow users to connect.

Securing Terminal Services CommunicationsHow, then, can you take advantage of the convenience of Windows Terminal Services and still protect your systems? First, make sure that terminal services is not installed (or enabled) on systems if you don’t want those systems to be accessed remotely. This includes Remote Desktop on Windows XP Professional computers. On Windows 2000 Server and Server 2003, TS is not installed by default. The Remote Desktop feature is installed on Windows XP Pro and Windows Server 2003, but is disabled by default (Windows XP Home and Windows 2000 Pro do not include the Remote Desktop service). It’s still a good idea to check, especially if you were not the one who installed the operating system, to make sure these services are not enabled on machines that don’t need them.

NOTE: It’s important to distinguish between the Remote Desktop Service and the Remote Desktop Connection client software. The latter is included on XP Home and Windows 2000 Pro and can be installed on Windows 9x and NT computers and some third party operating systems, as well. The client software does not present a security risk.

To disable or enable the Remote Desktop service on a Windows XP Pro or Windows Server 2003 computer, perform the following steps:

Click Start | Control Panel and select the System applet.
Click the Remote tab.
Under Remote Desktop, make sure the Allow users to connect remotely to this computer checkbox is unchecked.
What if you do want to make a system available for remote access through terminal services/Remote Desktop? What can you do to secure that system as much as possible? In the next sections, we will show you some ways.

Configuring the Terminal ServerThere are some major differences between Windows 2000 and Windows Server 2003 when it comes to terminal services. In this article, we will focus on Windows 2000 terminal services, with some references to Server 2003 and Windows XP/2003’s Remote Desktop service.

A Windows 2000 terminal server can be installed in one of two modes: administrative or application server. In administrative mode, only users with administrative accounts can access the terminal server and only two such connections are allowed simultaneously. Such users will be able to make configuration changes to the terminal server, so it’s absolutely imperative that you start your security plan by ensuring that administrative rights are not given to users who should not have them.

If you want regular users to access the terminal server to run applications (a “thin client” solution), then you must install terminal services in application server mode. You can then assign terminal services permissions to users and groups to control how they are able to access the terminal server.

Securing the RDP-TCP ConnectionYou can configure the properties of the terminal server’s RDP-TCP connection to provide better protection. For example:

Restrict the number of client sessions that can remain active on the server (making it easier to keep track of who is connected) Set session time limits (helping to ensure that sessions are not left unattended and active for long periods) Restrict reconnections of a disconnected session to the client computer from which the user originally connected, if the Citrix ICA client software is used Configure encryption levels Set permissions for users and groups on the terminal server

Using EncryptionYou can use encryption to protect the data that travels between the terminal server and the terminal services client. If you fear unauthorized interception of the data as it travels between the two, you should enable encryption. RSA RC4 encryption is used; encryption can be set to one of the following three levels:

High: encrypts both the data sent from client to server and the data sent from server to client using a 128 bit key. Medium: encrypts both the data sent from client to server and the data sent from server to client using a 56 bit key if the client is a Windows 2000 or above client, or a 40 bit key if the client is an earlier version. Low: encrypts only the data sent from client to server, using either a 56 or 40 bit key, depending on the client version. Useful to protect usernames and passwords sent from client to server. To change the encryption level, you must be an administrator. In Programs | Administrative Tools, select Terminal Services Configuration and perform these steps:

In the left console pane, select Connections.
In the right details pane, right click RDP-TCP and select Properties.
Click the General tab.
Under Encryption level, select the desired level in the drop down box and click OK.
Rights and PermissionsNow let’s look at rights and permissions in regard to using Windows 2000 terminal services. Users, groups and computers can be added to the permissions list via the Permissions tab of the RDP-TCP connection’s properties. Click Add and select the user, group or computer name.

There are three basic permissions that can be granted:

Full Control (given to administrators and the system; allows logging on the terminal server, modifying the connection parameters, connecting to a session, getting session info, resetting or ending a session, logging off other users, remotely controlling other users’ sessions, sending messages to other users, and disconnecting sessions. User Access (given to ordinary users; allows logging onto the terminal server, getting session info, connecting to a session or sending messages to other user sessions). Guest Access (for restricted users; allows logging onto the terminal server).

Per-User Terminal Services SettingsYou can configure a number of per-user terminal services settings for each user via Active Directory Users and Computers. You need to be a domain administrator; open the ADUC administrative tool and perform the following:

In the left pane, expand the domain name and click the Users folder.
In the right pane, right click the name of the user and select Properties.
Click the Terminal Services Profile tab.
Check or uncheck the Allow logon to terminal server checkbox at the bottom to control whether or not the user can access the terminal server.
You can create a profile and set a path to a terminal services home directory using this tab.

Using the Sessions tab, you can set terminal session timeout limits for a particular user, control what happens when the session limit is reached or the connection is broken, and determine whether the user can reconnect to a session via any client computer or only the original one.

The Remote Control tab is used to configure whether a user’s sessions can be viewed and controlled remotely by administrators and if so, whether the user’s permission will be required.

The Environment tab can be used to set a startup environment for the user. A particular program can be started when the user logs onto the terminal server, and you can specify whether client devices will be connected at logon.

SummaryAny remote connection opens up a system to some vulnerabilities, but Windows terminal services includes configuration options that give administrators the ability to better secure terminal sessions. In this article, we have discussed several methods by which you can make terminal services available to users without compromising your network’s or system’s security.

Check out MSTerminalServices.org, a new resource for Windows Terminal Services and Citrix focusing on all aspects of server based computing and thin client computing.

How to change the listening port for Remote Desktop

2006-02-14T06:38:00.000-08:00

How to change the listening port for Remote Desktop

Note The Remote Desktop Connection Client for the Mac supports only port 3389. 3389 is the default port.
MORE INFORMATION

You can use the Remote Desktop feature in Microsoft Windows XP Professional to connect to your computer from another remote computer.

Warning The Remote Assistance feature in Microsoft Windows XP may not work correctly if you change the listening port.

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
307711 (http://support.microsoft.com/kb/307711/) Remote Assistance invitation file does not contain correct port number
To change the port that Remote Desktop listens on, follow these steps.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.1. Start Registry Editor.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\ControlTerminalServer\WinStations\RDP-Tcp\PortNumber
3. On the Edit menu, click Modify, and then click Decimal.
4. Type the new port number, and then click OK.
5. Quit Registry Editor.
Note When you try to connect to this computer by using the Remote Desktop connection, you must type the new port.
304304 (http://support.microsoft.com/kb/304304/) How to configure the Remote Desktop client to connect to a specific port when you use Windows XP

The Windows Server 2003 R2 optional components

2006-02-01T07:40:00.000-08:00

Important Installation Information
Before you install Windows Server 2003 R2, consider the following:

• The Windows Server 2003 R2 optional components are not installed automatically. When you complete the installation of Disc 2, you are not installing the Windows Server 2003 R2 optional components. After Setup is complete, you can install the optional components by using Add/Remove Windows Components in Control Panel. You also have the option to add or upgrade server roles by using Manage Your Server.

Note:
Microsoft Management Console (MMC) 3.0 is installed automatically when you install Windows Server 2003 R2.

• You may need to upgrade a component. If Active Directory Application Mode (ADAM) or Windows SharePoint Services is already installed on your computer, you can upgrade to the new version that is included in Windows Server 2003 R2. For more information about upgrading one of these components, see the Help for the component on the Windows Server 2003 R2 TechCenter Web site (http://go.microsoft.com/fwlink/?LinkId=45560).

• You cannot uninstall Windows Server 2003 R2. The Windows Server 2003 R2 source files are permanent, but you will be able to uninstall any optional components that you install.

• You cannot uninstall Windows Server 2003 Service Pack 1 (SP1). If SP1 is installed on your computer by using the stand-alone service pack (for example, if you downloaded from the Web), you will not be able to uninstall SP1 after you upgrade the computer to Windows Server 2003 R2 (Disc 2). This is because having SP1 installed is a requirement for installing Windows Server 2003 R2.

• If you reinstall SP1 on top of your existing Windows Server 2003 R2 installation using Disc 1, you will need to reinstall Disc 2.

• Important information for 64-bit versions. You can only install 64-bit versions of Windows Server 2003 R2 (Disc 2) on computers running the 64-bit versions of SP1 (Disc 1). In other words, you cannot install the 32-bit version of Windows Server 2003 R2 on a computer running the 64-bit version of SP1.

rdesktop: A Remote Desktop Protocol Client

2006-01-19T05:00:00.000-08:00

rdesktop: A Remote Desktop Protocol Client
for accessing Windows NT Terminal Server

Documentation Overview
rdesktop is an open source client for Windows NT Terminal Server and Windows 2000/2003 Terminal Services, capable of natively speaking Remote Desktop Protocol (RDP) in order to present the user's NT desktop. Unlike Citrix ICA, no server extensions are required.
rdesktop currently runs on most UNIX based platforms with the X Window System, and other ports should be fairly straightforward.

rdesktop was initially written by Matthew Chapman based on various scarce documentation, wire sniffs, and trial-and-error. It is released under the GNU Public Licence (GPL). Please send feedback, bug reports and patches to the appropriate mailing list. Patches can also be submitted to the SF patch tracker.

Managing Terminal Services users

2006-01-16T06:51:00.000-08:00

Managing Terminal Services users

Managing Terminal Services Users
Each user who logs on to a Terminal Services session must have a user account either on the server or in a domain on the network that the server is on. The Terminal Services user account contains additional information about the user that determines when users log on, under what conditions, and how specific desktop settings are stored. Windows Server 2003 family operating systems contain a built-in User group called Remote Desktop Users, which is used to manage Terminal Services users.

Top of page
About the Remote Desktop Users group
When you install one of the Windows Server 2003 family operating systems, the Remote Desktop Users group is one of the built-in user groups on your computer. Members of this group have the same access as members of the Users group, but they have the additional ability to log on remotely to the computer.

By default, this group is not populated when you install Terminal Server on your computer. You must choose the users and groups that you want to have permission to log on remotely to the terminal server, and manually add them to the Remote Desktop Users group. This increases the security of remote connections, and also allows you to install any required programs before users start connecting to the terminal server.

The Select Remote Users button on the Remote tab of the System Properties dialog box allows you to add users to the Remote Desktop Users group. However, if a server running a Windows Server 2003 family operating system is being used as a domain controller in a Windows 2000 domain, this button is disabled. This domain controller can have domain groups, but not local groups, so in this situation you cannot use this button to add users to the Remote Desktop Users group.

Terminal server role: Configuring a terminal server

2006-01-12T07:17:00.000-08:00

Configuring a terminal server

The Cache Option for Offline Files Must Be Disabled on Roaming User Profile Shares

2006-01-11T06:48:00.000-08:00

SYMPTOMS
With roaming user profiles, if you do not disable the cache option for Offline Files, synchronization problems may occur. The user profile can be placed in an unstable state as both Offline Files and the roaming user profiles attempt to synchronize the files in a user's profile.
CAUSE
This behavior can occur because the cache option in Offline Files is based on the server message block (SMB) protocol, and is SMB share-based.

If the cache option is enabled on a share, any files that are created on the remote share from the local computer can be cached. This action, however, can result in synchronization problems if the cache option is enabled on a share where roaming user profiles are located, or are accessed by means of a path where the cache option is enabled.

If a roaming user profile is located below a share where the cache option is enabled, Offline Files caches files in the users profile, as they are copied to and from the server. The reason this occurs is to handle situations where programs work with new copies of a file, and then rename the original file. (Offline Files caches all files created on the remote share from the local computer.)

Because a roaming user profile can copy the files in the user's profile to temporary files on the server share, and then rename them, Offline Files adds the files in the user's profile to the cache.
RESOLUTION
To work around this behavior, create a separate share to store the users' profiles, and then disable the cache option on that share. (The cache option can only be disabled on shares that are hosted by computers that run Windows 2000.)

Microsoft recommends that you store the roaming user profiles and offline-enabled shares on a separate server, whenever possible.
To disable the cache option by means of the command line:
1. Click Start.
2. Click Run.
3. Type: cmd and click OK.
4. At the command prompt, type: net share sharename /cache:no, where sharename is the name of the shared folder.

To disable the cache option by means of the user interface:
1. Locate the shared folder by using Windows Explorer.
2. Right-click the folder, and then click Properties.
3. Click the Sharing tab.
4. Click the Caching button.
5. Click to clear the Allow caching of files in this folder check box.

STATUS
This behavior is by design.
MORE INFORMATION
The cache option for Offline Files must be disabled on shares where roaming user profiles are stored. If you want to store offline-enabled redirected folders and roaming user profiles on the same server, they must be on separate shares.

For additional information regarding IntelliMirror and user data management, visit the following Microsoft Web sites:

User Profile Hive Cleanup Service

2006-01-11T05:06:00.000-08:00

Overview
The User Profile Hive Cleanup service helps to ensure user sessions are completely terminated when a user logs off. System processes and applications occasionally maintain connections to registry keys in the user profile after a user logs off. In those cases the user session is prevented from completely ending. This can result in problems when using Roaming User Profiles in a server environment or when using locked profiles as implemented through the Shared Computer Toolkit for Windows XP.

On Windows 2000 you can benefit from this service if the application event log shows event id 1000 where the message text indicates that the profile is not unloading and that the error is "Access is denied". On Windows XP and Windows Server 2003 either event ids 1517 and 1524 indicate the same profile unload problem.

To accomplish this the service monitors for logged off users that still have registry hives loaded. When that happens the service determines which application have handles opened to the hives and releases them. It logs the application name and what registry keys were left open. After this the system finishes unloading the profile.
Top of page

System Requirements
Supported Operating Systems: Windows 2000; Windows NT; Windows Server 2003; Windows XP
Windows Installer: To use the MSI installation package you must have Windows Installer version 2.0 installed. Otherwise you can follow the manual installation instructions from the readme provided below. Windows Installer 2.0 is included with Windows 2000 SP3 and later, Windows XP and Windows Server 2003. You can install Windows Installer 2.0 using this link Windows Installer 2.0 Redistributable for Windows NT & 2000.

NOTE: The service has not been localized but is expected to run properly on localized version of Windows. The event log messages will be shown in English.

download

You cannot use Group Policy settings to configure Terminal Services roaming user profiles on a Windows 2000-based

2006-01-10T05:43:00.000-08:00

SYMPTOMS
On a Microsoft Windows 2000-based Terminal server, you cannot use Group Policy settings to configure Terminal Services roaming user profiles and home directories.

Back to the top
RESOLUTION

Hotfix informationA supported hotfix is now available from Microsoft, but it is only intended to correct the problem that this article describes. Apply it only to systems that are experiencing this specific problem.To resolve this problem, contact Microsoft Product Support Services to obtain the hotfix. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, visit the following Microsoft Web site:
http://support.microsoft.com/contactus/?ws=support (http://support.microsoft.com/contactus/?ws=support)Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
PrerequisitesTo install this hotfix, you must have Windows 2000 Service Pack 3 (SP 3) installed on your computer.
Restart requirementYou must restart your computer after you apply this hotfix.
Hotfix replacement informationThis hotfix does not replace any other hotfixes.
File informationThe English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel. Date Time Version Size File name

Configuring Roaming User Profiles

2006-01-09T08:12:00.000-08:00

Before you create a roaming user profile, you need to create each user account. Then, log on to a server as an administrator to create a network share to store the roaming user profiles, designate the groups of users to receive the roaming user profiles, and grant all users Full Control permissions.
Use the following procedures when you create and manage roaming user profiles.
Creating Roaming User Profiles
To perform the following procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. For enhanced security, consider using the Runas command to perform this procedure.
Top of page
To create a roaming user profile
1.
Open Active Directory Users and Computers.
2.
Click the domain and the OU where the user account resides.
3.
Right-click the user account for which to set a roaming profile, and then click Properties.
4.
Click the Profile tab, and then type the profile path information in Profile path. (Use the full path in each user account. For example, type \\Server\ShareName\UserName.)
Another way to populate the profile path is to use an Active Directory® Service Interfaces (ADSI) script. ADSI provides a single set of interfaces for managing resources on the network. You can use ADSI in combination with Microsoft® Visual Basic® Scripting Edition (VBScript) or JScript scripts to manage Active Directory resources such as users and services.
For information about ADSI and ADSI scripts, see the Microsoft Platform SDK link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Changing User Profile Type from Local to Roaming
Typically, a large organization has many users with local profiles. For ease of management, you might want to change many of the local profiles to roaming profiles. Moving user’s data and settings from the workstation to a server reduces the user’s dependence on the workstation’s availability, simplifies user data management, and allows centralized account management.
Top of page
To create a roaming user profile for a user that has a local profile
1.
Open Active Directory Users and Computers.
2.
Click the domain and the OU where the user account resides.
3.
Right-click the appropriate user account for which to set a roaming profile, and then click Properties.
4.
Click the Profile tab, and type the profile path information in Profile path (for example, type \\Server\ShareName\UserName).
Note
•
To change a user’s local profile to a roaming profile for a user who uses multiple computers simultaneously, the user must log off last from the computer that has the profile that the user wants to use.
Disabling Roaming User Profiles on Certain Computers
You can prevent computers from receiving roaming profiles by enabling the Only allow local user profiles policy setting, which blocks roaming profiles from being used on a computer. By default, when roaming profile users log on to a computer, the user’s roaming profile is copied to the local computer. If the user has previously logged on to this computer, the roaming profile is merged with the local profile. Similarly, when the user logs off from this computer, the local copy of the profile, including any changes the user made, is merged with the server copy of the profile.
If you enable the Only allow local user profiles policy setting, the following occurs on the affected computer: When the user first logs on, the user receives a new local profile instead of the roaming profile. At logoff, changes are saved to the local profile. All subsequent logons use the local profile.
If you enable both the Prevent Roaming Profile changes from propagating to the server setting and the Only allow local user profiles setting, roaming profiles are disabled for that computer. These policy settings are in the Computer Configuration\Administrative Templates\System\User Profiles node.
Creating Accounts That Possess roaming user profiles
You can save time and reduce the chances for error by scripting many repetitive tasks, such as creating user accounts. A script to automate the creation of user profiles for roaming user might look something like the sample script Listing 7.1, which shows a script for creating user accounts that have roaming profiles.
Listing 7.1 Creating User Accounts That Have Roaming User Profiles

set Args = Wscript.ArgumentsouName = Args(0)
usrName = Args(1)
RUProot = Args(2)
RUPpath = RUProot & " \" & usrName
'Get the domain
Set dse = GetObject(" LDAP://RootDSE" )
Set domain = GetObject( " LDAP://" & dse.Get(" defaultNamingContext" ))
set ou = domain.GetObject(" organizationalUnit" , " OU=" & ouName )
wscript.echo " Creating user in " & ou.Name
set usr = ou.Create(" user" , " cn=" & usrName )
usr.Put " samAccountName" , usrName
usr.Put " userPrincipalName" , usrName
usr.Put " Profilepath" , RUPpath
usr.SetInfo
wscript.echo " User " & usrName & " was created successfully in " & ou.Name & " with a RUP Path of: " & RUPpath
Every Windows Server 2003 user has a profile. If the operating system does not have a profile to apply to the user when the user logs on, a new local profile is created for the user, based on the defaults in place. Windows Server 2003 applies a generic user profile format by default.
Configuring a Default Profile
You can create a default profile to ensure that all users within a domain receive an identical profile the first time they log on. This option simplifies administrative control over the users’ desktops and settings.
To create a default user profile, you must be logged on as Administrator or a member of the Administrators group. Create a default profile for all new user accounts in a domain. Include any domain-specific customizations that you want in the profile. To create subsequent profiles, you can create a new user account as a template.
Before creating a new user account to use as a new user’s profile template, perform the following tasks:
1.
Log on to the domain as the new user, and then customize the desktop if appropriate.
2.
Optionally, install and configure any applications to be shared by user accounts made from this template.
3.
Log off, and then log on as the administrator.
For more information about creating a new user account, see "Create a new user account" in Help and Support Center for Windows Server 2003.
Top of page
To configure a new user account to use as a new user’s profile template
1.
After you create a new user account template, in Control Panel, click System.
2.
On the Advanced tab, under User Profiles, click Settings.
3.
Under Profiles stored on this computer, select the user that you created in step 1, and then click Copy To.
4.
To create the default user profile for the domain, type the path to NETLOGON\Default User on the domain controller.
5.
In the Copy To dialog box, under Permitted to use, click Change.
6.
In the Select User or Group dialog box, enter the object name to select, and then type: Everyone.
Troubleshooting: Creating a Log File for User Profiles
User profiles log events in the Application event log. To aid in troubleshooting, administrators can also create detailed log files by using the following procedure.
Caution
•
Do not edit the registry unless you have no alternative. The registry editor, regedit.exe, bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you edit the registry, make sure to back it up first and see the Windows Server 2003 Resource Kit Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.
Top of page
To create a detailed log file for user profiles
1.
In the Run dialog box, type regedit, and then click OK.
2.
Locate the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNTCurrentVersion\Winlogon.
3.
Create a new entry named UserEnvDebugLevel of data type REG_DWORD, and set its value to 0x30002.
The log file is stored in this location: %windir%\Debug\Usermode\Userenv.log.

Change a user's Terminal Services profile path

2006-01-08T04:48:00.000-08:00

Related Links
• Terminal Services users
• Terminal Server Best practices
• Terminal Services Profile

To change a user's Terminal Services profile path
• Using Group Policies (best practice)

• Using Terminal Services Extension to Local Users and Groups

Using Group Policies (best practice)
1.
Choose from the following:

• For a domain user account, from a Domain Controller, open Active Directory Users and Computers.

In the console tree, right click the domain node, and then click Properties. In the Group Policy tab, double-click the Group Policy object, or click Edit.

Important

• To perform this procedure, you must be a member of the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.

• For a local user account, open Group Policy.

2.
In the Group Policy console tree, click Terminal Services under Computer Configuration.

Where?

• Local Computer Policy/Computer Configuration/Administrative Templates/Windows Components/Terminal Services

Important

• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.

3.
Double-click the Set path for TS Roaming Profiles setting, and then click Enabled.

4.
In the Profile path box, type the path for Terminal Services roaming profiles, and then click OK.

Important

• You should thoroughly test any changes you make to Group Policy settings before applying them to users or computers. For more information on testing policy settings, see Resultant Set of Policy.

Using Terminal Services Extension to Local Users and Groups
1.
Choose from the following:

• For a domain user account, open Active Directory Users and Computers.

In the console tree, expand the domain node, and then click the folder in which users are located.

Important

• To perform this procedure, you must be a member of the Domain Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.

• For a local user account, open Computer Management (Local).

In the console tree, click Users.

Where?

• Computer Management/System Tools/Local Users and Groups/Users

Important

• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.

2.
Double-click the user whose profile path you want to change.

3.
On the Terminal Services Profile tab, under Profile Path:, type the new path to the user's profile, and then click OK.

Notes

• To open Active Directory Users and Computers, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers. This procedure works only if the server has been promoted to a domain controller.

• To open Computer Management, click Start, click Control Panel, double-click Administrative Tools, and then double-click Computer Management.

Troubleshooting Remote Desktop Licensing Error Messages

2006-01-07T02:53:00.000-08:00

Troubleshooting Licensing Error Messages
This topic lists licensing error messages that can appear on client computers, and it describes the causes of and solutions for these errors. Although these error messages appear on clients, they are frequently caused by problems with the Windows Server 2003 Terminal Server license server or the terminal server. Therefore, when you troubleshoot Terminal Server Licensing issues, it is useful to first determine whether there are server configuration issues or problems with network connectivity.

Important

The solutions in this topic are intended to be implemented by administrators. If you are not an administrator, contact your server administrator for assistance in resolving these error messages. If you are an administrator, to help prevent Terminal Server Licensing issues and to more efficiently diagnose issues, it is highly recommended that you see Guidelines for Deploying Terminal Server (http://go.microsoft.com/fwlink/?LinkID=34627), and Windows Server 2003 Terminal Server Licensing Issues and Requirements for Deployment (http://go.microsoft.com/fwlink/?LinkID=23444).

Which message are you getting?

• The remote session was disconnected because the local computer's client access license could not be upgraded or renewed. Please contact the server administrator.

• The remote computer disconnected the session because of an error in the licensing protocol. Please try connecting to the remote computer again or contact your server administrator.

• The remote session was disconnected because there were network problems during the licensing protocol. Please try connecting to the remote computer again.

• A licensing error occurred while the client was attempting to connect. (Licensing timed out.) Please try connecting to the remote computer again.

• The remote session was disconnected because there are no Terminal Server client access licenses available for this computer. Please contact the server administrator.

• The remote session was disconnected because there are no Terminal Server License Servers available to provide a license. Please contact the server administrator.

• Because of a security error, the client could not connect to the terminal server. After making sure that you are logged on to the network, try connecting to the server again.

The remote session was disconnected because the local computer's client access license could not be upgraded or renewed. Please contact the server administrator.
Cause: The Terminal Server licensing mode on the terminal server might be set to Per Device, while the license server might be configured to issue only Per User client access licenses (CALs). If this is the case, then the license server issues only temporary licenses that cannot be upgraded. When the temporary licenses are within several days of expiring, "Event ID 26, Source: Application Pop-up" appears in the application event log on the client. The event message indicates the number of days remaining before the temporary license expires. Similarly, "Event ID 1011, Source TermService" appears in the application event log on the terminal server.

Solution: Change the Terminal Server licensing mode from Per Device to Per User.

Important

Per User CALs are not monitored by Terminal Server. This means that even though there is a Per User CAL in the license server database, the Per User CAL is not decremented when it is used. This does not remove administrators from End User License Agreement (EULA) requirements to have a valid terminal server CAL for each user. Failure to have a Per User CAL for each user, if Per Device CALs are not being used, is a violation of the EULA.

The following text is from the EULA for Windows Server 2003:

"Two different TS CALs are available to you: 'Device' and 'User.' Each TS Device CAL permits one Device (used by any User) to conduct Windows Sessions on any of your Servers. Each TS User CAL permits one User (using any Device) to conduct Windows Sessions on any of your Servers. You may use a mix of TS Device CALs and TS User CALs simultaneously with the Server Software in your environment. You can have a Terminal Server request Per User licenses or Per Device (default) but not both simultaneously."

See also: Configure the Terminal Server Licensing mode

The remote computer disconnected the session because of an error in the licensing protocol. Please try connecting to the remote computer again or contact your server administrator.
Cause: The terminal server might not be able to locate the license server.

Solution: Perform the following steps:

1.
Verify that the license server is correctly installed.

2.
Verify that the Terminal Server Licensing service is running on the license server.

3.
Verify that the client, the terminal server, and the license server can communicate by ensuring that Domain Name System (DNS) is configured correctly on each computer. To do this, run the ping command from each computer to each computer using the IP address, FQDN, and the NetBIOS name. If any of the ping commands fail, verify the DNS configuration on the network.

4.
On the terminal server, set a preferred licensing server to connect to. You can do this by using the registry, a Windows Management Instrumentation (WMI) script, or, in Windows Server 2003 with Service Pack 1, you can use Group Policy settings or Terminal Server Configuration.

See also: Install Terminal Server Licensing; Set preferred Terminal Server license servers; Terminal Server license server roles

Solution: If the previous solution does not resolve this problem, create a backup of the MSLicensing registry key and its subkeys on the client, and then remove the original key and subkeys by doing the following:

1.
On the client, navigate to the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

2.
Click MSLicensing.

3.
On the Registry menu, click Export Registry File.

4.
In the File name box, type mslicensingbackup, and then click Save.

5.
If you need to restore this registry key in the future, double-click mslicensingbackup.reg.

6.
On the Edit menu, click Delete, and then click Yes to confirm the deletion of the MSLicensing registry subkey.

7.
Close Registry Editor, and then restart the computer.

When the client is restarted, the missing registry key is rebuilt.

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

See also: Removing Terminal Server Licenses From an RDP Client (http://go.microsoft.com/fwlink/?LinkId=38560)

The remote session was disconnected because there were network problems during the licensing protocol. Please try connecting to the remote computer again.
Cause: The terminal server might not be able to locate the license server.

Solution: Perform the following steps:

1.
Verify that the license server is correctly installed.

2.
Verify that the Terminal Server Licensing service is running on the license server.

3.
Verify that the client, the terminal server, and the license server can communicate by ensuring that Domain Name System (DNS) is configured correctly on each computer. To do this, run the ping command from each computer to each computer using the IP address, FQDN, and the NetBIOS name. If any of the ping commands fail, verify the DNS configuration on the network.

4.
On the terminal server, set a preferred licensing server to connect to. You can do this by using the registry, a Windows Management Instrumentation (WMI) script, or, in Windows Server 2003 with Service Pack 1, you can use Group Policy settings or Terminal Server Configuration.

See also: Install Terminal Server Licensing; Set preferred Terminal Server license servers; Terminal Server license server roles

Cause: The license server might be running Windows 2000, and it might be configured to prohibit anonymous connections, except by resources that have been explicitly granted access to the server.

Solution: On the Windows 2000 license server, do one of the following:

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

• In the registry, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous, and set the RestrictAnonymous registry key to a value of 1 or 0.

• In Local Security Policies, open the appropriate policy and, in the console tree, navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Then, enable either Do not allow enumeration of SAM accounts and shares (equivalent to a RestrictAnonymous value of 1 or None) or Rely on default permissions (equivalent to a RestrictAnonymous value of 0).

Notes

• If the license server is a member of an Active Directory domain and a conflicting security setting is configured for the license server in Group Policy, the Group Policy setting overrides the local security setting. In this case, to ensure that the security setting that you want to apply takes effect, configure the setting in Group Policy.

• In Windows Server 2003, you cannot set RestrictAnonymous to a value of 2 to prohibit anonymous connections. If you need to prohibit anonymous users from being granted the same access that is granted to members of the Everyone group, you must use the new Everyone Network access: Let Everyone permissions apply to anonymous users setting in Local Security Policies.

Solution: If the previous solution does not resolve this problem, create a backup of the MSLicensing registry key and its subkeys on the client, and then remove the original key and subkeys by doing the following:

1.
On the client, navigate to the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

2.
Click MSLicensing.

3.
On the Registry menu, click Export Registry File.

4.
In the File name box, type mslicensingbackup, and then click Save.

5.
If you need to restore this registry key in the future, double-click mslicensingbackup.reg.

6.
On the Edit menu, click Delete, and then click Yes to confirm the deletion of the MSLicensing registry subkey.

7.
Close Registry Editor, and then restart the computer.

When the client is restarted, the missing registry key is rebuilt.

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

See Also: How To Use the RestrictAnonymous Registry Value in Windows 2000 (http://go.microsoft.com/fwlink/?LinkId=38561)

A licensing error occurred while the client was attempting to connect. (Licensing timed out.) Please try connecting to the remote computer again.
Cause: If you are using Internet Protocol security (IPsec) to help protect traffic over TCP between clients and terminal servers, then packet fragmentation might occur. As a result, some packets might not reach their destination, and client connections to terminal servers might fail.

Solution: Configure IPsec to help protect traffic over UDP rather than over TCP.

See Also: Define IPSec Policies

The remote session was disconnected because there are no Terminal Server client access licenses available for this computer. Please contact the server administrator.
Cause: The license server might not have any remaining Per Device CALs to issue.

Solution: Use Terminal Server Licensing to determine the number of CALs remaining on the license server. To open Terminal Server Licensing, click Start, Programs, Administrative Tools, and then point to Terminal Server Licensing. If the license server does not have any remaining CALs to issue to clients, purchase and install additional CALs as required.

See also: Purchase client access licenses; Install Client Access Licenses; Purchasing and installing client access licenses on a Terminal Server license server

Cause: The Terminal Server licensing mode on the terminal server might be set to Per Device, while the license server might have only Per User CALs. If this is the case, the license server issues only temporary licenses that cannot be upgraded. When the temporary licenses are within several days of expiring, "Event ID 26, Source: Application Pop-up" appears in the application event log on the client. The event message indicates the number of days remaining before the temporary license expires. Similarly, "Event ID 1011, Source TermService" appears in the application event log on the terminal server.

Solution: Change the Terminal Server Licensing mode from Per Device to Per User.

Important

Per User CALs are not monitored by Terminal Server. This means that even though there is a Per User CAL in the license server database, the Per User CAL is not decremented when it is used. This does not remove administrators from End User License Agreement (EULA) requirements to have a valid terminal server CAL for each user. Failure to have a Per User CAL for each user, if Per Device CALs are not being used, is a violation of the EULA.

The following text is from the EULA for Windows Server 2003:

"Two different TS CALs are available to you: 'Device' and 'User.' Each TS Device CAL permits one Device (used by any User) to conduct Windows Sessions on any of your Servers. Each TS User CAL permits one User (using any Device) to conduct Windows Sessions on any of your Servers. You may use a mix of TS Device CALs and TS User CALs simultaneously with the Server Software in your environment. You can have a Terminal Server request Per User licenses or Per Device (default) but not both simultaneously."

See also: Configure the Terminal Server Licensing mode

Cause: The terminal server might not be able to locate the license server.

Solution: Perform the following steps:

1.
Verify that the license server is correctly installed.

2.
Verify that the Terminal Server Licensing service is running on the license server.

3.
Verify that the client, the terminal server, and the license server can communicate by ensuring that Domain Name System (DNS) is configured correctly on each computer. To do this, run the ping command from each computer to each computer using the IP address, FQDN, and the NetBIOS name. If any of the ping commands fail, verify the DNS configuration on the network.

4.
On the terminal server, set a preferred licensing server to connect to. You can do this by using the registry, a Windows Management Instrumentation (WMI) script, or, in Windows Server 2003 with Service Pack 1, you can use Group Policy settings or Terminal Server Configuration.

See also: Install Terminal Server Licensing; Set preferred Terminal Server license servers; Terminal Server license server roles

Solution: If the previous solution does not resolve this problem, create a backup of the MSLicensing registry key and its subkeys on the client, and then remove the original key and subkeys by doing the following:

1.
On the client, navigate to the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

2.
Click MSLicensing.

3.
On the Registry menu, click Export Registry File.

4.
In the File name box, type mslicensingbackup, and then click Save.

If you need to restore this registry key in the future, double-click mslicensingbackup.reg.

5.
On the Edit menu, click Delete, and then click Yes to confirm the deletion of the MSLicensing registry subkey.

6.
Close Registry Editor, and then restart the computer.

When the client is restarted, the missing registry key is rebuilt.

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

See Also: How To Use the RestrictAnonymous Registry Value in Windows 2000 (http://go.microsoft.com/fwlink/?LinkId=38561)

The remote session was disconnected because there are no Terminal Server license servers available to provide a license. Please contact the server administrator.
Cause: The terminal server might not be able to locate the license server.

Solution: Perform the following steps:

1.
Verify that the license server is correctly installed.

2.
Verify that the Terminal Server Licensing service is running on the license server.

3.
Verify that the client, the terminal server, and the license server can communicate by ensuring that Domain Name System (DNS) is configured correctly on each computer. To do this, run the ping command from each computer to each computer using the IP address, FQDN, and the NetBIOS name. If any of the ping commands fail, verify the DNS configuration on the network.

4.
On the terminal server, set a preferred licensing server to connect to. You can do this by using the registry, a Windows Management Instrumentation (WMI) script, or, in Windows Server 2003 with Service Pack 1, you can use Group Policy settings or Terminal Server Configuration.

See also: Install Terminal Server Licensing; Set preferred Terminal Server license servers; Terminal Server license server roles

Cause: The client might have exceeded its Terminal Server Licensing grace period, and a license server has not yet been installed or activated to issue the client a CAL.

Solution: Install Terminal Server Licensing, activate the license server, and then install and purchase a sufficient number of CALs to support the clients in your organization.

See also: Terminal Server Licensing grace period; Install Terminal Server Licensing; Activate a Terminal Server License Server; Purchase client access licenses; Install Client Access Licenses; Purchasing and installing client access licenses on a Terminal Server license server; Activating a Terminal Server license server

Because of a security error, the client could not connect to the terminal server. After making sure that you are logged on to the network, try connecting to the server again.
Cause: If you upgraded a Windows NT domain to Windows 2000 or Windows Server 2003, then the certificate on the terminal server might be corrupt. As a result, Windows 2000 Terminal Services clients might be repeatedly denied access to the terminal server.

Solution: On each terminal server and client, perform the following steps:

1.
On each terminal server, create a backup of the registry.

2.
Navigate to the following registry subkey: HKLM\SYSTEM\CurrentControlSet\Services\TermServices\Parameters.

3.
On the Registry menu, click Export Registry File.

4.
In the File name box, type exported-parameters, and then click Save.

If you need to restore this registry subkey in the future, double-click exported-parameters.reg.

5.
Under the Parameters registry subkey, right-click each of the following values:

• Certificate

• X509 Certificate

• X509 Certificate ID

6.
Click Delete, and then click Yes to confirm the deletion.

7.
Close Registry Editor, and then restart each terminal server.

8.
On the client, create a backup of the MSLicensing registry key and its subkeys, and then remove the original key and subkeys by doing the following:

• Navigate to the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

• Click MSLicensing.

• On the Registry menu, click Export Registry File.

• In the File name box, type mslicensingbackup, and then click Save.

• If you need to restore this registry key in the future, double-click mslicensingbackup.reg.

• On the Edit menu, click Delete, and then click Yes to confirm the deletion of the MSLicensing registry subkey.

• Close Registry Editor, and then restart the client computer.

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Solution: If the client still cannot connect to the terminal server, perform the following variation of this procedure:

1.
Deactivate the license server.

2.
Reactivate the license server by using the Telephone connection method in the Terminal Server License Server Wizard.

When you activate Terminal Server Licensing by using the Telephone option, Terminal Server Licensing uses a different certificate.

3.
On each terminal server, create a backup of the registry, and then delete the Certificate, X509 Certificate, and X509 Certificate ID registry keys, as described in the preceding procedure.

4.
Close Registry Editor, and then restart each terminal server.

5.
On the client, create a backup of the MSLicensing registry key and its subkeys on the client, and then remove the original key and subkeys as described in the preceding procedure.

6.
Close Registry Editor, and then restart the computer.

When the client is restarted, the missing registry key is rebuilt.

See also: Deactivate a Terminal Server license server; Reactivate a Terminal Server license server

Cause: Windows XP-based clients might be attempting to connect to a Windows 2000-based Terminal Services server in a low-bandwidth network environment, in which client sessions are encrypted. In this case, IP packet fragmentation can cause encrypted frames that are sent by a client to be decrypted incorrectly.

Solution: Obtain the latest service pack for Windows 2000.

Cause: The Remote Desktop Protocol (RDP) encryption settings on the terminal server computer and the client might not be compatible. For example, the terminal server might be running 128-bit encryption with an encryption level set to High. When this occurs, "Event ID 50, Source: TermDD" appears in the system event log on the terminal server.

Solution: Change the RDP encryption level on the terminal server to Medium or Low.

Microsoft Virtual Server

2006-01-05T05:15:00.000-08:00

Licensing Microsoft Server Products with Virtual Machine Technologies
This licensing brief provides an overview of updates to Microsoft’s licensing models for the server operating system and server applications. It also clarifies existing licensing policies to help you deploy and use software under these updated models. These updates do not apply to the desktop operating system or desktop applications. The purpose of these updates and clarifications is to help you understand how to use Microsoft server products with virtual machine technologies such as Microsoft® Virtual Server 2005 R2. These updates and clarifications are less significant if you do not use virtual machine technology.

Many of the updates described in this licensing brief apply to licenses purchased from channels other than Microsoft Volume Licensing. However, there are some differences. Please review the license terms that accompany the software if you have acquired licenses through a means other than a Microsoft Volume Licensing agreement.

Definitions of certain terms are included at the end of this licensing brief. Please review those terms. They are helpful in understanding virtual machine technology and your use rights for Microsoft server products.

Virtual Machine Technology on x86 and x64 Hardware Platforms
Virtual machine (VM) technology allows you to run multiple operating system environments (OS environments) on a single physical hardware system (e.g., a server) (Figure 1). Before VM technology, you could run only one OS environment on a server at a time—the physical OS environment that runs directly on the server (Figure 2 – A). Current technologies such as Microsoft Virtual Server 2005 R2 add a layer on top of the OS in the physical OS environment to enable you to run multiple OS environments on the same server (Figure 2 – B). VM technology works by allocating virtualized hardware resources to virtual hardware systems or virtual machines. Virtual OS environments run on virtual machines. Upcoming technologies from Microsoft and other vendors provide virtualization services directly in the OS and rely on a hypervisor to allocate resources to individual OS environments on a server (Figure 2 – C). Processors from Intel and Advanced Micro Devices (AMD) will include technology starting in 2006 to improve the performance of VM technologies on x86 and x64 hardware platforms.

Figure 1 – Physical and virtual hardware and OS environments

Figure 2 – Physical and virtual OS environments

Benefits and Capabilities of VM Technology
Microsoft is committed to developing and investing in VM technology to deliver a number of benefits and capabilities. These include :

Production server consolidation: Reduce TCO by maximizing hardware utilization and consolidating workloads
• Legacy application re-hosting. VM technology allows legacy applications that need an older OS to run on a VM with that older OS. The VM can run on a server with newer hardware and a newer OS. The technology enables greater application availability, without application upgrades or violating ISV support policies.
• Server consolidation. VM technology can be used to consolidate a variety of workloads, each running on its own instance of the OS, from many servers onto fewer servers. The technology allows instances of the same or different OS, or of the same OS with different patch levels, to run on a server.
• Resource partitioning. VM technology can be used to provide OS environments with specific resource limits. The technology can limit a given OS environment to using only a subset of the server’s overall processing, memory and other resources.

Business continuity management: Eliminate scheduled and unscheduled downtime
• Workload deployment and provisioning. VM technology can package an instance of the OS, and the applications that are configured to run on it, into a virtual hard disk (VHD) file. The VHD file can be rapidly deployed onto a licensed server to run the workload it contains. Complex workloads that span multiple servers on a network can be quickly provisioned by deploying the associated VHD files together. A workload can also be easily duplicated by copying its associated VHD file. A particularly interesting use of this capability is to create a central library of workloads in preconfigured VHD files on centralized storage and deploy them on servers as necessary.
• OS and application patching and rollback. With VM and management technology, VHD files with preconfigured OS and application instances can be patched offline. These updated VHD files can be quickly swapped for production instances, dramatically shortening the time to deploy a patch to a critical system to just minutes—allowing time for offline testing, production testing and rapid rollback.
• Batch jobs. VM technology can be used with scripts and schedulers to automatically start and stop workloads on a server according to a pre-defined schedule.
• Isolation/sandboxing. VM technology can be used to provide secure, isolated OS environments for running untrusted applications. With the proper safeguards and security mechanisms, these OS environments can be sandboxed to protect other application and server instances from crashing. In addition, the technology can help prevent malicious code from affecting other OS environments on the same server or other servers in the network.
• Increased performance and reliability on multi-core processor and multi-processor servers. VM technology can continuously shift the execution of an OS environment to the optimal core or processor in the server. When a particular OS environment is configured to use only a subset of the server’s overall processing resources, VM technology can provide these resources from cores on separate physical processors, if necessary.

Dynamic data center: Leverage the benefits of virtualization to create a more agile infrastructure
• Workload mobility. VM technology can be used to encapsulate the complete running state of an OS environment. With this capability, running workloads can be moved from one licensed server to another by pausing the OS environment momentarily, moving the associated VHD file, and continuing execution of the workload.

Development and testing: Maximize test hardware to reduce costs, improve lifecycle management and improve test coverage
• Development and testing. VM technology can be a great tool in software development, test and staging environments. The technology allows for detailed step-by-step debugging and performance monitoring of individual workloads. It can also be used to create arbitrary test scenarios to ensure proper operation in niche scenarios and hardware configurations. In addition, it can be used to simulate the operation of a workload running across a network of multiple servers—on a single physical hardware system.

Updates to Licensing Models for Microsoft Server Products
Microsoft is updating the licensing models for server products to enable you to take advantage of the benefits and capabilities of VM technology. We are also clarifying existing licensing policies to help you understand how to use our software under these updated models. If you do not use VM technology, these updates and clarifications do not significantly impact your use of Microsoft server products.

Overview
The following summary provides an overview of the updated licensing models and clarifications to existing licensing policies. For further detail and examples, please see the white paper at http://www.microsoft.com/licensing/userights. Your review of this licensing brief and white paper should not substitute for careful review and understanding of your rights and obligations as described in your Microsoft volume licensing agreement. The updates to the licensing models apply to new licenses for all server products covered by the December 1, 2005 Product Use Rights (PUR). For these products, you may also choose to apply the updates to licenses acquired prior to December 1st. However, if you apply any of these updates to any of your existing licenses, you must apply all the updates to all of your existing licenses. For example, these updates do not apply to a Microsoft SQL Server™ 2000 license because that product is not covered by the December 1st PUR. They may apply to an Exchange Server 2003 license acquired prior to December 1st because that product is covered by the December 1st PUR.

Products Impacted Updates and Clarifications
All products in the Microsoft Servers licensing model in the December 1st PUR
• Microsoft Windows Server™ 2003
• Exchange Server 2003
• Virtual Server 2005 R2
• Etc. Updates
• Use terms for each software license specify the number of instances of software that you may run on a particular server at a time, rather than the number of copies of the software that you may install and use on your server.
• Each software license allows you to create and store any number of instances of the software on any of your servers or storage media to make it easier for you to run those instances on any of your licensed servers.

Clarifications
• Before you use the software under a license for a server product, you must assign that license to a server
• Each hardware partition or blade is a separate physical hardware system, and therefore a separate server.
• You may reassign software licenses for server products, but not on a short-term basis (i.e., not within 90 days of the last assignment). They may be reassigned sooner if you retire the licensed server due to permanent hardware failure.
• You may not separate software to run it in more than one OS environment under a single license, unless expressly permitted—even if the OS environments are on the same server.
Products in the Microsoft Server OS and Microsoft Server/CAL licensing models in the December 1st PUR
• Windows Server 2003
• Exchange Server 2003
• SQL Server 2005
• Etc. Updates
• Each external connector license (EC) allows any number of external users to access any number of instances of the server software on a particular server, even if those instances are run under multiple licenses for the software.

Clarifications
• Each client access license (CAL) allows any number of OS environments on a particular device (e.g., client device) to access the server software. You do not need a separate device CAL for each OS environment on a device.
Products in the Management Servers licensing model in the December 1st PUR
• Microsoft Operations Manager 2005
• Systems Management Server 2003
• Systems Center Data Protection Manager 2006
• Etc. Clarifications
• Each management license (e.g., OML, CML) allows any number of OS environments on a particular device to be managed by the server software. You do not need a separate management license to manage each OS environment on a managed device.
Products in the Per Processor licensing model in the December 1st PUR
• Microsoft BizTalk® Server 2004
• SQL Server 2005
• ISA Server 2004
• Etc. Updates
• Software run in a virtual OS environment is licensed based on the number of virtual processors used by that virtual OS environment, rather than all the physical processors in the server.
o If you run the software in virtual OS environments, you need a license for each virtual processor used by those virtual OS environments on a particular server—whether the total number of virtual processors is lesser or greater than the number of physical number of processors in that server.
o If you run the software in a physical OS environment, you need a license for each physical processor used by the physical OS environment.

Microsoft is also introducing expanded use rights for licenses for Windows Server 2003 R2 Enterprise Edition and SQL Server 2005. These expanded use rights are summarized in the following table. They apply only to licenses for the specific editions described. They do not apply to licenses for previous versions of these products.

Products Impacted Expanded Use Rights
Windows Server 2003 R2 Enterprise Edition • Each software license allows you to run, at any one time, one instance of the server software in a physical OS environment and up to four instances of the server software in virtual OS environments on a particular server.
SQL Server 2005 (licensed Server/CAL) Workgroup Edition, Standard Edition and Enterprise Edition • Each software license allows you to run any number of instances of the server software in one physical or virtual OS environment on a particular server at a time.

Definitions

Server: A server is a physical hardware system capable of running server software. A hardware partition or blade is considered to be a separate physical hardware system, and therefore a separate server.

Figure D1 – Different types of servers

Instance: You create an instance of software by executing the software’s setup or install procedure. You can also create an instance of software by duplicating an existing instance. An instance of software is the set of files that make up the software, stored in executable form and ready to be run.

Examples:
• An installed copy of Windows Server 2003 on a hard disk is an instance of Windows Server 2003.
• An installed copy of Exchange Server within a VHD (or other image format) file is an instance of Exchange Server.
• A VHD file with Exchange Server installed on top of Windows Server 2003 contains an instance of Windows Server 2003 and an instance of Exchange Server. Copying that VHD file will create another instance of Windows Server 2003 and another instance of Exchange Server. Deploying that VHD file to another server will create an instance of Windows Server 2003 and an instance of Exchange on that server.

Run an instance: You run an instance of software by loading it into memory and executing one or more of its instructions. Once running, an instance is considered to be running (whether or not its instructions continue to execute) until it is removed from memory.

Examples:
• If you merely copy an existing instance, it is not considered to be running because no instruction from that instance has yet been executed.
• If you load an instance of Exchange Server into memory, and execute one of its instructions, you are running an instance of Exchange Server. If you pause execution of any instructions of that instance by shifting all execution resources to another application, you are still considered to be running that instance of Exchange Server because it is still loaded in memory. To stop running an instance, you must terminate execution of its instructions, and also completely remove it from memory.

Assigning a license: To assign a license means simply to designate that license to one device or user. The purpose of this designation is to avoid sharing a license across multiple devices or multiple users at the same time.

Figure D2 – Assigning a license

Operating system (OS) environment: An OS environment is one instance of an OS and instances of applications, if any, configured to run on that OS instance. There are two types of OS environments, physical and virtual. A physical OS environment is configured to run directly on a physical hardware system. A virtual OS environment is configured to run on a virtual (or otherwise emulated) hardware system. A physical hardware system can have either or both of the following:
• one physical OS environment
• one or more virtual OS environments

Figure D3 – Different types of OS environments on a server

Physical and virtual processors: A physical processor is a processor in a physical hardware system. Physical OS environments use physical processors. A virtual processor is a processor in a virtual (or otherwise emulated) hardware system. Virtual OS environments use virtual processors.

Figure D4 – Physical and virtual hardware systems and resources

Virtual processors are considered to have the same number of threads and cores as each physical processor in the underlying physical hardware system. Microsoft is adopting this definition to enable customers to take advantage of the licensing policy we announced in 2004 for multi-core processors. For reliability and performance, VM technology can allocate resources from separate physical processors in the server to create a virtual processor for use by a particular OS environment. If the physical processors in the server have two cores, for licensing purposes, each virtual processor also has two cores, even if the cores are allocated from separate physical processors. For example, in Figure D5 below, the virtual processor 1 is allocated a core from physical processor 1 and a core from physical processor 2. Although that virtual processor is using cores from different physical processors, it is considered to be only a single virtual processor because it has the same number of cores as the physical processors in the server.

Figure D5 – The allocation of cores to virtual processors

Examples:
• Assume server B has dual-core processors. If you are running SQL Server (licensed Per Processor) in a virtual OS environment on server B, for licensing purposes, each virtual processor in each virtual OS environment can have up to two cores as well. It does not matter whether those cores are allocated from the same physical processor or not.
• Assume server C has four-core processors. If you are running BizTalk Server in a virtual OS environment on server C, for licensing purposes, each virtual processor in each virtual OS environment can have up to four cores as well. It does not matter whether those cores are allocated from the same physical processor or not.

Checklist: Configure Terminal Server Licensing

2006-01-03T02:10:00.000-08:00

Step Reference
• Read the "Windows Server 2003 Terminal Server Licensing" white paper and the Terminal Server Licensing overview.

Windows Server 2003 Terminal Server Licensing (http://go.microsoft.com/fwlink/?LinkID=26220)

Terminal Server Licensing overview

Choose a Terminal Server license server role.
Terminal Server license server roles

Install Terminal Server Licensing.
Install Terminal Server Licensing

Choose a license server activation method.
Activating a Terminal Server license server

Activate the license server.
Activate a Terminal Server License Server

Review information about purchasing and installing client access licenses (CALs).
Purchasing and installing client access licenses on a Terminal Server license server

Decide what type of CAL to purchase.
Choosing the Licensing Model (http://go.microsoft.com/fwlink/?LinkID=31898)

Purchase CALs.
Guidelines for Deploying Terminal Server (http://go.microsoft.com/fwlink/?LinkID=34627)

Install CALs.

Caution

• You must configure Terminal Server Licensing correctly in order for your terminal server to continue to accept connections from clients. To allow ample time for you to deploy a license server, Terminal Server provides a licensing grace period, during which no license server is required. During this grace period, a terminal server can accept connections from unlicensed clients without contacting a license server. The grace period begins the first time the terminal server accepts a client connection. It ends after you deploy a license server and that license server issues its first permanent client access license (CAL), or after 120 days, whichever comes first.

Install Client Access Licenses

Ensure that the terminal server can detect the license server.

Note

• Although Terminal Server attempts to detect a license server automatically, it is recommended that you explicitly specify a preferred license server that a terminal server connects to.

Set preferred Terminal Server license servers

Ensure that the Terminal Server mode matches the type of CALs purchased.
Guidelines for Deploying Terminal Server (http://go.microsoft.com/fwlink/?LinkID=34627)

disable login script on terminal server

2006-01-02T07:14:00.000-08:00

Well, I haven't actually tried this, but from what I've read it should work.

Apply a GPO that has Loopback processing turned on to the OU containing the
Terminal Servers .
Apply a second GPO to the same OU (or perhaps in the same GPO that has the
loopback setting) that specifies a Logon Script that runs an empty command
file.

With "Merge mode" loopback, the User settings applied by loopback processing
are applied after other User settings, so, the Logon Script setting in the
GPO applied by the loopback feature should be the "wining" GPO. With
"Replace mode" loopback, GPOs that apply to the user's account are not
processed at all.

See [url]http://support.microsoft.com/?kbid=231287[/url] and
[url]http://support.microsoft.com/?kbid=260370[/url]

--
Bruce Sanderson MVP Printing
[url]http://members.shaw.ca/bsanders[/url]

Terminal Server CAL Transition Plan: Frequently Asked Questions

2006-01-02T04:34:00.000-08:00

Terminal Services functionality is included in the Standard, Enterprise, and Datacenter editions of the Windows Server 2003 operating system.

This FAQ answers commonly asked questions about the Terminal Server CAL transition for Windows Server 2003. Click a question to view its answer. To view all the answers at one time, select the View all answers check box.

Q. Who qualifies to receive a complimentary Windows Server 2003 Terminal Server Client Access License (TS CAL)?

A. A. Every Windows XP Professional license purchased or owned before April 24, 2003, is eligible for a complimentary Windows Server 2003 TS CAL. Note that the Windows XP Professional license does not have to be installed as of April 24, 2003, to qualify. The product must simply be owned by that date.

Q. What is Microsoft doing to help customers with the transition to Windows Server 2003 Terminal Server CALs?

A. Microsoft is committed to accommodating existing customers who would like to take advantage of Windows Server 2003 features and realizes that the removal of desktop operating system equivalency will affect those customers.

Every Windows XP Professional desktop license owned as of April 24, 2003 (the public launch of Windows Server 2003), is eligible for a complimentary Windows Server 2003 TS CAL. One of the following scenarios will apply:

• If customers have either platform or operating system component Enterprise Agreements (EAs), Upgrade Advantage (UA), or Software Assurance (SA) coverage for their Windows desktop computers, then they can receive a Windows Server 2003 TS CAL, plus SA coverage on that TS CAL for each covered desktop (owned as of April 24, 2003).

• If customers own Windows XP Professional licenses, without upgrade rights—in other words, no EA, UA, or SA—then they can receive a Windows Server 2003 TS CAL for each licensed desktop owned as of April 24, 2003, but will not receive upgrade rights on the TS CAL.

Q. Is there a choice between a TS User CAL and a TS Device CAL in the Terminal Server Licensing Transition Plan?

A. Yes, customers who qualify for the Terminal Server Licensing Transition Plan will be able to choose between a TS User CAL or a TS Device CAL for each qualifying desktop.

Q. What steps do I take to choose TS User CALs or TS Device CALs?

A. When you are setting up your terminal server, the license management wizard will prompt you to choose which type of TS CAL you prefer.

Q. What information is required to prove eligibility for obtaining TS CALs?

A. Volume licensing agreement information is required. Or for retail or OEM customers, a Windows XP Professional product key is required.

Q. For customers who qualify for the Terminal Server Licensing Transition Plan, what is the process for obtaining the complimentary TS CAL?

A. The process varies depending on how the corresponding Windows XP Professional licenses were acquired. Refer to the two scenarios below.

Scenario 1: Windows XP Professional licenses acquired through volume licensing Using the Install Licenses function of the Terminal Server Licensing administration tool, a customer needs to provide volume licensing program information (enrollment number, agreement number, or license and authorization numbers) depending on program type, along with the requested quantity and type of TS CAL tokens. The information entered into the Terminal Server Licensing administration tool will be validated by the Microsoft Clearinghouse, and assuming that the request for tokens falls within the boundaries of the entitlement, license tokens will be installed onto the Terminal Server License Management server.

Scenario 2: Windows XP Professional licenses acquired through retail or OEM channels Customers who acquired Windows XP Professional licenses through these channels will have received a product key with their software. Customers should go to the transition Web site to input the product key using the Install Client Access License Tokens option. Eligibility will be validated through the transition Web site. Once validation occurs, the customer will receive a license key pack (via the Web site) that should be entered into the Terminal Server Licensing administration tool.

Q. How long do customers have to activate the TS CALs for which they may be eligible in this transition plan?

A. Customers have until June 30th, 2007, to follow the proper steps to receive their complimentary TS CALs. During this period, the transition Web site, Terminal Server License Management service, and Microsoft Clearinghouse will be equipped to dispense the appropriate number of TS CAL tokens to customers who validate their eligibility. After June 30th, 2007, customers forfeit their right to this process for complimentary TS CALs.

Q. How long do customers have to obtain their transition CALs, if they are eligible?

A. Transition CALs must be obtained before June 30, 2007. This does not change the fact that customers must have owned the license rights for Windows XP Professional as of April 24, 2003, in order to qualify.

Q. By what date must customers own use rights for Windows XP Professional in order to participate in the Terminal Server Licensing Transition Plan?

A. You must own the license rights to Windows XP Professional as of April 24, 2003.

Q. If, for example, I have 3,000 desktops, do I need to enter 3,000 separate product keys at the TS CAL transition site to receive the tokens that enable TS connections?

A. No, you do not have to enter 3,000 product keys. You have two options:

• You can go to the TS CAL transition site, where you will be asked to enter 10 product keys from the OEM PCs. You will then be asked for the total number of transition tokens needed and automatically receive that many.

• If you have a Select, EA, Campus, or School agreement, you can use the licensing wizard in the Terminal Services Licensing administrative tool in Windows Server 2003 to install the 3,000 TS CAL tokens, which will make it possible for 3,000 PCs to connect to TS.

The second of these two options is simpler and will save time and energy. Please note that you are not actually receiving 3,000 TS CALs from the transition plan related to the release of Windows Server 2003 TS. You cannot apply the TS CAL tokens received from the transition plan to any device. The tokens are intended specifically for the 3,000 PCs that ran Windows XP Professional prior to April 24, 2003.

Q. I have operating system licenses other than Windows XP Professional installed on my desktops, but I have Software Assurance coverage for those licenses. Can I still receive the complimentary TS CALs under the transition plan?

A. Yes. Even if you don't have Windows XP Professional installed, as long as you possessed the rights to the license by April 24, 2003—for example, through Software Assurance, Upgrade Advantage, or an Enterprise Agreement—you are eligible for the complimentary Windows Server 2003 TS CAL.

Q. I had an EA, UA, or SA agreement covering my Windows desktops, which was active at the time Windows XP Professional was released, but I let the agreement expire. Can I still receive TS CALs for the desktops that were covered under that agreement?

A. Yes. If you had an Enterprise Agreement (EA), Upgrade Advantage (UA), or Software Assurance (SA) agreement covering your Windows desktops at the time Windows XP Professional was released, you can still receive Windows Server 2003 TS CALs. As long as your upgrade protection coverage expired after the release of Windows XP Professional, you should have perpetual rights to those licenses. Since you still have rights to Windows XP Professional, you would qualify for the transition plan to receive TS CALs for the desktops that were covered at the time that the agreement expired.

Q. Can I acquire Software Assurance for the TS CAL that I receive as part of this transition plan?

A. Yes. Given the special circumstances with Windows Server 2003 TS CALs, you have the ability to acquire Software Assurance (SA) on those complimentary TS CALs. To enroll the complimentary licenses in SA, customers must acquire the Windows Server 2003 TS CAL Transition SKU. This is available from June 1 through December 31, 2003.

Normally, Microsoft requires customers to purchase SA at the time of license acquisition or shortly thereafter. However, in this case, since the TS CAL license was granted, the SA portion can be acquired separately until the end of the 2003 calendar year.

Note that this special TS CAL Transition SKU is a License and Software Assurance (L&SA) SKU, but the License (L) portion does not represent a second license in addition to the complimentary TS CAL that customers receive; the L portion represents the complimentary TS CAL.

Q. Once I receive my complimentary TS CAL, how long do I have to acquire Software Assurance to keep the TS CAL updated?

A. The general policy is to require customers who desire SA to pay for it at the same time they acquire the underlying license. SA renewals allow grace periods of 30 to 90 days, depending on the product. Since some customers may not choose to receive their complimentary TS CALs immediately after April 24, 2003, Microsoft will extend the normal 90-day grace period to December 31, 2003, during which SA may be acquired. After this period, customers who wish to upgrade their TS CALs but do not have SA will need to acquire a new TS CAL.

Q. Why aren't Windows 2000 Professional desktops included in the transition plan to receive complimentary TS CALs?

A. Under the old licensing model with desktop operating system equivalency, only operating systems with the same version number (or later version number) of the corresponding version of server operating system qualified to be the equivalent of a TS CAL—for example, a Windows NT 4.0 workstation connecting to a Windows NT 4.0 Terminal Server, or a Windows 2000 Professional desktop connecting to a Windows 2000 Terminal Server. Even if desktop equivalency had not been removed for Windows Server 2003, Windows 2000 Professional desktops would still have to have had a Windows Server 2003 TS CAL to connect to a Windows Server 2003 Terminal Server, and as such, the transition plan focuses on Windows XP Professional licensees.

Licensing Terminal Server in Windows Server 2003

2006-01-02T04:32:00.000-08:00

Licensing Terminal Server in Windows Server 2003 R2
Published: April 24, 2003 | Updated: December 9, 2005
Terminal Services functionality in Windows Server 2003 R2 lets you remotely execute applications on a Windows-based server from a wide range of devices over virtually any type of network connection. A server running Terminal Services can be referred to as a Terminal Server (TS).

Related Links
• Windows Server 2003 R2 Licensing Overview
• Terminal Server CAL Transition Plan: Frequently Asked Questions
• Microsoft Terminal Server Licensing Changes and Transition Plan
• Windows Server 2003 Terminal Server Licensing
• Windows Server 2003 Purchasing Options
• Purchasing Windows Server 2003 Terminal Server

On This Page
Terminal Server Licensing Requirements
Terminal Server Client Access Licensing Mode

Terminal Server Licensing Requirements
Windows Server License
The Windows Server 2003 R2 licensing model requires a server license for each copy of the server software installed. Terminal Services functionality is included in the Windows Server license.

Windows Server Client Access License
In addition to a server license, a Windows Server Client Access License (CAL) is required. If you wish to conduct a Windows session, an incremental Terminal Server Client Access License (TS CAL) is required as well. A Windows session is defined as a session during which the server software hosts a graphical user interface on a device. For Windows sessions, a TS CAL is required for each user or device.

Device-based versus User-based Terminal Server CALs
Two types of Terminal Server Client Access Licenses are available: TS Device CAL or TS User CAL.

• A TS Device CAL permits one device (used by any user) to conduct Windows Sessions on any of your servers.

• A TS User CAL permits one user (using any device) to conduct Windows Sessions on any of your servers.

You may choose to use a combination of TS Device CALs and TS User CALs simultaneously with the server software.

Top of page
Terminal Server Client Access Licensing Mode
Terminal Server CALs are available in Per User/Per Device mode only.

In Per User or Per Device mode, a separate TS CAL is required for each user or device that accesses or uses the server software on any server. You may reassign a TS CAL from one device to another device, or from one user to another user, provided the reassignment is made either (a) permanently away from the one device or user or (b) temporarily to accommodate the use of the TS CAL either by a loaner device, while a permanent device is out of service, or by a temporary worker, while a regular employee is absent.

TS CALs are not available in Per Server mode as Windows sessions are not allowed in Per Server mode.

Note: To use User and Device TS CALs simultaneously on one Terminal Server, the server must be configured for Per User TS CAL mode. Failure to have the appropriate number of User CALs or Device CALs for each device or user connecting to the server is a violation of the license agreement.

Terminal Server CAL Changes
The following licensing changes have been made with regard to Terminal Server Client Access Licenses.

Removal of Operating System Equivalency in Terminal Server
With Windows 2000 Server Terminal Server licensing, if a client device is running the most recent version of the Windows desktop operating system, a TS CAL is not required to satisfy the licensing requirement. However, with Windows Server 2003, a TS CAL is required for each device or user using Terminal Server functionality, irrespective of which desktop operating system is running on the device.

Terminal Server Licensing Transition Plan
Microsoft realizes that the removal of operating system equivalency will affect customers and is committed to accommodating existing Microsoft customers who would like to take advantage of Windows Server 2003 features.

Every Windows XP Professional desktop license that you own on the date of the public launch of Windows Server 2003 (April 24, 2003) is eligible for a Windows Server 2003 TS CAL. For further information, see the Microsoft Terminal Server Licensing Changes and Transition Plan page.