Posted on Thu, Aug 25, 2011
Group Policy has been a standard element of domain management since Windows 2000 Server over a decade ago. However, Group Policy hasn't always kept up with the changes in desktop operating systems, limiting the amount of control network administrators can maintain over client machines.
That all changed with the introduction of Group Policy Preferences, introduced with Windows 2008 Server. By using GPP technology, Windows 2008 Server allows much more extensive control of client systems than ever before. Essentially anything that can be configured through the Control Panel of the client system can now be controlled through a Group Policy Object. But GPP is not limited to just Control Panel options. Administrators can now install printers (both local and network), map network drives without using ancient DOS-based batch scripts, modify registry entries, install applications, and control folders and files all from a simple Group Policy interface. And best of all, each of these features can be easily targeted to specific users, computers, or groups through a simple to use GUI. Yes, you can now easily control which users are assigned which network drives or printers right from a Group Policy without having to use cumbersome and buggy logon scripts!
Unfortunately, because GPP was introduced with Windows 2008 Server, it does not support clients older than Windows Vista out of the box. However, there is a small patch available from Microsoft (http://www.microsoft.com/download/en/details.aspx?id=3628) which enables support for GPP on Windows XP SP2 and SP3 machines. This patch can be easily deployed across a network using any typical patch deployment software platform. My personal favorite tool for doing this is PDQDeploy (http://www.adminarsenal.com/pdq-deploy/main/), which is an excellent, free utility.
Group Policy Preferences completely revolutionize network administration and management for Windows-based networks. However, it is still extremely common to see older-style GPOs and custom logon scripts being used at companies of all sizes even today. This results in unnecessary instability and difficulty in management for many networks. If you're concerned that your network may not be utilizing the powerful new features of Windows 2008 Server such as GPP, Contact Us today and one of our engineers will be more than happy to review your network infrastructure with you.
Brian St. Marie - Sr. Systems Engineer
Give Us a Call 617-731-6319 and Ask a Professional IT Support Technician Any Questions You May Have!
Sincerely, Terminal We Serve All of Greater Boston and Cambridge, MA
Posted on Thu, Apr 21, 2011
Most network administrators and technicians are familiar with mapping a printer from a server. This is the most typical and efficient way of sharing printers on a network. However, many applications, especially legacy applications, only work with a local, non-network printer. Some applications may also require the printer have a specific name, which won't work with network printers as you cannot rename them. There are a few ways to get around these problems, if an application requires it.
The first, and most straightforward, is simply to manually create a local printer port which actually redirects to the server hosting the printer. This can be done through the Add Printer Wizard on any version of Windows by simply selecting "Local Printer" and adding a new Local Printer Port. The name of the port is \\servername\printername.
However, this process requires manually installing the printer on each computer, which can be time consuming and difficult to manage if you're trying to deploy the printer to several machines.
Installing a local printer via script can be done, using the PrintUIEntry function found in Windows XP and onward. The basic command is:
rundll32 printui.dll,PrintUIEntry /if /b <printername> /f %windir%\inf\ntprint.inf /r <portname> /m <drivername> /u
This will install the printer with the specified name, port, and driver. However, this script assumes the port name specified already exists, so the port must be created first. There are two ways to do this. For computers with old LPT parallel ports, you can map LPT1 to a network location and then specifiy LPT1 in the script. The script would look something like this:
net use LPT1 \\servername\printername /persistent:yes
rundll32 printui.dll,PrintUIEntry /if /b <printername> /f %windir%\inf\ntprint.inf /r LPT1 /m <drivername> /u
Unfortunately, this will not work if there are no parallel ports on the target computer, as then LPT1 does not exist. In that case, we need to create a new Local Port on the machines the way we did above in the manual scenario, but this time we need to do it via script. The best way to do this is by adding a registry entry to the target machine, which creates the port. Then we restart the spooler on the target machine so it recognizes the new port. The basic script would look like this:
net stop spooler
reg ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Ports" /v \\servername\printername /t REG_SZ /f
net start spooler
rundll32 printui.dll,PrintUIEntry /if /b <printername> /f %windir%\inf\ntprint.inf /r \\servername\printername /m <drivername> /u
The catch with this scenario is that we must have elevated privileges to run this script on Windows Vista or Windows 7. Otherwise, we will not be allowed to add any info to the registry or restart services via script.
One last method uses new technology released with Windows 2008, call Group Policy Preferences. GPP allows an administrator to control almost anything they like on the target machines, including adding local printers to an entire domain. The sets are essentially the same as the manual process above, except done through the GPP interface. Once configured, GPP will execute on each machine as it starts up on the domain, ensuring the printer is added appropriately. This is the cleanest and simplest method, but requires Windows 2008 domain controllers and also requires Windows 7 clients. For Windows Vista or Windows XP, the GPP extensions will first need to be deployed and installed. However, this is the simplest and most reliable method, once GPP is deployed and working on the network.
There are many solutions to the problem of local printing emulation on a network. Exactly which method is right for each network depends on many factors and choosing the wrong method can result in extensive headaches and buggy deployment. Proper research and preparation is necessary before committing to any solution.
Brian St. Marie - Sr. Systems Engineer
Give Us a Call 617-731-6319 and Ask a Professional IT Support Technician Any Questions You May Have!
Sincerely, Terminal We Serve All of Greater Boston and Cambridge, MA