This chapter covers some of the fundamental services that most Windows servers perform. In the business world, file and printer sharing were the reasons computers were networked in the first place, and with Windows Server 2012 R2, remote management has become a critical element of server administration.
Objectives in this chapter:
Objective 2.1: Configure file and share access
Objective 2.2: Configure print and document services
Objective 2.3: Configure servers for remote management
One of the critical daily functions of server administrators is deciding where users should store their files and who should be permitted to access them.
This objective covers how to:
Create and configure shares
Configure share permissions
Configure offline files
Configure NTFS permissions
Configure access-based enumeration (ABE)
Configure Volume Shadow Copy Service (VSS)
Configure NTFS quotas
Create and configure Work Folders
Sharing folders makes them accessible to network users. After you have configured the disks on a file server, you must create shares to enable network users to access those disks. As noted in the planning discussions in Chapter 1 you should have a sharing strategy in place by the time you are ready to create your shares. This strategy should consist of the following information:
What folders you will share
What names you will assign to the shares
What permissions you will grant users to the shares
What Offline Files settings you will use for the shares
If you have the necessary permissions for a folder, you can share it on a Windows Server 2012 R2 computer by right-clicking the folder in any File Explorer window, selecting Share With, Specific People from the shortcut menu, and following the instructions in the File Sharing dialog box, as shown in Figure 2-1.
This method of creating shares provides a simplified interface that contains only limited control over elements such as share permissions. You can specify only that the share users receive Read permissions or Read/Write permissions to the share. If you are not the Creator Owner of the folder, you can access the Sharing tab of the folder’s Properties sheet instead. Clicking the Share button launches the same File Sharing dialog box. Clicking the Advanced Sharing button displays the Advanced Sharing dialog box, shown in Figure 2-2, which provides greater control over share permissions.
For the users on the network to be able to browse the shares you create on the file server in File Explorer, you must make sure the Network Discovery settings and the File Sharing settings are turned on in the Network and Sharing Center control panel.
To take control of the shares on all your disks on all your servers and exercise granular control over their properties, you can use the File and Storage Services home page in Server Manager.
Windows Server 2012 R2 supports two types of folder shares:
Server Message Blocks (SMB). SMB is the standard file sharing protocol used by all versions of Windows.
Network File System (NFS). NFS is the standard file sharing protocol used by most UNIX and Linux distributions.
When you install Windows Server 2012 R2, the setup program installs the Storage Services role service in the File and Storage Services role by default. However, before you can create and manage SMB shares by using Server Manager, you must install the File Server role service; to create NFS shares, you must install the Server for NFS role service.
To create a folder share by using Server Manager, use the following procedure.
In Server Manager, click the File and Storage Services icon and, in the submenu that appears, click Shares. The Shares home page appears.
From the Tasks menu, select New Share. The New Share Wizard starts, displaying the Select The Profile For This Share page, as shown in Figure 2-3.
From the File Share Profile list, select one of the following options:
SMB Share–Quick. Provides basic SMB sharing with full share and NTFS permissions
SMB Share–Advanced. Provides SMB sharing with full share and NTFS permissions and access to services provided by File Server Resource Manager
SMB Share–Applications. Provides SMB sharing with settings suitable for Hyper-V and other applications
NFS Share–Quick. Provides basic NFS sharing with authentication and permissions
NFS Share–Advanced. Provides NFS sharing with authentication and permissions and access to services provided by File Server Resource Manager
Click Next. The Select The Server And Path For This Share page appears.
Select the server on which you want to create the share and either select a volume on the server or specify a path to the folder you want to share. Click Next. The Specify Share Name page appears.
Selecting one of the NFS share profiles adds two pages to the wizard: The Specify Authentication Methods page and the Specify The Share Permissions page. Each page provides access to functions implemented by the Server for NFS role service, as covered in Objective 2.1, “Configure Advanced File Services,” in Exam 70-412, “Configuring Advanced Windows Server 2012 R2 Services.”
In the Share Name text box, specify the name you want to assign to the share and click Next. The Configure Share Settings page appears, as shown in Figure 2-4.
Select any or all of the following options:
Enable Access-Based Enumeration. Prevents users from seeing files and folders they do not have permission to access
Allow Caching Of Share. Enables offline users to access the contents of this share
Enable BranchCache On The File Share. Enables BranchCache servers to cache files accessed from this share
Encrypt Data Access. Causes the server to encrypt remote file access to this share
Access-based enumeration (ABE), a feature first introduced in Windows Server 2003 R2, applies filters to shared folders based on the individual user’s permissions to the files and subfolders in the share. Simply put, users who cannot access a particular shared resource are unable to see that resource on the network. This feature prevents users from seeing files and folders they cannot access. You can enable or disable ABE for a share at any time by opening the share’s Properties sheet in the Sharing and Storage Management console and clicking Advanced, which displays the same Advanced dialog box displayed by the Provision a Shared Folder Wizard.
Offline Files, also known as client-side caching, is a Windows feature that enables client systems to maintain local copies of files they access from server shares. When a client selects the Always Available Offline option for a server-based file, folder, or share, the client system copies the selected data to the local drive and updates it regularly so the client user can always access it, even if the server is offline. To enable clients to use the Offline Files feature, the share must have the Allow Caching Of Share check box selected. Windows Server 2012 R2 and Windows 8.1 also have an Always Offline mode for the Offline Files feature that causes clients to always use the cached copy of server files, providing better performance. To implement this mode, you must set the Configure slow-link mode Group Policy setting on the client to a value of 1 millisecond.
Click Next to move to the Specify Permissions To Control Access page.
Modify the default share and NTFS permissions as needed and click Next. The Confirm Selections page appears.
Selecting one of the Advanced share profiles on the Select The Profile For This Share page adds two more pages to the wizard: The Specify Folder Management Properties page and the Apply A Quota To A Folder Or Volume page. Each page provides access to functions of the File Server Resource Manager application, as covered in Objective 2.2, “Configure File Server Resource Manager (FSRM),” in Exam 70-411, “Administering Windows Server 2012 R2.”
Click Create. The View Results page appears as the wizard creates the share.
Close the New Share Wizard.
After you create a share by using the wizard, the new share appears in the Shares tile on the Shares home page in Server Manager. You can now use the tile to manage a share by right-clicking it and opening its Properties sheet or by clicking Stop Sharing.
Using Windows Server 2012 R2, you can control access to a file server to provide network users the access they need while protecting other files against possible intrusion and damage, whether deliberate or not. To implement this access control, Windows Server 2012 R2 uses permissions.
Permissions are privileges granted to specific system entities, such as users, groups, or computers, enabling them to perform a task or access a resource. For example, you can grant a specific user permission to read a file while denying that same user the permissions needed to modify or delete the file.
Windows Server 2012 R2 has several sets of permissions, which operate independently of each other. For the purpose of file sharing, you should be familiar with the operation of the following permission systems:
Share permissions. Control access to folders over a network. To access a file over a network, a user must have appropriate share permissions (and appropriate NTFS permissions if the shared folder is on an NTFS volume).
NTFS permissions. Control access to the files and folders stored on disk volumes formatted with the NTFS file system. To access a file, either on the local system or over a network, a user must have the appropriate NTFS permissions.
All these permission systems operate independently of each other and sometimes combine to provide increased protection to a specific resource. For network users to be able to access a shared folder on an NTFS drive, you must grant them both share permissions and NTFS permissions. As you saw earlier, you can grant these permissions as part of the share creation process, but you can also modify the permissions at any time afterward.
To store permissions, Windows elements have an access control list (ACL). An ACL is a collection of individual permissions in the form of access control entries (ACEs). Each ACE consists of a security principal (that is, the name of the user, group, or computer granted the permissions) and the specific permissions assigned to that security principal. When you manage permissions in any of the Windows Server 2012 R2 permission systems, you are actually creating and modifying the ACEs in an ACL.
To manage permissions in Windows Server 2012 R2, you can use a tab in the protected element’s Properties sheet, like the one shown in Figure 2-5, with the security principals listed at the top and the permissions associated with them at the bottom. Share permissions are typically found on a Share Permissions tab and NTFS permissions are located on a Security tab. All the Windows permission systems use the same basic interface, although the permissions themselves differ. Server Manager also provides access to NTFS and share permissions by using a slightly different interface.
The permissions protecting a particular system element are not like the keys to a lock, which provide either full access or no access at all. Permissions are designed to be granular, enabling you to grant specific degrees of access to security principals.
To provide this granularity, each Windows permission system has an assortment of permissions you can assign to a security principal in any combination. Depending on the permission system with which you are working, you might have dozens of different permissions available for a single system element.
Windows provides preconfigured permission combinations suitable for most common access control tasks. When you open the Properties sheet for a system element and look at its Security tab, the NTFS permissions you see are called basic permissions. Basic permissions are actually combinations of advanced permissions, which provide the most granular control over the element.
Prior to Windows Server 2012, basic permissions were known as standard permissions and advanced permissions were known as special permissions. Candidates for certification exams should be aware of these alternative terms.
For example, the NTFS permission system has 14 advanced permissions you can assign to a folder or file. However, there are also six basic permissions, which are various combinations of the 14 advanced permissions. You can also assign both types of permissions in a single ACE, combining a basic permission with one or more advanced permissions, to create a customized combination. In most cases, however, administrators work only with basic permissions. Many administrators rarely, if ever, have reason to work directly with advanced permissions.
If you find it necessary to work directly with advanced permissions, Windows makes it possible. When you click the Advanced button on the Security tab of any Properties sheet, an Advanced Security Settings dialog box appears, as shown in Figure 2-6, which enables you to access directly the ACEs for the selected system element. System Manager provides access to the same dialog box through a share’s Properties sheet.
When you assign permissions to a system element, you are, in effect, creating a new ACE in the element’s ACL. There are two basic types of ACE: Allow and Deny. This makes it possible to approach permission management tasks from two directions:
Additive. Start with no permissions and then grant Allow permissions to individual security principals to give them the access they need.
Subtractive. Start by granting all possible Allow permissions to individual security principals, giving them full control over the system element, and then grant them Deny permissions for the access you don’t want them to have.
Most administrators prefer the additive approach, because Windows, by default, attempts to limit access to important system elements. In a properly designed permission hierarchy, the use of Deny permissions is often unnecessary. Many administrators frown on their use, because combining Allow and Deny permissions in a hierarchy can make it difficult to determine the effective permissions for a specific system element.
The most important principle in permission management is that permissions tend to run downward through a hierarchy. This is called permission inheritance. Permission inheritance means that parent elements pass their permissions down to their subordinate elements. For example, when you grant Alice Allow permissions to access the root of the D drive, all the folders and subfolders on the D drive inherit those permissions, which means Alice can access them.
The principle of inheritance greatly simplifies the permission assignment process. Without it, you would have to grant individual Allow permissions to security principals for every file, folder, share, object, and key they need to access. With inheritance, you can grant access to an entire file system by creating one set of Allow permissions.
In most cases, whether consciously or not, system administrators take inheritance into account when they design their file systems and their Active Directory Domain Services OU structures. The location of a system element in a hierarchy is often based on how the administrators plan to assign and delegate permissions.
In some situations, an administrator might want to prevent subordinate elements from inheriting permissions from their parents. There are two ways to do this:
Turn off inheritance. When you assign advanced permissions, you can configure an ACE not to pass its permissions down to its subordinate elements. This effectively blocks the inheritance process.
Deny permissions. When you assign a Deny permission to a system element, it overrides any Allow permissions that the element might have inherited from its parent objects.
A security principal can receive permissions in many ways, and it is important for an administrator to understand how these permissions combine. The combination of Allow permissions and Deny permissions a security principal receives for a given system element—whether explicitly assigned, inherited, or received through a group membership—is called the effective access for that element. Because a security principal can receive permissions from so many sources, it is not unusual for those permissions to overlap. The following rules define how the permissions combine to form the effective access.
Allow permissions are cumulative. When a security principal receives Allow permissions from more than one source, the permissions are combined to form the effective access permissions.
Deny permissions override Allow permissions. When a security principal receives Allow permissions—whether explicitly, by inheritance, or from a group—you can override those permissions by granting the principal Deny permissions of the same type.
Explicit permissions take precedence over inherited permissions. When a security principal receives permissions by inheriting them from a parent or from group memberships, you can override those permissions by explicitly assigning contradicting permissions to the security principal itself.
Of course, instead of examining and evaluating all the possible permission sources, you can just open the Advanced Security Settings dialog box and click the Effective Access tab. On this tab, you can select a user, group, or device and view its effective access, without accounting for group membership or while accounting for group membership.
In Windows Server 2012 R2, shared folders have their own permission system, which is independent from the other Windows permission systems. For network users to access shares on a file server, you must grant them the appropriate share permissions. By default, the Everyone special identity receives the Allow Read Full Control share permission to any new shares you create using File Explorer. In shares you create using Server Manager, the Everyone special identity receives the Allow Full Control share permission.
To modify the share permissions for an existing share by using File Explorer, you open the Properties sheet for the shared folder, select the Sharing tab, click Advanced Sharing, and then click Permissions to open the Share Permissions tab, as shown in Figure 2-7.
By using this interface, you can add security principals and allow or deny them the three share permissions. To set share permissions by using Server Manager, either while creating a share or modifying an existing one, use the following procedure.
In Server Manager, click the File and Storage Services icon and, in the submenu that appears, click Shares to open the Shares home page.
In the Shares tile, right-click a share and, from the shortcut menu, select Properties. The Properties sheet for the share opens.
Click Permissions. The Permissions page opens.
Click Customize Permissions. The Advanced Security Settings dialog box for the share opens.
Click the Share tab to display the interface shown in Figure 2-8.
Click Add to open a Permission Entry dialog box for the share.
Click the Select A Principal link to display the Select User, Computer, Service Account, Or Group dialog box.
Type the name of or search for the security principal to whom you want to assign share permissions and click OK. The security principal you specified appears in the Permission Entry dialog box.
Select the type of permissions you want to assign (Allow or Deny).
Select the check boxes for the permissions you want to assign and click OK.
The new ACE you just created appears in the Advanced Security Settings dialog box.
Many file server administrators simply leave the Allow Full Control share permission to the Everyone special identity in place, essentially bypassing the share permission system, and rely solely on NTFS permissions for granular file system protection. NTFS permissions control access by both local and remote users, rendering share permissions redundant.
Click OK to close the Advanced Security Settings dialog box.
Click OK to close the share’s Properties sheet.
Close the Server Manager window.
The majority of Windows installations today use the NTFS file systems as opposed to FAT32. One of the main advantages of NTFS is that they support permissions, which FAT32 does not. As described earlier in this chapter, every file and folder on an NTFS drive has an ACL that consists of ACEs, each of which contains a security principal and the permissions assigned to that principal.
In the NTFS permission system, the security principals involved are users and groups, which Windows refers to by using security identifiers (SIDs). When a user attempts to access an NTFS file or folder, the system reads the user’s security access token, which contains the SIDs for the user’s account and all the groups to which the user belongs. The system then compares these SIDs to those stored in the file or folder’s ACEs to determine what access the user should have. This process is called authorization.
Most file server administrators work almost exclusively with basic NTFS permissions because there is no need to work directly with advanced permissions for most common access control tasks.
To assign basic NTFS permissions to a shared folder, the options are essentially the same as with share permissions. You can open the folder’s Properties sheet in File Explorer and select the Security tab or you can open a share’s Properties sheet in Server Manager, as described in the following procedure.
In Server Manager, open the Shares home page.
NTFS permissions are not limited to shared folders. Every file and folder on an NTFS volume has permissions. Although this procedure describes the process of assigning permissions to a shared folder, you can open the Properties sheet for any folder in a File Explorer window, click the Security tab, and work with its NTFS permissions in the same way.
Open the Properties sheet for a share and click Permissions to open the Permissions page.
Click Customize Permissions to open the Advanced Security Settings dialog box for the share, displaying the Permissions tab, as shown in Figure 2-9. This dialog box is as close as the Windows graphical interface can come to displaying the contents of an ACL.
Click Add. This opens the Permission Entry dialog box for the share.
Click the Select A Principal link to display the Select User, Computer, Service Account, or Group dialog box.
Type the name of or search for the security principal to whom you want to assign NTFS permissions and click OK. The security principal you specified appears in the Permission Entry dialog box.
In the Type drop-down list, select the type of permissions you want to assign (Allow or Deny).
In the Applies To drop-down list, specify which subfolders and files should inherit the permissions you are assigning.
Select the check boxes for the basic permissions you want to assign and click OK. The new ACE you just created appears in the Advanced Security Settings dialog box.
Click OK twice to close the Advanced Security Settings dialog box and the Properties sheet.
Close the Server Manager window.
In Windows Server 2012 R2, the ability to manage advanced permissions is integrated into the interface you use to manage basic permissions.
In the Permission Entry dialog box, clicking the Show Advanced Permissions link changes the list of basic permissions to a list of advanced permissions. You can then assign advanced permissions in any combination, just as you would basic permissions.
It is important for file server administrators to understand that the NTFS permission system is completely separate from the share permission system and that for network users to access files on a shared NTFS drive, the users must have the correct NTFS share permissions and the correct share permissions.
The share and NTFS permissions assigned to a file or folder can conflict. For example, if a user has the NTFS Write and Modify permissions for a folder but lacks the Change share permission, that user will not be able to modify a file in that folder.
The share permission system is the simplest of the Windows permission systems and it provides only basic protection for shared network resources. Share permissions provide only three levels of access, in contrast to the far more complex system of NTFS permissions. Generally, network administrators prefer to use either NTFS or share permissions, not both.
Share permissions provide limited protection, but this might be sufficient on some small networks. Share permissions might also be the only option on a computer with FAT32 drives because the FAT file system does not have its own permission system.
On networks already possessing a well-planned system of NTFS permissions, share permissions are not really necessary. In this case, you can safely grant the Full Control share permission to Everyone and allow the NTFS permissions to provide security. Adding share permissions would complicate the administration process without providing any additional protection.
Volume Shadow Copies is a Windows Server 2012 R2 feature that enables you to maintain previous versions of files on a server, so if users accidentally delete or overwrite files, they can access a previous copy of those files. You can implement Volume Shadow Copies only for an entire volume; you cannot select specific shares, folders, or files.
To configure a Windows Server 2012 R2 volume to create Shadow Copies, use the following procedure.
Open File Explorer. The File Explorer window appears.
In the Folders list, expand the Computer container, right-click a volume and, from the shortcut menu, select Configure Shadow Copies. The Shadow Copies dialog box appears, as shown in Figure 2-10.
In the Select A Volume box, choose the volume for which you want to enable Shadow Copies. By default, when you enable Shadow Copies for a volume, the system uses the following settings:
To modify the default parameters, click Settings to open the Settings dialog box.
In the Storage Area box, specify the volume where you want to store the shadow copies.
Specify the Maximum Size for the storage area or choose the No Limit option. If the storage area becomes filled, the system begins deleting the oldest shadow copies. However, no matter how much space you allocate to the storage area, Windows Server 2012 R2 supports a maximum of 64 shadow copies for each volume.
Click Schedule to open the Schedule dialog box. By using the controls provided, you can modify the existing Shadow Copies tasks, delete them, or create new ones, based on the needs of your users.
Click OK twice to close the Schedule and Settings dialog boxes.
Click Enable. The system enables the Shadow Copies feature for the selected volume and creates the first copy in the designated storage area.
Close File Explorer.
After you complete this procedure, users can restore previous versions of files on the selected volumes from the Previous Versions tab on any file or folder’s Properties sheet.
Managing disk space is a constant concern for server administrators, and one way to prevent users from monopolizing storage is to implement quotas. Windows Server 2012 R2 supports two types of storage quotas. The more elaborate of the two is implemented as part of File Server Resource Manager. The second, simpler option is NTFS quotas.
The objectives for the 70-410 exam specifically mention NTFS quotas, while the quotas in File Server Resource Manager are covered in the objectives for exam 70-411. Candidates should be careful to distinguish between the two types of quotas.
NTFS quotas enable administrators to set a storage limit for users of a particular volume. Depending on how you configure the quota, users exceeding the limit can either be denied disk space or just receive a warning. The space consumed by individual users is measured by the size of the files they own or create.
NTFS quotas are relatively limited in that you can only set limits at the volume level. The feature is also limited in the actions it can take in response to a user exceeding the limit. The quotas in File Server Resource Manager, by contrast, are much more flexible in the limits you can set and the responses of the program (which can send email notifications, execute commands, generate reports, or create log events.
To configure NTFS quotas for a volume, use the following procedure.
Open File Explorer. The File Explorer window appears.
In the Folders list, expand the Computer container, right-click a volume and, from the shortcut menu, select Properties. The Properties sheet for the volume appears.
Click the Quota tab to display the interface shown in Figure 2-11.
Select the Enable Quota Management check box to activate the rest of the controls.
If you want to prevent users from consuming more than their quota of disk space, select the Deny Disk Space To Users Exceeding Quota Limit check box.
Select the Limit Disk Space To option and specify amounts for the quota limit and the warning level.
Select the Log Event check boxes to control whether users exceeding the specified limits should trigger log entries.
Click OK to create the quota and close the Properties sheet.
Close File Explorer.
Work Folders is a Windows Server 2012 R2 feature that enables administrators to provide their users with synchronized access to their files on multiple workstations and devices while storing them on a network file server. The principle is roughly the same as Microsoft’s SkyDrive service, except that the files are stored on a private Windows server instead of a cloud server on the Internet. This enables administrators to maintain control over the files, backing them up, classifying them, and/or encrypting them as needed.
Work Folders is a new feature in Windows Server 2012 R2 that has been added to the 70-410 objectives. Candidates for the revised exam should be familiar with the process of creating and configuring Work Folders on a server, though they need not dwell on the Windows 8.1 client side of the application.
To set up the Work Folders environment, you install the Work Folders role service in the File and Storage Services role on a server running Windows Server 2012 R2 and create a new type of share called a sync share. This installs the IIS Hostable Web Core feature, which makes it possible for the server to respond to incoming HTTP requests from Work Folders clients on the network.
On the client side, you configure Work Folders in the Windows 8.1 Control Panel, specifying the email address of the user and the location of the Work Folders on the local disk. The system also creates a system folder called Work Folders, which appears in File Explorer and in file management dialogs. When the user saves files to the Work Folders on the client system, they are automatically synchronized with the user’s folder on the Work Folders server.
Users can create as many Work Folders clients as they need on different computers or other devices. After saving files to their Work Folders on their office workstations, for example, users can go home and find those files already synchronized to their home computers. In the same way, Work Folders can synchronize a user’s files to a portable device at the office and the user can work on them while offline during the commute home. Arriving home and connecting to the Internet, the device synchronizes the files back to the server, so that the user finds the latest versions on the office computer the next day.
Work Folders is not designed to be a collaborative tool; it is just a means synchronizing folders between multiple devices while enabling administrators to retain control over them. It is possible to specify that Work Folders files remain encrypted during synchronization and administrators can impose security policies that force the use of lock screens and mandatory data wipes for lost machines.
Creating folder shares makes the data stored on a file server’s disks accessible to network users.
NTFS permissions enable you to control access to files and folders by specifying the tasks individual users can perform on them. Share permissions provide rudimentary access control for all the files on a network share. Network users must have the proper share and NTFS permissions to access file server shares.
ABE applies filters to shared folders based on an individual user’s permissions to the files and subfolders in the share. Simply put, users who cannot access a particular shared resource are unable to see that resource on the network.
Offline Files is a Windows feature that enables client systems to maintain local copies of files they access from server shares.
Volume Shadow Copies is a Windows Server 2012 R2 feature that enables you to maintain previous versions of files on a server, so if users accidentally delete or overwrite a file, they can access a copy.
NTFS quotas enable administrators to set a storage limit for users of a particular volume.
Work Folders is a Windows Server 2012 R2 feature that synchronizes files between multiple client devices and a file server located on a private network.
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the Answers section at the end of this chapter.
What is the maximum number of shadow copies a Windows Server 2012 R2 system can maintain for each volume?
8
16
64
128
Which of the following terms describes the process of granting users access to file server shares by reading their permissions?
Authentication
Authorization
Enumeration
Assignment
Which of the following are tasks you can perform by using the quotas in File Server Resource Manager but can’t perform by using NTFS quotas? (Choose all that apply.)
Send an email message to an administrator when users exceed their limits.
Specify different storage limits for each user.
Prevent users from consuming storage space on a volume beyond their allotted limit.
Generate warnings to users when they approach their allotted storage limit.
In the Windows Server 2012 R2 NTFS permission system, combinations of advanced permissions are also known as _____________ permissions. (Choose all that apply.)
Special
Basic
Share
Standard
Which of the following statements best describes the role of the security principal in file system permission assignments?
The security principal in file system permission assignments is the only person who can access a file that has no permissions assigned to it.
The security principal in file system permission assignments is the person responsible for creating permission policies.
The security principal in file system permission assignments is the person assigning the permissions.
The security principal in file system permission assignments is the person to whom the permissions are assigned.
Like the file-sharing functions discussed in the previous section, print device sharing is one of the most basic applications for which local area networks were designed.
This objective covers how to:
Configure the Easy Print print driver
Configure Enterprise Print Management
Configure drivers
Configure printer pooling
Configure print priorities
Configure printer permissions
Installing, sharing, monitoring, and managing a single network print device is relatively simple, but when you are responsible for dozens or even hundreds of print devices on a large enterprise network, these tasks can be overwhelming.
It is important to understand the terms Microsoft uses when referring to the components of the network printing architecture. Printing in Microsoft Windows typically involves the following four components:
Print device. A print device is the actual hardware that produces hard-copy documents on paper or other print media. Windows Server 2012 R2 supports both local print devices, which are attached directly to computer ports, and network interface print devices, which are connected to the network either directly or through another computer.
Printer. In Windows, a printer is the software interface through which a computer communicates with a print device. Windows Server 2012 R2 supports numerous physical interfaces, including Universal Serial Bus (USB), IEEE 1394 (FireWire), parallel (LPT), serial (COM), Infrared Data Access (IrDA), Bluetooth ports, and network printing services such as LPR, Internet Printing Protocol (IPP), and standard TCP/IP ports.
Print server. A print server is a computer (or standalone device) that receives print jobs from clients and sends them to print devices that are either attached locally or connected to the network.
Printer driver. A printer driver is a device driver that converts the print jobs generated by applications into an appropriate string of commands for a specific print device. Printer drivers are designed for a specific print device and provide applications with access to all the print device’s features.
“Printer” and “print device” are the most commonly misused terms in the Windows printing vocabulary. Obviously, many sources use “printer” to refer to the printing hardware. However, in Windows, printer and print device are not equivalent. For example, you can add a printer to a Windows Server 2012 R2 computer without a physical print device being present. The computer can then host the printer, print server, and printer driver. These three components enable the computer to process the print jobs and store them in a print queue until the print device is available.
These four components work together to process the print jobs produced by Windows applications and turn them into hard-copy documents, as shown in Figure 2-12.
Before you can print documents in Windows, you must install at least one printer. To install a printer in Windows, you must do the following:
Select the print device’s specific manufacturer and model.
Specify the port (or other interface) the computer will use to access the print device.
Supply a printer driver created specifically for that print device.
When you print a document in an application, you select the printer that will be the destination for the print job.
The printer is associated with a printer driver that takes the commands generated by the application and converts them into a printer control language (PCL), a language understood by the printer. PCLs can be standardized, like the PostScript language, or they can be proprietary languages developed by the print device manufacturer.
The printer driver enables you to configure the print job to use the various capabilities of the print device. These capabilities are typically incorporated into the printer’s Properties sheet. For example, your word-processing application does not know if your print device is color or monochrome or if it supports duplex printing. The printer driver provides support for print device features such as these.
After the printer processes a print job, it stores the job in a print queue, known as a spooler. Depending on the arrangement of the printing components, the spooled jobs might be in PCL format, ready to go to the print device, or in an interim format, in which case the printer driver must process the spooled jobs into the PCL format before sending them to the device. If other jobs are waiting to be printed, a new job might wait in the spooler for some time. When the server finally sends the job to the print device, the device reads the PCL commands and produces the hard-copy document.
The flexibility of the Windows print architecture is manifested in the different ways you can deploy the four printing components. A single computer can perform all the roles (except for the print device, of course) or you can distribute those roles across the network. The following sections describe four fundamental configurations that are the basis of most Windows printer deployments:
You can scale these configurations up to accommodate a network of virtually any size.
The simplest print architecture consists of one print device connected to one computer, also known as a locally attached print device, as shown in Figure 2-13. When you connect a print device directly to a Windows Server 2012 R2 computer and print from an application running on that system, the computer supplies the printer, printer driver, and print server functions.
In addition to printing from an application running on that computer, you can also share the printer (and the print device) with other users on the same network. In this arrangement, the computer with the locally attached print device functions as a print server. Figure 2-14 shows the other computers on the network, which are known as the print clients.
In the default Windows Server 2012 R2 printer-sharing configuration, each client uses its own printer and printer driver. As before, the application running on the client computer sends the print job to the printer and the printer driver renders the job, based on the capabilities of the print device.
The main advantage of this printing arrangement is that multiple users, located anywhere on the network, can send jobs to a single print device connected to a computer functioning as a print server. The downside is that processing the print jobs for many users can impose a significant burden on the print server. Although any Windows computer can function as a print server, you should use a workstation for this purpose only when you have no more than a handful of print clients to support or you have a very light printing volume.
The printing solutions discussed thus far involve print devices connected directly to a computer using a USB or other port. Print devices do not necessarily have to be attached to computers, however. You can connect a print device directly to the network instead. Many print device models are equipped with network interface adapters, enabling you to attach a standard network cable. Some print devices have expansion slots into which you can install a network printing adapter you have purchased separately. Finally, for print devices with no networking capabilities, standalone network print servers are available, which connect to the network and enable you to attach one or more print devices. Print devices so equipped have their own IP addresses and typically have an embedded web-based configuration interface.
With network-attached print devices, the primary deployment decision the administrator must make is to decide which computer will function as the print server. One simple (but often impractical) option is to let each print client function as its own print server, as shown in Figure 2-15. Each client processes and spools its own print jobs, connects to the print device by using a TCP (Transmission Control Protocol) port, and sends the jobs directly to the device for printing.
Even individual end users with no administrative assistance will find this arrangement simple to set up. However, the disadvantages are many, including the following:
Users examining the print queue see only their own jobs.
Users are oblivious of the other users accessing the print device. They have no way of knowing what other jobs have been sent to the print device or how long it will be until the print device completes their jobs.
Administrators have no way of centrally managing the print queue because each client has its own print queue.
Administrators cannot implement advanced printing features, such as printer pools (covered later in this section) or remote administration.
Error messages appear only on the computer that originated the job that the print device is currently processing.
All print job processing is performed by the client computer rather than being partially offloaded to an external print server.
For these reasons, this arrangement is suitable only for small workgroup networks that do not have dedicated administrators supporting them.
The other, far more popular option for network-attached printing is to designate one computer as a print server and use it to service all the print clients on the network. To do this, you install a printer on one computer (which becomes the print server) and configure it to access the print device directly through a TCP port. You then share the printer, just as you would a locally attached print device, and configure the clients to access the print share.
As you can see in Figure 2-16, the physical configuration is the same as in the previous arrangement, but the logical path the print jobs take on the way to the print device is different. Instead of going straight to the print device, the jobs go to the print server, which spools them and sends them to the print device in order.
With this arrangement, virtually all the disadvantages of the multiple print server arrangement become advantages:
All the client jobs are stored in a single print queue, so users and administrators can see a complete list of the jobs waiting to be printed.
Part of the job-rendering burden is shifted to the print server, returning control of the client computer to the user more quickly.
Administrators can manage all the queued jobs from a remote location.
Print error messages appear on all client computers.
Administrators can implement printer pools and other advanced printing features.
Administrators can manage security, auditing, monitoring, and logging functions from a central location.
Administrators can use the four configurations described in the previous sections as building blocks to create printing solutions for their networks. Many possible variations can be used to create a network printing architecture that supports your organization’s needs. Some of the more advanced possibilities are as follows:
You can connect a single printer to multiple print devices, creating what is called a printer pool. On a busy network with many print clients, the print server can distribute large numbers of incoming jobs among several identical print devices to provide more timely service and better fault tolerance.
You can connect multiple print devices that support different paper forms and various paper sizes to a single printer, which will distribute jobs with different requirements to the appropriate print devices.
You can connect multiple printers to a single print device. By creating multiple printers, you can configure different priorities, security settings, auditing, and monitoring parameters for different users. For example, you can create a high-priority printer for company executives and a lower-priority printer for junior users. This ensures that the executives’ jobs get printed first, even if the printers are connected to the same print device.
Using Windows Server 2012 R2 as a print server can be simple or complex, depending on how many clients the server has to support and how much printing they do. For a home or small business network, in which a handful of users need occasional access to the printer, no special preparation is necessary. However, if the computer must support heavy printer use, hardware upgrades (such as additional disk space or system memory) might be needed.
You might also consider making the computer a dedicated print server. In addition to memory and disk space, using Windows Server 2012 R2 as a print server requires processor clock cycles, just like any other application. On a server handling heavy print traffic, other roles and applications are likely to experience substantial performance degradation. If you need a print server to handle heavy traffic, consider dedicating the computer to print server tasks only and deploying other roles and applications elsewhere.
On a Windows Server 2012 R2 computer, you can share a printer as you are installing it or at any time afterward. On older printers, you initiate the installation process by launching the Add Printer Wizard from the Devices and Printers control panel. However, most of the print devices on the market today use either a USB connection to a computer or an Ethernet or wireless connection to a network.
In the case of a USB-connected printer, you plug the print device into a USB port on the computer and turn on the device to initiate the installation process. Manual intervention is required only when Windows Server 2012 R2 does not have a driver for the print device.
For network-attached print devices, an installation program supplied with the product locates the print device on the network, installs the correct drivers, creates a printer on the computer, and configures the printer with the proper IP address and other settings.
After the printer is installed on the Windows Server 2012 R2 computer that will function as your print server, you can share it with your network clients by using the following procedure.
Open the Devices and Printers control panel. The Devices and Printers window appears.
Right-click the icon for the printer you want to share and, from the shortcut menu, select Printer Properties. The printer’s Properties sheet appears.
Click the Sharing tab.
Select the Share This Printer check box. The printer name appears in the Share Name text box. You can accept the default name or supply one of your own.
Select one or both of the following optional check boxes:
Render Print Jobs On Client Computers. Minimizes the resource utilization on the print server by forcing the print clients to perform the bulk of the print processing.
List In The Directory. Creates a new printer object in the Active Directory Domain Services (AD DS) database, enabling domain users to locate the printer by searching the directory. This option appears only when the computer is a member of an AD DS domain.
Optionally, click Additional Drivers to open the Additional Drivers dialog box. This dialog box enables you to load printer drivers for other Windows platforms, such as x86. When you install the alternate drivers, the print server automatically supplies them to clients running those operating system versions.
Select any combination of the available check boxes and click OK. For each check box you select, Windows Server 2012 R2 displays a Printer Drivers dialog box.
In each Printer Drivers dialog box, type or browse to the location of the printer drivers for the selected operating system and click OK.
Click OK to close the Additional Drivers dialog box.
Click OK to close the Properties sheet for the printer. The printer icon in the Printers control panel now includes a symbol indicating that it has been shared.
Close the control panel.
At this point, the printer is available to clients on the network.
Printer drivers are the components that enable your computers to manage the capabilities of your print devices. When you install a printer on a server running Windows Server 2012 R2, you also install a driver that other Windows computers can use.
The printer drivers you install on Windows Server 2012 R2 are the same drivers that Windows workstations and other server versions use, with one stipulation. As a 64-bit platform, Windows Server 2012 R2 uses 64-bit device drivers, which are suitable for other computers running 64-bit versions of Windows. If you have 32-bit Windows systems on your network, however, you must install a 32-bit driver on the server for those systems to use.
The Additional Drivers dialog box, accessible from the Sharing tab of a printer’s Properties sheet, enables you to install drivers for other processor platforms. However, you must install those drivers from a computer running on the alternative platform. In other words, to install a 32-bit driver for a printer on a server running Windows Server 2012 R2, you must access the printer’s Properties sheet from a computer running a 32-bit version of Windows. You can do this by accessing the printer directly through the network by using File Explorer or by running the Print Management snap-in on the 32-bit system and using it to manage your Windows Server 2012 R2 print server.
For the server to provide drivers supporting different platforms to client computers, you must make sure when installing the drivers for the same print device that they have identical names. For example, Windows Server 2012 R2 will treat “HP LaserJet 5200 PCL6” and “HP LaserJet 5200 PCL 6” as two different drivers. The names must be identical in order for the server to apply the drivers properly.
When a Remote Desktop Services client connects to a server, it runs applications using the server’s processor(s) and memory. However, if that client wants to print a document from one of those applications, it wants the print job to go to the print device connected to the client computer.
The component that enables Remote Desktop clients to print to their local print devices is called Easy Print. Easy Print takes the form of a printer driver that is installed on the server along with the Remote Desktop Session Host role service.
The Remote Desktop Easy Print driver appears automatically in the Print Management snap-in, but it is not associated with a particular print device. Instead, the driver functions as a redirector, enabling the server to access the printers on the connected clients.
On Windows Server 2012 R2, Easy Print requires no configuration other than the allowance of Remote Desktop connections or the installation of the Remote Desktop Services role. However, once it is operational, it provides the server administrator with additional access to the printers on the Remote Desktop clients.
When a Remote Desktop client connects to a server by using the Remote Desktop Connection program or the RD Web Access site, the printers installed on the client system are redirected to the server and appear in the Print Management snap-in as redirected server printers, as shown in Figure 2-17.
A client running an application on the server can therefore print to a local print device using the redirected printer. Administrators can also open the Properties sheet for the redirected printer in the usual manner and then manipulate its settings.
As with folder shares, clients must have the proper permissions to access a shared printer. Printer permissions are much simpler than NTFS permissions; they dictate whether users are allowed to use the printer, manage documents submitted to the printer, or manage the properties of the printer itself. To assign permissions for a printer, use the following procedure.
Open Control Panel and select Hardware, Devices and Printers. The Devices and Printers window appears.
Right-click one of the printer icons in the window and, from the shortcut menu, select Printer Properties. The printer’s Properties sheet appears.
Click the Security tab. The top half of the display lists all the security principals currently possessing permissions to the selected printer. The bottom half lists the permissions held by the selected security principal.
Click Add. The Select Users, Computers, Or Groups dialog box appears.
In the Enter The Object Names To Select text box, type a user or group name and click OK. The user or group appears in the Group Or User Names list.
Select the security principal you added and select or clear the check boxes in the bottom half of the display to Allow or Deny the user any of the basic permissions.
Click OK to close the Properties sheet.
Close Control Panel.
Like NTFS permissions, there are two types of printer permissions: basic and advanced. Each of the three basic permissions consists of a combination of advanced permissions.
By default, all printers assign the Allow Print permission to the Everyone special identity, which enables all users to access the printer and manage their own documents. Users who possess the Allow Manage Documents permission can manage any users’ documents.
Managing documents refers to pausing, resuming, restarting, and canceling documents that are currently waiting in a print queue. Windows Server 2012 R2 provides a print queue window for every printer, which enables users to view the jobs that are currently waiting to be printed. To manage documents, use the following procedure.
Open Control Panel and select Hardware, Devices and Printers. The Devices and Printers window appears.
Right-click one of the printer icons and, from the shortcut menu, select See What’s Printing. A print queue window named for the printer appears, as shown in Figure 2-18.
Select one of the menu items to perform the associated function.
Close the print queue window.
Close Control Panel.
Users with the Allow Manage This Printer permission can go beyond manipulating queued documents; they can reconfigure the printer itself. Managing a printer refers to altering the operational parameters that affect all users and controlling access to the printer.
Generally, most of the software-based tasks that fall under the category of managing a printer are those you perform once while setting up the printer for the first time. Day-to-day printer management is more likely to involve physical maintenance, such as clearing print jams, reloading paper, and changing toner or ink cartridges. However, the following sections examine some of the printer manager’s typical configuration tasks.
In some cases, administrators with the Manage This Printer permission might want to give certain users in your organization priority access to a print device so that when print traffic is heavy, their jobs are processed before those of other users. To do this, you must create multiple printers, associate them with the same print device, and then modify their priorities, as described in the following procedure.
Open Control Panel and select Hardware, Devices and Printers. The Devices and Printers window opens.
Right-click one of the printer icons and, from the shortcut menu, select Printer Properties. The Properties sheet for the printer appears.
Click the Advanced tab, as shown in Figure 2-19.
Set the Priority spin box to a number representing the highest priority you want to set for the printer. Higher numbers represent higher priorities. The highest possible priority is 99.
The values of the Priority spin box do not have any absolute significance; they are pertinent only in relation to one another. As long as one printer has a higher priority value than another, the server will process its print jobs first. In other words, it doesn’t matter if the higher priority value is 9 or 99, as long as the lower priority value is less.
Click the Security tab.
Add the users or groups that you want to provide with high-priority access to the printer and assign the Allow Print permission to them.
Revoke the Allow Print permission from the Everyone special identity.
Click OK to close the Properties sheet.
Create an identical printer using the same printer driver and pointing to the same print device. Leave the Priority setting at its default value of 1 and leave the default permissions in place.
Rename the printers, specifying the priority assigned to each one.
Close Control Panel.
Inform the privileged users that they should send their jobs to the high-priority printer. All jobs sent to that printer will be processed before those sent to the other, lower-priority printer.
As mentioned earlier, a printer pool increases the production capability of a single printer by connecting it to multiple print devices. When you create a printer pool, the print server sends each incoming job to the first print device it finds that is not busy. This effectively distributes the jobs among the available print devices, providing users with more rapid service.
To configure a printer pool, use the following procedure.
Open Control Panel and select Hardware, Devices and Printers. The Devices and Printers window opens.
Right-click one of the printer icons and, from the shortcut menu, select Printer Properties. The Properties sheet for the printer appears.
Click the Ports tab.
Select the Enable Printer Pooling check box and click OK.
Select all the ports to which the print devices are connected.
Close Control Panel.
To create a printer pool, you must have at least two identical print devices, or at least two print devices that use the same printer driver. The print devices must be in the same location because there is no way to tell which print device will process a given document. You must also connect all the print devices in the pool to the same print server. If the print server is a Windows Server 2012 R2 computer, you can connect the print devices to any viable ports.
All the printer sharing and management capabilities discussed in the previous sections are available on any Windows Server 2012 R2 computer in its default installation configuration. However, installing the Print And Document Services role on the computer provides additional tools that are particularly useful to administrators involved with network printing on an enterprise scale.
When you install the Print And Document Services role by using Server Manager’s Add Roles And Features Wizard, a Select Role Services page appears, enabling you to select from the following options:
Print Server. Installs the Print Management console for Microsoft Management Console (MMC), which enables administrators to deploy, monitor, and manage printers throughout the enterprise
Distributed Scan Server. Enables the computer to receive documents from network-based scanners and forward them to the appropriate users
Internet Printing. Creates a website that enables users on the Internet to send print jobs to shared Windows printers
LPD Service. Enables UNIX clients running the line printer remote (LPR) program to send their print jobs to Windows printers
As always, Windows Server 2012 R2 adds a new icon to the Server Manager navigation pane when you install a role. The Print Services home page contains a filtered view of print-related event log entries, a status display for the role-related system services and role services, and performance counters.
The Print Management console, an administrative tool, consolidates the controls for the printing components throughout the enterprise into a single console. By using this tool, you can access the print queues and Properties sheets for all the network printers in the enterprise, deploy printers to client computers by using Group Policy, and create custom views that simplify the process of detecting print devices that need attention due to errors or depleted consumables.
Windows Server 2012 R2 installs the Print Management console when you add the Print And Document Services role to the computer. You can also install the console without the role by adding the Print And Document Services Tools feature, found under Remote Server Administration Tools, Role Administration Tools in the Add Roles And Features Wizard.
The following sections demonstrate some of the administration tasks you can perform by using the Print Management console.
By default, the Print Management console displays only the local machine in its list of print servers. Each print server has four nodes beneath it, as shown in Figure 2-20, listing the drivers, forms, ports, and printers associated with that server.
To manage other print servers and their printers, you must add them to the console by using the following procedure.
In Server Manager, click Tools and then click Print Management to open the Print Management console.
Right-click the Print Servers node and, from the shortcut menu, click Add/Remove Servers to open the Add/Remove Servers dialog box.
In the Specify Print Server box, click Browse. The Select Print Server dialog box opens.
Select the print server you want to add to the console and click Select Server. The server you selected appears in the Add Server text box in the Add/Remove Servers dialog box.
Click Add To List. The server you selected appears in the Print Servers list.
Click OK. The server appears under the Print Servers node.
Close the Print Management console.
You can now manage the printers associated with the server you have added to the console.
One of the major difficulties for printing administrators on large enterprise networks is keeping track of dozens or hundreds of print devices, all in frequent use and all needing attention on a regular basis. Whether the maintenance required is a major repair, an ink or toner replenishment, or a paper tray refill, print devices will not get the attention they need until an administrator is aware of the problem.
The Print Management console provides multiple ways to view the printing components associated with the print servers on the network. To create views, the console takes the complete list of printers and applies various filters to it, selecting which printers to display. Under the Custom Filters node, there are four default filters, as follows:
All Printers. Contains a list of all the printers hosted by all the print servers which have been added to the console
All Drivers. Contains a list of all the printer drivers installed on all the print servers which have been added to the console
Printers Not Ready. Contains a list of all printers that are not reporting a Ready status
Printers With Jobs. Contains a list of all the printers that currently have jobs waiting in the print queue
Views such as Printer Not Ready are a useful way for administrators to identify printers that need attention without having to browse individual print servers or search through a long list of every printer on the network. In addition to these defaults, you can create your own custom filters.
After you have used filtered views to isolate the printers you want to examine, selecting a printer displays its status, the number of jobs currently in its print queue, and the name of the print server hosting it. If you right-click the filter in the left pane and select Show Extended View from the shortcut menu, an additional pane appears containing the contents of the selected printer’s queue. You can manipulate the queued jobs just as you would from the Print Queue window in the Print Server console.
The Print Management console also enables administrators to access the configuration interface for any printer or print server appearing in any of its displays. Right-clicking a printer or print server anywhere in the console interface and then selecting Properties from the shortcut menu displays the same Properties sheet you would see on the print server computer itself. Administrators can then configure printers and print servers without having to travel to the site of the print server or establish a Remote Desktop connection to the print server.
Configuring a print client to access a shared printer is a simple matter of browsing the network or the AD DS tree and selecting the printer. However, when you have to configure hundreds or thousands of print clients, the task becomes more complicated. AD DS helps simplify the process of deploying printers to large numbers of clients.
Publishing printers in the AD DS database enables users and administrators to search for printers by name, location, or model (if you populate the Location and Model fields in the printer object). To create a printer object in the AD DS database, you can either select the List In The Directory check box while sharing the printer or right-click a printer in the Print Management console and, from the shortcut menu, select List In Directory.
To use AD DS to deploy printers to clients, you must configure the appropriate policies in a Group Policy object (GPO). You can link a GPO to any domain, site, or organizational unit (OU) in the AD DS tree. When you configure a GPO to deploy a printer, all the users or computers in that domain, site, or OU will receive the printer connection by default when they log on.
To deploy printers with Group Policy, use the following procedure.
In the Print Management console, right-click a printer in the console’s scope pane and, from the shortcut menu, select Deploy With Group Policy. The Deploy With Group Policy dialog box appears, as shown in Figure 2-21.
Click Browse to open the Browse For A Group Policy Object dialog box.
Select the GPO you want to use to deploy the printer and click OK. The GPO you selected appears in the GPO Name field.
Select the appropriate check box to select whether to deploy the printer to the users associated with the GPO, the computers (or both) and click Add. The new printer GPO associations appear in the table.
Deploying the printer to the users means that all the users associated with the GPO will receive the printer connection no matter what computer they use to log on. Deploying the printer to the computers means that all the computers associated with the GPO will receive the printer connection no matter who logs on to them.
Click OK. A Print Management message box appears, informing you that the operation has succeeded.
Click OK and then click OK again to close the Deploy With Group Policy dialog box.
Close the Print Management console.
The next time the users running Windows Server 2008 or later and Windows Vista or later who are associated with the GPO refresh their policies or restart, they will receive the new settings and the printer will appear in the Devices and Printers control panel.
Printing in Windows typically involves the following four components: print device, printer, print server, and print driver.
The simplest form of print architecture consists of one print device connected to one computer, known as a locally attached print device. You can share this printer (and the print device) with other users on the same network.
With network-attached print devices, the administrator’s primary deployment decision is which computer will function as the print server.
Remote Desktop Easy Print is a driver that enables Remote Desktop clients running applications on a server to redirect their print jobs back to their local print devices.
Printer permissions are much simpler than NTFS permissions; they dictate whether users are allowed to use the printer, manage documents submitted to the printer, or manage the properties of the printer itself.
The Print Management console is an administrative tool that consolidates the controls for the printing components throughout the enterprise into a single console.
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the Answers section at the end of this chapter.
Which of the following terms best describes the software interface through which a computer communicates with a print device?
Printer
Print server
Printer driver
Print Management console
You are setting up a printer pool on a computer running Windows Server 2012 R2. The printer pool contains three identical print devices. You open the Properties dialog box for the printer and select the Enable Printer Pooling option on the Ports tab. Which of the following steps must you perform next?
Configure the LPT1 port to support three printers.
Select or create the ports mapped to the three printers.
On the Device Settings tab, configure the installable options to support two additional print devices.
On the Advanced tab, configure the priority for each print device so that printing is distributed among the three print devices.
One of your print devices is not working properly, so you want to temporarily prevent users from sending jobs to the printer serving that device. Which of the following actions should you take?
Stop sharing the printer.
Remove the printer from Active Directory.
Change the printer port.
Rename the share.
You are administering a computer running Windows Server 2012 R2 configured as a print server. Users in the Marketing group report that they cannot print documents using a printer on the server. You view the permissions in the printer’s properties. The Marketing group is allowed Manage Documents permission. Which of the following statements best explains why the users cannot print to the printer?
The Everyone group must be granted the Manage Documents permission.
The Administrators group must be granted the Manage Printers permission.
The Marketing group must be granted the Print permission.
The Marketing group must be granted the Manage Printers permission.
You are administering a print server running Windows Server 2012 R2. You want to perform maintenance on a print device physically connected to the print server. There are several documents in the print queue. You want to prevent the documents from being printed to the printer, but you don’t want users to have to resubmit the documents to the printer. Which of the following statements best describes the best way to do this?
Open the printer’s Properties dialog box, select the Sharing tab, and select the Do Not Share This Printer option.
Open the printer’s Properties dialog box and select a port that is not associated with a print device.
Open the printer’s queue window, select the first document, and select Pause from the Document window.
Open the printer’s queue window and select the Pause Printing option from the Printer menu.
Windows Server 2012 R2 is designed to facilitate remote server management so administrators rarely, if ever, have to work directly at the server console. This conserves server resources that can better be devoted to applications and saves administrators’ time.
Configure WinRM
Configure down-level server management
Configure servers for day-to-day management tasks
Configure multiserver management
Configure Server Core
Configure Windows Firewall
Manage non-domain joined servers
Server Manager has been the primary server administration tool for Windows Server ever since Windows Server 2003. The most obvious improvement to the Server Manager tool in Windows Server 2012 R2 is the ability to perform administrative tasks on remote servers and on the local system.
When you log on to a GUI installation of Windows Server 2012 R2 with an administrative account, Server Manager loads automatically, displaying the Welcome tile. The Server Manager interface consists of a navigation pane on the left containing icons representing various views of server resources. Selecting an icon displays a home page in the right pane, which consists of a number of tiles containing information about the resource. The Dashboard page, which appears by default, contains, in addition to the Welcome tile, thumbnails that summarize the other views available in Server Manager. These other views include a page for the Local Server, a page for All Servers, containing any additional servers you have added to the manager, and others for server groups and role groups.
For information on adding servers to the Server Manager interface, see “Adding Servers” in Objective 1.2, “Configuring Servers.”
The primary difference between the Windows Server 2012 R2 (and Windows Server 2012) Server Manager and previous versions is the ability to add and manage multiple servers at once. Although only the local server appears in Server Manager when you first run it, you can add other servers, enabling you to manage them together. The servers you add can be physical or virtual and can be running any version of Windows Server since Windows Server 2003. After you add servers to the interface, you can create groups containing collections of servers, such as those at a particular location or those performing a particular function. These groups appear in the navigation pane, enabling you to administer them as a single entity.
To add servers in Server Manager, use the following procedure.
In the navigation pane, click the All Servers icon to open the All Servers home page.
From the Manage menu, select Add Servers to open the Add Servers dialog box.
Select one of the following tabs to specify how you want to locate servers to add:
Active Directory. Enables you to search for computers running specific operating systems in specific locations in the local AD DS domain
DNS. Enables you to search for servers in your currently configured Domain Name System (DNS) server
Import. Enables you to supply a text file containing the names or IP addresses of the servers you want to add
Initiate a search or upload a text file to display a list of available servers.
Select the servers you want to add and click the right arrow button to add them to the Selected list, as shown in Figure 2-22.
Click OK. The servers you selected are added to the All Servers home page.
Close the Server Manger console.
Once you have added remote servers to the Server Manager interface, they appear on the All Servers home page. You can then access them in a variety of ways, depending on the version of Windows the remote server is running.
When you add servers that are members of an Active Directory Domain Services (AD DS) domain to the Server Manager interface, Windows Server 2012 R2 uses the standard Kerberos authentication protocol and your current domain credentials when connecting to the remote systems. You can also add servers that are not joined to an AD DS domain, but obviously, the system cannot authenticate using an AD DS account.
Candidates for the 70-410 exam should be familiar with remote management techniques for both non-domain servers and domain servers. This means using alternative authentication methods and network communication that does not rely on AD DS for server discovery.
To manage a non-domain joined server using Server Manager, you must first complete the following tasks:
Supply administrative credentials for the non-domain joined server
Add the non-domain joined server to the system’s WS-Management TrustedHosts list
To add non-domain joined servers to Server Manager, you must use the DNS option or the Import option in the Add Servers Wizard. After creating the server entries, you must right-click each one and select Manage As from the context menu. This displays a Windows Security dialog box, in which you can supply credentials for an account with administrative privileges on the remote server.
Domain membership automatically establishes a trust relationship among the computers in the domain. To manage computers that are not in a common domain, you must establish that trust yourself by adding the computers you want to manage to the TrustedHosts list on the computer running Server Manager.
The TrustedHosts list exists on a logical drive called WSMan:; the path to the list itself is WSMan:\localhost\Client\TrustedHosts. To add a computer to the list, use the Set-Item cmdlet in Windows PowerShell. After opening a Windows PowerShell session with administrative privileges on the computer running Server Manager, use the following command to add the servers you want to manage to the list:
Set-Item WSMan:\localhost\Client\TrustedHosts –value <servername> -force
When you add servers running Windows Server 2012 R2 to Server Manager, you can immediately begin using the Add Roles and Features Wizard to install roles and features on any of the servers you have added.
You can also perform other administrative tasks, such as configuring network interface card (NIC) teaming and restarting the server, because Windows Remote Management (WinRM) is enabled by default on Windows Server 2012 R2.
WinRM enables administrators to manage a computer from a remote location by using tools based on Windows Management Instrumentation (WMI) and Windows PowerShell. If the default WinRM setting has been modified, or if you want to change it manually, you can do so through the Server Manager interface.
On the Local Server home page, the Properties tile contains a Remote Management indicator that specifies the server’s current WinRM status. To change the WinRM state, click the Remote Management hyperlink to open the Configure Remote Management dialog box. Clearing the Enable Remote Management Of This Server From Other Computers check box disables WinRM; selecting the check box enables it.
If you attempt to launch MMC snap-ins targeting a remote server, such as the Computer Management console, you will receive an error because of the default Windows Firewall settings in Windows Server 2012 R2. MMC uses the Distributed Component Object Model (DCOM) for remote management instead of WinRM, and these settings are not enabled by default.
To address this problem, you must enable the following inbound Windows Firewall rules on the remote server you want to manage:
COM+ Network Access (DCOM-In)
Remote Event Log Management (NP-In)
Remote Event Log Management (RPC)
Remote Event Log Management (RPC-EPMAP)
To modify the firewall rules on the remote system, you can use any one of the following methods:
Open the Windows Firewall with Advanced Security MMC snap-in on the remote server (if it is a Full GUI installation).
Use the NetSecurity module in Windows PowerShell.
Create a GPO containing the appropriate settings and apply it to the remote server.
Run the Netsh AdvFirewall command from an administrative command prompt.
To configure the Windows Firewall rules required for remote server management using DCOM on a Server Core installation, you can use the following Windows PowerShell syntax:
Set-NetFirewallRule –name <rule name> –enabled True
To obtain the Windows PowerShell names for the preconfigured rules in Windows Firewall, use the Get-NetFirewallRule command. The resulting commands to enable the four rules listed earlier are as follows:
Set-NetFirewallRule –name ComPlusNetworkAccess-DCOM-In –enabled True Set-NetFirewallRule –name RemoteEventLogSvc-In-TCP –enabled True Set-NetFirewallRule –name RemoteEventLogSvc-NP-In-TCP –enabled True Set-NetFirewallRule –name RemoteEventLogSvc-RPCSS-In-TCP –enabled True
For the administrator interested in remote management solutions, the Group Policy method provides distinct advantages. It not only enables you to configure the firewall on the remote system without accessing the server console directly but enables you to configure the firewall on Server Core installations without having to work from the command line. Finally—and possibly most important for large networks—you can use Group Policy to configure the firewall on all the servers you want to manage at once.
To configure Windows Firewall settings by using Group Policy, use the following procedure. This procedure assumes the server is a member of an AD DS domain and has the Group Policy Management feature installed:
In Server Manager, open the Group Policy Management console and create a new GPO, giving it a name like Server Firewall Configuration.
Open the GPO you created using the Group Policy Management Editor.
Browse to the Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules node.
Right-click Inbound Rules and, from the shortcut menu, select New Rule. The New Inbound Rule Wizard appears, displaying the Rule Type page.
Select the Predefined option and, in the drop-down list, select COM+ Network Access and click Next. The Predefined Rules page opens.
Click Next to open the Action page.
Leave the Allow The Connection option selected and click Finish. The rule appears in the Group Policy Management Editor console.
Open the New Inbound Rule Wizard again.
Select the Predefined option and, in the drop-down list, select Remote Event Log Management. Click Next. The Predefined Rules page opens, displaying the three rules in the Remote Event Log Management group.
Leave the three rules selected and click Next to open the Action page.
Leave the Allow The Connection option selected and click Finish. The three rules appear in the Group Policy Management Editor console.
Close the Group Policy Management Editor console.
In the Group Policy Management console, link the Server Firewall Configuration GPO you just created to your domain.
Close the Group Policy Management console.
The settings in the GPO you created will be deployed to your remote servers the next time they recycle or restart and you will be able to use MMC snap-ins, such as Computer Management and Disk Management, to connect to them remotely.
The Windows Firewall rules you have to enable for remote servers running Windows Server 2012 R2 are also disabled by default on computers running earlier versions of Windows Server, so you also have to enable them there.
Unlike Windows Server 2012 R2 and Windows Server 2012, however, earlier versions of the operating system lack the WinRM support needed for them to be managed by using the new Server Manager.
By default, when you add servers running Windows Server 2008 or Windows Server 2008 R2 to the Windows Server 2012 R2 Server Manager, they appear with a manageability status that reads “Online - Verify WinRM 3.0 service is installed, running, and required firewall ports are open.”
To add WinRM support to servers running Windows Server 2008 or Windows Server 2008 R2, you must download and install the following updates:
.NET Framework 4.0
Windows Management Framework 3.0
These updates are available from the Microsoft Download Center at the following URLs:
After you install the updates, the system automatically starts the Windows Remote Management service, but you must still complete the following tasks on the remote server:
Enable the Windows Remote Management (HTTP-In) rules in Windows Firewall, as shown in Figure 2-23.
Create a WinRM listener by running the winrm quickconfig command at a command prompt with Administrative privileges.
Enable the COM+ Network Access and Remote Event Log Management rules in Windows Firewall, as described in the previous section.
After installing the updates listed here, there are still limitations to the management tasks you can perform on earlier versions of Windows Server from a remote location. For example, you cannot use the Add Roles And Features Wizard in Server Manager to install roles and features on earlier versions of Windows Server. These servers do not appear in the server pool on the Select Destination Server page.
However, you can use Windows PowerShell to install roles and features on servers running Windows Server 2008 and Windows Server 2008 R2 remotely, as in the following procedure.
Open a Windows PowerShell session with Administrative privileges.
Establish a Windows PowerShell session with the remote computer by using the following command:
Enter-PSSession <remote server name> -credential <user name>
Type the password associated with the user name you specified and press Enter.
Display a list of the roles and features on the remote server by using the following command:
Get-WindowsFeature
Using the short name of the role or service as it appears in the Get-WindowsFeature display, install the component by using the following command:
Add-WindowsFeature <feature name>
Close the session with the remote server by using the following command:
Exit-PSSession
Close the Windows PowerShell window.
When you install a role or feature on a remote server by using Windows PowerShell, the installation does not include the role’s management tools as a wizard-based installation does. However, you can install the tools along with the role or feature if you include the IncludeManagementTools parameter in the Install-WindowsFeature command line. Be aware, however, that in the case of a Server Core installation, adding the IncludeManagementTools parameter will not install any MMC snap-ins or other graphical tools.
For administrators of enterprise networks, it might be necessary to add a large number of servers to Server Manager. To avoid having to work with a long scrolling list of servers, you can create server groups based on server locations, functions, or any other organizational paradigm.
When you create a server group, it appears as an icon in the navigation pane, and you can manage the servers in the group just as you would those in the All Servers group.
To create a server group, use the following procedure:
In Server Manager, in the navigation pane, click the All Servers icon. The All Servers home page appears.
From the Manage menu, select Create Server Group to open the Create Server Group dialog box, as shown in Figure 2-24.
In the Server Group Name text box, type the name you want to assign to the server group.
Select one of the four tabs to choose a method for selecting servers.
Select the servers you want to add to the group and click the right arrow button to add them to the Selected box.
Click OK. A new server group icon with the name you specified appears in the navigational pane.
Close the Server Manager console.
Creating server groups does not affect the functions you can perform on them. You cannot, for example, perform actions on entire groups of servers. The groupings are just a means to keep a large number of servers organized and easy to locate.
You can manage remote servers from any computer running Windows Server 2012 R2; all the required tools are installed by default. However, administrators have found it most efficient to use their client computers to manage servers remotely (especially with the introduction of cloud-based services).
To manage Windows servers from a workstation, you must download and install the Remote Server Administration Tools package for the version of Windows running on your workstation from the Microsoft Download Center at http://www.microsoft.com/download.
Remote Server Administration Tools is packaged as a Microsoft Update file with an .msu extension, enabling you to deploy it easily from File Explorer, from the command prompt, or by using Software Distribution in a GPO. When you install Remote Server Administration Tools on a workstation running Windows 8 or Windows 8.1, all the tools are activated by default, unlike in previous versions that required you to turn them on by using the Windows Features control panel. You can still use the control panel to turn selected features off, however.
When you launch Server Manager on a Windows workstation, there is no local server and there are no remote servers to manage until you add some. You add servers by using the same process described in Objective 1.2.
Your access to the servers you add depends on the account you use to log on to the workstation. If an “Access denied” message appears, you can connect to the server using another account by right-clicking it and, from the shortcut menu, selecting Manage As to display a standard Windows Security dialog box, in which you can supply alternative credentials.
Once you have added remote servers to Server Manager, you can access them using a variety of remote administration tools.
Server Manager provides three basic methods for addressing remote servers, as follows:
Contextual tasks. When you right-click a server in a Servers tile anywhere in Server Manager, you see a shortcut menu that provides access to tools and commands pointed at the selected server. Some of these are commands that Server Manager executes on the remote server, such as Restart Server and Windows PowerShell. Others launch tools on the local system and direct them at the remote server, such as MMC snap-ins and the Install Roles And Features Wizard. Still others modify Server Manager itself by removing servers from the interface. Other contextual tasks sometimes appear in the Tasks menus for specific panes.
Noncontextual tasks. The menu bar at the top of the Server Manager console provides access to internal tasks, such as launching the Add Server Wizard and the Install Roles And Features Wizard, and the Server Manager Properties dialog box, in which you can specify the console’s refresh interval.
Noncontextual tools. The console’s Tools menu provides access to external programs, such as MMC snap-ins and the Windows PowerShell interface, that are directed at the local system.
Windows Server 2012 R2 is designed to facilitate remote server management so administrators rarely if ever have to work directly at the server console. This conserves server resources that can better be devoted to applications.
When you add servers running Windows Server 2012 R2 to Server Manager, you can immediately begin using the Add Roles and Features Wizard to install roles and features on any of the servers you have added.
The Windows Firewall rules you have to enable for remote servers running Windows Server 2012 R2 are also disabled by default on computers running versions earlier than Windows Server 2012, so you also have to enable them there.
For administrators of enterprise networks, it might be necessary to add a large number of servers to Server Manager. To avoid having to work with a long scrolling list of servers, you can create server groups based on server locations, functions, or any other organizational paradigm.
You can manage remote servers from any computer running Windows Server 2012 R2; all the required tools are installed by default. However, the new administrative method that Microsoft is promoting urges administrators to keep servers locked away and use a workstation to manage servers from a remote location.
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the Answers section at the end of this chapter.
Which of the following tasks must you perform before you can manage a remote server running Windows Server 2012 R2 using the Computer Management snap-in?
Enable WinRM on the remote server.
Enable the COM+ Network Access rule on the remote server.
Enable the Remote Event Log Management rules on the remote server.
Install Remote Server Administration Tools on the remote server.
Which of the following Windows PowerShell cmdlets can you use to list the existing Windows Firewall rules on a computer running Windows Server 2012 R2? (Choose all that apply.)
Get-NetFirewallRule
Set-NetFirewallRule
Show-NetFirewallRule
New-NetFirewallRule
Which of the following tasks can you not perform remotely on a server running Windows Server 2008?
Install roles by using Server Manager
Install roles by using Windows PowerShell
Connect to the remote server by using the Computer Management snap-in
Monitor event log entries
Which of the following updates must you install on a server running Windows Server 2008 before you can connect to it by using Windows Server 2012 R2 Server Manager? (Choose all that apply.)
.NET Framework 3.5
.NET Framework 4.0
Windows Management Framework 3.0
Windows Server 2008 R2
When you run Server Manager from a Windows 8 workstation using Remote Server Administration Tools, which of the following elements do not appear in the default display?
The Dashboard
The Local Server home page
The All Servers home page
The Welcome tile
This section contains the solutions to the thought experiments and answers to the objective review questions in this chapter.
The most likely cause of the problem is that Leo does not have sufficient share permissions for read/write access to the Contoso files. Granting the CONTOSO_USERS group the Allow Full Control share permission should enable Leo to save his changes to the Contoso files.
Correct answer: C
Incorrect: Windows Server 2012 R2 can maintain more than 8 volume shadow copies.
Incorrect: Windows Server 2012 R2 can maintain more than 16 volume shadow copies.
Correct: Windows Server 2012 R2 can maintain up to 64 volume shadow copies before it begins deleting the oldest data.
Incorrect: Windows Server 2012 R2 cannot maintain 128 volume shadow copies.
Correct answer: B
Incorrect: Authentication is the process of verifying the user’s identity.
Correct: Authorization is the process by which a user is granted access to specific resources based on the permissions he or she possesses.
Incorrect: Access-based enumeration is a Windows feature that prevents users from seeing resources to which they do not have permissions.
Incorrect: Assignment describes the process of granting permissions, not reading permissions.
Correct answer: A
Correct: Using File Server Resource Manager, you can notify administrators with email messages when users exceed their allotment of storage.
Incorrect: Using NTFS Quotas, you can create quotas for individual users that specify different storage limits.
Incorrect: You can use NTFS quotas to prevent users from consuming storage space on a volume beyond their allotted limit.
Incorrect: You can use NTFS quotas to generate warnings to users when they approach their allotted storage limit.
Correct answers: B, D
Incorrect: In Windows Server versions prior to Windows Server 2012 R2, special permissions are combined to form standard permissions.
Correct: Basic permissions are formed by creating various combinations of advanced permissions.
Incorrect: Share permissions are a system that is separate from the NTFS permission system.
Correct: In Windows Server versions prior to Windows Server 2012 R2, standard permissions are formed by creating various combinations of special permissions.
Correct answer: D
Incorrect: The owner is the only person who can access a file that has no permissions assigned to it.
Incorrect: The security principal is not the person responsible for creating an organization’s permission policies.
Incorrect: The security principal receives permissions; the security principal does not create them.
Correct: The security principal is the user or computer to which permissions are assigned.
Install additional, identical printers, connecting them to the same Windows Server 2012 R2 print server, and create a printer pool by selecting the appropriate check box on the Ports tab of the printer’s Properties sheet.
Correct answer: A
Correct: In Windows, a printer is the software interface through which a computer communicates with a print device.
Incorrect: A print server is a device that receives print jobs from clients and sends them to print devices that are either attached locally or connected to the network.
Incorrect: A printer driver is a device driver that converts the print jobs generated by applications into an appropriate string of commands for a specific print device.
Incorrect: The Print Management snap-in is a tool that administrators can use to manage printers all over the network.
Correct answer: B
Incorrect: Whether the printers are pooled or not, each one must be connected to a separate port.
Correct: To set up printer pooling, select the Enable Printer Pooling check box and select or create the ports corresponding to printers that will be part of the pool.
Incorrect: You do not use the installable options settings to create a printer pool.
Incorrect: Priorities have nothing to do with printer pooling.
Correct answer: A
Correct: If you stop sharing the printer, users will no longer be able to use the print device.
Incorrect: Removing the printer from Active Directory will prevent users from finding the printer by using a search, but they can still access it.
Incorrect: Changing the printer port will prevent the printer from sending jobs to the print device, but it will not prevent users from sending jobs to the printer.
Incorrect: Renaming the share can make it difficult for users to find the printer, but they can still use it when they do find it.
Correct answer: C
Incorrect: The Manage Documents permission does not allow users to send jobs to the printer.
Incorrect: The Manage Printers permission does not allow users to send jobs to the printer.
Correct: The Print permission allows users to send documents to the printer; the Manage Documents permission does not.
Incorrect: The Manage Documents permission does not allow users to send jobs to the printer.
Correct answer: D
Incorrect: A printer that is not shared will continue to process jobs that are already in the queue.
Incorrect: Changing the port will require the users to resubmit the jobs that were in the queue.
Incorrect: Pausing the first document in the queue will not prevent the other queued jobs from printing.
Correct: When you select the Pause Printing option, the documents will remain in the print queue until you resume printing. This option applies to all documents in the queue.
After creating a GPO containing the required Windows Firewall settings, Ralph should create a security group containing all the 24 computer objects representing his servers. Then he should link the GPO to the company domain and use security filtering to limit the scope of the GPO to the group he created.
Correct answer: B
Incorrect: WinRM is enabled by default on Windows Server 2012 R2.
Correct: The COM+ Network Access rule must be enabled on the remote server for MMC snap-ins to connect.
Incorrect: The Remote Event Log Management rules are not necessary to connect to a remote server using an MMC snap-in.
Incorrect: The remote server does not have to be running Remote Server Administration Tools.
Correct answers: A, C
Correct: The Get-NetFirewallRule cmdlet displays a list of all the rules on a system running Windows Firewall.
Incorrect: The Set-NetFireWallRule cmdlet is for managing specific rules, not listing them.
Correct: The Show-NetFirewallRule cmdlet displays a list of all the rules on a system running Windows Firewall.
Incorrect: The New-NetFireWallRule cmdlet is for creating rules, not listing them.
Correct answer: A
Correct: You cannot install roles on a remote server running Windows Server 2008 by using Server Manager.
Incorrect: You can install roles on a remote server running Windows Server 2008 by using Windows PowerShell.
Incorrect: You can connect to a remote server running Windows Server 2008 by using the Computer Management console as long as you enable the COM+ Network Access rule.
Incorrect: You can monitor event log entries on a remote server running Windows Server 2008 as long as you enable the Remote Event Log Management rules.
Correct answers: B, C
Incorrect: .NET Framework 3.5 is not needed for Server Manager to connect to Windows Server 2008.
Correct: .NET Framework 4.0 is needed for Server Manager to connect to Windows Server 2008.
Correct: Windows Management Framework 3.0 is needed for Server Manager to connect to Windows Server 2008.
Incorrect: It is not necessary to upgrade to Windows Server 2008 R2 for Server Manager to connect to Windows Server 2008.
Correct answer: B
Incorrect: The Dashboard does appear in the default Server Manager display.
Correct: The Local Server home page does not appear, because the local system is a workstation, not a server.
Incorrect: The All Servers home page does appear in the default Server Manager display.
Incorrect: The Welcome tile does appear in the default Server Manager display.