• • • • • • • • Licensing is probably the most dreaded component of any environment’s implementation. In Terminal Server environments, you must account for both OS licenses and application licenses. Investigate the Microsoft Terminal Services License manager to see if the workstation is enumerated. If the workstation is not enumerated, then this issue is on the Windows OS level. For more information, contact Microsoft Technical Support and verify that your Windows 2003 Terminal Licenses are activated. We have 2 ts cal licenses on the windows 2003 server we can only get one branch pc to logon. Terminal server licensing. Financial services; Developer. Licensing is really no different from non-Terminal Server environments, except that Windows Server 2003 has technical components that force you to comply with your licenses. If you decide to ignore it, you’ll most likely revisit licensing in 120 days when your Terminal Servers stop functioning because they weren’t licensed properly. Terminal Servers running on Windows 2000 were the first to use Microsoft’s new licensing enforcement technology, and Windows 2003 builds on that. This paper concludes with a look at how third-party applications are licensed in Terminal Server environments. Terminal Server 2003 Licensing Overview Before addressing the technical components that will make up your licensing infrastructure, let’s review Microsoft’s licensing policy. Microsoft licenses can be divided into two groups: • Licenses required for each server. • Licenses required for clients. Terminal Server implementation will require both client and server licenses. Licenses Required for Each Terminal Server Microsoft requires one license for each server in a Terminal Services environment. This license, known as a “server license,” is just the standard Windows Server 2003 license—you don’t need anything special to run Terminal Server. It is the same license used for the base server operating system of any Windows 2003 server—whether that server is an Exchange Server, a SQL Server, or a file and print server. However, unlike some Microsoft server applications that require specific server licenses (like Exchange or SQL Server), no additional server licenses are required to use Terminal Server. Some features (as described in require the “Enterprise” edition of Windows Server 2003. For those you would need an Enterprise version of a Windows Server 2003 license for your server. Microsoft Terminal Server Client Access Licenses Before you get too excited about the fact that you don’t need a special server license to run Terminal Services, remember that you’ll need a client license for everyone that connects to a Windows 2003 Terminal Server. Prior to Windows Server 2003, a Terminal Server Client Access License (TS CAL) was required for every computer device that connected to a Terminal Server. This licensing system is known as “per device” licensing. Microsoft defined one “device” as a unique piece of hardware used to access a server. If you had two computers and you accessed the same server from each of them, you had two different devices and needed a separate “per device” license for each. Such was the case even if you never used both devices at the same time. Naturally this method of licensing elicited numerous complaints. In Windows Server 2003, Microsoft added a second TS CAL option. This “per user” client licensing option allows you to purchase one license for each user account. A user can then access a Terminal Server from multiple client devices using one license. “Per user” TS CALs are associated with user accounts, so two users cannot share a license even if they never log on at the same time. If two users share the same physical computer, then it might be preferable to employ the “per device” license option discussed in the previous paragraph. Microsoft also offers an “external connector” Terminal Server client access license that you buy for a server and lets you connect an unlimited number of non-employees to the server. Let’s look at the three different Terminal Server client license options. Terminal Server “Device” Client Access License Terminal Services licensing has traditionally been handled by the Terminal Server device Client Access License (TS Device CAL). One license is assigned to each specific client device. Each unique client device that accesses a Terminal Server requires a single TS Device CAL. What is this license good for? If your environment has workstations that are used by a multiple users, as in round-the-clock environments such as factory floors, call centers, and nursing stations, this license is the most effective since your users could share a single TS Device CAL. Terminal Server “User” Client Access License A Terminal Server user Client Access License (TS User CAL) is assigned to a user account. It then “follows” that user no matter which server he logs on to and no matter which client device he logs on from. This license is ideal for mobile workers that roam from location to location while using Terminal Servers to access their applications. Also, if your users use multiple client devices (perhaps their work PC and home PC), this model may save your company significant licensing dollars. External Connector License A challenge to using per-user and per-device CALs is the fact that they have to be assigned to a specific user account or a specific client device. While adequate for employees of the company that bought the license, what happens if a company wants to extend its Terminal Server environment to business partners where the names of users and client devices wouldn’t be known? What happens if a company wants to extend an application via a Terminal Server to the Internet? Technically following the Microsoft terms, you would need to buy a license for each unique user or computer that connected to your server. Clearly this is not feasible. To address this challenge, Microsoft introduced the External Connector License (ECL), designed to be used when systems are extended to external parties, including business partners and the public. ECLs are available for all new Microsoft products (except products that are licensed on a per-processor basis since per-processor licenses already account for unlimited users and client devices). In Terminal Server 2003 environments, ECLs provide a simple way to buy “concurrent” user licenses for those who need to connect to your server. If you wanted to open up a server to trading partners, you would buy a Terminal Server ECL. At this point you might be wondering why you can’t just buy ECLs and forget all this per-user and per-device garbage. Microsoft has strict rules governing the use of ECLs, and users of the TS ECLs cannot be employees of the organization that bought the license. Microsoft Windows Server Client Access Licenses Now that you understand the difference between the three Terminal Server-specific CALs, you need to know that each client device also needs a standard Windows Server 2003 CAL. To legally access a Windows 2003 Terminal Server, each client seat requires each of the following licenses: • Windows Server 2003 Client Access License. • Windows Server 2003 Terminal Server Client Access License. Windows Server Client Access License (Server CAL) Any user needs this Windows Server CAL to access a Windows 2003 server. This license provides the “basic” access rights that allow users to store files, print, and be part of an Active Directory. If you have a unified Active Directory with 5000 users, then you’ll have 5000 Windows Server CALs. Windows Server 2003 Terminal Server Client Access License (TS CAL) We discussed the TS CAL (either per-device, per-user, or External Connector License) in the previous section. It builds upon the regular Windows Server CAL, adding the legal right for users to access a “remote control” session on a Terminal Server. If you have a 5000-user Active Directory environment with a few Terminal Servers that provide applications for 300 users, then you’ll need 5000 Windows Server CALs and 300 Terminal Server CALs. Special Licensing Scenarios Prior to Windows Server 2003, there were special license rules for specific situations. Microsoft has changed the way these situations are handled with the introduction of Windows Server 2003. TS CAL Requirements when Connecting to a Terminal Server from Windows XP Prior to Windows Server 2003, client workstations that ran Windows NT, 2000, or XP Professional had the right to obtain a “free” TS CAL. The only requirement was to purchase a TS CAL for client devices that ran an operating system lower than the Terminal Server operating system. For example, Windows 2000 Professional workstations did not require purchase of a TS CAL to connect to a Windows 2000 Terminal Server since Windows 2000 client devices had the right to obtain a free Windows 2000 TS CAL. Also, since these licenses were backwards compatible, the Windows 2000 TS CAL would also apply if you were using a Windows XP Professional client to connect to a Windows 2000 Terminal Server. Since Windows XP was released over a year before Windows Server 2003, many people bought Windows XP Professional with the assumption that it would include a “free” Windows Server 2003 TS CAL. However, with the release of Windows 2003, Microsoft removed the “free” TS CAL license that was built-in to Windows XP Professional. Unfortunately, this announcement came well after many organizations bought multiple copies of Windows XP assuming that its free TS CAL would work with Windows 2003 Terminal Servers. Negative response to this announcement prompted Microsoft grant a free Windows 2003 TS CAL to anyone who owned a Windows XP Professional license on April 23, 2003 (the day before the release of Windows Server 2003.Does your copy of Windows XP come with a free Windows Server 2003 TS CAL? If you bought it before April 24, 2003, then it does. If you bought if after that it does not, and you’ll have to buy a Windows 2003 TS CAL. (If you had TS CALs that were enrolled in Microsoft Enterprise Agreements or Software Assurance, then you automatically qualified for the Windows 2003 TS CAL upgrade.) Interestingly, the added TS CAL costs of Terminal Server on Windows Server 2003 has upset some companies so much that they are claiming it as the sole reason that they will keep their Terminal Servers running on Windows 2000. The Work-at-Home TS CAL Microsoft licensing agreements also used to provide “work-at-home” licenses for Terminal Servers. These were additional, cheap TS CALs for users that used an office computer to access Terminal Servers and then went home and accessed Terminal Servers from a home PC. With the advent of Windows 2003’s new per-user TS CAL, the work-at-home license is no longer an option. Similar to TS CALs, any prior work-at-home licenses that are enrolled in an Enterprise Agreement or Software Assurance may be upgraded to current licenses. Windows 2003 Terminal Server Licensing Components Windows NT Server 4.0 Terminal Server Edition used the “honor system” for tracking licenses. While you were legally supposed to purchase the correct licenses, there was nothing technically stopping you from connecting more users than you paid for. While the honor system worked well for system administrators and thieves, it has not worked as well for Microsoft shareholders. As alluded to in the opening sentences of this paper, this system changed when Windows 2000 was released. In Terminal Services for Windows 2000, a Microsoft “Terminal Services Licensing Service” is required to run on one or more servers on your network. This Terminal Services licensing service is responsible for monitoring, distributing, and enforcing TS CAL usage. Microsoft implemented this licensing service as a “service to their customers” who were “deeply concerned that they might accidentally forget to pay for a license or two, every once in awhile.” In Terminal Server environments running on Windows 2000 platforms, this licensing service infrastructure guarantees that there be no “accidentally forgetting” to purchase all the needed licenses. Windows 2003 Terminal Servers also make use of licensing servers—although the exact manner depends upon for which of three licensing options a server is configured (per device, per user, or the external connector license). In Windows 2003 environments, there are four main technical components that make up the Terminal Services licensing infrastructure: • Terminal Services licensing servers. • The Microsoft license clearinghouse. • Windows 2000/2003 Terminal Servers. Microsoft licensing components Let’s take a look at the licensing–related roles of each component. Terminal Services License Server The Terminal Services license server is a standard Windows 2003 server with the “Terminal Server Licensing Service” installed. This license server stores digital certificates for TS CALs that are distributed to client devices. Like Windows 2000 environments, a Windows 2003 license server is responsible for issuing licenses and tracking their use. Microsoft License Clearinghouse TS license servers and TS client access licenses must be activated be Microsoft before they can be used. The Microsoft license clearinghouse is a large Internet-based certificate authority that authorizes and activates these licenses and servers. Microsoft does this to ensure that no TS CALs are stolen, copied, or pirated (which is why more and more Microsoft software requires activation after you input your license codes). A TS license server will function before it’s activated via the Microsoft clearinghouse, however, an unactivated license server will only pass out temporary TS CALs that expire after 90 days. In order for a license server to distribute permanent licenses, it must be activated. Terminal Server Windows 2003 Terminal Servers understand that client devices must be licensed. To that end, when you enable Terminal Services, the server immediately begins trying to locate a licensing server. It then communicates with the licensing server to ensure that client devices are licensed properly. Each Terminal Server must be configured to use per-user, per-device, or external connector licenses. Licenses The license service that runs on a Windows 2003 server keeps track of seven different types of licenses. These include four types of licenses for Windows 2003 Terminal Servers and three types (for backward compatibility) for Windows 2000 Terminal Servers. The seven types of Windows 2003 client licenses include: • Windows Server 2003 TS Device CALs. This license is the per-device CAL that is issued to unique client hardware devices. It allows the client device to access Windows 2000 and 2003 Terminal Servers. • Windows Server 2003 TS User CALs. This is the per user CAL that’s assigned to unique user accounts. This license allows a user to access Windows 2000 and 2003 Terminal Servers. If the client device has a valid TS Device CAL, then this TS User CAL is not needed, and vice versa. • Windows Server 2003 TS External Connector Licenses. When assigned to a Terminal Server, this ECL license allows unlimited non-employee connections. When this ECL is used, TS Device CALs and TS User CALs are not needed. • Windows 2000 TS CALs. These are per-device licenses for devices connecting to Terminal Servers running Windows 2000. • Windows 2000 TS Internet Connector Licenses. These licenses are essentially the Windows 2000 version of the Windows 2003 TS ECL. When assigned to a Windows 2000 Terminal Server, this license allows 200 simultaneous connections. These connections must be made by non-employees, across the Internet, via anonymous user accounts. • Windows 2000 Built-in Licenses. These built-in licenses are used for Windows 2000 and Windows XP workstations that are connecting to Windows 2000-based Terminal Servers. Remember from the previous section that Windows 2003 Terminal Servers do not support the use of built-in licenses. (Which is why even if your Windows XP workstations qualify for “free” Windows 2003 TS CALs, you have to obtain TS Devices CALs from Microsoft—they’re not automatically built in.) • Temporary Licenses. If a licensing server ever runs out of activated licenses, it will issue temporary licenses to any client devices requesting per-device TS CALs (applicable to Windows 2000 or 2003-based Terminal Servers). The number of temporary TS CALs a licensing server can grant is unlimited, although the temporary CALs themselves expire after 90 days and cannot extended. The Terminal Services Licensing Service As you’re starting to see, the Windows 2003’s Terminal Server licensing environment is extremely complex. It’s probably also fairly obvious that the licensing service plays a central role. In Windows 2003, this service builds on the licensing functionality that was available in Windows 2000. TS Licensing Service Installation Considerations The TS licensing service is separate from the actual Terminal Server components that allow users to run remote sessions. In Windows 2003 Terminal Server environments, the TS licensing service must be installed on a Windows 2003 server. That server can be any server in your environment that has a trust path to your Terminal Servers. Same domain, or trusted domain, or trusted forest, etc.) The license service does NOT have to be a server that’s running Terminal Server. Most companies install the TS licensing service on a standard Windows 2003 file and print server. The TS licensing service can be installed on any Windows 2003 server. It does not have to be in-stalled on a domain controller. Furthermore, this installation can be done at the time of the OS installation or at any time after that via the Control Panel (Control Panel| Add Remove Pro-grams| Windows Components| Terminal Services Licensing Service). There is no need to build a dedicated licensing server. The TS licensing service can run on any Windows 2003 server without adversely affecting performance. It adds very little CPU or memory overhead, and its hard disk requirements are negligible. The average memory usage is less than 10MB when active, and the license database will grow in increments of only 5 MB for every 6,000 license tokens issued. The license server does not require Internet access. TS Licensing Service Scope As part of the licensing service setup, the installation routine asks if you want to set up the license server for your “Enterprise” or “Domain or Workgroup.” The option chosen here (called the “scope”) dictates how the license server communicates with your Terminal Servers and lets you control which Terminal Servers can receive licenses from your licensing server. You can configure your license server so that it provides licenses for either: • An entire Active Directory site. (Enterprise licensing server) • An entire domain or workgroup. (Domain/workgroup licensing server). Enterprise Scope If you choose the “Enterprise” installation option, your licensing server will respond to a license request from any Terminal Server in the same Active Directory site. If Terminal Servers from multiple domains exist in that Active Directory site, the license server will provide licenses for all of them. This option requires that your Terminal Servers be part of an Active Directory domain. When the licensing service starts, it registers itself with a domain controller and creates a “TS-Licensing” object in the directory, allowing Terminal Servers from any domain to query a domain controller to locate the license server. Domain / Workgroup Scope Choosing the “Your domain or workgroup” option causes the license server to behave differently, depending on whether it’s part of an Active Directory domain. In AD environments, this choice causes your licensing servers to only respond to license requests from Terminal Servers in the same Active Directory domain. If an Active Directory domain crosses multiple Active Directory sites, the licensing server will fulfill requests from multiple sites. This option is useful in situations where there are multiple business units partitioned into different domains on the same network. A license server from one domain won’t give licenses to clients connecting to Terminal Servers from a different domain. In non-AD environments, choosing this option means that your license server will not attempt to register itself with a domain controller, and your Terminal Servers will have to find your license servers on their own. (More on this later.) TS Licensing Server Activation After the TS licensing service is installed on a server, it must be activated by the Microsoft clearinghouse via the Terminal Services Licensing tool. This activation gives the license server the digital certificate it will use to accept and activate TS CALs. The license server activation is fairly straightforward (Start| Programs| Administrative Tools| Terminal Services Licensing| Right-click on server| Activate). Activation can be accomplished directly via the Internet or via a web page, fax, or telephone call. If you run the licensing tool on a computer other than the license server, the computer that you are using must have access to the Internet—not the license server. You must install a TS licensing server within 120 days of using Terminal Services on a Windows 2003 server. (This was increased from 90 days with Windows 2000.) If a Windows 2003 Terminal Server can’t find a license server after it’s been used for 120 days, the Terminal Server will refuse connections to clients without valid TS CALs. How Terminal Servers find Licensing Servers Since you can install the licensing service on any Windows 2003 server in your environment, the real fun begins when you try to get your Terminal Servers to talk to your license server(s). Merely installing a license server on your network does not necessarily mean that your Terminal Servers will be able to find it. License server “discovery” is the technical term for the process by which Terminal Servers locate and connect to licensing servers. As soon as the Terminal Server role is added to a Windows 2003 server, the server immediately begins the discovery process. License server discovery can happen in a number of ways, depending on which of the following environments the Terminal Server finds itself in: • No domain (workgroup mode). • Windows NT 4.0 domain. • Active Directory domain, with the TS license servers operating in domain mode. • Active Directory domain, with the TS license servers operating in enterprise mode. Hard-Coding Preferred License Servers Regardless of which of these four situations a Terminal Server is in, you always have the option of manually specifying a license server or servers that each Terminal Server should get licenses from. You can manually configure any Terminal Server to get licenses from any license server—there’s no need to stay within domain, subnet, location, or site boundaries. You can configure a Terminal Server to use a specific license server via the Terminal Server’s registry. Be careful though, because this registry edit is not like most others. In this case, rather than specifying a new registry value and then entering data, you have to create a new registry key (or “folder”). To do this, browse to the following registry location: HKLM SYSTEM ControlSet Services TermService Parameters Add a new key called “LicenseServers.” Underneath the new LicenseServers key, create another key with the NetBIOS name of the license server that you want this Terminal Server to use. You don’t need to add any values or data under this new key. Add multiple keys for multiple servers if you wish, although the Terminal Server will only communicate with one license server at a time. Once you’re done, reboot the server for it to take affect. As you’ll see, this manual process is needed in situations where the Terminal Servers cannot automatically “discover” the license servers. It’s also useful if you want to override the default license server that a Terminal Server discovers. Discovery in Windows NT 4 Domains or Workgroup Environments In non-Active Directory environments, a Terminal Server first looks to the LicenseServer registry location to see if any license servers have been manually specified. If the registry key is empty or if the server or servers specified there cannot be contacted, the Ter-minal Server performs a NetBIOS broadcast to attempt to locate a license server. (NetBIOS broadcasts are not routable, so only license servers on the same subnet as the Terminal Server making the broadcast will respond.) If multiple license servers respond, the Terminal Server re-members their names and chooses which it will use exclusively. Once the Terminal Server picks a license server, the Terminal Server periodically verifies that it exists. (See Figure 2.) If the license server ever fails to respond to the verification poll from the Ter-minal Server, the Terminal Server attempts to connect to one of the other license servers that responded to the original NetBIOS process. If no connection can be made to a license server, the Terminal Server attempts to find a new license server by starting the entire discovery process over again. Figure 2 Terminal Servers periodically verify that they can contact license servers Environment Once contact, license server is verified after xxx minutes of no activity If not found, discovery process repeats every: NT 4 domain or workgroup 120 min 15 min Domain Mode 120 min 15 min Enterprise Mode 60 min 60 min Discovery in Active Directory Environments When a Terminal Server is a member of an Active Directory domain, the license server discovery process is entirely different. • First, the Terminal Server attempts to contact the license server (or servers) specified in its LicenseServers registry key. If a license server is discovered at any point through this process, the remainder of the discovery process is aborted. • If that attempt fails, the server next looks for an enterprise scope licensing server by performing an LDAP query for the following object in its Active Directory site: LDAP://CN=TS-Enterprise-License-Server,CN=, CN=sites,CN=configuration,DC=,DC=com • If that attempt also fails, the Terminal Server begins querying every domain controller in the site, looking for “enterprise scope” licensing servers. • If the Terminal Server still has not found a license server, it will query every other domain controller (outside of its site) to see if any are configured as a domain scope license server. One thing that you might have noticed about this discovery process is that domain scope license servers must be installed on domain controllers in order for your Terminal Servers to discover them. Domain scope license servers do not register themselves with other domain controllers and Terminal Servers only query domain controllers to see if they are license servers. There’s nothing wrong with installing a domain scope license server on a non-domain controller. Just be aware than you’ll need to manually configure the registries of your Terminal Servers to find those license servers. Enterprise scope license servers are not affected, since they register themselves with the domain controllers, even when not installed on a domain controller. If a Terminal Server does not find a license server via this discovery process, the whole process is started over once every hour. If license servers are found, the Terminal Server keeps a list of them in its registry. Enterprise li-censing servers are stored in the HKLM Software Microsoft MSLicensing Parameters EnterpriseServerMulti registry location, and domain licensing servers are stored in the HKLM Software Microsoft MSLicensing Parameters DomainLicenseServerMulti registry location. By storing these server names in the registry, a Terminal Server is able to quickly pick a new license server if its primary choice is not available. Once a license server is found, the Terminal Server will only start the discovery process over again if it can’t connect to any of the servers in the registry. Troubleshooting License Server Discovery You are likely to run into situations in which one of your Terminal Servers cannot find a license server and the reason is not apparent. Fortunately, the Windows Server 2003 Resource Kit in-cludes a Terminal Server License Server viewer tool, LSVIEW.EXE. LSVIEW is a GUI-based tool that is run on a Terminal Server. It provides you with the names and types of each license server that it can discover. Microsoft license server discovery process The Terminal Server 2003 Licensing Process Let’s take a look now at how the entire licensing process works. The exact process that takes place is different depending on whether the Terminal Server is configured to use device-based or user-based TS CALs. Terminal Servers Configured for Device-Based TS CALs When a Terminal Server is configured to use TS Device CALs (Start| Administrative Tools| Ter-minal Services Configuration| Server Settings| Licensing), each client device needs to have its own license. • Terminal Server CALs are purchased and installed into the license database on the (pre-viously activated) TS Licensing Server. • The TS CALs are activated via the Microsoft License clearinghouse. The activated li-censes remain on the license server, waiting for assignment to client devices. • A user makes an RDP connection to the Terminal Server. • Since the Terminal Server is in per device licensing mode, the Terminal Server checks for the device’s TS CAL (in the form of a digital certificate). • If the client device does not present a valid TS CAL, the Terminal Server connects to the license server to obtain one. • If the license server does not have any more TS CALs, it will route the Terminal Server to another license server that does have available TS CALs (if known). • The license server sends the Terminal Server a digital certificate for a temporary 90-day TS CAL. • The Terminal Server passes this certificate down to the client. • The user’s credentials are validated. If the user successfully authenticates, the Terminal Server contacts the license server a second time. This time around, the Terminal Server informs the license server that the TS CAL that was sent to the client should be marked as “valid.” If the user did not successfully authenticate, (i.e. The connection was from an inappropriate user), the Terminal Server will not contact the license server, and the li-cense that was sent out will not be marked “valid.” • The next time that client device connects, it presents its 90-day temporary TS CAL to the Terminal Server. • The Terminal Server contacts the license server. Since the licensing server marked the CAL as valid the first time the user authenticated, the client device’s temporary CAL is up-graded to a full CAL. If, for some reason, all of the license servers have depleted their in-ventories of TS CALs, the client device keeps its temporary 90-day TS CAL certificate. As long as the 90-day certificate has not expired, the client device can still connect, even with no available licenses on any license servers. An unlicensed client device will always be granted a temporary 90-day TS CAL at the time of its first connection. Only after successful authentication and a second logon is the temporary TS CAL upgraded to a full TS CAL. This two–stage licensing process is used to ensure that TS CALs are only assigned to authenticated users. Previously (before hotfix 287687 or Windows 2000 Ser-vice Pack 3) any user that connected was assigned a full TS CAL, even if he did not belong on the system. The full TS CAL certificate was granted at connection time, before the logon screen even popped up. If a user thought, “Oops, I don’t belong on this system!” it was too late—his client device had already received a full TS CAL certificate, even if the administrator never meant for him to access the system. This circumstance often led to license servers running out of TS CALs. During this process, if the license server does not respond to the Terminal Server, the Terminal Server will try to connect to one of the other license servers from the list of servers it maintains in the registry that was built as a result of the license server discovery process. If it can’t connect to any of them, it will start the license server discovery process again. If a client device does not have a TS CAL and the Terminal Server cannot contact a license server, the user’s session will be denied. The only exception to this is for new Terminal Servers. In Win-dows 2003, you have a 120-day “grace period” during which a Terminal Server will function even if it cannot contact a license server. However, 121 days after you install Terminal Services onto a Windows 2003 server, that server must be able to contact a licensing server or no new users will be able to connect. All of this action takes place a soon as the connection is made—before the user even authenticates! TS CAL License Certificate Storage on Client Devices As mentioned earlier, when a client device receives a TS Device CAL from a Terminal Server, it receives it in the form of a digital certificate from a license server. For this reason you must acti-vate the license server with the Microsoft clearinghouse (which is just a certificate authority). The digital certificate is an actual certificate copied to the client device (even with Windows CE). Once a client device connects to a Terminal Server, a TS CAL digital certificate is transferred from the license server to the client device. The license server loses one of its licenses from its in-ventory, and the client device has the digital certificate that it can present to any Terminal Server on future connections. The digital certificate is stored in different locations depending on the operating system. On 32-bit Windows platforms, the TS CAL digital certificate is stored in the registry at HKLM Software Microsoft MSLicensing Store License00x. Anyone who has been in the computer industry for more than five minutes can probably spot a potential flaw in this plan. Client devices tend to break. Windows-based terminals have their ROMs reflashed. Operating systems are reinstalled on workstations. PCs are reimaged. Whenever this happens, the TS CAL digital certificate stored on the client device is lost forever. The TS CAL doesn’t exist on the license server after it’s transferred to a client device. When that client connects back to a Terminal Server, it has no digital certificate to present. The server thinks that it has no license, and instructs the license server to issue a new TS CAL in the form of a new digital certificate. In effect, that one client device ends up consuming two TS CALs—the old one that was lost and the new one that was just issued. If the client device were reset again, a third TS CAL would be used. In Windows 2003 (and Windows 2000 SP3), when a Terminal Server requests a TS CAL from the license server for a client device, a full TS CAL certificate is granted with an expiration date randomly selected between 52 and 89 days from the current date. The license server keeps track of the expiration date and it is also embedded into the digital certificate that represents the actual license passed down to the client device. Every time the client device connects to a Terminal Server, it presents its TS CAL certificate to the server. The server checks not only whether the client device has a valid certificate, but also the expiration date of that certificate. If the expiration date of the certificate is within 7 days of the current date, the Terminal Server connects to the license server to renew the license for another random period of 52 to 89 days. The license server also tracks the expiration date of TS CALs. If for some reason the client’s CAL is never renewed and expires, the license server returns that TS CAL to the inventory of available unused licenses. If a client device with a TS CAL were to blow up or be rebuilt, the license server would automatically add the TS CAL back into its available license pool after it expired (a maxi-mum of 89 days). If the Terminal Server is not able to obtain a TS CAL renewal when the client device’s TS CAL certificate expires after the 52 to 89 days, the client is denied access. A temporary 90-day certifi-cate cannot replace a full certificate that has expired, but this shouldn’t ever be a problem for you (unless you don’t have enough TS CALs). Someone at Microsoft deserves an award for the fact that the temporary TS CALs are valid for 90 days and the full TS CALs are valid for a maximum of 89 days—conveniently one day less than the temporary licenses. Consider the following scenario: Assume that a client device successfully authenticates to a Terminal Server and is granted a full TS CAL certificate that was (worst case) randomly selected to expire at the 89 day maximum. When it passes down the certificate, the license server decrements its total TS CAL license count by one, also noting that particular certificate’s expiration date. Now, assume that a catastrophic event oc-curs at the client, causing its local operating system to be reinstalled and its local TS CAL certifi-cate to be lost. When that client authenticates to a Terminal Server, the Terminal Server will request a new TS CAL certificate from the license server and the license server (again) decrements its TS CAL inventory by one. At this point there have been two TS CAL licenses given out to that one client, but the first one will never be renewed because the certificate was lost when the client was rebuilt. After 89 days (the randomly selected duration of the first certificate), the first TS CAL is returned to the pool by the license server. The administrator in this situation probably bought just enough TS CALs to cover the exact number of client devices. He did not buy extras to cover the 52 – 89 day period during which one client device had two CALs assigned. By purchasing the exact amount of TS CALs, the li-cense server would not have any more TS CALs to give out when the client device asked for the new TS CAL certificate after the first was lost. In this case, the license server would grant a tem-porary 90-day TS CAL certificate to the client device because the client device appears to the server as a brand new machine. Because the temporary TS CAL certificate is always valid at least one day longer then the full CAL certificate (90 days versus a maximum of 89 days), the old, lost full TS CAL will always be returned to the inventory on the license server at least one day before the temporary TS CAL cer-tificate would expire. For example, after day 88, the client device’s temporary TS CAL certificate will expire in 2 days, but the license server is tracking the expiration of the full TS CAL that was originally granted for 89 days. That full TS CAL only has 1 day left before it expires. The following day, when the client device’s temporary TS CAL certificate has only 1 day remaining, the license server will add the original TS CAL back in its inventory pool, making it available to grant to the client as a permanent license for another random period of 52 – 89 days. True geeks will enjoy tracing the entire licensing flow in Windows 2003 Terminal Server envi-ronments in Figure 4. Multiple License Timeframes Explained Throughout this license distribution and acquisition process, we have discussed two different li-cense timeframes. While both are related to Windows 2003 Terminal Services licensing, they are actually completely different. • A Windows 2003 Terminal Server will work without a license server for 120 days. • If a license server runs out of TS CALs (licenses), it will issue 90-day temporary ones. The first item relates to the presence of a license server. If a Terminal Server cannot locate a li-cense server, it will still allow unlicensed client devices to log on. The Terminal Server itself does not grant 90-day temporary licenses if it cannot find a license server. Instead, if a license server cannot be located, the Terminal Server simply “looks the other way” for 120 days. After the grace period ends, unlicensed client device connections are refused. This 120-day countdown begins the first time a Terminal Services client device connects to the server. From a legal standpoint, you must have a valid TS CAL for each client device that connects to a Terminal Server, even during the first 120 days. The 120-day threshold is not a free evaluation period. Rather, it gives you a chance to set up your Terminal Server environment and get the bugs worked out before you activate your license server. The second item relates to the license server itself. If, over the course of business, a TS licensing server runs out of licenses, it will begin to grant 90-day temporary license certificates to client devices. Unlike Windows 2000, Windows 2003 license servers do not have to be activated to hand out 90-day temporary TS CALs. Figure 4. The Terminal Server 2003 Device-Based TS CAL Licensing Process These temporary licenses can only be replaced by full TS CAL licenses—they cannot be replaced by additional temporary licenses. There is no limit to the number of temporary licenses that a li-cense server can grant. Also, the 90-day timer for the expiration of the TS CALs is client specific, meaning that different temporary licenses can expire on different days—even if they were all granted by the same license server. Terminal Servers configured for User-Based CALs Everything discussed in the previous section is applicable only when Terminal Servers are config-ured in “per device” licensing mode. When a user connects to a Terminal Server configured in “per user” licensing mode, a different process takes place. • When Terminal Services is installed on a Windows 2003 server, the server verifies that it can find (via the discovery process outlined previously) a license server. • There is no Step Two. That’s right. All this TS CAL digital certificate, temp license, transfer mumbo-jumbo only applies when Terminal Servers are configured for “per device” licenses. With per user licenses, all you have to do is make sure that the Terminal Server can find a license server. (The license server doesn’t even have to be activated!) Other than periodically verifying that it exists, there’s no com-munication between a “per user” configured Terminal Server and a license server. How did this come to be? When Windows 2003 was in beta testing, Microsoft was planning to offer a “per processor” licensing model. At the last minute (with Release Candidate 2), Microsoft changed its mind and decided to go with a “per user” option instead. This decision was a popular move on Microsoft’s part. The only problem was that it was so late in the game that Microsoft didn’t have time to build the “per user” technical license compliance infrastructure (although you can bet we’ll see it in future versions of Windows). Designing your Licensing Server Environment Now that we’ve reviewed the details of how licensing works, let’s look at some of the issues affect the design of your TS licensing servers. • Selecting which Terminal Servers can access which license servers. • Licensing Terminal Servers in mixed Windows 2000 and Windows 2003 environments. Enforcing which Terminal Servers are Authorized to Receive Licenses A new feature of Windows 2003 allows you to specify security permissions for your license servers. That is, you can specify which Terminal Servers are authorized to pass out licenses from a specific license server. This feature is useful to organizations that manage licensing by business unit or specific users groups, since it can prevent one department from “stealing” another department’s licenses. You must first enable this security feature via a policy applied to the license server (Computer Configuration| Administrative Templates| Windows Components| Terminal Services| Licens-ing). Once this functionality is enabled, a local group called “Terminal Services Computers” is created on the license server. The License Server will only respond to license requests from servers (or global groups containing servers) whose computer accounts are a member of this group. When this policy is enabled on a license server that’s also a domain controller, the group that’s created is a domain local group (since domain controllers don’t have local groups). Therefore, if you really plan on managing your licenses by department, it’s probably not the best idea to install the licensing service on a domain controller. If you want to manage licenses by business unit, it’s usually easiest to install the license server in “domain or workgroup mode” onto a server that’s “owned” by that business unit. Then, activate the License Server Security via Group Policy. Once this policy is applied, add the Business Unit’s Terminal Servers into the local License Server Security Group, ensuring that only authorized Terminal Servers can receive Terminal Service CALs. This is also a good way to prevent other de-partments or even rogue Terminal Servers from accessing your license service and using up CALs. Licensing in Mixed Windows 2000 / 2003 Environments If you’re migrating from Windows 2000 or if you’re running a 2000/2003 mixed environment, there are a few licensing issues to consider when planning your design. Preventing TS CAL License Upgrades Since it’s possible for a single Windows 2003-based license server to distribute both Windows 2000 and Windows 2003 TS CALs, you need to give some special thought to environments where both are used. Your Windows 2000 Terminal Servers communicates with your Windows 2003 license server and request licenses from it, and your Windows 2003 license server mimics a Windows 2000 license server. Because Microsoft licenses are backwards-compatible, the Windows 2003 license server can technically issue either a Windows 2000 or 2003 TS CAL for clients wanting to connect to a Windows 2000 Terminal Server. The license server will always try to provide the exact match for the version of the license. But what happens when a client device requires a TS CAL to connect to a Windows 2000 Terminal Server and the license server only had 2003 TS CALs available? Should the license server “waste” a 2003 CAL on the Windows 2000 server, or should it provide a 90-day temporary 2003 license? If the client already had a temporary CAL, should the server “upgrade” it to a 2003 permanent TS CAL, or should it deny the user’s connection? The desired outcome of this situation depends upon your business environment. You can specify which behavior you want your licensing server to follow. This functionality is controlled via the “Prevent License Upgrade” policy (Group Policy| Computer Configuration| Administrative Templates| Windows Components| Terminal Services| Licensing). As the name implies, enabling this policy prohibits a licensing server from ever using a Windows 2003 TS CAL for a Windows 2000 environment. Chapter 6 in out book Terminal Services for Windows Server 2003: Advanced Technical Design Guide explains how policies are used and implemented in Terminal Server environments. Upgrading a Windows 2000 Licensing Server If you have an existing Windows 2000 license server, it’s possible to upgrade it to Windows 2003 while preserving the existing license database. During the upgrade from 2000 to 2003, the license service that was installed will be upgraded and the database content will be migrated into the new license database. After the upgrade to Windows 2003, you’ll need to reactivate your license server, just as if you had installed a new license server. This can be accomplished by using the “Reactivate Server” option from the action menu in the Terminal Services Licensing Manager. Managing your TS Licensing Servers Once your environment grows to become a Terminal Server powerhouse serving thousands of customers with hundreds of servers, you’ll need a few tools to ensure that everything is going according to plan with regards to licensing. Managing Windows 2003 Terminal Services license servers should not take much of your time. There are only a few tasks you’ll need to know about: • Adding new licenses to the license pool. • Administering the license server. • Reporting on license usage. • Troubleshooting client device license acquisition. Adding Licenses to a TS License Server All newly–purchased Terminal Server Client Access Licenses must be installed into a TS license server database. Since Windows Server 2003 also supports Windows 2000 licenses, you can also install your Windows 2000 TS CALs onto a 2003 server. (These licenses cannot be used for Windows 2003 Terminal Servers, but at least you’ll be able to centrally manage all your licenses.) TS CALs are purchased just like any Microsoft license. Traditionally, if you bought a Client Access License pack, that pack only contained a license agreement—nothing more than a piece of paper. Now when you buy a TS CAL license pack, it comes with a 25-character license code. This code must be entered into the TS Licensing Wizard for the TS licensing servers. If you buy licenses through a volume license agreement such as Select or an Enterprise Agreement, then you’ll need to enter that agreement number into the Licensing Wizard when you add the licenses. After the licenses have been installed, you must activate them. Licenses are activated via the same three methods you use to activate the license server (Internet, web, or phone). Once activated, the licenses are ready to be distributed to client devices. Clients that previously received the 90-day temporary licenses will be upgraded to full licenses the next time they connect. In some situations, adding or removing licenses to a license server will cause that server to notify other license servers. • A domain scope license server will notify other license servers within the same domain. • An enterprise scope license server will notify other license servers in its Active Directory site. • An enterprise scope license server will notify other license servers in its domain. In all of these cases, adding or removing licenses to a Windows 2000 or Windows 2003 license server will cause the server to notify the appropriate Windows 2003 license servers as mentioned. A Windows 2003 license server will not notify a Windows 2000 license server. As outlined earlier in this paper, this notification allows the license servers to redirect client requests to other license servers should the first server run out of licenses. Remotely Administering License Servers The TS licensing service is mainly a “set it and forget it” kind of service. Theoretically, it only needs to be administered when new licenses are purchased or old licenses are removed. However, there are times when it would be convenient to administer TS licensing servers remotely. For technical reasons, the TS Licensing Tool cannot be run via a remote Terminal Services session. However, this tool can be executed locally on any Windows 2003 computer and used to connect back to one or more TS license servers. To do this, copy the licmgr.exe and the lrwizdll.dll files from the system32 directory of the TS licensing server to the system32 directory of the computer you would like to use. Run licmgr.exe to use the tool. As was mentioned previously, running the tool in this manner can be helpful when activating TS licensing servers or TS CAL packs. During the activation, the machine running the TS Licensing Tool needs access to the Internet—not the actual license server itself. This method works well in scenarios in which the Terminal Servers are not connected to the Internet but there are certain administrator workstations connected to the Internet and the internal network. Maintaining TS license servers is simple. One TS licensing console can connect to all of the license servers in your environment, facilitating centralized administration. Reporting on License Usage The Terminal Server License Reporting tool, lsreport.exe, from the Windows Server 2003 Resource Kit can be used to view and analyze the data contained within the licensing server database. This tool outputs the information in the database into a tab-delimited format that allows you to create reports of who is using your licenses. Run “lsreport /?” from a command prompt for a list of options. Uncovering Client Device TS CAL Details The Terminal Server Client License Test tool, TSCTST.EXE, is a command-line client-side tool that displays information about a client device’s local TS CAL. Also included in the Windows Server 2003 Resource Kit, it provides the following information about a license: • Issuer • Scope • Issued to computer • Issued to user • License ID • Type and Version • Valid From • Expiration date By using the “/A” switch, the following additional information is displayed: • Server certificate version • Licensed product version • Hardware ID • Client platform ID • Company name This tool is used from the command line of a client device. It’s useful when you need to locate information about the TS CAL certificate that’s stored locally on that device. Application Licensing All this work on the Terminal Server licensing might almost make you forget that you have to properly license your applications as well. While the purpose of this book is to focus on Terminal Server, there are some common threads worth pointing out regarding application licensing. Because there are so many different ways that applications can be licensed, it’s impossible go into specifics here. However, in almost all cases, the application usage license is tied in some way to the number of users or client devices. Most application licenses are not linked to the number of times the application is installed because the application vendors don’t want you to buy one copy of the application for each Terminal Server that you have and then make that application available to hundreds of users per server. Most applications today have licensing agreements that fall into one of two categories: • Per Named User. One license for each user that could execute the application. • Per Concurrent User. One license for each concurrent copy of the application that is executed. Enforcing Named User Application Licenses Applications that are licensed “per named user” require that you have a license for each user that could access the application. If you have 100 users with access to an application but no more than 10 ever connect at the same time, you still need to purchase 100 application licenses. Most Microsoft applications are licensed this way, in addition to many expensive line-of-business applications. The key to properly enforcing per named user application licenses is permitting or preventing users from being able to access the applications. An easy way to do this is to create a domain group with all the user accounts of the users that will need to access the application. Then, add these users to the Remote Desktop users group on the Terminal Server hosting the application so that only members of that domain group can use it. This can also be done by setting NTFS permissions on the executable if users that don’t use this application connect to the same Terminal Server. Another option is to create a Software Restriction Policy to restrict that application to only a certain group of users. This policy could be applied in the Group Policy at the OU level for a large number of Terminal Servers. By restricting access to the application itself, you guarantee that only appropriate users will ever use the application. When it comes time to pay for your application licenses, all you have to do is count the number of users that are in your application group and buy that number of licenses. Enforcing Concurrent User Application Licenses Applications whose licenses are based on the number of concurrent users only require that an application license is purchased for each concurrent connection. If you have 100 users that have access to an application but no more than 10 ever connect at the same time, you only need to purchase 10 licenses. Your company’s accountants will appreciate applications that are based on concurrency. You will probably not appreciate them because they are harder to enforce from a technical standpoint. Within Terminal Server, there are two ways to enforce concurrent users: • Limit the number of connections on the Terminal Server hosting the application. This can be done in the Terminal Server Configuration utility by editing the RDP connection properties. • Create a batch file that writes to a flag file before an application is launched. That batch file can be configured to check the flag file to see how many other instances of the application are running. For environments in which applications are executed across more than one server, the flag file can be stored on a network drive. When users quit the application, the flag file is updated to reflect the user change. The only problem with this (other than the complexity of writing the scripts in the first place) is that the flag file is not updated if users do not exit the application properly. Hardware Dongles in Terminal Server Environments The only additional item worth mentioning about application licensing relates to applications that require a hardware key. If you have an application that requires a hardware key, or “dongle,” it probably won’t work on a Terminal Server. Microsoft has intentionally disabled this functionality because the sole purpose of a hardware key is to prevent multiple users from using an application, and Terminal Services’ sole purpose is to allow multiple users to use an application. If your hardware key vendor did not use the standard Microsoft APIs when writing the application, the hardware key may work on a Terminal Server. If this is the case for your application you must ensure that its use in a Terminal Server environment is acceptable from a licensing standpoint. This message was originally posted by Freddie LArsson on April 7, 2004 Hi. My name is Freddie Larsson, I live in Sweden and my passion is SBC. I'm trying to figure out the license model of 2003 and I have some questions for you. First to show you if I have understood the model right. If I use a 2003 TS without a licensing server I can connect users for 120 days. If I then install a licensing server BUT NOT activating it I can connect users to me TS for 90 days more, the key question is if I now activate the licensing server and connect user even 120 days more? I find your site for a few weeks ago and I have to say you seem to know what you are talking about, and your site is were god, I think i can learn much from you. I have been working whit SBC sense win 2000 and have really find what I want to work whit, tanks for a were god site. I read the book about 2003 terminal services in December, that was also a god source. One last thing, maybe it would take to much time but what if you and us that are reading you site could make a special newsgroup or part of your site were we address specific application issues, for example: configurations, fixes and tricks. What do you think about that? Kind regards Freddie larsson www.sbcomputing.se [email protected] Add My Comment. This message was originally posted by ShackDaddy on April 14, 2004 I have four 5-user 2003 TS-CAL tokens (gotten via legacy transition route). I installed License Server on our solo 2003 server and installed the license paks. The rest of the domain is W2K. The clients were getting 'Can't find license server' errors, so I deactivated the license server and uninstalled it, then reinstalled it and put in that registry fix to look at itself for licenses. When I went to readd the license packs, the Clearinghouse returned the message that those keys were invalid because they were already activated. But they aren't active on my server or anywhere else! Am I supposed to call Microsoft and have them deactivate them, or is there a better way to resolve this issue? Dave Shackelford - Exchange MVP Add My Comment. This message was originally posted by an anonymous visitor on April 21, 2004 Hi Brian, I bought the book you co-authored with Ron Oglesby. I must congratulate you, you did a very good job. My EDP-manager called all sorts of people resellers, vars even Microsoft people, and they did not know!Let along were in the possibility of explaining it! Especially the existens of ECL (External Connector License) is a non-event! A halfhour of reading in your very fine Design Guide explained all! Add My Comment. This message was originally posted by Martin Vliem on August 31, 2004 L.S., I did not find someting about this (from Microsoft 'Terminal Server Licensing.doc'-2003) in your article. Do you know if this is true?.Although it is possible for non-domain controllers to be license servers in Windows Server 2003, it is important to note that domain license servers are not automatically discovered. You must configure a preferred license server on all terminal servers that need to communicate with non-Domain controller license servers configured as domain license servers. Enterprise domain license servers deployed on non-domain controllers are automatically discovered. Best regards, Martin Vliem Capgemini Add My Comment. This message was originally posted by unciatim on October 8, 2004 In a bout of late nite stupidity, I installed regular user CALS for Windows 2003 Small Business Server on the wrong server and now need to remove them from the wrong one and install them in the right one. MS wants to charge me $245 tech support to tell me how to do this after i just spend thousands on multiple OS copies. Kinda pissed. Does anyone know how to unistall them? MS has no problems letting me install them on the new server (according to their licensing dept.), I just need to get them uninstalled first. Any info is much appreciated. Add My Comment. This message was originally posted by an anonymous visitor on October 12, 2004 1. This crap about piracy is a two way street. How much did MS steal from the public in beta testing time for their R&D! How much money did they steal from businesses by selling software that was broken and did not perform as specified? How much money did they steal from EVERYONE by delivering products which were CLEARLY and almost INTENTIONAL left open for exploitation by hackers! How much time and money are they wasting now with this crap making us the police for their stupid software. How much time did they waste by backing SCO to go after the Linux community? Read about Palladium and MS's lust for total control of your PC experience. Look out folks. Who does MS think they are to make it extremely difficult to move your software from one machine to the next? Piracy my butt. I can't tell you the number of Windows 95 licenses WE WERE FORCED TO BUY OR THE VENDOR WOULD NOT SELL US A PC!!!!!!!!!!!!!!!!!!! Anyone who acts like MS is even the slightest bit correct in their approach is simply foolish and gullable. By the way, there is no such word as Gullable. It does not even exist. To those of you just trying to do your job, I understand. To those of you just trying to do your job and you make excuses for MS, get a life and try Linux. Thank you, Upset User who is tired of doing MS's job when it comes to policing their software and managing their mistakes. Add My Comment. This message was originally posted by an anonymous visitor on October 25, 2004 I have 5 servers with 5 CALS each. Can they be added together so that one machine can be in charge of all of them? -- I also have 2 machines with SBS2003 and accidentally chose 'per server licensing'. It also installed Active Directory as well so I ran dcpromo to demote the domain because I already have a Windows2000 Domain Controller. Now none of the licensing works on either of these machines. How can I change this to 'per seat' licensing and get the licensing module to work again? Any help would be appreciated. Thank you Add My Comment. This message was originally posted by Merando on November 4, 2004 Just want to thank you for the excellent work you've done in this paper. You obviously know what you're talking about. I'm just investigating TS right now, spending time in the lab and researching on the net, and your article cleared up a number of questions for me in regards to licensing. Bottom line for the moment is if our apps work in W2K environment, then that's what we'll go with as the clients are all W2K or XP, and there won't be any client TS Cal's to buy. You can be sure that if the project is approved I'm buying your book! Thanks again! Add My Comment. This message was originally posted by an anonymous visitor on December 6, 2004 I have limited experience with Win2K3 TS at this point (soon to change). You have made no metion (that I could find) of Remote Admin mode vs Application Server mode. In Windows 200 TS licensing was only enforced when the server was places in Application Server mode. Leaving the server in Remote Administration mode eliminated the need for a license server, but limited you to 2 concurrent sessions which I believe must be Admin accounts. Licensing is such a pain.add in Citrix and the fun just increases. Very well written article by the way. Microsoft should be so knowledgable about their own product! Add My Comment. Please excuse my ignorance of this subject, but I am confused about Windows 2003 TS Licensing. We are currently in the process replacing an old server with a new server running Windows 2003 Server. The second server in this remote office is a Windows 2000 Server/Terminal Server. We have two servers in our home office-one running Windows 2000 Server and an old one running Windows NT. We are purchasing a 10 user license for Windows 2003 Server. What do I do about Terminal Servers Licenses? The pllan is to migrate all of the applications in our remote office to the new 2003 server. Can we use our current terminal server licenses? Do we need to upgrade the 2000 Server to 2003? Or should we just purchase Terminal Server CALs for the Windoows 2003 server? Thanks very much in advance! -William Block Add My Comment. Hi guys, and Gals. I have a site that has a windows 2000 server (ts license server / domain controller) Also a windows server 2003 (member server / terminal server) I spent some time trying to install windows 2003 ts device cals win 2003 server - failed. Contacted microsoft licensing tech support and was told that in order for me to install licenses, i will have to upgrade windows 2000 server to windows 2003. Does this sound right to any of yous. Is it possible to change license server to AD sites and services to use windows 2003 server as license server, then install ts license. Any feed back will be MUCH APPRICIATED. CHEERS Add My Comment. The reason why big companies don't use Linux is because of the image that little rants like this give the OS. All they can see are a bunch of wild kids who don't document, don't test, and don't give you support when you need it. Granted, that's MS to a tee, but we're talking perception here. I would add to your list 12. For those of you just doing your job and making excuses for Linux, get Solaris. A real unix for real enterprise environments that runs Linux apps native. Add My Comment. I'm no microsoft fan, but hey: 1) agreed 2) all software has some form of bug 3) some versions of unix are have more security holes than windows does, do a little reasearch. Mac os x is no better 4) blame the f*ckers actually writing the code to do it 5) *shrug* 6) agreed 7) if its OEM software, that software can only be used on the machine it was bought with, hence why you get it a lot cheaper than buying the boxed full product. If you have the boxed product, then you can install it on another machine, providing you have removed it from another 8) agree with the vender. 1 license per machine. Apple does the same, but does not enforce it as much as microsoft, if at all. However the license agreement clearly states that you must own 1 licence PER machine 9) get your spelling right. 10) agreed 11) you seem to be making an excuse for yourself, pull your head out your a*se and go by the right way of it. 9 times out of 10, its the user who falls for the tricks that exploit their PC. Add My Comment. I've been working with Microsoft on this for the past few weeks. It appears that this functionality has changed between Windows 2000 and Windows 2003. In Windows 2000, the license server had to be on a domain controller, but that domain controller didn't have to be in the same domain (or trusted domain) as the Terminal Servers. In Windows 2003, the license server can be installed onto a member server or domain controller, but it must be in the same trust path (same domain, or trusted domain, or trusted forest) as the Terminal Server. Brian Add My Comment. Firstly, great article. One quick question to ask. When setting up a Windows 2003 terminal server (say for 5) do I need (option 1) CDROM software for BOTH * MS Windows 2003 Server (standard edition) which includes 5 CAL and * MS Windows 2003 Terminal Server software which includes 5 CAL OR (option 2) CDROM software for ONLY * MS Windows 2003 Server (standard edition) which includes 5 CAL and only the license (no software required) for * MS Windows 2003 Terminal Server which includes 5 CAL OR is it a different combination from the above. Please advise as everyone I talk to is giving me a different answer. Thanks in advance for your help. TW Add My Comment. Thanks for the feedback. Now I have two other questions; 1. Could the terminal server have less license than the windows 2003 server connection license OR should they be the same? In other words, if I have 8 users and only 3 will have access to the terminal server, could I just purchase 5 terminal server license or do I need to purchase 10 (in this case, I will be purchasing 10 windows connection licenses CAL)? If I only need the license for the 'terminal server' (since its included with Windows 2003 server), when will someone need the 'software' version of the 'terminal server'. What is the benefit of having software version? Are the two basically the same in terms of functionality? Thanks in advance again for your help. TW Add My Comment. 20 Users connect to a TS. Is there a way to restrict the Drive Mapping, LPT Mapping or Clipboard Mapping for 10 of them and allow for the rest of them. I mean can we do it on user basis.(It doesn't work by configuring user Properties in Active Directory Users and Comuters, at least in my case). Secondly and preferably is it possible by using Group Policy? Remember we are talking only about users and not the computers. So the restriction should be on the users in the group policy so that those 10 users shouldn't be able to use Drive, LPT or Clipboard Mapping. Right now I have disabled it from Terminal Services Configuration. Which disables it for all the users including the Administrator:( Thanx in advance. Add My Comment. Firstly I would like to congratulate Madden & Oglesby on the excellent Terminal Services book. Its a relief to come across a book that is written from an architects perspective. The licensing section in particular clears up a very murky area, but I am still a little perplexed by the licensing of applications and the enforcement of application licenses. The book highlights typical application licensing modes, named and concurrent basis. It suggests that most Microsoft applications are licensed on a named basis and suggests that an acceptable way forward would be restrict access to applications my group membership. Whilst there is an implication that the likes of Office, Project & Visio could be addressed in this way, some further guidance would be appreciated. Has anyone had a statement from Microsoft on this matter? In our environment, we have an Enterprise Agreement for Office, but Project & Visio are licensed on an as needed basis. Would be accceptable to Microsoft the access to Project & Vision was be group membership? Add My Comment. Hi everybody, as a nice guy said before I basically had the problem that I just needed two connections maximum for administering the server. Went to 'terminal services configuration' (not server terminal server licensing) and changed setting from 'per device' ---> to 'per user'. Now not anymore annoyng warnings about licensing days left of whatever. By the way I think Ms did not a great job with all this licensing craziness stuff about managing a server I OWN. Nice site and nice fellows here by the way, I'll be back for sure. Add My Comment. ORIGINAL: Guest This message was originally posted by ShackDaddy on April 14, 2004 I have four 5-user 2003 TS-CAL tokens (gotten via legacy transition route). I installed License Server on our solo 2003 server and installed the license paks. The rest of the domain is W2K. The clients were getting 'Can't find license server' errors, so I deactivated the license server and uninstalled it, then reinstalled it and put in that registry fix to look at itself for licenses. When I went to readd the license packs, the Clearinghouse returned the message that those keys were invalid because they were already activated. But they aren't active on my server or anywhere else! Am I supposed to call Microsoft and have them deactivate them, or is there a better way to resolve this issue? Dave Shackelford - Exchange MVP Got the same problem here, does it work now? Otherwise I have to find out what to fix then. Could you give me some info? Add My Comment. I have some trouble with activating my license server for a second time. I have 1 license key with 5 TS CAL's. It has been used for a former installation on the same server. I have 1 Server which is Domain Controller too which is running Terminal Server License manager. A second server(evaluation version) is running Terminal Server. Both 2003 Servers The first problem is: When I go to my Terminal Server License Manager and I reinstall it completely in Contol Panel; Add/Remove Windows Components. After the reinstall I do a reboot. I can activate my server from there untill i insert the key. When the key is accepted it says Terminal Server key already activated. Only when I open Terminal Server to check the licenses, it only says the Terminal Server 2000 Automatic Licenses and no 2003 Licenses which allready should be activated. I read something about calling Clearinghouse but I'd rather not call Microsoft before i'm sure to do it. I don't want a call to be made, which could cost lot's of money. A second problem is: When using terminal Server inside the building it's all working fine with the automatic licenses. Only when I try to connect to the Terminal Server from outside with a wireless connection on a router with Internet, I get a black screen and it's not working then. The server is reachable from there only the Term. Doesn't work. There is SonicWall installed. Could somebody give some advice about this, cause it getting kinda annoying now. Thanx, Add My Comment. If fixed this after calling ClearingHouse, so the first problem is not necessary anymore. One other thing occurs though. Now when I log in through Terminal Server connection, it still keeps sending Automatic licenses, so I wondered. How can I fix it so it will accept a official license 2003, and not the automatic's who will stop after 120-day. Do you need to do this by yourself or does it changes itself (so it wil accept the officials after the 120 days) If allready changed some registry settings on my Terminal Server see Article ID: 279561 on the site. But it's still not functioning right. Does anybody have a clue? Thnx, Jack Add My Comment. Hi, Read your entire paper with great interest - learned much - congrats on making a rather complex topic much clearer. Wondering if you might confirm my understanding regarding implications of a WAN outage & loss of access to our sole off-site/centralized Licensing Server. We currently have an AD envirnoment with mixed win2k and win2k3 terminal servers at multiple WAN-connected sites, hosting apps, with a single centralized Licensing server. These servers have all been in place for 6 months or more, so no 'temporary' licensing issues/options apply here. Recently, we tested the impact of a WAN outage (which only affects access to the off-site/centralized licensing server, the app/terminal servers are on-site) and were disappointed to learn that no users could access any applications because the single centralized licensing server could not provide/confirm any TS CALs to any remote site terminal servers and/or clients/users. It appears our only option (to make app access at each site WAN-outage-proof) is to install at least one secondary/backup license server at each and every site. Given that this approach represents a significant amount of work (not just a simple install of the licensing service, but we must also configure, manage, etc.), I'm wondering if you agree, or perhaps can suggest a better strategy? Thanks, and keep up the good work! Sorry about the anonymous response, but I've been burned/spammed before at other sites when using my real/identifiable account. Add My Comment. Somehow when I installed a 2003 TS server and a 2003 PDC (TS licensing on PDC), the TS Server gave out temp per device licenses. I bought 50 per user licenses and installed & activated on the license server (PDC). But now I have like 60 temp per device licenses, 45 running out soon. (I am going to get 50 more as I have like 95 users). How do I transfer the 1st batch of users from per device CALs to the activated per user CALs? It states that I have 50 available and 'NA' issued for per user CAL. Add My Comment. Hi, In the licesnse server discovery flow (in case of Active Directory), you have mentioned following four steps: Discovery in Active Directory Environments When a Terminal Server is a member of an Active Directory domain, the license server discovery process is entirely different. First, the Terminal Server attempts to contact the license server (or servers) specified in its LicenseServers registry key. If a license server is discovered at any point through this process, the remainder of the discovery process is aborted. If that attempt fails, the server next looks for an enterprise scope licensing server by performing an LDAP query for the following object in its Active Directory site: LDAP://CN=TS-Enterprise-License-Server,CN=, CN=sites,CN=configuration,DC=,DC=com If that attempt also fails, the Terminal Server begins querying every domain controller in the site, looking for 'enterprise scope' licensing servers. If the Terminal Server still has not found a license server, it will query every other domain controller (outside of its site) to see if any are configured as a domain scope license server. I think there is a correction that is required in the step 3. The terminal server will query the domain controller in the site for 'domain' scope license server and not the 'enterprise' scope ones. Otherwise, it will not be possible to discover the license server which is in the same domain as terminal server and installed on DC (please note that step 4 will check for the LS in the other DC and not in the host DC). Please update. Add My Comment. ORIGINAL: Guest This message was originally posted by ShackDaddy on April 14, 2004 I have four 5-user 2003 TS-CAL tokens (gotten via legacy transition route). I installed License Server on our solo 2003 server and installed the license paks. The rest of the domain is W2K. The clients were getting 'Can't find license server' errors, so I deactivated the license server and uninstalled it, then reinstalled it and put in that registry fix to look at itself for licenses. When I went to readd the license packs, the Clearinghouse returned the message that those keys were invalid because they were already activated. But they aren't active on my server or anywhere else! Am I supposed to call Microsoft and have them deactivate them, or is there a better way to resolve this issue? Dave Shackelford - Exchange MVP Add My Comment. Point #7 cracks me up. When Windows 95 came out, MS wasn't where they are now. No one forced the PC vendors to sign the deals they did with Microsoft. OS2/Warp was a viable competitor but even IBM didn't sell Warp like they sold Windows. Did MS seriously push IBM into selling Windows 95? MS didn't make themselves a monopoly, the greedy PC vendors who signed those agreements made MS a monopoly. MS was handed a monopoly on a silver platter by the pc vendors and IBM's misteps. Add My Comment. We have a 2000 Server running with Terminal server. The clients use terminal server to access a DB app and we have about 10-12 people using this all the time. The server was activated and worked fine until there was a problem with the OS. The Server was re-installed and since that time the terminal server cannot be activated. But, most users are able to connect and not have a problem, there are however two people who always are getting 'Temporary License' and you have to make a registry change to renew the license. Most of the users are not listed as having a license at all but are able to connect without a problem. Any help or ideas? The info on this seems vague at best! Add My Comment. Hi, we are in a very small environment and we have a Windows 2000 Advanced Server (acting as File/Print server) in a workgroup environment (i.e. No Windows domain, PDC, BDC, Active Directory). Current Licence is: Per Server with 5 concurrent connections. Currently we are running 3 PCs with Win98 and 1 with Win2000. I like the idea of windows 2000 Advanced Server on a new server and 5 Thin-Clients, or the PC's we have at the moment. What is the best way (Licence wise) to go? Thanks, Yiannis Add My Comment. I 'think' I have it, but am hoping for something in black and white (and maybe pictures and point and click would be helpful). I have a client with 20 TSCals, they have about 10 Systems, and 10 Terminals. Systems are starting to die one by one, and they want to replace them with thin clients mostly, but maybe some notebooks. They have used all the cals, and do not seem to have any temps available (its been about a year now) How can I get the Cals' out of the 'device' and back into the pool, and. What about systems that have been removed and reformatted? (this has happend to one.) Thanks, Add My Comment. Ok, so i came accross a setup that worked fine with 2000 but need a guide as far as 2003 goes. If I use RDP for administrative purposes i dont need TS to do that (right?) and i can only have 1 RDC active at a time. (?) we have 12 users that RDC to the Win2003 server to access a Database application. They all use the same UID and Pass to connect via RDC and it starts the database program. We moved the database from a 2000 server to the 2003 server and the TS is configured to 'per user' and 'allow multiple sessions'. Since we only have 1 'user' log in do we still need to get the TS CALs? The TS lists, for example, 6 session active and every session is activated by 'DBUser'. Because RDC on its own does not allow for multiple sessions we have to use TS. Do the TS Cals apply even just for that one 'user'. We have to use DBUser account so that the 12 users can access the database, if we use their useraccounts the database fails (ideally they should switch out the DB program, but with all the data and training involved it not feasable at this time). Thank you Add My Comment. ORIGINAL: Guest If I use RDP for administrative purposes i dont need TS to do that (right?) and i can only have 1 RDC active at a time. (?) Yes you need Terminal Services. No, you do not need TS Application Mode and you do not need CALs for this. You can actually get two RDC into the server for Remote Admin purposes. ORIGINAL: Guest we have 12 users that RDC to the Win2003 server to access a Database application. They all use the same UID and Pass to connect via RDC and it starts the database program. So you were doing this in Remote Admin mode with only a single user concurrency? ORIGINAL: Guest We moved the database from a 2000 server to the 2003 server and the TS is configured to 'per user' and 'allow multiple sessions'. Since we only have 1 'user' log in do we still need to get the TS CALs? The TS lists, for example, 6 session active and every session is activated by 'DBUser'. Because RDC on its own does not allow for multiple sessions we have to use TS. Do the TS Cals apply even just for that one 'user'. Yes, you need TS CALs in this case. Microsoft's licensing doesn't allow multiple physical users to share a CAL even in the event that they have the same virtual user name. If this was the case, I'd expect that just about everyone in the world would be using the same scheme that you're trying to do. Shawn Add My Comment. I was reading on the MS site that 2003 Small Business Server shouldn't run Terminal Server. They said that you should run the Terminal Server on another 2003 Server, but that the SBS CALs could be used for the CALs. This is confusing in relation to the 2003 Server CALs and the Terminal Server CALs. We are looking at having 1 SBS Premium 2003 Server with 10 CALs, another 2003 Server running 5 User Citrix Metaframe, and 1 or 2 additional 2000 servers running SQL Servers (7/2k with SBS server running SQL 2K5 when R2 upgrade comes out). With SBS, do I need to purchase server CALs for each server or does the SBS CAL cover other servers in the domain. Again, it was confusing on MS site. (To maintain compatibility with client setups, we have to have a mix of Server OS/SQL Server versions) One option we have is to keep the Citrix on a 2000 server as all users are running XP PRO and this would not require new 2k3 CALs. Is there any specific reason that we should go with 2k3 on the Citrix Metaframe system? Thank you for any guidance on this confusing issue. Add My Comment. I'm attempting to determine why new users added to an NT 4.0 domain are not found in the domain user list after they are added to the domain. They are viewable across the WAN from another domain but the Terminal Server which is in the same domain as the PDC is unable view the entire domain users list. Users added just a few days ago can be found. Event Type: Error Event Source: Winlogon Event Category: None Event ID: 1219 Date: 6/2/2006 Time: 1:10:36 PM User: N/A Computer: TS100 Description: Logon rejected for MYDOMAIN Davis_M. Unable to obtain Terminal Server User Configuration. Error: Access is denied. Add My Comment. Gone through the pain of our TSL server dying on us (no backup). All the other servers are still looking for the dead server prior to looking for the new TSL we had setup and registered. If you start up TSL on the new License server it still looks firstly at the old dead server before settling on itself. Is there any way of removing the TSL lookup to the old box due to is causing login pauses through Citrix ICA client? Perhaps a registry change or something, there seems to be very little info about this problem, maybe because people have a backup. Add My Comment. I have a Windows 2003 Terminal Server in a thin client environment using per device licensing. In August, I changed to a VMware tftp server. When I initially added my clients, they grabbed default numbered names like 809-23 so I went into the VMware management tool and renamed them to logical names like 809-BusnMgr. Unfortunately, those numbered clients each took a TS CAL and then when I renamed them they took another TS CAL, so I have run out of CALS (I had 100) and it doesn't want to issue anymore temporary ones (it has issued 34 already). Is there anyway I can force it to give up those TS CALS and return them to the pool? I don't want to wait until November for this to clear itself up. Any help would be appreciated. Add My Comment. ORIGINAL: Michael Burke Terminal Services shouldn't be installed at all for remote administration on a W2K3 box. You use Remote Desktop in that case and can remove Terminal Services from Add/Remove Programs. Are there any bad side effects to the installed applications when you remove Terminal Services? I just need Remote Desktop for administration but have heard rumblings that removing Terminal Services will break the already installed applications. Is there reason to be concerned? Add My Comment. We upgraded our DC to Windows 2003. After 90 days, citrix connections stopped. I am told that we have to buy TS CALs for Windows 2003. We did not need them earlier as DC/terminal servers were on Win2K and all clients are Windows XP and I assume the built-in CALS sufficed. We need to use the Citrix environment for 6-8 months more only. Can we retain the Terminal Server on Windows 2000, still join the domain with the DC on Win 2003 and keep using Citrix? What could be the issues? What do we lose? Thanks in advance Add My Comment. A real Unix feeding another company hell bent on control of the market (it's all about money Chief.). Linux, Solaris, All flavours of BSD and even, hang me if you must, Windows; it doesn't matter. It is what you make of them that counts. I can build a Linux Server that is as effective and useful as a Solaris. It all depends on what you are using it fore and how creative you are with it. Even Windows can be made to work if you are savvy enough. Besides, Al of us techies would be out of a job without faults and bugs. Add My Comment. Brian, Your article was a great help. It confirmed the information that is stated (although not very clearly) in the MS TS Licensing document that per-user TS CALs are not allocated (Server 2003), tracked, counted, etc. It is easier for me to just track my licenses using a spreadsheet, and true up when I need to. What really kills me, is that when I had talked to the TS Clearinghouse, they inadvertently added licenses to my TS Licensing server by reactivating my existing licenses (they also did this once with the integrator that set the system up). So now I have activated 10 purchased CALs, but the licensing server shows 20. Knowing that per-user CALs are not tracked, I will stop screwing around trying to fix MS's licensing issues (I went through three people and was told that tech support would charge me for an incident to remove the extra licenses, a problem that they caused!) and just continue on my merry way tracking my own license usage as I usually do. This is a great in depth article that has obviously helped many people. Microsoft should be compensating you!:>) I have bookmarked your site now as a reference. Glen Martin PS Get a 'Null' popup box when I try to submit a new post, so I will try this as a reply to another post. Add My Comment. Hello, I have a terminal server environment in which a lot of employees are working on a small amount of sattelite workstations. Since I only have 6 of those workstations, and 50 employees using them, I chose to employ per/devic e-licensing. However, because people are used to work on the terminal server, they also connect to it from their own workstations when they're in the office. The terminal server simply issues licenses to those workstations, and as a result, I run out of TSCAL's in a flash. Therefore I'm lookgin for a way to control to what client devices the terminal server will issue a TSCAL (for example based on computer name). Is that possible? Thanks in advance -- Rien Broekstra Add My Comment. I have a W2K domain enviroment, one of my DC's has the TS Licensing running, but I have several W2K3 servers. Can I remove the TS Licensing from the W2K DC and choose one of the W2K3 Server and install the Licensing Server. I have mixed licenses, in this cenario, it will work? Because a have one problem, whem I try to connect to any W2K3 server, the TS session tells me that could not find the Licensing Server. I have tried many troubleshoot steps, edit registry and others, but doesnt work. Add My Comment. So I have mobile Windows Embedded SP2 on WYSE 941G thin client and I'm having a issue on a few of the thin clients. We roll out our base image to the thin client using Rapport server. (At this point the image does not have HKLM Software Microsoft MSLicensing Store License00x key) We run New Sid name the client install Citrix PNAgent, test the connection to the Citrix farm by opening a App and then enable the file based write filter. Like I said the problem I'm having on a few clients is that for some reason they will grab a new license using the same name. I look on my license server and will see the same client XXX grab a license on Tuesday and the same XXX on Thursday. They are not being rebuil or re-image they are just out on the floors being used. Has anyone seen this? I seem to think it's the write filter blowing away the key after a reboot and when it connects to the terminal Server again it think it's a new device and ask for another license, but I can't prove it. I went to the other 20 I have out so far and rebooted them many times with the write filter enable, but can't recreat the issue. I would hope that WYSE/Microsoft are smart enough when creating the Write Filter to ignore that regestry key, but who know. I opened at case with WYSE, but they closed my case and said resolved, but nevey answered me. ANY HELP WOULD BE MUCH APPRECIATED!!! Add My Comment. If I purchase Office 2007 through the Home Use Program would I be able to use it legally when connecting to my company through a Citrix connection that allows me access to either a specific Microsoft Office application or SharePoint or JDE which both require using Office without having to secure another full license of Office2003? I am wondering if the rights provided by Office 2007 would be equivalent to a valid Microsoft license # or certification # for MS Office 2003 Professional residing on my personal laptop or desktop. Would the license provided under the Home Use Program allow me to access Office applications through Citrix or would I have to buy a new Office2003 license as well in order to use Office applications through Citrix when I am connecting from home? Add My Comment. I have some problem im new on our compny. And one of my task is to monitor and check terminal service licenses and i was inform that they have 50 device cals installed but when i check the license server manager it has 3 groups 2 volume license and 1 retail license and on each group they have 25 Device cals each all in all they have 75 Device CALs running. They are not aware why it has 75 all they know is that they only have 50. Now they want to add 36 from their exisiting 50 device CALs. They are asking to remove the 25 retail device CALs before adding the new 36 CALs. Is this possible that they might be using more than the license CALs? Is it possible aswell to remove the 25 CALs? Please help with your great minds. Thanks in advance. Add My Comment. Please help, i already install CAL per Device Remote Desktop OLP in windows server 2003.The count down about 2 month since i activate those CAL via web. My worried is after end date. There are 4 product in terminal server licensing: 1. Exiting Windows 200 Server>Type Built-in>Total Unlimited>Available Unlimited>issue 0 2. Temporary Licenses for Windows Server 2003-Terminal Server Per Device CAL Token>type temporary. 3.Windows Server 2003 - Terminal Server Per Device CAL Token>type open>total 3> available 3>issued 0 4.Windows Server 2003 - Terminal Server Per Device CAL Token>type open>total 3> available 0>issued 3 Product number 4 is i try to reactivate per Device CAL OLP with same as the first activate Licensing ID and Authorization number. Question: 1.My question is why appear expired date in Terminal service license. Can device logon normally or can't not log on to the server. How to remove product number 4 at Terminal Server Licensing? How to remove expired date for Terminal Server per Device? Please advice ASAP. Add My Comment. Attention, Internet Explorer User Announcement: Jive has discontinued support for Internet Explorer 7 and below. In order to provide the best platform for continued innovation, Jive no longer supports Internet Explorer 7. Jive will not function with this version of Internet Explorer. Please consider upgrading to a more recent version of Internet Explorer, or trying another browser such as Firefox, Safari, or Google Chrome. (Please remember to honor your company's IT policies before installing new software!) • • • •.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
March 2018
Categories |