The first task is to create a simple logon script that will map printers based on a user’s group membership. The following code sample demonstrates how such a script could be created using Visual Basic Scripting (VBScript).

The logic for this script is straightforward. A global user group called PRN Accounting has been created in the active directory, and any users who should map to this printer are assigned to that group. The script looks to see if the user belongs to this group, and if so, the printer connection is established and set as the default. When a user is mapping the drive, a pop-up message briefly appears saying the drive is being mapped. This message closes either when OK is clicked or automatically after being displayed for three (3) seconds. I like to include this message not only as a visual confirmation to the user that the proper printer mapping is being initiated but also as a troubleshooting tool for an administrator if printer mapping issues arise.

'**********************************************************************
**
'* ConnectPrinters.vbs
*
'*
*
'* Connects the user's printers based on their group membership.
*
'* Printers are assigned by the particular group's business function.
*
'* For example, the accountants belong to the group "PRN Accounting".
*
***********************************************************************
**
option explicit

'Define the printer groups that are being evaluated
'We use constants so that the code doesn't have to change if
'the printer name changes.
Const PRN_Accounting = "cn=PRN Accounting"

'Define the variables that will be used for mapping
dim wshNetwork, ADSysInfo, oCurrentUser
dim sPrinterPath, sPrinterDriver, sGroups
dim wshSysEnv, wshShell

'Initialize the variables and retrieve the necessary information
Set wshShell = CreateObject("WScript.Shell")

'system environment information
set wshSysEnv = wshShell.Environment("PROCESS")
Set WshNetwork = CreateObject("WScript.Network")
Set ADSysInfo = CreateObject("ADSystemInfo")

'retrieve the user's account information
Set oCurrentUser = GetObject("LDAP://" + ADSysInfo.UserName)
sGroups = LCase(Join(oCurrentUser.MemberOf))

'verify the user's domain group membership and map printers
If InStr(sGroups, LCase(PRN_Accounting)) Then
    wshShell.Popup "Mapping Accounting printer...", 3, "Mapping
Printer", 64
    wshNetwork.AddWindowsPrinterConnection "\PRNServer01Accounting"
    wshNetWork.SetDefaultPrinter "\PRNServer01Accounting"
End If

Once you have a simple script created, the next step is to define what logon script will be used and under what circumstances it will execute. Logon scripts can be initiated either through a group policy or from within the user’s domain account on the Profile tab, as show in Figure 17.8. The entry in the user’s profile is executed under all circumstances, whether the user is logging on to a desktop PC or a Terminal Server. If you wish to use the same logon script for all desktop environments, it can be defined here. If you prefer to configure logon scripts that apply only from within the Terminal Server environment, the script should be configured to start within a group policy defined for Terminal Servers only.

Figure 17.8. The logon script setting defined for specific user accounts.

In this example I use a logon script defined within the group policy called All Users Policy, as defined in Chapter 15, “Group Policy Configuration.” This policy is applied to all users who log on to a Terminal Server that is a member of the Terminal Servers organizational unit. The specific policy to modify is located under

By double-clicking the Logon entry, you open a dialog box where you can list the logon scripts that will execute (see Figure 17.9). If multiple scripts are listed, they are processed in order from top to bottom. In order for Windows to process the desired logon script(s) during a user’s logon, the script must be saved into the specific Scripts folder for the policy. You can quickly access this folder by clicking the Show Files button located on the lower left-hand side of the Logon Properties dialog box shown in Figure 17.9. This opens a Windows Explorer screen pointing into the proper script folder. The logon script you created earlier can now be copied into this folder.

Figure 17.9. Logon scripts can also be defined in a group policy object.

Once all the desired scripts have been copied into this folder, close the dialog box and then click Add from the main Logon Properties screen. The Add a Script dialog box opens, and you can then click Browse to be taken into the Scripts folder where you can select the logon scripts to add to the policy. Once added, the scripts appear in the script list, and once the Logon Properties dialog box is closed by clicking OK, the scripts are configured and ready to execute.

You can now test out the script processing by logging on to your Terminal Server using a user account configured to process the corresponding group policy. If you used the same policy configuration as the one I discussed in Chapter 15, any Terminal Server user will process this logon script. If everything is configured properly, the desired network printers should automatically be connected and ready for use.

Besides using the traditional method of printer assignment based on membership in one or more domain user groups, one alternative is to designate printer assignments based on the client device’s name. During logon, information such as the client name can be accessed directly from the environment variables, such as CLIENTNAME variable. Listing 17.2 shows an example of the environment variables listed when running the SET command from a Windows Server 2003 command prompt.

C:Documents and Settingsadministrator.NRTESTDOM>set
CLIENTNAME=GLENROTHES
ClusterLog=C:WINNTClustercluster.log
CommonProgramFiles=C:Program FilesCommon Files
COMPUTERNAME=OBAN
ComSpec=C:WINNTsystem32cmd.exe
HOMEDRIVE=C:
HOMEPATH=Documents and Settingsadministrator.NRTESTDOM
LOGONSERVER=\LAGAVULAN
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Path=C:WINNTsystem32;C:WINNT;C:WINNTsystem32WBEM; C:Program
FilesCitrixSystem32CitrixIMA; C:Program FilesCitrixSystem32
CitrixIMASubsystems;C:WINNTSystem32CitrixIMA;C:Program
FilesCitrixsystem32
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 8 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0803
ProgramFiles=C:Program Files
PROMPT=$P$G
SESSIONNAME=RDP-Tcp#8
SystemDrive=C:
SystemRoot=C:WINNT
TCP_NODELAY=1
TEMP=C:DOCUME~1ADMINI~1.NRTLOCALS~1Temp3
TMP=C:DOCUME~1ADMINI~1.NRTLOCALS~1Temp3
USERDNSDOMAIN=NRTESTDOM.COM
USERDOMAIN=NRTESTDOM
USERNAME=Administrator
USERPROFILE=C:Documents and Settingsadministrator.NRTESTDOM
windir=C:WINNT

Depending on how the client machines are named, you may be able to modify your logon scripts to assign printers based on the client and its location in the organization. This approach is one way to address the problem of users who roam to different computers in the organization and wish to print to the printer local to that particular printer, not just the printer they access normally. For example, if a user normally works in the Miami office but travels to the Orlando office for the day, that user would likely prefer to print to a printer in the Orlando office instead of defaulting to their normal printer back in the Miami office.

For such a logon script configuration to work effectively, the company would have to be sure to employ a naming standard based on physical site location, as well as possibly office location, if the site was large enough. While scripts could be created for each individual computer name, being able to break things down based on some general geographic region would expand the range of the scripting and simplify the management process.

For example, you could employ a client-naming standard such as

where SITE is the actual PC site (MIA or ORL, for example). In the example,

An example client name might be ORLPC-03WEST003.

With this information, you could create a logon script that would look at the SITE, FLOOR, and REGION information and assign a default printer based on this. While certainly more complicated than simply using a domain security group, this method can provide much more flexibility in how printers are managed.

To install and complete configuration of the TCP/IP port, you need to know the TCP/IP address of the printer or print server, the protocol used (RAW or LPR), and the corresponding protocol setting (port number for RAW or queue name for LPR). Of the two, LPR is much more common. When using the Add Printer wizard, the steps for configuring a local TCP/IP port are as follows:

While the steps involved in setting up a local printer on the server are straightforward, take care when implementing such a configuration. Additional load is introduced because of the print server responsibilities this creates, which in turn diminishes the resources available to Terminal Server sessions. Local server printers are best suited for smaller, less loaded Terminal Servers that have the capacity to manage print server duties without noticeably degrading the user’s Terminal Server experience.

For this redirection to be successful, you need to ensure that the Terminal Server is configured so it automatically attempts to map the client’s printers when he or she logs on to the server. To do this, client printer redirection must be enabled at both the RDP connection level and the individual user account level. By default both methods are enabled, but you can verify or modify this option as desired. At the RDP connection level, you can configure this setting using either the Terminal Services Configuration tool or a group policy object, which is the preferred method in large deployments because it centralizes the management process and alleviates the need to log on to each server to set these options. If you want to use the Terminal Services Configuration tool, you can do so as follows:

Details on configuration and use of group policy objects were provided in Chapter 15, so there is no need to rehash the steps here. It is sufficient to say that the GPO properties directly related to managing printer redirection can be found within the Computer Configuration section in the following folder:

Any settings defined here override any set directly on the Terminal Server using the Terminal Services Configuration tool. Figure 17.15 shows these properties listed within the Group Policy Object Editor.

Figure 17.15. Printer redirection settings can be defined within a group policy object.

Client printer mappings for individual user accounts are managed as follows:

TIP:

As I discussed in Chapter 1, “Microsoft Windows Terminal Services,” the RDP protocol can be expanded to support additional, customizable features using what are called virtual channels. Virtual channels are also used to drive RDP features such as clipboard mapping, client drive mapping, and local client printer redirection.

While it has been suggested that access to these features is dependent on whether the Virtual Channels permission for the RDP protocol is allowed or not, this information is false (see Figure 17.17). Local client printer redirection is in no way affected by the status of this connection permission. Even if Virtual Channels have been expressly denied, local client printer redirection still functions as designed.

Figure 17.17. The Virtual Channel permission for the RDP-Tcp connection does not control whether or not client printer mapping is available.

When local client printer redirection is enabled, the Terminal Server attempts to automatically connect all the printers available on a user’s local desktop whenever they log on to the server. Whether or not a client printer is successfully redirected within an RDP session depends on whether a suitable match between the client and the server printer drivers can be determined.

During the logon, the RDP client enumerates all the client’s local printers and sends the local queue name and complete driver name to the Terminal Server. For this redirection to occur, the Terminal Server must take the client’s driver name and find a corresponding driver on the server with the exact same name. For example, if the client machine has a driver called “hp deskjet 970c series”, the server must have a driver with an identical name (same punctuation, same case, same everything) in order for the redirection to occur. If the names do not match or a driver cannot be found, an event ID 1111 (see Figure 17.18) is created in the server’s system log and the printer mapping silently fails. No error message is displayed to the user. Driver installation is discussed in the “Printer Driver Management” section, earlier in this chapter. If the corresponding driver has been installed and the mapping is still failing, it is likely because the driver names differ between the client and the server. I discuss ways to correct this problem in the next section.

Figure 17.18. An event ID 1111 message is displayed when a client printer driver cannot be found on the Terminal Server.

When an event ID 1111 is generated, it is either because the driver names on the client and the server do not match or because a corresponding driver has not yet been installed on the Terminal Server. If the driver is not yet installed, it needs to be made available before you attempt the mapping. The earlier section entitled “Printer Driver Management” discusses in detail the criteria for managing printer drivers on your Terminal Server.

If a suitable server driver has been installed and the client printer mapping still fails, then the two drivers have slightly different names and a special cross-reference matching (also commonly called a mapping or substitution) file must be used to tell the Terminal Server that these two names do in fact reference the same drivers. For example, if we have a Windows XP client connecting with an updated version of the DeskJet 970c driver with the name

and our Windows 2003 Terminal Server has the following driver installed:

then when the mapping comparison is made, we see that these two drivers are certainly not identical, so the mapping is not created and an event ID 1111 is created. To remedy the problem of nonstandard driver names, Microsoft provides the ability (Windows 2003, and Windows 2000 post–Service Pack 2) to create a custom substitution file to handle these anomalies. The substitution file would then contain an entry such as

This entry tells the Terminal Server that whenever a client connects and provides the driver name “hp deskjet 970c series”, the corresponding server driver “HP DeskJet 970Cse” should be used.

To use this custom substitution file, you must first make an addition to the system registry telling the Terminal Server what file to use and where within that file to find the custom substitution information. You can do this by opening REGEDIT, traversing to the following registry key:

and adding the two values listed in Table 17.1 to the key.

The substitution file would then need to be created and placed in the proper folder. For example, my sample INF file for these DeskJet drivers would look like the one shown in Listing 17.3. You can list multiple driver substitutions within this file if necessary.

Remember that for the substitution to function properly, you must have the server-side driver installed on your Terminal Server. The driver will not automatically be installed by itself.

[Printers]
;
; Client Side Driver     |   Server Side Driver
;
"hp deskjet 970c series" = "HP DeskJet 970Cse"

To assist users in making the necessary changes to a substitution file, Microsoft released a tool called the Printer Driver Redirection wizard, which is downloadable free from the Terminal Services Community Web site. The URL for this site is http://www.microsoft.com/windowsserver2003/community/centers/terminal/default.mspx

Both the Windows 2000 and 2003 communities point to the same home page. As you scroll down toward the bottom of this page, you see the link for the Printer Driver Redirection wizard. After downloading the file, simply extract it into a folder on your Terminal Server and double-click the TSPDRW.EXE executable. The redirection wizard will scan either a local or remote server for any existing event ID 1111 entries in the event log with the source “TermServDevices”. Once completed, it provides you with an option screen where you either choose an existing printer driver to use as a substitution or manually add a driver. Figure 17.19 shows this utility prompting for the choice of the installed driver to be used to substitute for the “hp deskjet 970c series” entry that was found.

Figure 17.19. The Printer Driver Redirection wizard automates creation of the substitution file used to map printers with different printer driver names on their client and the MetaFrame server.

After choosing the appropriate file to create the substitution with, you can click Next and see the next driver found in the event log displayed. If you do not wish to create a substitution, you can select the (none) entry located at the bottom of the list.

Once the last driver is prompted, the tool displays a summary message stating what changes were made. On the very last screen you are provided with the name of the substitution file that was created or updated. The necessary registry entries to have MetaFrame read the contents of this file are also automatically set. If a reboot is required to complete the setup, you are prompted. If you say no, the updates are deferred until later.

WARNING:

When manually adding a printer using the Add Printer wizard, you may notice that under the list of local printer ports are a number of special ports with the prefix TSxxx, where xxx is a three-digit number as shown in Figure 17.20. As you might suspect, these ports are associated with redirected local ports for the listed computer name.

Figure 17.20. Terminal Server client-mapped printer ports.

Although Windows will let you complete the action, it is highly recommended that you do not manually create a local printer associated with one of these printer ports. While doing so may appear to work properly, Microsoft does not support the configuration because of a couple of different issues that may arise. The first has to do with how these ports are cleared when a user logs off. Normally the Terminal Server will purge all redirected client ports when a user logs off, but because the server is not “aware” of these manually created ports, they will not be cleared and will remain on the server unless manually removed. Another side effect of this manual mapping is that print jobs that are sent to one client printer actually end up printing out on a different client printer, usually belonging to someone else.

Two types of printer driver replication are supported by MPS: replication between specific servers, and auto-replication of printer drivers between all servers in the farm running the same operating system platform.

Replication between specific servers running the same Windows platform is configured as follows:

Auto-replication of printer drivers to all available MetaFrame servers in the farm is configured as follows:

The speed at which these entries are processed is a direct product of how busy the server is managing other tasks. Because the IMA service processes the queue entries with a low priority, if the server is busy with other things this process takes much longer. The number of servers that are the target of the driver replication also affects the replication speed. As the number of servers increases, the time it takes to replicate each driver to all servers also increases.

The QPRINTER utility can be used to help monitor and troubleshoot printer driver replication. The tool is located in the Supportdebug<OS Version> folder on the Windows MPS installation CD. The OS version is W2K3 for Windows Server 2003 and W2K for Windows 2000 Server.

Manually importing printers from a non-MetaFrame print server is a straightforward exercise executed by right-clicking the Printer Management module in the Management Console and selecting Import Network Print Server. You are then prompted to provide the name of the print server. Do not include the double-backslash that normally would precede a Windows server name; instead, just enter the server name. You then need to provide the credentials necessary to allow the connection with the server to be established. Figure 17.25 shows an example.

Figure 17.25. When importing printers from a print server, you must provide the server name and credentials for authentication.

Once the contents of the print server have been imported, the server appears on the Network Print Servers tab that is visible when you click the Printer Management module. The print server remains on this list indefinitely until manually discarded. If you add or remove specific printers from any of the listed print servers, you must manually update the printers in the data store by right-clicking the print server and selecting Update Network Print Server. You will need to provide valid credentials before the updated contents are read from the server. Once the printers from a print server have been imported, they appear in the Printers list alongside any printers shared off MetaFrame servers within the farm.

If at some point it is ever decided that printers from this print server are no longer required, they can all be removed simply by right-clicking on the print server and selecting Discard Network Print Server. The print server will be removed from the list and all associated printers under the Printers object will also immediately be removed.

With all the desired printers now listed in the server farm, you are ready to configure the network printer auto-creation so these network printers are automatically mapped to the appropriate users based on their user ID or group membership.

Printer auto-creation assignment is performed by right-clicking the desired printer listed in the Printers object and then selecting the Auto-Creation option. You are then presented with a dialog box where you are expected to select the desired user ID or group to be assigned to this printer when they log on to any MetaFrame server in the farm (see Figure 17.26). When a user who belongs to this group logs on to a MetaFrame server in the farm, they have their associated printers automatically mapped for them.

Figure 17.26. Printer auto-creation is best assigned to user groups instead of individual users.

If you wish to assign the same groups to more than one printer, you can duplicate an existing auto-creation configuration from one printer onto another simply by right-clicking the printer you wish to replicate and selecting Copy Auto-Creation Settings. You can then select one or more printers from the list and click OK. The auto-creation settings are automatically replicated for the selected items.

One configuration option exists that dictates whether or not a user can maintain personal configuration settings from one session to the next for an auto-created network printer. By default, a user can modify the settings for an auto-created network printer and have those settings persist from session to session. The option can be found by right-clicking the Printer Management icon and selecting Properties from the Context menu. From the Properties dialog box, select the Printers settings. You see the auto-created network printers setting at the bottom of the dialog box. I describe the settings that pertain to auto-created client printers in the next section.

Now that we’ve examined the advanced features MetaFrame provides for managing network-mapped printers in your environment, we look more closely at the features MetaFrame provides to enhance support for client-printer redirection.

The first group of printer management options available pertains directly to the logic employed by MetaFrame when attempting to establish a printer driver match between the client and the server. There are four options available:

The default option of using the native driver and falling back on the UPD only if the native driver is not found is a suitable configuration under most circumstances, but there may be certain situations where you want to support only the native drivers. In this case, you need to modify the default printer driver action.

When the option “Automatically install native drivers for auto-created client and network printers” is enabled, the MetaFrame server automatically installs the signed drivers provided by Microsoft if they are not already available when a user attempts to establish a client-mapped or network-mapped printer. This option installs only the native drivers that ship with Windows; it cannot be used to install custom third-party drivers. Third-party drivers must still be installed manually and then replicated. Because the printer drivers being installed have been digitally signed by Microsoft, they are certified to work not only with Windows but also with Windows Terminal Services. I prefer not to enable this option, in order to maintain control over exactly what drivers are available on the MetaFrame servers.

Under certain situations you may want to control the printer drivers that are used to support client printers. You may wish to limit your MetaFrame environment to use only a specific set of printer drivers, or maybe you are having issues with only one particular printer driver and want to ensure that it is never loaded into your MetaFrame environment.

The drivers used by client printers are managed using the Printer Driver Compatibility tool, which is accessed by right-clicking on the Drivers object and selecting Compatibility from the context menu. This opens the Driver Compatibility dialog box shown in Figure 17.28.

Figure 17.28. The Driver Compatibility dialog box allows you to control what printer drivers are used by client-mapped printers.

The default behavior of MetaFrame is to allow all printer drivers to be used except for any that are added on this screen. You can add the drivers to exclude simply by clicking the Add button and either typing in the driver name, which must match exactly, or selecting the driver from the listbox.

You can also configure MetaFrame so that all drivers are disallowed, except for those that are explicitly added to this list.

Many people have asked why they should even bother with managing installation and replication of printer drives now that MetaFrame supports the different universal printer drivers (UPDs). Why not use the UPD for all client-mapped printing? While certainly the UPD helps ensure that most client-based printers are accessible through a MetaFrame session, there are some limitations to this approach.

The universal drivers by nature must be based on a generic printer driver that is most likely to be compatible with most of printers available. Citrix has deployed three flavors of its UPD, one for PCL5c based on the HP Color LaserJet 4500 driver, a PCL4 driver based on the HP LaserJet Series II, and a PostScript (PS) driver based on the HP Color LaserJet PS. While these drivers meet most basic printing requirements, they may not be able to access certain special features available with a printer; for example, special paper trays, output bins, and collating or duplex options.

I prefer to try to implement the true printer driver for any work-based client printers that must be mapped and relegate the generic universal drivers to support of any other client printers that may need to be supported. Home and home-office printers will fall into this category, since many are targeted specifically for the home user, and reliable, stable server-grade printer drivers may not be readily available.

If you click the Printers selection on the left-hand side of the Printer Management Properties dialog box, the options specific to configuring auto-created client printers are displayed (Figure 17.29).

Figure 17.29. The Auto-Created Client Printer settings for the Printer Management Properties dialog box.

From this screen you can centrally manage the state of client printer redirection for the server farm. The default options are suitable under most circumstances, except that you may want to change the “Auto-create these client print devices:” setting from reading the individual connection settings on each server to following a single configuration option. The function of each property is described in Table 17.2.

Earlier in the chapter, in the “Driver Naming Requirements and Alternate Name Matching” section, I explained that when a client printer is being mapped in a Terminal Server session, the printer driver name on the client is compared to the driver name on the server. If they do not match exactly, the mapping is not generated. MetaFrame provides a graphical interface directly within the Management Console where any necessary substitution entries can be added without having to make registry changes or modify text files. The specific dialog box is opened by right-clicking the Drivers object and then selecting Mapping from the Context menu. The Driver Mapping dialog box opens, listing all the existing mappings that have been created. A new substitution is added by clicking the Add button. The dialog box shown in Figure 17.30 appears. In the upper portion, enter the full client driver name exactly as it appears. The spacing and capitalization must match exactly, or the substitution will not function properly. For the server driver, you can either manually type in the name or select the name of an installed printer driver from the drop-down list box.

Figure 17.30. When you enter a mapping, enter the client-side drive name exactly as it appears on the client.

Once the information has been entered, click OK to save the changes. The information then appears in the Driver Mapping dialog box (Figure 17.31). Once entered, this information is applied to all servers in the farm. In this example, when a client provides the server with the driver name “hp deskjet 970c series”, the client queue is created but the driver “HP DeskJet 970Cse” is used instead.

Figure 17.31. The Driver Mapping dialog box.

The final note to mention has to do with the naming convention used by MetaFrame for client-mapped printers. This was discussed in Chapter 8, but I review it quickly here. When mapped, a MetaFrame client-mapped printer has the following naming:

where “Client” is a constant used to show that the mapping is a client printer. “Client name” is the name assigned to the client device during installation of MetaFrame. And finally, the printer name corresponds to the full printer name on the client device.

For example, if I have a local printer called “HP LaserJet”, and I log on to a MetaFrame server configured to support this client mapping, I would expect to have a client printer mapping with the following name:

where “TODDPC” is my client name. Similarly, if I had a network-mapped printer on my local PC with the mapping of

then when I next logged on to the MetaFrame server, my client name should automatically become

The extra backslashes in the name are not a concern because they are ignored and have no effect on actually attempting to print to that client-mapped printer.

When clients are connecting to a MetaFrame server over a limited bandwidth connection, the amount of bandwidth consumed by client printer jobs can directly impact the user’s computing experience. To the end-user the impact manifests itself as sluggish screen updates and slow system response to keyboard and mouse input. In order to counteract this problem, Citrix provides the ability within MetaFrame to dictate the maximum bandwidth that all client print jobs on a server can utilize. This setting is accessed by clicking on the Printer Management icon in the Management Console and then selecting the Bandwidth tab as shown in Figure 17.32.

Figure 17.32. The bandwidth available for client printing can be set from within the Printer Management module.

By default all servers in the farm are automatically assigned no limit on the bandwidth that is consumed by client-mapped print jobs. A limit on bandwidth is set by right-clicking on the desired server and selecting Edit. A dialog box will then open allowing you to choose Unlimited or to set a limit by specifying a value in Kilobits per second (Kbps). This value has the following characteristics:

In order to determine the per-connection client printing bandwidth you need to know how much available bandwidth there is over the link and then divide that by the total number of concurrent users that are operating across that link. Using this simple formula you can establish an initial estimate that you can then adjust up or down as necessary to maximize the configuration for your environment.

PrinterBandwidth = (Total bandwidth available – Total bandwidth utilized) / Total concurrent users

The specific parameters are

With this information you can generate some numbers that will give a starting point. For example, say I have a T1 connection (1540 Kb), a total bandwidth utilization of 80% or around 1232Kb, and 45 concurrent users that must access that link. The formula would generate a result of around 6.8Kb per connection. This means that you would then enter the value of 7Kb for the bandwidth limit. You can enter only integer values, so I have simply rounded the number 6.8Kb up to 7Kb.

I would recommend that after entering this value you monitor the network to see if the change has reduced the network load. With this information you can increase or decrease the value as necessary to fine-tune your environment.

When in doubt about the bandwidth available, you can simply start off by setting the value to 5Kbps and then slowly adjusting the value upwards until a noticeable degradation in performance occurs. At this point you will know that you have reached that threshold and need to throttle back a little.