File and Print Annoyances

I hear about certain file and print "challenges" over and over again from clients. Visitors of my Web site echo these annoyances. I want to address three of the most popular complaints I hear on this subject: the inability to restrict file shares, to deploy printers via Group Policy, and to control quota usage.

Too often, we give in to the temptation of reaching out to third-party solutions rather than using freely available, built-in OS tools. In particular, Windows Server 2003 Release 2 (R2) and the forthcoming Longhorn Server offer terrific file and print management solutions.

Can't Restrict File Shares
File services have vastly matured in Windows, but there are always features that other network OSs have that Windows doesn't (or hasn't had before now). One such feature is visibility of folders and files to which users don't have permissions. In OSs such as Novell NetWare, users see only the files and folders to which they have access, whereas in Windows, users typically see all shared files and folders—even those to which they're denied access. Perhaps this default behavior doesn't seem significant, but users can often glean an idea of file contents from filenames. For example, the file John Savill reasons to fire.doc would make me uncomfortable even though I can't see what's in the file. And depending on industry type, this hint of data content might break regulations and compliance requirements.

To solve this problem, Microsoft has released Windows Server 2003 Access-based Enumeration, a downloadable add-on for Windows 2003 Service Pack 1 (SP1) that you can obtain from Microsoft's Web site. This tool lets you control—at the server or individual share level—the ability for users to see only the files and folders to which they have access. Downloads are available for both 32-bit and 64-bit versions of the OS; although Windows 2003 SP1 is discussed, Windows 2003 R2 is also fully supported (since Windows 2003 R2 is essentially Windows 2003 SP1 with "extras").

The installation procedure prompts you to enable access-based enumeration for all folders or to allow folders to be individually enabled (the default option). After installation, the properties of a shared folder will have a new tab—Access-based Enumeration—which Figure 1 shows. On this tab, you configure folders so that only users who have at least Read permissions can view them.

A command-line tool called Abecmd is also provided as part of the download. This tool gives you command-line control of access-based enumeration.

Can't Deploy Printers via Group Policy
Longhorn Server will offer full support for printer deployment and management, but until we're all enjoying Longhorn Server and Windows Vista clients, most of us are turning to third-party alternatives for help in the management of printer deployments. However, you might not know about an interim solution that's part of Windows 2003 R2—a feature that helps fill the gap between what we have today in terms of printer deployment via Group Policy (i.e., zero functionality) and Longhorn (i.e., a useful set of tools). The new Print Management Console aids in the management of print servers both locally and remotely, and it lets you push printers via Group Policy.

There is a caveat. Typically, the client reads and automatically processes Group Policy settings; obviously, legacy clients won't understand the Windows 2003 R2 print-deployment capabilities of Group Policy. Therefore, you'll need to install a client-side piece on those computers so that you can process printers they should connect to. These client pieces are usually Client Side Extensions (CSEs), which are part of the OS and executed automatically as required to process Group Policy settings. For example, there are Folder Redirection, Administrative Template, and Security CSEs—to name a few. Unfortunately, there's no Printer Connections CSE in Windows XP. (Vista will have one.) So, in addition to setting Group Policy options for the actual printers, you'll need to deploy a command-line utility—Pushprinterconnections.exe—to run at machine startup or user logon (accomplished through a startup or logon script).

To install the Print Management Console, open the Control Panel Add/Remove Programs applet and find the tool in Add/Remove Windows Components. During installation, the system creates a folder called PMCSnap under the Windows folder. The PMCSnap folder contains the files that the Print Management Console will use, including the new Microsoft Management Console (MMC) Print Management snap-in and the client-side Pushprinterconnections.exe image.

A word of caution: The Pushprinterconnections.exe tool automatically matches the processor type of the server on which you enable it. For example, if I'm running on 64-bit Windows 2003 R2, the Pushprinterconnections.exe tool installed on the server will be the 64-bit version, which won't run on most client plat-

forms. Therefore, you'll need to take Pushprinterconnections.exe from the 32-bit Windows 2003 R2 CD (the second disc), and you'll need to manually expand it by using the Expand command on the \CMPNENTS\R2\PUSHPRINTERCONNECTIONS .EX_ file.

After you've installed the Print Management Console, you can deploy printers through Group Policy as follows:

1. Open the Print Management MMC snap-in by clicking Start, Programs, Administrative Tools, Print Management.
2. Expand the Print Servers branch, click the print server that hosts the printer, and select Printers.
3. Right-click the printer that you want to use Group Policy to deploy, and select Deploy with Group Policy.
4. To find the GPO name to use, click Browse.
5. Click the New GPO icon (or select an existing GPO), use the name Deploy Printers, and click OK. You need to ensure that this Group Policy is applied to a container that holds the users and computers to which you want to install this printer.
6. Select either The users that this GPO applies to (per user) or The computers that this GPO applies to (per machine), or both, and click Add, as Figure 2, shows.
7. Click OK.

If you open the Group Policy Object (GPO), you'll notice a new Deployed Printers branch that lists deployed printers in the GPO.

You now need to assign Pushprinterconnections.exe so that the selected printers are processed when the computer starts or when users log on (depending on the target for the printer deployment—user or computer).

1. In the GPO Editor, open the GPO that you used for the printer deployment.
2. If the selected printer is deployed to users, navigate to User Configuration, Windows Settings, Scripts (Logon/Logoff). If the printer is deployed to computers, navigate to Computer Configuration, Windows Settings, Scripts (Startup/Shutdown).
3. Right-click Startup or Logon, then click Properties.
4. In the Logon Properties or Startup Properties dialog box, click Show Files. In the Address field, you'll see the location of the scripts—for example, \\savilltech.com\SysVolsavilltech.com\Policies\\{EAB0039E-A6774C89-9CF2-053576CDA1FC\}\Machine\Scripts Startup.
5. Copy the Pushprinterconnections.exe file from the C:\windows\PMCSnap folder (or, if you're using a 64-bit server, copy the 32-bit version from the 32-bit CD) to this location, then close the window.
6. In the Logon Properties or Startup Properties dialog box, click Add.
7. Type pushprinterconnections.exe in the Script Name field. (If you want to enable logging, type -log in the Script Parameters field on the computer to which the policy is applied. For per-computer connections, log files are written to %windir%\Temp\PpcMachine.log; for per-user connections, log files are written to %temp%\PpcUser.log.)
8. Click OK.

For per-user deployed printers, you should now log off, then log back on. For per-machine deployed printers, you should restart the targeted computer.

The use of Pushprinterconnections.exe—while not ideal—isn't a major deployment consideration. Also, the generated log files give you information that you can use for debugging should the deployment not work. You can also look on the machines that are targets for deployment by checking the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft PPC or HKEY_CURRENT_USER\SOFTWARE Microsoft\PPC registry subkey, whose default value is a multivalue string, each line of which is a printer that needs to be connected through Pushprinterconnections.exe.

Can't Control Quota Usage
Quotas can be extremely useful. However, users sometimes have a tendency to misuse the space. Quota reports can tell you how users are utilizing that space, but it can be difficult to prevent users from writing illegal file types in the first place.

One of the huge wins for Windows 2003 R2 is the File Server Resource Management (FSRM) component. In addition to its powerful reporting capabilities and a new quota system that accounts for the disk's physical size (as opposed to the logical size) with disk-level and folder-level targeted quotas, FSRM includes a real-time engine that enables file-type enforcement based on file extensions. This new screening technology checks a file's extension—for example, if it's an MP3 file, the system knows it's a music file, and therefore a policy to stop music files can act on the file. If a user renames a music file to music.not_a_mp3, the system wouldn't detect the file. The system doesn't check the file's contents. However, the purpose of the technology is to stop the "accidental" offender.

You manage file screening through the MMC File Server Resource Manager snap-in, which Figure 3 shows. The default installation contains a number of file-group types, which are definitions of common file extensions and their content. For example, there's an Audio and Video Files group that contains nearly all known extensions. Once file groups exist, you can apply a file screen to a disk or folder to enforce certain behavior toward one or more file groups.

You can create an active or passive file screen. If a certain file is a banned file type, an active file screen actually stops the file—in real time—from being written; a passive screen allows the writing of the file but will perform a particular action that you've defined. For a given file screen, you can define a comprehensive set of actions to be performed in the event of an offense (i.e., file activity of a screened file type). These actions include sending an email message to the user or administrator, creating an event log, and creating a report that shows how a certain user is using disk space. You can also initiate a custom action.

The first action type—sending an email message—is crucial to the success of a filescreen rollout. Remember that file screening is a new server-side technology; file screens are invisible to client OSs, and if a user attempted to write a screened file type, he or she would simply receive an Access denied message, then probably get on the phone to the Help desk. By configuring an email action to occur seconds after the Access denied message, you can inform the user, with your own custom text, that company policy prohibits the type of file he or she was attempting to write and that the user should refer to a URL for a full list of company policies surrounding file server usage. Microsoft supplies 11 standard File Groups, which you can modify to add additional file types as necessary.

To avoid the need to recreate actions every time you set a file screen, you can define the actions on templates. You can apply a template to a specific file group, then apply it to disks and folders as necessary. To create a file screen, follow these steps:

1. Open the MMC File System Resource Manager snap-in by clicking Start, Programs, Administrative Tools, File Server Resource Manager.
2. Expand the File Screening Management branch, and select File Screens.
3. In the Actions pane, click Create File Screen.
4. Click Browse, and select the path to which you want to apply the file screen. You can then select the template from which you want to derive the settings or set specific values, then click Create.

As Figure 4 shows, after you build a template, you can tune it and define other file types or perform other actions as necessary.

Another type of file screen is possible. The standard file screen is to block file groups, but you can also create a file-screen exception. This capability is useful if, for example, you want to block nearly all file types at a root folder level but create an Audio or Images folder as a subfolder. You can then create file-screen exceptions on those subfolders to allow only audio and images, respectively, thereby forcing data to be stored according to a predefined structure—as opposed to anywhere on disk.

Obviously, there's a small amount of overhead associated with this new technology because the system is performing extra checks. However, the overhead isn't significant: File Screening Management intercepts only write and change operations, and I haven't seen any instances in which file screening has introduced any appreciable bottleneck to system operations.

A Final Caveat
These three common solutions can offer a real benefit to almost any environment. However, a non-technical aspect of these solutions must not be overlooked: communication. Both access-based enumeration and file screening directly affect the end user's experience, and unless communication occurs with users before changes are made, the overall implementation will be seen a failure—no matter how technically successful the implementation is. You never want end-user confusion to ensue and productivity to drop