I thought I would post a followup for others to try to consolidate the information into a single post (based on what I have learnt and the other information already posted).
PAE:
PAE will allow a 32bit Windows server to make use or more than 4GB RAM, with the maximum being dependant on the version of windows you are running (Wikipedia has a nice reference here)
One thing to note, if you have Data Execution Prevention (DEP) or NoExecution (NX) turned on, then this will effectivly enable PAE without having to explicitly enable it in the boot.ini.
Bottom line, PAE has no effect of the amount of memory a single 32bit process can access. It only affects the total amount of memory windows can 'see' and make use of (so you can have 2 processes each using 2GB, with Windows using 2GB on a 6GB system)
3GB:
Firstly, when I am speaking about the memory available to single 32bit process, I am refering to the processes virtual address space. For a 32bit process on a 32bit Windows OS this is limited to 4GB.
On a system without the /3GB switch, the 4GB of virtual address space is split 2GB / 2GB between the running process and the Windows kernel.
When you enable the 3GB switch, the split in virtual address space is changed to 3GB / 1GB. This allows the process to use more memory, at the expense of the kernel memory. Please note: Windows will only allow a process to use more the 2GB or memory if the executable has been compiled with the IMAGEFILELARGEADDRESSAWARE flag set.
Now, as has been mentioned in other posts, the penalty of using the 3GB switch is that the kernel has less memory to work with. And one of the main casualties of the reduced memory is the number of Page Table Entries (PTEs) available. A page table is the data structure used by the Windows Virtual Memory Manager to store the mapping between virtual addresses and physical addresses in memory. If you have insufficient free PTEs, then windows may fail to allocate memory to a process when requested, even if the process has not yet exhausted its address space.
The free PTE count can be measured using perfmon (\Memory\Free System Page Table Entries). Anything under 5000 is considered critical by Microsoft. As an example, on the servers mentioned in the original post, without the 3GB switch and with the process running, the free PTE count was around 160k. After enabling 3GB but before the process had started, windows was reporting 3.5k free PTEs (a dramatic reduction). This number would have dropped quickly if we had started the process.
The way to compensate for this dramatic change is to enable the USERVA switch in the boot.ini. By setting USERVA=2800, this moves the 3GB / 1GB split in memory and 'gives back' approximately 250MB back to the kernel for its use. By way of example, after setting USERVA=2800 in the boot.ini on our system, the free PTE count now sits around 60k with the process running (a lot better than the 3.5k we were seeing).
More information on the USERVA switch can be found in the Microsoft KB article.
It is also worth mentioning that enabling PAE also has an impact on the free PTE count. The PAE switch causes each PTE entry to use twice the normal allotted virtual address space.
Hopefully this provides a nice concise summary of the information for anyone looking at a later date.
Cheers
Sam
There is no built-in mechanism to disable printer redirection for only specific printers.
I'd consider doing the following (it's convoluted as all get out, but it should give you what you want):
"Share" the printers on each client computer that should be available to the Terminal Server.
Add the "TCP/IP Print Server" service to each client computer (marking the service for automatic startup and opening port 515 in the local Windows Firewall on each client computer, if applicable).
Create local printers on the Terminal Server (or other server computer) corresponding to each printer attached to client computers. These printers should use "Standard TCP/IP" ports configured for LPR, with the "Queue Name" set to the share name specified on the client comptuer for each given printer, and with the "LPR Byte Counting Enabled" check-box checked.
You have control of the print queue name using this method such that you can make the name appear as you'd like. You can set permissions on the queues to prevent users from sending jobs to the wrong printers if you so desire. You can completely disable client printer redirection, as well.
(I do the whole "TCP/IP Print Server" dance, as described above, rather than using "Local Ports" naming UNCs. Some people do the "Local Ports" but I've found throughout the years that I have severe reliability problems doing it that way. My method basically makes the PC act like a really expensive "JetDirect" box...)
Best Answer
Windows Server 2003 x86 kernel memory by default is grossly underconfigured for a heavily used terminal server.
To view the actual in-use values on the running system, you can use SysInternal's Process Explorer, under View > System Information. If the system is configured to use the maximum amount of Paged Pool and Nonpaged Pool, the Paged Limit will be 512 MB and Nonpaged Limit will be 256 MB.
To show this level of detail, the proper symbols must be loaded under Options > Configure Symbols:
If either the Paged Physical or Nonpaged are approaching the limit, there will be system instability. The registry values that configure these maximum limits are located at:
It's worth noting that having a large amount of physical memory may not be helpful, as x86 windows can only use a rather small amount for kernel memory space, and it cannot grow beyond what is shown in the limit. (x64 kernel memory limits are far less constraining). The limit is calculated dynamically at system startup time based on available memory and registry settings.
You can get more detail about what is using the kernel memory with the following Windows Debugger commands:
!vm
- shows information similar to the process explorer kernel memory limits.! poolused n
- displays information about paged/nonpaged pool usage. This can sometimes be helpful if a driver has a memory leak that is consuming excessive kernel memory.!poolused command
http://msdn.microsoft.com/en-us/library/windows/hardware/ff564700%28v=vs.85%29.aspx
!vm command
http://msdn.microsoft.com/en-us/library/windows/hardware/ff565602%28v=vs.85%29.aspx