CHAPTER 17
Windows Server 2016 Administration

Administrators can administer a Windows Server 2016 infrastructure by learning only a few simple tasks and applying them at different levels and to different objects. This enables the administrator to easily scale the administration of the infrastructure without proportionally increasing the work. However, this requires defining and enforcing an administrative model.

The overall management of an environment is composed of administrative tasks that touch almost every aspect of the network, including user administration, server and workstation administration, and network administration. For example, in a single day, an administrator might check for a successful server backup, reset a user’s password, add users to or remove them from existing groups, or manage local-area network (LAN) and wide-area network (WAN) hardware. Although each of these tasks can independently be very simple or difficult in nature, administrators should at least understand their portion of the overall enterprise network and understand how the different components that make up the network communicate and rely on one another.

Active Directory forms the basis for the administrative model in Windows Server 2016. The Active Directory structure is used to control the authorization and access to other technologies such as Microsoft Exchange Server, SQL Server, System Center Operations Manager, SharePoint, and so on. This chapter focuses on the common Windows Server 2016 Active Directory Domain Services (AD DS) user and group administrative tasks and touches on the management of Active Directory sites to optimize user access and replication performance.

Centralized

Distributed

Mixed

When there is no administrative model, the environment is managed chaotically, and the bulk of work is usually made up of reactive troubleshooting (that is, firefighting). This can often require server updates and modifications to occur with short notice and proper planning or testing. Also, when administrative or maintenance tasks are not performed correctly or consistently, securing the environment and auditing administrative events are nearly impossible. Environments that do not follow an administrative model are administered inefficiently and problems are addressed reactively rather than proactively.

To choose or define the correct administrative model, the organization must discover what services are needed in each location and where the administrators with the skills to manage these services are located. Placing administrators in remote offices that require very little IT administration might be a waste of money, but when the small group is composed of VIPs in the company, it might be a good idea to give these elite users the highest level of service available.

Windows Server 2016 systems allow for granular administrative rights and permissions, giving enterprise administrators more flexibility when assigning tasks to staff members. Historically, distributed administration based only on geographic proximity is commonly found among organizations. After all, if a physical visit to the server, workstation, or network device is needed, having the closest qualified administrator responsible for it might prove more effective. More recently with the proliferation of server virtualization and advanced remote access technologies, remote management of servers is becoming the norm.

Each AD site is typically configured to contain resources that have high-bandwidth connectivity between them. The sites can contain one more physical location depending on the network architecture. Sites can be optimized for replication which, during regular daily operations, require very little network bandwidth. After an AD site is defined, servers and client workstations use the information stored in the site configuration to locate the closest domain controllers, Global Catalog servers, and distributed file shares. Configuring a site can be a simple task, but if the site topology is not defined correctly, network access speed might suffer because servers and users might connect to resources across the WAN instead of using local resources.

As mentioned previously, configuring a site should take only a short time because there are very few components to manipulate. In most cases, defining and setting up an Active Directory site configuration might take only a few hours of work. After initial setup, AD sites rarely need to be modified unless significant changes are made to the network topology, including IP addressing changes, domain controllers added or removed from a site, or new sites added or old ones decommissioned.

Examples of site topologies and names might include the name of the city where the company locations are, airport codes for the cities, or the office identifier if the company already has one.

If a user workstation subnet is not defined within Active Directory, the workstation picks another domain controller essentially at random. The domain controller could be one from the same physical location or it could be one on another continent across multiple WAN links. The user workstation might authenticate and download policies or run services from a domain controller that is not directly connected to the same LAN. This authentication and download across a WAN could create excessive traffic and unacceptable response times.

In looking at the Active Directory infrastructure, it might seem that branch offices with no domain controller could simply be lumped with their central office site by adding the branch office subnets to the main office site. This would save a lot of configuration time needed to create those branch office sites.

This is somewhat shortsighted, as many other applications are Active Directory aware and leverage the Active Directory site architecture to control the behavior of their application. This includes the Windows Server 2016 file system technologies, security technologies as well as system configuration and management technologies. Thus, it is important to fully define the Active Directory site architecture, including the subnets to mirror the WAN architecture of the organization.

All subnets should be defined in Active Directory Sites and Services to ensure that the proper domain controller and application server assignments are made to workstations. And all locations should have their own sites and subnets defined, even if there is no domain controller currently in the location. This ensures that resources are allocated correctly by the Active Directory infrastructure not only for domain services, but for other services as well.

Once again, some administrators do not fully define the site architecture and don’t create sites for locations that do not have a domain controller. The reasoning is that the sites are used by Active Directory for replication, and so domain controller-challenged locations do not need a site defined.

Just like with subnet design, this is also shortsighted, because many other applications are Active Directory aware and leverage the Active Directory site architecture to control the behavior of their application. Site links are also used by Active Directory-aware applications to understand the physical topology to optimize WAN communications.

Therefore, it is important to fully define the Active Directory site architecture, including both subnets and site links to mirror the WAN architecture of the organization.

Examples of site links include a site link for every WAN link, such as from the main office to each of the branch offices. For fully meshed offices, such as those connected via meshed Multiprotocol Label Switching (MPLS), a single site link can be used. This can be done for all offices or just for a subset of offices (for example, North America offices) if needed.

That said, there are some specific applications where site group policies can prove to be very useful. For example, it is a best practice to have virtual private network (VPN) users assigned to a site in Active Directory. This is accomplished by creating a VPN site in Active Directory Sites and Services and assigning the VPN subnet to that site. Then, group policies that add additional controls can be assigned to the VPN site using the Site Group Policy object (GPO). That way, when users use their laptop to connect in the office, they receive the standard set of group policies. However, when they use the same laptop to connect to the office via the VPN, they get the additional policies needed for VPN access.

For these examples, the company locations and IP addresses in Table 17.1 will be used. The company has a hub-and-spoke topology, with each branch office connected to the main office. The main office has an IPv4 and an IPv6 subnet.

To create a site, follow these steps:

1. Launch Server Manager on a domain controller.

2. Expand the Tools menu and run Active Directory Sites and Services.

3. Right-click the Sites container and choose New Site.

4. Type in the name of the site and select any existing site link, as shown in Figure 17.1. Then click OK to create the site.

5. A pop-up window might appear, stating what tasks still need to be completed to properly create a site. Read the information, take notes if necessary, and click OK.

Repeat this for each site that needs to be created. For the sample company, Table 17.2 lists the sites that will be created.

1. Within the Active Directory Sites and Services console, right-click the Subnets container, and choose New Subnet.

2. Type in the address prefix in the Prefix field (for example, 192.168.3.0/24 for the Oakland site IPv4 subnet).

3. Select the appropriate site from the list at the bottom of the window to associate it with the new subnet.

4. Click OK to create the new subnet.

Repeat this for each subnet in the locations. Table 17.4 lists the resulting entries for the sample Company ABC.

1. Launch Server Manager on a domain controller.

2. Expand the Tools menu and run Active Directory Sites and Services.

3. Expand the Sites folder.

4. Locate the site that contains the desired domain controller to move. You can browse the site servers by expanding the site and selecting the Servers container of the site, as shown in Figure 17.2.

5. When you locate the desired server, take note of the source site, right-click the server name, and choose Move.

6. When a window opens listing all the sites in the forest, select the destination site, and click OK to initiate the server move.

7. When the move is complete, verify that the domain controller has been placed in the correct Servers container of the desired site.

To create an IP-based site link, follow these steps:

1. Launch Server Manager on a domain controller.

2. Expand the Tools menu and run Active Directory Sites and Services.

3. Expand the Sites folder.

4. Expand the Inter-Site Transports folder, and select the IP folder.

5. Right-click the IP container and select New Site Link.

6. Enter a name for the site link, select at least two sites that will replicate Active Directory using this site link, and click Add, as shown in Figure 17.3 for Paris and Boston sites.

7. Click OK to create the site link.

8. Back in the Active Directory Sites and Services console, right-click the new site link in the right pane, and choose Properties.

9. At the top of the window, enter a description for the site link. Keep the description simple but informative. For example, enter Site link between Paris and Boston.

10. At the bottom of the window, enter a cost for the site link. This determines the preferred link if more than one is available. See the text following these steps for a discussion of site link costs and Table 17.5 for some typical costs. In this example, the connection between Paris and Boston is a T1, and the cost is set to 321.

11. Enter the replication frequency. This number indicates how often Active Directory will attempt to replicate during the allowed replication schedule. The default is 180 minutes. The lowest this can be set to between sites is 15 minutes. In most well-connected organizations, the frequency is usually set to 15.

12. Click the Change Schedule button to configure specific intervals when Active Directory should not replicate. This is not typically used in modern well-connected networks. Click OK to leave unchanged.

13. Click OK on the Site Link property page to complete the site link configuration.

After the site link is configured, the Active Directory connections between domain controllers in different sites generate new connections to optimize replication when the KCC runs. The cost of a site link is an arbitrary value that is selected by the administrator to reflect the speed and reliability of the physical connection between the sites. When you lower the cost value on the link, the priority is increased. Site links have a replication interval and a schedule that are independent of the cost. The cost is used by the KCC to prefer one site link path over another.

Cost values determine which connector is preferred for data transfer. When costs are assigned to the links, the KCC computes the replication topology automatically and clients automatically goes to the cheapest link. Link costs can be based on the following formula:

Cost = 1024/log(bw/1000)

where

bw = Bandwidth of the link between the two sites in bits per second (bps)

Cost = Site link cost setting

Table 17.5 lists the cost values for some typical bandwidths. The values in the Cost column would be entered into the Cost field of the site link properties.

Of course, in a simple network with only a single WAN connection between locations, the site link cost value can be left at the default value of 100 with little impact. In this configuration, all links are considered equal by the KCC.

In general, a site link topology serves to provide an Active Directory-integrated method for defining preferred routes between physically remote sites connected by WAN links.

The site links created for Company ABC are shown in Table 17.6. The site links represent the hub-and-spoke topology on the Company ABC WAN, with the appropriate costs based on the link speeds.

To delegate control at the site level, follow these steps:

1. Launch Server Manager on a domain controller.

2. Expand the Tools menu and run Active Directory Sites and Services.

3. Expand the Sites folder.

4. Right-click the desired site object and select Delegate Control.

5. Click Next on the Delegate Control Wizard Welcome screen.

6. Using the Add button, select the user, users, or groups that will delegate control over the site, and click OK. For example, you can choose an Active Directory group created for the organization’s networking team or the default group named Network Configuration Operators.

7. Click Next to continue.

8. On the Tasks to Delegate page, select Create a Custom Task to Delegate, and then click Next.

9. On the Active Directory Object Type page, select This folder, Existing Objects in This Folder, and Creation of New Objects in This Folder, which is the default option to delegate control. The permissions granted trickle down to each of the containers below the selected container, so you can manage access to all sites by selecting the Sites container itself and using the Delegation Wizard.

10. Click Next to continue.

11. On the Permissions page, check the desired permissions type check boxes and choose each permission the delegated user or group should have.

12. Click Next and then click Finish to complete the Delegate Control Wizard.

To delegate administrative tasks, security groups can be defined for different levels of responsibility. For example, a level 1 server administrator might have the right to reset user passwords and manage workstations, whereas a level 2 administrator might have those permissions plus the right to add or remove objects from a particular organizational unit or domain. The level of granularity possible is immense, so designing and implementing a functional security group structure can be one way to simplify administration and improve security across the enterprise. This is sometimes referred to as role-based access control (RBAC).

Security groups can also be used for emailing purposes, so they can serve a dual purpose.

For most organizations, however, the use of universal groups for most or even all groups is the best solution Thanks to improvements to the speed of networks and the efficiency of directory replication over the past several years, the performance impact of the extensive use of universal groups is often minor. In addition, environments that also use Exchange 2007 or later versions must migrate all distribution groups to universal groups, making universal groups a common standard.

A common best practice for larger forests is to create a universal security group named Forest Admins with each of the domain’s Domain Admin groups as members. Then you would need to configure only a single entry to allow all the administrators access forestwide for a particular resource or user right. Universal security groups are preferred because they can have members from each domain, but if the group strategy necessitates their use, domain local and domain global groups could still handle most situations.

Windows 2000 Native—This domain level allows Windows 2000 or later domain controllers in the domain. Universal security groups can be leveraged, along with universal and global security group nesting. This level can be raised to Windows Server 2003 Native level, which also enables you to change some existing groups’ scopes and types on-the-fly. This DFL is no longer supported.

Windows Server 2003—This level allows Windows Server 2003 or later domain controllers. It provides all the features of the Windows 2000 native domain level, plus additional security and functionality features, such as domain rename, logon timestamp updates, and selective authentication. This DFL is supported, but the server is not.

Windows Server 2008—The Windows Server 2008 functional level allows Windows Server 2008 or later domain controllers. This level supports all the features of the Windows Server 2003 functional level, plus additional features such as AES 128 and AES 256 encryption support for Kerberos, last interactive logon information to provide visibility into true logon activity by the user, fine-grained password policies to allow policies to be set on a per-group and per-user basis, and DFSR for Active Directory replication.

Windows Server 2008 R2—The Windows Server 2008 R2 functional level, which allows only Windows Server 2008 R2 and Windows Server 8 domain controllers, adds Authentication Mechanism Assurance. This essentially inserts the type of logon method into the Kerberos token and allows applications to determine authorization or access based on the logon method. For example, an application could only allow logon type 2 (interactive) and not type 3 (network) to ensure that the user was actually at a workstation.

Windows Server 2012—The Windows Server 2012 functional level, which allows only Windows Server 2012 domain controllers provides no additional features.

The most important note is that all the domain functional levels supported by Windows Server 2016 and higher allow universal security groups.

1. Launch Server Manager on a machine that has the Remote Server Administration Tools (RSAT) AD DS Tools installed.

2. Expand the Tools menu and run Active Directory Users and Computers.

3. Expand the domain folder (in this example, the companyabc.com folder).

4. Select a container—for example, the Users container or an organizational unit (OU). Right-click it and select New, Group.

5. Enter the group name and select the appropriate group type and scope, as shown in Figure 17.4.

6. Click OK to finish creating the group.

To add members to an existing group, follow these steps:

1. Launch Server Manager on a machine that has the RSAT AD DS Tools installed.

2. Expand the Tools menu and run Active Directory Users and Computers.

3. Expand the domain folder (in this example, the companyabc.com folder).

4. Select the Users container or the OU that was used in the previous section. In the right pane, right-click the group that was created earlier, and select Properties.

5. Enter a description for the group on the General tab, and then click the Members tab.

6. Click Add to add members to the group.

7. In the Select Users, Contacts, Computers, Service Accounts or Groups window, type in the name of each group member separated by a semicolon and click OK to add these users to the group. If you don’t know the names, clicking the Advanced button opens a window where you can perform a search to locate the desired members.

8. When all the members are listed on the Members tab of the group’s property page, click OK to complete the operation.

To delegate control of a group to a particular user, follow these steps:

1. Launch Server Manager on a machine that has the RSAT AD DS Tools installed.

2. Expand the Tools menu and run Active Directory Users and Computers.

3. Select Advanced Features from the View menu.

4. Expand the domain folder (in this example, the companyabc.com folder).

5. Select the Users container or the OU that was used in the previous section. In the right pane, right-click the group that was created earlier, and select Properties.

6. Select the Security tab.

7. At the bottom of the page, click the Advanced button.

8. In the Advanced Security Settings for Group dialog box, select the Permissions tab.

9. Click Add and then click Select a Principal.

10. In the Select User, Computer, Service Account or Group window, type in the name of the account for which you want to grant permissions, and click OK.

11. When the Permissions Entry for Group window appears, click the Apply To dropdown list arrow, and then select This Object Only as shown in Figure 17.5.

12. In the Properties section, check the boxes for Read Members and Write Members, and then click OK.

13. Click OK to close the Advanced Security Settings for Group dialog box.

14. Click OK to close the group’s property pages.

Chapter 14, “Network Policy and Access Services, Routing and Remote Access, and DirectAccess ” describes security policy in more depth, but the best way to discover and learn about all the Group Policy settings is to open an actual GPO and start browsing each section.

To open an existing policy, follow these steps:

1. Launch Server Manager on a machine that has the GPMC feature installed.

2. Expand the Tools menu and run Group Policy Management Console.

3. Expand the Forest folder.

4. Expand the Domains folder.

5. Expand the specific domain, such as companyabc.com.

6. Select a GPO, such as the Default Domain Policy. Click OK to close the linked policy warning window.

7. Select the Settings tab to review the settings. Or right-click the GPO and select Edit to change the settings.

After you access the policy, you can view each setting or settings container to determine the default value and, in some cases, learn what the setting controls. Keep in mind that, with the correct level of permissions, any changes you make to this policy are live changes; there is no undo other than reversing the individual setting changes or performing an authoritative restore of Active Directory.

The preceding section described how to locate a group policy. Using the Group Policy Management Console, you can also create, configure, and open site, domain, and organizational unit (OU) group policies for editing.

In some cases, it will be necessary to prevent a GPO from being applied to a user or computer. That is, there might be a GPO that applies to all members of a department, but it is necessary to make a single exception to the rule. Rather than create a specific OU to apply the GPO, security filtering can be used to allow or deny the application of the GPO.

The following steps outline how to create a new domain-based policy and configure its security filtering to apply to a single user:

1. Launch Server Manager on a machine that has the GPMC feature installed.

2. Expand the Tools menu and run Group Policy Management Console.

3. Expand the Forest folder.

4. Expand the Domains folder.

5. Select the specific domain, such as companyabc.com.

6. Right-click the domain and select Create a GPO in This Domain, and Link It Here.

7. Type in a descriptive policy name, leave the source starter GPO set to None, and click OK to create the policy.

8. The new policy will be displayed under the domain. Right-click the new policy and select Edit to launch the Group Policy Management Editor snap-in.

9. Right-click the GPO name in the Group Policy Management Editor, and select Properties.

10. Select the Security tab and highlight the Authenticated Users entry.

11. In the Permissions section, scroll down and uncheck the Allow check box for Apply Group Policy. This means that the GPO will not take effect on any user or computer.

12. Select each entry in the Group Policy ACL and verify that no existing groups are allowed to apply Group Policy.

13. Click Add and type in the name of a user or group. To find a list of users and groups within the current domain, click the Advanced button, and in the Search window, click Find Now to return the complete list. Scroll down and select the users or groups you want, and click OK.

14. Click OK to add the entries to the policy.

15. Back in the Security window, select the respective entry and check the Allow check box for Apply Group Policy, as shown in Figure 17.6. This means that the GPO will take effect on the members of this group, which could include both users and computers. Click OK when you’re finished.

16. Close the Group Policy Management Editor snap-in.

Now the group policies set in the GPO will affect only the users or computers that were specified—in this case, members of the HelpDesk group. This allows for fine-grained application of group policies to targeted groups.

When multiple group policies exist, they are applied in a predefined order. For a particular user or computer, the order can be derived using the Resultant Set of Policies snap-in. The results of standard policies are that if setting X is enabled on a top-level policy and disabled on the last policy to apply to an object, the resulting setting will disable setting X. Many policy settings have three states: Enabled, Disabled, and the default of Not Configured.

You can limit group policies to apply to specific users or computers by modifying the security entries. In addition to disabling portions of each GPO, policy inheritance can be blocked at the domain or OU container level using a setting called Block Policy Inheritance. When blocking or precedence rules need to be ignored for the settings of a particular group policy, you can configure the group policy as Enforced.

The general guidelines to improve the logon performance of group policies are as follows:

Reduce the number of OU levels—By reducing the number of OU levels, there will be fewer levels to link GPOs to and therefore better performance. The best practice is to have a maximum of three levels, if possible. If more are needed, prohibit the linking of GPOs to some of the levels.

Reduce the number of GPOs—By consolidating settings into fewer GPOs, less processing time is needed to read the GPOs. A single GPO at the same OU level will perform faster than 10 GPOs at the same level.

Use security filtering—If a GPO is security filtered to not apply to a user or computer, the settings do not need to be read or processed. This speeds up logon and startup performance.

Disable user or computer settings in GPOs—Each GPO consists of a user and a computer section. If there are no settings in either of those sections, that section can be disabled and will be ignored. For example, if a GPO only has computer settings and the user settings are disabled, that GPO will be skipped at logon (which only deals with user settings).

These guidelines can dramatically improve logon and startup performance.

The last guideline suggested disabling the user setting or computer settings, because processing a GPO takes a certain amount of time for a computer at startup and for a user at logon. To enable or disable the entire GPO or the user/computer portion of the GPO, follow these steps:

1. Open the Group Policy Management Console.

2. Expand the Forest folder, expand the Domains folder, select the specific domain, and select the Group Policy Objects folder.

3. Right-click the GPO and select GPO Status.

4. Select the appropriate option: Enable, User Configuration Settings Disabled, Computer Configuration Settings Disabled, or All Settings Disabled.

This will take effect immediately. The All Setting Disabled option is useful for troubleshooting when you want to completely disable a GPO without changing the ACLs or the settings.

To block policy inheritance, follow these steps:

1. Launch Server Manager on a machine that has the GPMC feature installed.

2. Expand the Tools menu and run Group Policy Management Console.

3. Expand the Forest folder.

4. Expand the Domains folder.

5. Select the specific domain, such as companyabc.com.

6. Locate and right-click the OU for which you want to block inheritance, and select Block Inheritance, as shown in Figure 17.7.

In this example, policy inheritance was blocked on the Servers OU. Group policies created above the OU will not affect objects within the OU (unless the group policy is enforced; see the next section). Note the blue exclamation mark icon on the OU to alert the administrator that policy inheritance is blocked.

To configure the Enforce option for a policy, follow these steps:

1. Launch Server Manager on a machine that has the GPMC feature installed.

2. Expand the Tools menu and run Group Policy Management Console.

3. Expand the Forest folder.

4. Expand the Domains folder.

5. Expand the specific domain, such as companyabc.com.

6. Right-click the group policy link to enforce, and select Enforce.

Now the group policy link will be enforced even if the Block Policy Inheritance option is set on down-level OUs. Note that the group policy link will now have a small lock icon associated with it to show that it is enforced.

Now that you know the order in which policies are applied, you can proceed to use the Group Policy testing and troubleshooting tools provided with Windows Server 2016, namely the Group Policy Modeling tool in the Group Policy Management Console and the command-line utility GPResult.exe, which is the command-line version of the Resultant Set of Policy (RSoP) snap-in.

To simulate the policies for a user, use the Group Policy Modeling snap-in as follows:

1. Launch Server Manager on a machine that has the GPMC feature installed.

2. Expand the Tools menu and run Group Policy Management Console.

3. Expand the Forest folder.

4. Select the Group Policy Modeling folder.

5. Select Action, Group Policy Modeling Wizard to launch the wizard.

6. Click Next.

7. Leave the default domain controller selection, which chooses any available domain controller. Click Next.

8. Select the User option button in the User Information box, and click Browse.

9. Enter the name of a user to check, and click OK. Click Next to accept the user and computer selection.

10. Click Next on the Advanced Simulation Options page. The advanced simulation options enable you to model slow network connections, loopback processing mode, or specific sites.

11. Click Next to skip the Alternate AD Paths.

12. The User Security Groups page shows the groups that the user is a member of. You can add additional groups to see the effects of changes. Leave as is and click Next.

13. Click Next to skip the WMI Filters for Users page.

14. Click Next to run the simulation.

15. Click Finish to view the results.

16. Select the Details tab and if needed use Show link next to Group Policy Objects and next to Denied GPOs.

Within the console, you can review each particular setting to see whether a setting was applied or the desired setting was overwritten by a higher-level policy. The report will show how policy will be applied, as shown in Figure 17.8. The Default Domain Policy GPO was denied because it is empty (of user settings) and the Remote Control Executives GPO was denied because of security filtering. This is the GPO created earlier in the chapter, which was applied only to members of the HelpDesk group. The user tsmith is not a member of this group and, hence, does not have the GPO applied.

The Print Management console, which was later integrated into the Windows operating system, provides a single interface where an administrator can view all printers and print servers in the enterprise. Furthermore, printer resources can be grouped to simplify administration of some of the printers. For example, if an organization has an administrator for a particular building, the Print Management interface could be filtered to only list printers within the building. This would allow the administrator to only see certain printers they are responsible for and to consolidate multiple print server groups of printers into a single interface for management and administration.

The Print Management component only needs to be installed on the system that the administrator is managing from; it does not need to be installed on all print servers or systems in the enterprise. Functionally, Print Management could be installed on just one system. However, it is automatically installed on Windows Server 2016 servers with the Print Service role installed.

1. Launch Server Manager.

2. Expand the Manage menu and select Add Roles and Features.

3. Accept the default Installation Type.

4. Select the appropriate server on the Server Selection page. Note: If not installing on the local server, the target server must be added to server manager before starting this process.

5. Check the Print and Document Services Tools check box.

6. Click Next, Install, and Close to complete the installation process.

Now the Print Management console will be available within Server Manager on the server.

To configure print management resources, launch the Print Management console as follows:

1. Select Start, then select Open Server Manager

2. At the Tools menu select the Print Management option.

Upon opening the Print Management console, a screen appears similar to the one shown in Figure 17.9.

1. Click the Start button and then Control Panel.

2. Select the Hardware category within the Control Panel.

3. Select the Advanced Printer Setup link in the Devices and Printers category.

4. After the search completes, select The Printer That I Want Isn’t Listed.

5. Select the type of printer being added. For this example, select Add a Printer Using a TCP/IP Address or Hostname, and then click Next.

6. Enter the hostname or IP address or the printer and if necessary, also the port and device type, and then click Next.

7. If the automated driver detection fails, select the appropriate driver.

8. When prompted, give the printer a name (such as HP LaserJet P2035 PCL6 in the Marketing Dept), and then click Next.

9. When prompted whether you want to share the printer, select the Share Name option and type in a name that will describe the printer (such as HP2035MKTG), and then click Next.

10. If you want to print a test page, click the Print a Test Page button; otherwise, click Finish to complete the addition of the printer.

To start the Network Printer Installation Wizard within the Print Management console, follow these steps:

1. Expand the Print Servers section of the Print Management console.

2. Right-click one of the print servers listed in the Print Servers section of the interface, and choose Add Printer.

3. Follow the wizard prompts to add your printer as outlined in the preceding section.

Adding a print server to the Print Management console allows the administrator to manage the print server and all the printers the print server hosts. To add a print server to the Print Management console, follow these steps:

1. Right-click the Print Servers item in the Print Management console, and choose Add/Remove Servers.

2. Type in the name of the print server you want to add, or click Browse and search the Microsoft Windows network to view the various servers in the environment.

3. Click OK to add the print server.

Updating printer drivers—By right-clicking the Drivers item in the Print Server section of the Print Management console and choosing Manage Drivers, an administrator can update or change the printer driver of a printer. This is rarely done in a network environment, but sometimes when a new printer add-on, such as an envelope feeder or expansion paper feeder or sorter, is added a new printer driver is needed to support the new add-on.

Managing forms—By right-clicking the Forms item in the Print Server section and choosing Manage Forms, an administrator can create and delete new forms to support different size paper or to specify a custom letterhead paper form.

Additional configuration—Additionally within this interface, an administrator can change the printer port that a printer is attached to on a print server, define log settings, and enable the function to have users notified when a print job has successfully completed printing.

First, to view all printers in the environment, an administrator can click the All Printers section of the Custom Filters section of the Print Management console. All the printers for managed print servers will be listed here.

To create a custom printers view, follow these steps:

1. Right-click the Custom Filters View in the Print Management console, and choose Add New Printer Filter.

2. Type in a descriptive name for this filter view (such as All Printers in the Boston Site).

3. Check the Display the Total Number of Printers Next to the Name of the Printer Filter check box. Click Next.

4. In the Field drop-down list, choose a field that will contain information that can be filtered. In many cases, the print servers can be filtered because a print server frequently services printers in a specific geography. Alternately, organizations that entered in location information for printers such as Building 11 would be able to filter for that designation in a custom printer filter filtered by name. An example might be Field=Location, Condition=Contains, Value=Boston. Click Next to continue.

5. On the Set Notification Options page, an administrator can note an email address where the administrator would be notified on the status of events related to the printers in the filter. You can also run a script. This might include being emailed every time a printer is offline, or every time a printer is out of paper. Enter in the appropriate email information (email address, SMTP mail server to be used, and message desired), or leave this section unchecked, and then click Finish.

By clicking the newly created filter, the filter rule is applied, and the printers noted in the filter will be displayed, as shown in Figure 17.10. In this figure, notice that the environment contains five printers; however, the filter is searching only for printers in Boston, and therefore only three printers are displayed for this administrator to view and manage.

An almost unlimited number of printer filters can be created to show different groupings of printers to be managed or administered. Organizations have created custom printer filters by printer manufacturer such as HP, Xerox, and Sharp or by printer type such as laser, color laser, and plotter to be able to view assets by make, model, or configuration. Printer filters can even be created based on queue length and to run an automatic script to take action in addition to notifying the administrator.

This chapter addressed options for administration that included centralized, decentralized, and mixed administration, which provides a model that fits pretty much all organizations. Some of the key criteria in administration are addressed when sites and groups are created that identify administration boundaries and define the role of administration within and across the boundaries.

In addition, policies clarify how management and administration will be handled, which ultimately trickle down to profiles and configuration settings to create a managed and administered Windows Server 2016 environment.

Clearly understand your roles and responsibilities in the enterprise network, and understand how the different components that make up the network communicate and rely on one another.

Choose the appropriate administrative model (central, distributed, or mixed) for the organization based on required services and skill sets in each location.

Always define the Active Directory sites to accurately reflect physical structure even if those locations don’t contain domain controllers.

Always define all subnets in the Active Directory Sites and Services to ensure that all domain computers can be located to their closest Active Directory resources.

Use site links to accurately reflect the WAN and LAN topology.

Use site policies to define custom network security settings for sites with unique requirements or to delegate administrative rights when administration is performed on a mostly geographic basis.

Ensure that sites contain local network services, such as domain controllers, global catalog servers, DNS servers, DHCP servers, and, if necessary, WINS servers.

For volatile groups, create a universal group to span domains, but have only a global group from each domain as a member.

Use group policies to manage users and desktops.

Modify Group Policy security entries to limit Group Policy application to specific users or computers.

Reduce the OU levels and the number of GPOs by consolidating multiple GPOs into a single GPO where possible to improve logon and startup performance.

Use Group Policy Modeling to view and troubleshoot the way group policies are applied.

Use the Print Management console included in to Windows Server 2016 to centrally view, manage, and administer printers in the network environment.