Thursday, March 27, 2014

Using Windows System Resource Manager

Applies To: Windows Server 2008 R2

Overview of Windows System Resource Manager

Applies To: Windows Server 2008 R2
With Windows System Resource Manager for the Windows Server® 2008 R2 operating system, you can manage server processor and memory usage with standard or custom resource policies. Managing your resources can help ensure that all the services provided by a single server are available on an equal basis or that your resources will always be available to high-priority applications, services, or users.
Windows System Resource Manager only manages processor resources when the combined processor load is greater than 70 percent. This means that it does not actively limit the resources that can be used by each consumer when processor load is low. When there is contention for processor resources, resource allocation policies help ensure minimum resource availability based on the management profile that you define.

Features of Windows System Resource Manager

You can use Windows System Resource Manager to:
  • Manage system resources (processor and memory) with preconfigured policies, or create custom policies that allocate resources per process, per user, per Remote Desktop Services session, or per Internet Information Services (IIS) application pool.
  • Use calendar rules to apply different policies at different times without manual intervention or reconfiguration.
  • Automatically select resource policies that are based on server properties and events (such as cluster events or conditions) or changes to installed physical memory or number of processors.
  • Collect resource usage data locally or in a custom SQL database. Resource usage data from multiple servers can be consolidated on a single computer running Windows System Resource Manager.
  • Create a computer group to help organize Remote Desktop Session Host (RD Session Host) servers that you want to manage. Policies can easily be exported or modified for an entire computer group.

Benefits of resource management

Because Windows Server 2008 R2 is designed to give as many resources as possible to non-operating system tasks, a server running a single role usually does not require resource management. However, when multiple applications and services are installed on a single server, they are not aware of competing processes. An unmanaged application or service will typically use all available resources to complete a task. Thus, it is important to use a tool such as Windows System Resource Manager to manage system resources on multipurpose servers. Using Windows System Resource Manager provides two key benefits:
  • More services can run on a single server because service availability can be improved through dynamically managed resources.
  • High-priority users or system administrators can access the system even during times of maximum resource load.

Methods of resource management

Windows System Resource Manager includes five built-in resource management policies that you can use to quickly implement management. In addition, you can create custom resource management policies to meet your specific needs.

Built-in resource management policies

You can enable built-in resource management policies by selecting the type of policy to use. No further configuration is required.

 

Policy Description
Equal per process
When the Equal_Per_Process resource allocation policy is managing the system, each running process is given equal treatment. For example, if a server that is running ten processes reaches 70 percent processor utilization, Windows System Resource Manager will limit each process to using 10 percent of the processor resources while they are in contention. Note that resources not used by low utilization processes will be allocated to other processes.
Equal per user
When the Equal_Per_User resource allocation policy is managing the system, processes are grouped according to the user account that is running them, and each of these process groups is given equal treatment. For example, if four users are running processes on the server, each user will be allocated 25 percent of the system resources to complete those processes. A user running a single application is allocated the same resources as a user running several applications. This policy is especially useful for application servers.
Equal per session
When the Equal_Per_Session resource allocation policy is managing the system, resources are allocated on an equal basis for each session connected to the system. This policy is for use with RD Session Host servers.
Equal per IIS application pool
When the Equal_Per_IISAppPool resource allocation policy is managing the system, each running IIS application pool is given equal treatment, and applications that are not in an IIS application pool can only use resources that are not being consumed by IIS application pools.
Weighted Remote Sessions
When the Weighted_Remote_Sessions resource allocation policy is managing the system, the processes are grouped according to the priority assigned with the user account. For example, if three users are remotely connected, the user assigned Premium priority will receive highest priority access to the CPU, the user assigned Standard priority will receive second priority to the CPU, and the user assigned Basic priority will receive lowest priority to the CPU. This policy is for use with RD Session Host servers.
noteNote
When Weighted_Remote_Sessions is set as the managing policy, system management is delegated to the Windows Server 2008 R2 scheduler, and Windows System Resource Manager only profiles the system. Setting or removing Weighted_Remote_Sessions as the managing policy requires a restart of the computer imposed by the kernel.

Custom resource management

You can use custom resource management methods to identify resource users and allocate resources to them based on your own criteria.

 

Feature Description
Process matching criteria
Enable you to select services or applications to be managed by resource allocation policy rules. You can choose by file name or command, or you can specify users or groups. For example, you could create a process matching criterion that applies management to the application iexplore.exe when it is run by the user Administrator.
Resource allocation policies
Allocate processor and memory resources to processes that are specified by the process matching criteria that you create.
Exclusion lists
Exclude applications, services, users, or groups from management by Windows System Resource Manager.
noteNote
You can also use command-line path matching in a resource allocation policy to exclude an application from management by only that policy.

Scheduling
Use a calendar interface to control one-time events or recurring changes to resource allocation. Different resource allocation policies can be active at different times of day, on different days of the week, or according to other scheduling paradigms.
Conditional policy application
Automatically switch resource allocation policies in response to certain system events (such as installing new memory or additional processors, starting or stopping a node, or changing the availability of a resource group in a cluster).

Additional references

Design the WSUS Server Layout

The most basic WSUS deployment consists of a WSUS server that serves client computers on a private network, as shown in the following image:

Simple WSUS Deployment
The WSUS server connects to Microsoft Update to download updates. This process is known as synchronization. During synchronization, WSUS determines whether any new updates are available since the last synchronization. The first time that a WSUS server synchronizes, all updates are available for download. The first synchronization can take an hour or longer to complete. Subsequent synchronizations take significantly less time.

A WSUS deployment can consist of multiple connected servers. When you connect multiple WSUS servers, you create at least one upstream WSUS server and at least one downstream WSUS server. This configuration creates a hierarchy of WSUS servers, as shown in the following image:
WSUS Servers Chained Together
You can synchronize a WSUS server to another WSUS server instead of to Microsoft Update. The WSUS server that connects to Microsoft Update is known as the root WSUS server.
ImportantImportant
The downstream server must always synchronize to an upstream server. If you attempt to synchronize an upstream server to a downstream server, you effectively create a closed loop. This configuration is not supported.

A WSUS server hierarchy deployment offers the following benefits:
  • You can download updates one time from the Internet and then distribute the updates to client computers by using downstream servers. This method saves bandwidth on the corporate Internet connection.
  • You can download updates to a WSUS server that is physically closer to the client computers, for example, in branch offices.
  • You can set up separate WSUS servers to serve client computers that use different languages of Microsoft products.
  • You can scale WSUS for a large organization that has more client computers than one WSUS server can effectively manage.
noteNote
We recommend that you do not create a WSUS server hierarchy that is more than three levels deep. Each level adds time to propagate updates throughout the connected servers. While there is no theoretical limit to a hierarchy, only deployments with a hierarchy of five levels deep have been tested by Microsoft Corporation.

You can connect WSUS servers in Autonomous mode (to achieve distributed administration) or in Replica mode (to achieve centralized administration). You do not have to deploy a server hierarchy that uses only one mode: you can deploy a WSUS solution that uses both autonomous and replica WSUS servers.

Distributed management by using autonomous mode is the default installation option for WSUS. In autonomous mode, an upstream WSUS server shares updates with downstream servers during synchronization. Downstream WSUS servers are administered separately and they do not receive update approval status or computer group information from the upstream server. By using the distributed management model, each WSUS server administrator selects update languages, creates computer groups, assigns computers to groups, tests and approves updates, and makes sure that the correct updates are installed to the appropriate computer groups.
The following image shows how you might deploy autonomous WSUS servers in a branch office environment:
WSUS Distributed Management

In replica mode, an upstream WSUS server shares updates, approval status, and computer groups with downstream servers. Downstream replica servers inherit update approvals and are not administered separately from the upstream WSUS server.
The following image shows how you might deploy replica WSUS servers in a branch office environment.
WSUS Centralized Management (Replica Role)
If you set up several replica servers to connect to a single upstream WSUS server, do not schedule synchronization to run at the same time on each replica server. This practice will avoid sudden surges in bandwidth usage.

If the corporate network includes a network segment that is not connected to the Internet, you can deploy WSUS in the manner shown in the following drawing to support update management on that segment. In this case, you create a WSUS server that is connected to the Internet but is isolated from the intranet. After you download updates to the WSUS server, you can export the updates to removable media, hand-carry the removable media to a WSUS server on the disconnected network segment, and import the updates to that server.
Distributing Updates on an Isolated Segment This method of using WSUS is also appropriate for organizations that have high-cost or low-bandwidth links to the Internet. Downloading updates for all Microsoft products throughout an organization can be bandwidth intensive. This method enables organizations to download updates one time and then distribute updates locally by using inexpensive removable media. For more information about this scenario, see Configure a Disconnected Network to Receive Updates.
Network Load Balancing (NLB) can increase the reliability and performance of a network. You can set up multiple WSUS servers that share a single SQL Server failover cluster, as shown in the following image. For more information about how to deploy WSUS with NLB, see the Configure WSUS for Network Load Balancing section of the WSUS Operations Guide.
c5b8a565-1d8f-40ba-b63c-6259d27692e7

If the network includes mobile users who log on to the network from different locations, you can configure WSUS to let roaming users update their client computers from the WSUS server that is closest to them geographically. In this configuration, shown in the following image, one WSUS server is deployed in each region, and each region is a DNS subnet. All client computers are directed to the same WSUS server name, which resolves in each subnet to the nearest physical WSUS server. For more information about how to configure DNS to support roaming client computers, see the Configure WSUS for Roaming Client Computers section of the WSUS Operations Guide.
fabc9790-e6b5-43d8-8c6b-eeaf41ff8980

Wednesday, March 26, 2014

Overview of Remote Desktop Gateway

Applies To: Windows Server 2008 R2

What is Remote Desktop Gateway?

Remote Desktop Gateway (RD Gateway) is a role service that enables authorized remote users to connect to resources on an internal corporate or private network, from any Internet-connected device that can run the Remote Desktop Connection (RDC) client. The network resources can be Remote Desktop Session Host (RD Session Host) servers, RD Session Host servers running RemoteApp programs, or computers with Remote Desktop enabled.
RD Gateway uses the Remote Desktop Protocol (RDP) over HTTPS to establish a secure, encrypted connection between remote users on the Internet and the internal network resources on which their productivity applications run.

Why use Remote Desktop Gateway?

RD Gateway provides many benefits, including:
  • RD Gateway enables remote users to connect to internal network resources over the Internet, by using an encrypted connection, without needing to configure virtual private network (VPN) connections.
  • RD Gateway provides a comprehensive security configuration model that enables you to control access to specific internal network resources. RD Gateway provides a point-to-point RDP connection, rather than allowing remote users access to all internal network resources.
  • RD Gateway enables most remote users to connect to internal network resources that are hosted behind firewalls in private networks and across network address translators (NATs). With RD Gateway, you do not need to perform additional configuration for the RD Gateway server or clients for this scenario.

    Prior to this release of Windows Server, security measures prevented remote users from connecting to internal network resources across firewalls and NATs. This is because port 3389, the port used for RDP connections, is typically blocked for network security purposes. RD Gateway transmits RDP traffic to port 443 instead, by using an HTTP Secure Sockets Layer/Transport Layer Security (SSL/TLS) tunnel. Because most corporations open port 443 to enable Internet connectivity, RD Gateway takes advantage of this network design to provide remote access connectivity across multiple firewalls.
  • The Remote Desktop Gateway Manager enables you to configure authorization policies to define conditions that must be met for remote users to connect to internal network resources. For example, you can specify:

    • Who can connect to internal network resources (in other words, the user groups who can connect).
    • What network resources (computer groups) users can connect to.
    • Whether client computers must be members of Active Directory security groups.
    • Whether device redirection is allowed.
    • Whether clients need to use smart card authentication or password authentication, or whether they can use either method.
  • You can configure RD Gateway servers and Remote Desktop Services clients to use Network Access Protection (NAP) to further enhance security. NAP is a health policy creation, enforcement, and remediation technology that is included in Windows Server® 2008 R2, Windows Server® 2008, Windows® 7, Windows Vista®, and Windows® XP Service Pack 3. With NAP, system administrators can enforce health requirements, which can include software requirements, security update requirements, required computer configurations, and other settings.

    noteNote
    Computers running Windows Server 2008 R2 or Windows Server 2008 cannot be used as NAP clients when RD Gateway enforces NAP. Only computers running Windows 7, Windows Vista, or Windows XP SP3 can be used as NAP clients when RD Gateway enforces NAP.
    For information about how to configure RD Gateway to use NAP for health policy enforcement for Remote Desktop Services clients that connect to RD Gateway servers, see the Remote Desktop Services page on the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?linkid=140433).
  • You can use RD Gateway server with Microsoft Internet Security and Acceleration (ISA) Server to enhance security. In this scenario, you can host RD Gateway servers in a private network rather than a perimeter network, and host ISA Server in the perimeter network. The Secure Sockets Layer (SSL) connection between the Remote Desktop Services client and ISA Server can be terminated at the ISA Server, which is Internet-facing.

    For information about how to configure ISA Server as an SSL termination device for RD Gateway server scenarios, see the Remote Desktop Services page on the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?linkid=140433).
  • Remote Desktop Gateway Manager provides tools to help you monitor RD Gateway server status and events. By using Remote Desktop Gateway Manager, you can specify events (such as unsuccessful connection attempts to the RD Gateway server) that you want to monitor for auditing purposes.

Additional references

Accounts: Rename administrator account


Delegate Control of an Organizational Unit

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012
Membership in Account Operators , Domain Admins , or Enterprise Admins , or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To delegate control of an organizational unit

  1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click Administrative Tools , and then double-click Active Directory Users and Computers .
    To open Active Directory Users and Computers in Windows Server® 2012, click Start , type dsa.msc .
  2. In the console tree, right-click the organizational unit (OU) for which you want to delegate control.
    Where?
    • Active Directory Users and Computers\ domain node \ organizational unit
  3. Click Delegate Control to start the Delegation of Control Wizard, and then follow the instructions in the wizard.

Additional considerations

  • To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.

Additional references

Tuesday, March 25, 2014

RODC Administration


Applies To: Windows Server 2008, Windows Server 2012

This topic describes general administration tasks that you might have to perform for read-only domain controllers (RODCs). The tasks that are covered in this topic apply to any scenario in which you plan to use an RODC. For any specific scenario, there might be additional administration tasks that you have to perform in addition to the general tasks described here.
As a best practice, you should not log on directly to a domain controller to perform any administration tasks. Instead, install administration tools on a trusted workstation where you perform your other day-to-day work assignments. Then, use the administration tools to connect to the domain controller remotely from that workstation.
You can use either of the following tools and technologies for remote RODC management:
  • Microsoft Remote Server Administration Tools (RSAT)
  • Windows Remote Management (WinRM) protocol and Windows Remote Shell (WinRS)
To remotely manage Windows Server 2008 domain controllers, you can use the Microsoft Remote Server Administration Tools for Windows Vista. This tool set is available as a download file at Microsoft Remote Server Administration Tools for Windows Vista (KB941314) (http://go.microsoft.com/fwlink/?LinkID=95703). So that you can install RSAT, your workstation must be running Windows Vista with Service Pack 1 (SP1).
If the workstation is running a 64-bit version of Windows Vista, you can use Microsoft Remote Server Administration Tools for Windows Vista for x64-based Systems. The 64-bit version is available at Microsoft Remote Server Administration Tools for Windows Vista for x64-based Systems (KB941314) (http://go.microsoft.com/fwlink/?LinkId=120123).
You can use RSAT to remotely manage servers running either a Server Core installation or a full installation of Windows Server 2008.
You can also manage Windows Server 2008 domain controllers from another server that runs Windows Server 2008. To use a server that runs Windows Server 2008 for remote management, you have to install the Remote Server Administration Tools because they are not installed by default. To manage domain controllers, you need to install at least the Active Directory Domain Controller tools. Depending on what other administration you plan to perform, you might also choose to install Group Policy Management, Distributed File System (DFS) Management, and Windows Server Backup. For more information, see Installing Remote Server Administration Tools.
You can use WinRM and WinRS to manage remote servers, including RODCs. WinRM is the Microsoft implementation of the WS-Management protocol. WinRS is a shell tool that relies on WinRM to execute remote commands.
WinRM and WinRS are especially well suited for managing an RODC that is deployed in a perimeter network (also known as a DMZ) because they use TCP port 80, which is a standard Internet services port that most firewalls leave open. These tools are also well suited for branch office scenarios because they do not require an administrator to log on to an RODC to remotely manage it.
To use WinRM, install it on the computer that you use for administration and on the remote server that you want to manage.
For more information about using WinRM and WinRS, see the following resources:
  1. On the computer that you want to manage, run the following command to enable WinRM:
    Winrm qc –quiet
    TipTip
    The –quiet parameter is useful if you want to automate other tasks, such as RunOnce.

  2. Open an elevated command prompt. For example, type the following command, and then press ENTER:
    Runas cmd
    Where is the name of an account that is a member of the Administrators group on the computer that you want to manage.
  3. In the command prompt window that opens after you run the previous command, use WinRS with the following syntax to run commands remotely.
    Winrs –r:
    For example, to view the replication partners for a domain controller, you can run the following command, and then press ENTER:
    Winrs –r:RODC01 repadmin /showrepl
Administrator Role Separation (ARS) is an RODC feature that you can use to delegate the ability to administer an RODC to a user or a security group. When you delegate the ability to log on to an RODC to a user or a security group, the user or group is not added the Domain Admins group and therefore does not have additional rights to perform directory service operations.
However, the user or group can perform local administration of the server, including any tasks that can be performed by a member of the Administrators group on a member server. For example, a delegated RODC administrator can do the following on the RODC:
  • Install hardware devices, such as network adapters and disk drives
  • Manage disk drives and other devices
  • Install software updates and drivers
  • Stop and start Active Directory Domain Services (AD DS)
  • Install and remove other server roles and features
  • View logs in Event Viewer
  • Manage shares and other applications and services

    noteNote
    By default, a delegated RODC administrator cannot make updates to SYSVOL contents. In addition, any updates that are made to the SYSVOL contents on an RODC are not replicated to other domain controllers because RODCs do not perform outbound replication.
You can specify a delegated RODC administrator during an RODC installation or after it.
During the RODC installation, you can set the name of the account in the Active Directory Domain Services Installation Wizard, at the command line, or in an answer file. In the wizard, set the name of the account on the Delegation of RODC Installation and Administration page, as shown in the following figure. If you are performing a staged RODC installation, this page appears when you precreate an RODC account. For more information about precreating an RODC account, see see Performing a Staged RODC Installation (http://go.microsoft.com/fwlink/?LinkID=103323)
Wizard page for Delegation of RODC Administration If you are installing an RODC at the command line or by using an answer file, add the /DelegatedAdmin parameter to specify the delegated RODC administrator.
To specify the delegated RODC administrator after installation, you can use either of the following options:
  • Modify the Managed By tab of the RODC account properties in the Active Directory Users and Computers snap-in, as shown in the following figure. You can click Change to change which security principal is the delegated RODC administrator. You can choose only one security principal. Specify a security group rather than an individual user so you can control RODC administration permissions most efficiently. This method changes the managedBy attribute of the computer object that corresponds to the RODC to the SID of the security principal that you specify. This is the recommended way to specify the delegated RODC administrator account because the information is stored in AD DS, where it can be centrally managed by domain administrators.

    Managed By tab on an RODC Properties sheet
  • Use the ntdsutil local roles command or the dsmgmt local roles command. You can use this command to view, add, or remove members from the Administrators group and other built-in groups on the RODC. For more information about syntax and examples for using this command, see local roles (http://go.microsoft.com/fwlink/?LinkId=120147).
Using ntdsutil or dsmgmt to specify the delegated RODC administrator account is not recommended because the information is stored only locally on the RODC. Therefore, when you use ntdsutil local roles to delegate an administrator for the RODC, the account that you specify does not appear on the Managed By tab of the RODC account properties. As a result, using the Active Directory Users and Computers snap-in or a similar tool will not reveal that the RODC has a delegated administrator.
In addition, if you demote an RODC, any security principal that you specified by using ntdsutil local roles remains stored in the registry of the server. This can be a security concern if you demote an RODC in one domain and then promote it to be an RODC again in a different domain. In that case, the original security principal would have administrative rights on the new RODC in the different domain.
You can only specify one security principal to be the delegated RODC administrator. As a best practice, you should create a security group for each RODC and assign that group to be the delegated administrator. Then, you can add individual user accounts to the group, and each user can manage the RODC.
Using a security group helps you manage administrative permissions on the RODC more effectively and helps you avoid logging on to the RODC by using privileged account.
For example, suppose that you have two RODCs named RODC1 and RODC2, as shown in the following table.

 

Server name
RODC1
RODC2
Managed by
RODC1Mgrs
RODC2Mgrs
Members
StanB (the name of a user account in this branch)
KarenC (the name of another user account in this branch)
PeterH (the name of a user account in this branch)
DavidK (the name of another user account in this branch)
In this example, RODC1Mgrs and RODC2Mgrs are the respective security groups that are the delegated administrators for each RODC. The membership of each group is comprised of the appropriate user accounts from the respective branch office.
Typically, a domain administrator can manage an RODC remotely without logging on to the RODC directly. In the rare case that a domain administrator must log on to an RODC, the administrator should create a temporary domain user account just for that purpose and add it to the delegated RODC administrator group account. The administrator can log on to an RODC using that domain user account instead of a domain administrator account and eventually delete the temporary account afterward for improved security.
Because you will deploy RODCs in locations where they might be compromised, you should manage them in the same way as you manage other potentially nonsecure computers. Always treat an RODC as though it is not secure. You should never log on to it—locally or remotely with Terminal Services, by using highly privileged credentials—such as Domain Admins or Enterprise Admins.
An attacker can use a compromised RODC that has a highly privileged account password to perform malicious operations in the forest. Even use of a smart card cannot mitigate the logon risk because a compromised RODC would have access to the security context and could use it maliciously.
It is not necessary for a compromised RODC to have cached the password of a privileged account to use that account maliciously. In addition, you do not want an administrative workstation to be authenticated by an RODC that you do not trust. Although you cannot control which domain controller authenticates the administrative workstation, RODCs do not register service (SRV) resource records for other sites. As a result, RODCs do not authenticate workstations from other sites. If the administrative workstation that you log on to is not in a site with an RODC, it cannot be authenticated by an RODC. Therefore, as a best practice, you should not log on to any workstation with a privileged account in any site that has an RODC—or log on to an RODC locally—unless you fully trust the RODC.
So that the delegated RODC administrator can log on to the RODC when the wide area network (WAN) link to the hub site domain controller is not available, the delegated RODC administrator account password must be cached on the RODC. Note that the delegated RODC administrator account is not allowed to be cached on an RODC by default. Therefore, you have to modify the default PRP to allow the password to be cached, cache the password, and the recache it after every password change for successful logon to the RODC when the WAN is not available or a writable domain controller cannot be contacted. You must do this for every member of the security group that you specify as an administrator of the RODC.
Depending on your security and service availability requirements for your RODC site, you may want to change the default PRP. The PRP acts as an access control list (ACL). It determines whether an RODC is permitted to cache a password.
After the RODC receives an authenticated user or computer logon request, if it does not have the credentials cached locally, it forwards the logon request to a writable Windows Server 2008 domain controller. The writable domain controller refers to the PRP to determine whether the password for the account should be cached on the RODC. For more information about how the PRP works, see Credential caching.
You can change the PRP by modifying attributes of an RODC. For more information about changing the PRP, see Administering the Password Replication Policy.
By default, all RODCs have the same Password Replication Policy (PRP). The default PRP specifies that no account passwords can be cached on any RODC, and certain accounts are explicitly denied from being cached on any RODC.
The RODC PRP is determined by two multivalued Active Directory attributes that contain security principals (users, computers, and groups):
  • msDS-Reveal-OnDemandGroup, also commonly known as the Allowed List
  • msDS-NeverRevealGroup, also commonly known as the Denied List
The msDS-Reveal-OnDemandGroup attribute specifies what security principals can have passwords cached on an RODC. By default, this attribute has one value, which is the Allowed RODC Password Replication Group. Because this domain local group has no members by default, no account passwords can be cached on any RODC by default.
The msDS-NeverRevealGroup attribute specifies what security principals are explicitly denied from having their passwords cached on an RODC. By default, this attribute has the following values:
  • Account Operators
  • Server Operators
  • Backup Operators
  • Administrators
  • Denied RODC Password Replication Group, which is a domain local group that includes the following:

    • Enterprise Domain Controllers
    • Enterprise Read-Only Domain Controllers
    • Group Policy Creator Owners
    • Domain Admins
    • Cert Publishers
    • Enterprise Admins
    • Schema Admins
    • Domain-wide krbtgt account
By using a combination of the Allowed List and the Denied List for each RODC with the domain-wide password replication groups, you have great flexibility to decide precisely which accounts can be cached on specific RODCs. The following table describes three examples of ways that you might administer the PRP to manage how passwords are cached on the RODCs that you deploy. You can customize any of these examples to best suit your needs.

 

Example Pros Cons
No accounts are cached (default)
Most secure—users are authenticated by a writable domain controller, and they get their Group Policy from the RODC for fast policy processing.
No offline access for anyone—a WAN is required for logon.
Most accounts are cached
Ease of password management—this option is intended for customers who care most about the manageability improvements of RODC, and not security.
More passwords are potentially exposed to an RODC.
Few accounts are cached
Enables offline access for those users who need it, but provides more security than caching most accounts.
This method requires more detailed administration. You may have to map user and computers to each branch that has an RODC. You may also use tools such as repadmin /prp to move accounts that have authenticated to an RODC to a group that is in the Allowed List or use Identity Lifecycle Manager (ILM) to automate that process.
The following sections explain each example in more detail.
This example provides the most secure option. No passwords are replicated to the RODC, except for the RODC computer account and its special krbtgt account. However, user and computer authentication relies on WAN availability. This example has the advantage of requiring little or no additional administrative configuration from the default settings.
You might choose to add your own security-sensitive user groups to the Denied List. Although no accounts are cached by default, adding your own security-sensitive user groups to the Denied List can protect those groups against accidental inclusion in the Allowed List, along with subsequent caching of their passwords on the RODC.
Note that the delegated RODC administrator account is not automatically added to the Allowed List. As a best practice, add the delegated RODC administrator account to the Allowed List to ensure that a delegated administrator can always log on to the RODC, regardless of whether the WAN connection to a writable domain controller is available. For more information, see Cache the password for the delegated RODC administrator.
This example is the simplest administrative mode, and it removes the dependency on WAN availability for user and computer authentication. In this example, you populate the Allowed List for all RODCs with groups that represent a significant portion of the user and computer population. The Denied List does not allow security-sensitive user groups, such as Domain Admins, from having passwords cached. Most other users, however, can have their passwords cached on demand. You might choose to add your own security-sensitive user groups to the Denied List.
This configuration is most appropriate in environments where the physical security of the RODC will not be at risk. For example, you might configure the PRP this way for an RODC that you have deployed in a secure location primarily to take advantage of its reduced replication and administration requirements.
ImportantImportant
You must also add the users' computer accounts to the Allowed list so that those users can log on at the branch office when the WAN is offline.

This example restricts the accounts that can be cached. Typically, you define this distinctly for each RODC—each RODC has a different set of user and computer accounts that it is permitted to cache. This example is usually for a set of users who work at a particular physical location.
The advantage of this example is that a set of users will be able to log on to the network and be authenticated by the RODC in the branch office if the WAN is offline. At the same time, the scope of exposure for passwords is limited by the reduced number of users whose passwords can be cached.
There is administrative overhead associated with populating the Allowed List and the Denied List in this example. There is no default automated method for reading accounts from the known list of security principals who have authenticated against a given RODC, and there is no default method for populating the Allowed List with those accounts. You can use the repadmin /prp move command to move these accounts to a group that is in the Allowed List, or you can use scripts or applications such as ILM to build a process.
Although you can add user or computer accounts directly to the Allowed List, you should instead create a security group for each RODC, add it to the Allowed List and then add user and computer accounts to the security group. This way, you can use standard group management tools such as the Active Directory Users and Computers snap-in or the Dsadd or Dsmod command-line tools to manage which accounts can be cached on the RODC.
The repadmin /prp move command requires that you specify a security group. If the security group that you specify does not exist, it creates the group and adds it to the Allowed list. For more information about using repadmin /prp move, see Moving accounts from the Auth2 list to the Allow list.
As with the previous example, you must also add appropriate computer accounts to the Allowed List.
You can perform the following additional tasks as necessary to manage passwords for an RODC.
After you initially deploy an RODC, you may want to prepopulate its password cache with the passwords for user and computer accounts that you want to be able to authenticate to the RODC when the WAN is offline. Remember that, by default, the credentials of the accounts whose passwords are allowed to be cached are not replicated to the RODC until the user or computer authenticates against the RODC. Therefore, if the WAN is not available, these users and computers will not be able to authenticate unless you prepopulate the password cache. If you prepopulate the password cache of an RODC with those accounts, the RODC does not rely on WAN availability to authenticate them.
For example, suppose that you are installing an RODC in a branch office, and you want the users and computers in that branch office to authenticate to the RODC when the WAN is offline. If you only add the accounts to the Allowed List, the passwords for those users and computers will be cached by the RODC as those users attempt to log on. If the WAN is not available when one of those users first attempts to log on, the authentication request for that user will fail.
By prepopulating the password cache right after the RODC installation, you can ensure that the passwords for all users and computers in the branch are cached, regardless of when they first attempt to log on.
You can use Active Directory Users and Computers or repadmin /rodcpwdrepl to prepopulate the password cache. The WAN link between the RODC and its replication partner must be available when you perform this task. You cannot prepopulate the password cache during RODC installation. For more information, see Populate the password cache for an RODC.
You can view whose passwords are stored on an RODC. This can help if you want to reset those passwords if the RODC is stolen. This can also help you determine if you need to cache an account that is not yet cached. For example, you can ensure that the delegated RODC administrator account password is cached on an RODC. For more information, see Reviewing Accounts with Cached Passwords on the RODC.
Periodically, you should review whose accounts have been authenticated to an RODC. This information can help you plan updates that you intend to make to the existing PRP. For example, you can look at which user and computer accounts have authenticated to an RODC so that you can add some of those accounts to the Allowed List so that they can be authenticated by the RODC when the WAN is offline.
You can use Active Directory Users and Computers or repadmin /prp to review whose accounts have been authenticated to an RODC. For more information, see Reviewing Accounts Authenticated to RODC.
There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the site that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be updated. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed. Simply removing a user or computer from the Allowed List will not securely ensure that the password cannot be tampered with in case the RODC gets compromised. In the event that an RODC is compromised, reset the passwords for all accounts that have cached passwords and then rebuild the RODC.
You can use Active Directory Users and Computers to delete the account for an RODC that has been stolen. To delete the account, right-click the name of the RODC account in the Domain Controllers organizational unit (OU), and then click Delete. After you confirm that you want to delete the RODC account, you can choose to reset the passwords that are cached on it, as shown in the following figure. As an option, you can also select the Export the list of accounts that were cached on this read-only domain controller to this file check box to create a list of user accounts whose passwords must be reset after the RODC account is deleted. That list of accounts is not available after the RODC account is deleted.
Delete an RODC account You can also use the repadmin /prp command to delete the security principals from the msDS-AuthenticatedToAccountList attribute or from the msDS-RevealOnDemandGroup attribute that is associated with the RODC. Note however, that this action only clears the value from the attribute; it does not clear the cache on the RODC.
This section explains how to add an attribute to the RODC filtered attribute set (FAS), and then mark the attribute as confidential. For an example, see Adding Attributes to the RODC Filtered Attribute Set. The example shows how to use the Ldifde command-line tool to add an attribute Contoso-App-Password from the Active Directory schema. This attribute is just an example of a possible secret-like attribute that you can add to a default schema.
As a best practice, make sure that the forest functional level is Windows Server 2008 if you plan to configure the RODC FAS. You can be assured that the RODC FAS is not replicated to RODCs only if the forest functional level is Windows Server 2008. This is because a compromised RODC can attempt to replicate attributes from the RODC FAS from a Windows Server 2003 domain controller, which cannot prevent replication from happening. However, by default, RODCs replicate only with Windows Server 2008 writable domain controllers, which ensures that attributes in the FAS will not get replicated. If an RODC is stolen without being compromised first, it will not contain any of the attributes in the FAS.
A compromised RODC may attempt to replicate attributes from the RODC FAS from a Windows Server 2003 domain controller because of the way that access rights to AD DS data are applied. The three possible access rights that can be granted for replication are as follows:
  • Replicating Directory Changes All

    Provides access rights to secrets, such as passwords.
  • Replicating Directory Changes Filtered Set

    Provides access rights to RODC FAS attributes.
  • Replicating Directory Changes

    Provides access to all other Active Directory data that is not defined by the previous two access rights.
noteNote
These are general definitions. Each access right has a slightly different precise definition for each operating system, but the general definitions are provided for the sake of this discussion.

The following table explains how these access rights are applied to domain controllers that run different versions of Windows Server.

 

Operating system Access rights
Windows 2000 Server
Access rights that are granted:
  • Replicating Directory Changes

    Access to any attribute from a Windows 2000 domain controller gives access to all attributes. With the Replicating Directory Changes right on an Active Directory partition, anything can be replicated from a Windows 2000 domain controller, including passwords and confidential attributes, regardless of which domain the replication request is made from.
Windows Server 2003
Access rights that are granted:
  • Replicating Directory Changes

    With the Replicating Directory Changes right on an Active Directory partition in Windows Server 2003, all attributes except secrets (such as passwords) can be replicated. This includes RODC FAS attributes.
  • Replicating Directory Changes All

    With the Replicating Directory Changes All and the Replicating Directory Changes rights on an Active Directory partition in Windows Server 2003, all attributes can be replicated.
Windows Server 2008
Access rights that are granted:
  • Replicating Directory Changes

    With the Replicating Directory Changes right on an Active Directory partition in Windows Server 2008, all attributes except secrets and the RODC FAS can be replicated.
  • Replicating Directory Changes All

    With the Replicating Directory Changes All and the Replicating Directory Changes rights on an Active Directory partition in Windows Server 2008, all attributes can be replicated.
  • Replicating Directory Changes Filtered Set

    With the Replicating Directory Changes and the Replicating Directory Changes Filtered Set rights, all attributes except secrets can be replicated.
An RODC is granted only the Replicating Directory Changes right. This means that a rogue RODC could potentially replicate everything, including secrets and RODC FAS attributes, from a domain controller that runs Windows 2000 Server. However, if you want to deploy an RODC, the forest functional level must be Windows Server 2003 or higher, which excludes any domain controllers that run Windows 2000 Server from the forest.
A rogue RODC can replicate RODC FAS data from a domain controller that runs Windows Server 2003 by making a replication request (running as System on an RODC, and using repadmin /getchanges with proper parameters).
A rogue RODC cannot get secrets or RODC FAS data from a domain controller that runs Windows Server 2008. However, domain controllers that run Windows Server 2003 are granted the Replicating Directory Changes right, and, in the case of Windows Server 2003, it includes RODC FAS attributes. This means that any attribute that is part of the partial attribute set that is replicated to the global catalog and is also part of the RODC FAS will replicate to global catalog servers that run Windows Server 2003. Therefore, the presence of a Windows Server 2003 global catalog server represents an opportunity for a rogue RODC to replicate RODC FAS data.
You cannot add system-critical attributes to the RODC FAS. An attribute is system critical if it is required for AD DS, Local Security Authority (LSA), Security Accounts Manager (SAM), and any of Microsoft-specific Security Service Providers, such as the Kerberos authentication protocol, to function properly. A system-critical attribute has a schemaFlagsEx attribute value of (schemaFlagsEx attribute value & 0x1 = TRUE).
Make sure that the domain controller that holds the schema operations master (also known as flexible single master operations or FSMO) role is running Windows Server 2008 when you add attributes to the RODC FAS so that the attributes are verified to not be system critical. If you try to add a system-critical attribute to the RODC FAS while the schema master is running Windows Server 2008, the server returns a Lightweight Directory Access Protocol (LDAP) error "unwillingToPerform" (0x35). The Windows Server 2003 operating system does not use the RODC FAS. If you try to add a system-critical attribute to the RODC FAS while the schema master is running Windows Server 2003, the operation will appear to succeed but the attribute will not actually be added to the set.
To mark an attribute as confidential, you have to remove the Read permission for the attribute for the Authenticated Users group. Before you mark an attribute as confidential, thoroughly test the effect that it might have on your applications. For more information about marking attributes as confidential, see article 922836 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=99814).
If you are certain that you need to add an attribute to the FAS, there is some benefit to adding it before you install the first RODC in the forest. This way, the attribute never appears on any RODC at any point in time.
You can also add any attribute to the FAS after you install RODCs. AD DS will then dynamically remove links to the attribute value in the Active Directory database from all RODCs in the forest. This removal process is similar to the removal of an attribute from the partial attribute set that is replicated to the global catalog. The attribute values are not immediately deleted from the Active Directory databases on the RODCs. Instead, a link to the value is removed, which prevents AD DS from reading it.
The following attributes are configured as part of the RODC FAS. They are marked as confidential by default to support Credential Roaming and BitLocker Drive Encryption in Windows Server 2008:
  • ms-PKI-DPAPIMasterKeys

  • ms-PKI-AccountCredentials

  • ms-PKI-RoamingTimeStamp

  • ms-FVE-KeyPackage

  • ms-FVE-RecoveryPassword

  • ms-TPM-OwnerInformation               

Forwarding Events (part 2) - How to Troubleshoot Event Forwarding & How to Configure Event Forwarding in Workgroup Environments

3. How to Configure Event Forwarding in Workgroup Environments

Typically, event forwarding is required only in large environments that use AD DS domains. However, you can also configure event forwarding in workgroup environments. The process is very similar to that used in AD DS environments, with the following exceptions:
  • You must add a Windows Firewall exception for Remote Event Log Management on each forwarding computer.
  • You must add an account with administrator privileges to the Event Log Readers local group on each forwarding computer. You must specify this account in the Configure Advanced Subscription Settings dialog box when creating a subscription on the collector computer.
  • On each collecting computer, run the following command to allow the forwarding computers to use NTLM authentication: winrm set winrm/config/client @{TrustedHosts=""}.
    Provide a comma-separated list of forwarding computers for the value in the previous example. Alternatively, you can provide a wildcard, such as msft*.

Tip:
For the exam, remember that you must configure the TrustedHosts parameter on the collecting computer, not the forwarding computer. This is counterintuitive and might be hard to remember.

4. How to Troubleshoot Event Forwarding

If event forwarding doesn't seem to function properly, follow these steps to troubleshoot the problem:
  1. Verify that you have waited long enough for the event to be forwarded. Forwarding events using the Normal setting can take up to 15 minutes. The delay might be longer if either the forwarding or the collection computer has restarted recently because the Windows Remote Management service is set to start automatically, but with a delay so that it doesn't affect startup performance. The 15-minute counter doesn't start until after the Windows Remote Management service has started.
  2. Check the Applications And Services Logs\Microsoft\Windows\Eventlog-ForwardPlugin\Operational event log and verify that the subscription was created successfully. Event ID 100 indicates a new subscription, whereas Event ID 103 indicates a subscription has been unsubscribed.
  3. Check the Security event log to verify that the forwarding and collecting computers are authenticating correctly.
  4. Verify that the subscription is Active. On the collecting computer, browse to Event Viewer\Subscriptions. The subscription status should be Active. If it is not, right-click the subscription and then click Runtime Status. Event Viewer displays the Subscription Runtime Status dialog box with an error code.
  5. Verify that the forwarding computer has the Windows Remote Management listener properly configured. From an elevated command prompt, run the following command: winrm enumerate winrm/config/Listener.
    If the Windows Remote Management listener isn't configured, there is no output. If the Windows Remote Management listener is configured properly for HTTP, the output resembles the following:
    Listener
       Address = *
       Transport = HTTP
       Port = 80
       Hostname
       Enabled = true
       URLPrefix = wsman
       CertificateThumbprint
       ListeningOn = 127.0.0.1, 192.168.1.214, ::1, fe80::100:7f:ffe%9,
                     fe80::5efe:192.168.1.214%10

    If the Windows Remote Management listener is configured properly for HTTPS, the output resembles the following (note that the host name must match the name the event collector uses to identify the computer):
    Listener
       Address = *
       Transport = HTTPS
       Port = 443
       Hostname = win7.nwtraders.msft
       Enabled = true
       URLPrefix = wsman
       CertificateThumbprint = 52 31 db a8 45 50 1f 29 d9 3e 16 f0 da 82 ae
                               94 18 8f 61 5e
       ListeningOn = 127.0.0.1, 192.168.1.214, ::1, fe80::100:7f:ffe%9,
                     fe80::5efe:192.168.1.214%10

  6. Verify that the collecting computer can connect to Windows Remote Management on the forwarding computer. From an elevated command prompt on the collecting computer, run the following command: winrm id -remote:..
    For example, if the forwarding computer is named win7.nwtraders.msft, you would run the following command: winrm id -remote:win7.nwtraders.msft.
    The result would be as follows:
    IdentifyResponse
       ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
       ProductVender = Microsoft Corporation
       ProductVersion = OS: 6.0.6000 SP: 0.0 Stack: 1.0

    If you receive the message "WS-Management could not connect to the specified destination," verify that the Windows Remote Management service is started on the forwarding computer and that no firewall is blocking connections between the two computers.
  7. Verify that the user account you configured the subscription to use has privileges on the forwarding computer. If necessary, enable failure security auditing on the remote computer , wait for events to be forwarded, and then examine the Security event log for logon failures. In addition, you can configure the subscription temporarily to use a Domain Admin account—if the subscription works with the Domain Admin account, the source of your problem is definitely related to authentication. Troubleshoot the authentication problem and reconfigure the subscription to use the original user account.
  8. If the subscription is configured to use Machine Account authentication, verify that the collecting computer's account is a member of the forwarding computer's Event Log Readers local group. If the subscription is configured to use a different user account, that account must be in the forwarding computer's Event Log Readers local group.
  9. Verify that the following services are started on the forwarding computer:
    • Windows Remote Management (WS-Management)
    • Windows Event Collector
  10. Verify that the Windows Event Collector service is started on the collecting computer.
  11. Verify Windows Firewall settings on the forwarding computer as follows:
    • Verify that the Windows Remote Management (HTTP-In) firewall exception is enabled.
    • If you are using HTTPS instead of HTTP, verify that you have created and enabled a custom firewall exception for TCP port 443.
    • Verify that the forwarding computer and the collecting computer are both connected to Private or Domain networks, rather than to Public networks. To verify the network profile, right-click the network icon in the system tray and then click Open Network And Sharing Center. In the Network And Sharing Center, the profile type appears after the network name. If it shows Public Network, click Customize and change the profile type to Work Network, which uses the private network profile.
  12. In addition to the forwarding computer, verify that the Windows Remote Management (HTTP-In) firewall exception is enabled on the collecting computer.
  13. Verify that a network firewall is not blocking traffic by testing connectivity. Because the forwarding computer must have HTTP (and possibly HTTPS) available, you can attempt to connect to it from the collecting computer by using Windows Internet Explorer—simply type http://computername (or https://computername if you are using HTTPS) in the Address bar. If the firewall on the forwarding computer is configured correctly, you receive an HTTP 404 error and Internet Explorer displays the message, "The webpage cannot be found." If Internet Explorer displays the message, "Internet Explorer cannot display the webpage," the firewall exception on the forwarding computer has not been enabled.
  14. Verify that the event query is valid by performing these steps:
    1. View the subscription properties, and click Select Events.
    2. Select the XML tab, select the contents of the query, and press Ctrl+C to copy it to the Clipboard.
    3. Open a second instance of Event Viewer. Right-click Event Viewer, and then click Connect To Another Computer. Select the forwarding computer, and then click OK.
    4. Right-click Custom Views, and then click Create Custom View.
    5. In the Create Custom View dialog box, select the XML tab. Select the Edit Query Manually check box, and click Yes when prompted.
    6. Click the query box and press Ctrl+V to paste the query. Then click OK.
    7. The new custom view appears and shows the matching events. If any events have appeared since you created the event forwarder, they should have been forwarded. If there are no new events, the problem is with your forwarding criteria. Try creating a custom view that matches the events that you want to forward and then importing that into a new subscription.
4.1. PRACTICE: Forward Events Between Computers
4.1.1. PRACTICE: Forward Events Between Computers
In this practice, you configure event forwarding between two computers using the default settings.
EXERCISE 1 Configuring a Computer to Collect Events
In this exercise, you configure a computer to collect events.
  1. Log on to the computer running Windows 7 that you want to use to collect events using a domain account with administrative privileges.
  2. Open an elevated command prompt by clicking Start, typing cmd, and pressing Ctrl+Shift+Enter.
  3. At the command prompt, run the following command to configure the Windows Event Collector service:
    wecutil qc

  4. When prompted to change the service startup mode to Delay-Start, type Y, and then press Enter.
EXERCISE 2 Configuring a Computer to Forward Events
In this exercise, you configure a computer running Windows 7 to forward events to the collecting computer. To complete this exercise, you must have completed Exercise 1.
  1. Log on to the computer running Windows 7 that you want to use to forward events using a domain account with administrative privileges.
  2. Open an elevated command prompt by clicking Start, typing cmd, and pressing Ctrl+Shift+Enter.
  3. At the command prompt, run the following command to configure the Windows Remote Management service: winrm quickconfig.
  4. When prompted to change the service startup mode, type Y, and then press Enter.
  5. When prompted to create the WinRM listener and enable the firewall exception, type Y and then press Enter.
  6. Verify that you have updated the Windows Firewall configuration by following these steps:
    1. Click Start and then click Control Panel.
    2. Click the System And Security link.
    3. Click the Windows Firewall link.
    4. Click the Advanced Settings link.
    5. Select the Inbound Rules node.
    6. In the Details pane, verify that the Windows Remote Management (HTTP-In) exception is enabled for the Domain and Private profiles.
  7. Verify that the Windows Remote Management service is configured to start automatically by following these steps:
    1. Click Start, type services.msc, and then press Enter.
    2. In the Services console, select the Windows Remote Management (WS-Management) service. Verify that it is started and that the Startup Type is set to Automatic (Delayed Start).
  8. Now you need to grant the collecting computer permission to read this computer's event log. If you skipped this step, you would need to configure the subscription to use an administrative user account. To grant access to the collecting computer account, perform these steps:
    1. Click Start, right-click Computer, and then click Manage.
    2. Under System Tools, expand Local Users And Groups. Then, select Groups.
    3. Double-click Event Log Readers.
    4. In the Event Log Readers Properties dialog box, click Add.
    5. In the Select Users, Computers, Service Accounts, Or Groups dialog box, click Object Types. By default, it searches only Users and Groups. However, we need to add the collecting computer account. Select the Computers check box and clear the Groups, Users, and Service Accounts check boxes. Click OK.
    6. In the Select Users, Computers, Or Groups dialog box, type the name of the collecting computer. Then, click OK.
    7. Click OK again to close the Event Log Readers Properties dialog box.
EXERCISE 3 Configuring an Event Subscription
In this exercise, you create an event subscription to gather events from the forwarding computer. To complete this exercise, you must have completed Exercises 1 and 2.

  1. Log on to the computer running Windows 7 that you want to use to collect events using a domain account with administrative privileges.
  2. Click Start, right-click Computer, and then click Manage.
  3. In the Computer Management console, expand System Tools, expand Event Viewer, right-click Subscriptions, and then click Create Subscription.
  4. In the Event Viewer dialog box, click Yes to configure the Windows Event Collector service (if prompted).
    The Subscription Properties dialog box appears.
  5. In the Subscription Name box, type Windows Defender Warnings And Errors.
  6. Click Select Computers. In the Computers dialog box, click Add Domain Computers. Type the name of the computer that will be forwarding events, and then click OK. In the Computers dialog box, click Test to verify that you can connect to the forwarding computer. Click OK twice.
  7. Click Select Events. In the Query Filter dialog box, select the Error, Critical, Warning, and Information check boxes. Click By Source. Then, click the Event Sources list and select Windows Defender (as shown in Figure 4). Click OK.
    Figure 4. Configuring the Query Filter to forward important Windows Defender events
  8. Click Advanced to open the Advanced Subscription Settings dialog box. Note that it is configured to use the Machine Account by default. This works because we have added this computer's domain account to the forwarding computer's Event Log Readers local group. Also, note that the subscription is configured by default to use Normal Event Delivery Optimization using the HTTP protocol. Click OK.
  9. In the Subscription Properties dialog box, click OK.
  10. Next, generate a Windows Defender event on the forwarding computer by following these steps:
    1. Log on to the forwarding computer.
    2. Click Start and type Defender. On the Start menu, click Scan For Spyware And Other Potentially Unwanted Software.
      Windows Defender scans the computer and adds an event to the event log.
  11. While still using the forwarding computer, open Event Viewer and check the Applications And Services Logs\Microsoft\Windows\Windows Defender\Operational log. You should see several Informational events with a source of Windows Defender.
  12. Using the collecting computer, select the Forwarded Events event log. If you don't see the Windows Defender event immediately, wait a few minutes—it might take up to 15 minutes for the event to appear.