If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article.
If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix. Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:.
If you do not see your language, it is because a hotfix is not available for that language. For more information about how to obtain a Windows Server service pack, click the following article number to view the article in the Microsoft Knowledge Base:.
The English United States version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time DST bias. Additionally, the dates and the times may change when you perform certain operations on the files. In addition to the files that are listed in these tables, this hotfix also installs an associated security catalog file KB Important Windows Vista hotfixes and Windows Server hotfixes are included in the same packages.
However, only "Windows Vista" is listed on the Hotfix Request page. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under "Windows Vista" on the page.
Always refer to the "Applies To" section in articles to determine the actual operating system that each hotfix applies to. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature. From within his session, he'll see his client device's printers listed within the application's printing interface. To the user, these printers look like regular printers. The user has no idea that these printers are actually mapped back to his local printers through the RDP protocol.
When the user prints to one of his client printers, the process outlined in Figure 8. Upon looking at the client printing process in Figure 8. The raw print job is usually quite large, and it can take a long time to transmit to the client's printer, especially if the user is connected via a dial-up line.
Additionally, the performance of the RDP session can be degraded because bandwidth is being consumed by the print job that is being sent to the client.
Now consider what happens when printing to a client network printer. Remember that a client network printer is a network printer that was mapped from the user's client workstation before their session with the Terminal Server was started. Conceptually, this process is similar to printing to a locally-attached client printer.
However, since this is a network printer, the client must take the additional step of sending the print job to the network print server once it's received from the Terminal Server.
At first glance you might wonder why Terminal Server is not smart enough to print directly to the network print server. It would seem that doing so would alleviate the need for the EMF file to travel down from the server to the client and back. Unfortunately, in reality, this is not feasible. For example, there can be situations where the print server from Figure 8.
Regardless of the specifics of a situation, the folks at Microsoft who designed Windows knew that they couldn't guarantee that Terminal Server had access to the print server. Therefore, they had to take the lowest common denominator and send the print jobs down to the client, even if that meant that in some cases the client turned around and sent the print jobs right back up to the server.
Of course an easy way to combat this potential inefficiency would be to simply map the network printer from within the user's Terminal Server session, thereby allowing the server to send the print job directly to the network print server. Sound familiar? It should, because this would be the exact description of a server printer as outlined back in Figure 8. Another way to combat this inefficiency would be to use a third-party printing product, as discussed later in this chapter.
In addition to the performance issues, there's one more potential downside to using client printers. As you saw in Figures 8. Because of this, the server needs to have the necessary drivers installed for the client's printer so that it can create the print job. After all, it's the server that will be creating print jobs from user sessions, not the client device. If you're lucky enough to have an environment in which your users have only a few different types of printers, then this might not be a problem.
However, if you have hundreds of users with hundreds of different printers, installing and configuring printer drivers on your Terminal Servers can be a nightmare. We'll study the use and management of printer drivers on Terminal Servers a bit later in this chapter. Another downside to using client printers in Terminal Server environments is that in order for a user to be able to use a printer, it must by definition be installed and configured locally on their client device.
If your users have a lot of printers already configured on their workstations, then this might be okay. However, this could also be the exact opposite of what you're trying to do by using Terminal Server.
Most likely, you want to move away from having to configure things on individual users' workstations. If a user installs, deletes, or otherwise modifies their local workstation printers not your problem , it will affect how they print from their Terminal Server session definitely your problem. By definition, client printers are already set up and configured on the client devices, so there is nothing else that you need to do there. All client printer mapping configuration is done on your Terminal Servers.
From a high level, allowing users to print to their client printers involves two steps:. Since client printers will only work when the printer drivers are installed on the Terminal Server, the first thing you need to do when using client printers is make sure that the proper drivers are installed on your server.
In the real world, there are many issues associated with the installation and management of printer drivers on Terminal Servers. We'll look at the specific details in the "Managing Printer Drivers" section of this chapter. After the printer drivers are installed, you need to configure your Terminal Server to connect clients' printers when their RDP sessions are started. To do this, you'll have to configure Terminal Server permissions, the RDP connection listener, and the user's domain account properties.
Even though these are not the default settings for Windows Server "out of the box," these settings have been a Terminal Services best practice since the beginning of Terminal Services. In the "client settings" tab section of the connection properties, make sure that the "Windows printer mapping" and "LPT port mapping" boxes are not checked in the "Disable the following" section.
Obviously, checking either one of these boxes will prevent client printers from being mapped. Also, if the "Use connection settings from user settings" option is checked, then you will need to verify that the user's account is properly configured for client printer mapping. See Chapter 6 for more information about GPOs.
These client printer mapping properties can be found within a GPO via the following path:. Step 2C: Configure User Account Settings You can also configure client printer connection settings on a user-by-user basis.
Selecting "Connect Client Printers at Logon" will cause the user's client printer to automatically be created when they log onto a Terminal Server. When the user logs off and all his print jobs have printed, the printer is automatically deleted. If you do not set the "Connect Client Printers at Logon" option, a user will still be able to manually map to his client printer, it just will not be created for him automatically.
Remember that your Terminal Server must have the proper printer drivers installed for users to be able to print to their client printers since the print jobs are rendered and spooled on the server. At first glance, this doesn't seem like it would be too much of a problem.
However, there can be complications. For example, how does a Terminal Server know if it has the proper driver installed for a user's client printers? When a user with client printer mapping enabled starts a Terminal Server session, the server checks the driver names of the printers install on the user's client device.
It then looks at all the names of the drivers that are installed on the server. If the two names are the same, the server knows that it has the appropriate drivers installed to support that printer and the printer is automatically mapped for that user's session. However, if there's not an exact match, then that printer is skipped and the Terminal Server moves on to the next client printer.
For example, if the Terminal server has a driver installed called "HP OfficeJet 40xi" and the RDP client has a printer installed that uses a driver called "HP OfficeJet 40xi," the server will know that there's a match. However, if the client has a printer that uses a driver called "HP DeskJet ," then obviously the server knows that there is not a match.
Since all these platforms use the same printer drivers, the names of the drivers are guaranteed to match. However, this leads to an interesting situation if your client devices are running anything prior to Windows , including ME, 98, 95, or NT. The problem arises from the fact that the same printer driver written for two different versions of Windows doesn't necessarily use the exact same printer driver names.
In the situation of a client connecting from Windows 98 with an HP LaserJet 5P printer attached, the server would not map that printer—even if it had the proper drivers installed—since the print drivers' names didn't match.
To address this, it's possible for you to correlate the names of printer drivers on your server with the names of printer drivers on your users' clients. In order to enable printer driver mapping, you need to place a file on your Terminal Server that contains the pairs of client and server driver names. In previous versions of Terminal Server, this was done via a mapping file called "wtsuprn. However, this file does not exist by default in Windows Server , and Windows does not look for it.
Data: Name of the. INF file that contains printer driver name mappings. Data: Name of the section in the. The cool thing about using the rundll32 method is that it can even be done from remote machines.
Here are some examples of how to use the command line to remove a local driver and a driver from a remote server.
Make sure to replace Computername with the name of the server you are removing the driver from. If all else fails which unfortunately still happens, even with Windows , you can manually remove a printer driver and all traces of its existence by following this procedure:. Occasionally you will need to figure out which drivers a printer uses that you haven't installed yet. This is especially handy if you allow your Terminal Server to automatically install any needed printer drivers.
Every Windows and Windows server has a "master list" of default printers that it supports and the drivers that each printer needs. You can open this file in a text editor to see which drivers each printer will request. One of the printing-related challenges that you'll face as an administrator of a multiple server environment is that each Terminal Server maintains its own list of configured printers and locally installed print drivers.
Each Terminal Server is completely unaware of the printer configuration and installed drivers of the other Terminal Servers. Further complicating this is that as an administrator, you'll have no idea whether a printer driver has been updated or installed unless you view each server and driver individually.
In addition to this, server printers and their configurations are stored locally on each server and must be added, removed, or modified on every server to maintain a consistent environment. This leads to a management nightmare in environments with hundreds different client printers. In a load-balanced or clustered server environment, each server must be configured identically. This means that drivers, printers, and printer configurations should match on all servers in the cluster.
Doing this manually in a server cluster of 5 servers with printers would be extremely time consuming. Now imagine those same printers in a or server cluster, and you'll quickly realize that you need a better way to manage drivers. There are really only a couple of ways to get both the Windows print drivers and the server printers you have created on a Terminal Server to other servers:. Print Migrator is a tool from Microsoft that can be used to replicate printer drivers between servers.
Since Microsoft is always changing things on their website, the easiest way to find this tool is to do a search on Microsoft. Printer Migrator allows you to back up printers, print queues, ports, printer drivers, and printer shares to a.
You can then restore the settings of that. You can even use this tool to migrate printers between different versions of Terminal Server. The other option for replicating printer drivers is to do it manually. You must manually install or copy all of the needed printer drivers onto each of your Terminal servers.
0コメント