how to manage Microsoft Active Directory with hp OpenView Microsoft Active Directory
hp OpenView Microsoft ® Active Directory manage white paper how to manage Microsoft Active Directory with hp OpenView what is Active Directory? Microsoft ® Active Directory is a central and inseparable component of the Windows® 2000 operating system when used as a network operating system. The Active Directory functions as a distributed, replicated, multimaster and fault-tolerant directory service. In a Windows 2000 infrastructure, the Active Directory is used as the repository for storing user identity data, computer and application configuration information, system configuration and security policies. In fact, Windows 2000 stores configuration information about the directory service itself in Active Directory. The Active Directory acts as a distributed authentication mechanism for the Windows infrastructure, providing single sign-on for all systems, users and applications with access to the directory. Coupling distributed authentication with policy dissemination allows Active Directory to increase enterprise-wide security by allowing for tightly managed systems which can ensure that corporatewide compliance with established security policies and best practices is maintained. The Active Directory can contain a vast amount of information related to a plethora of objects (applications, computers, users, groups, distribution lists, network devices, etc.). As such, it can act as a central point for managing these objects. Organizational management structures often form a hierarchical structure with the individuals at the highest levels of that structure delegating responsibilities and tasks to those at lower levels. The Active Directory functions in the same way by allowing for a hierarchical structure to be defined within the directory and allowing the objects within the directory to be organized within this hierarchy as appropriate. The Active Directory is built on open standards so it can also act as an integration point for other enterprise applications and systems requiring directory or authentication services, or requiring other data for processing related to the Windows infrastructure and its users. Many enterprise applications are now being written specifically to take advantage of the Active Directory, including e-mail systems, public key infrastructures, remote access providers, human resource systems, customer relationship management applications and more. These applications act as the mainstay of many day-to-day operations in enterprise environments. In short, today many businesses are becoming heavily dependant on enterprise directory services, which may include a single directory service, like Active Directory, or a variety of integrated directory services. These directories sustain many of the internal operations of the business, and their availability and reliability is becoming as important as the underlying network. Active Directory is a relatively new player in the directory services market. However, considering the installed base of Windows servers around the world, Active Directory is and will continue to be a formidable force. why does Active Directory need to be managed? Page 1 Active Directory and directory services in general can be an extremely far-reaching technology component in an enterprise infrastructure. As the reach of Active Directory expands, day-to-day business dependencies on Windows and Active Directory are increasing. Disruptions to the directory service, including outages, non-optimal configurations, latencies and inconsistent data, will begin to have a widespread impact on business operations. The impact may come in the form of lost productivity, disabled manufacturing systems, lost sales and more, all of which result in a cost, be it opportunistic or financial. The advent of Active Directory and its adoption for use as the NOS and enterprise directory service will further drive the importance of proper management and monitoring for Windows-based systems once pushed down the list of enterprise priorities. In fact, the new features of Active Directory, which allow for very distributed and complex deployments, are in many cases so fault tolerant that when a true outage occurs the system may be in a catastrophic state. hp OpenView Microsoft ® Active Directory white paper Traditionally, management and monitoring in a Windows environment was often disregarded as a low priority task because most systems supported workgroup applications and tasks while most mission-critical applications were supported by mainframe and UNIX® hosts. Aside from the role played by Windows servers in the enterprise infrastructures of the past, managing and monitoring Windows servers was not an easy task, especially in medium and large enterprise environments. Tools and interfaces available for managing Windows-based computing had several substantial shortcomings. Windows 2000 brings with it a host of new tools and interfaces native to the operating system to help deal with the problem of management and monitoring. Open interfaces based on industry standards like Active Directory Services Interface and Windows Management Instrumentation provide a robust base to develop solutions for managing and monitoring the Windows infrastructure, which now more than ever is critical to the success of Windows in the enterprise space. As Windows becomes more pervasive in the enterprise space, Active Directory will become a leveraging point for an increasing number of enterprise-wide applications (such as Exchange 2000). Many of these types of applications have a global scope. As they will rely on Active Directory it too must function with a distributed global environment in mind. Considering that enterprise applications may need to both read and write to the directory, Active Directory acts in a multimaster configuration, allowing changes and queries to be made to any domain controller. As such, objects may be created on different domain controllers spread around the world. Active Directory, via replication, will consolidate the state of these objects—new, modified and removed—but due to the network latency and the potentially distributed nature of the directory, data in the Active Directory is seen as loosely consistent or not immediately convergent. Applications that rely on Active Directory typically expect to get the same data regarding objects regardless of from where the request originates throughout the infrastructure. As consistency waivers, applications may behave incorrectly. Therefore, ensuring that you have a properly functioning Active Directory infrastructure with minimal, or at least a known amount of, replication latency is key when deploying business applications on top of the directory. detailed architecture review of Active Directory the database The Active Directory is built atop the JET Blue database, also known as the Extensible Storage Engine. Microsoft has built many of its products using a version of JET, including DHCP, WINS and Exchange 4.0-2000. Each domain controller in the forest hosts at least a partial copy of the Active Directory. From the file system perspective, JET Blue manifests itself as a series of files. The Active Directory database itself is stored in the ntds.dit file. Since JET is a transactional database, a series of log files exist to ensure that all transactions are committed to disk in case of a system crash. The log files include: • Several EDB*.log files, the transaction logs, each 10 MB in size, • Two “reserve” log files, Res1.log and Res2.log, which each reserve 10 MB of disk space to ensure that if the EDB*.log files fill, additional space will be available for writing transactions, • An EDB.chk file, which is the checkpoint file telling the system which transactions have been committed, and in the case of a failure, which log files need to be replayed to ensure the database is in the most up-to-date state possible. From a functional perspective, all write transactions to a given domain controller are written first to the transaction logs. The write process is sequential; therefore placing the transaction log files on a disk volume optimized for writes will improve transaction processing performance. All transactions written to the log files are later committed to the ntds.dit database file. Most read transactions are Page 2 hp OpenView Microsoft ® Active Directory white paper performed against the ntds.dit file and read requests can be made asynchronously. Therefore, placing the ntds.dit file on a disk volume optimized for reads will improve query performance. Given the different usage patterns of the database and its log files, these file sets are commonly split among different disk volumes to further improve performance by allowing for more I/Os per second and different configurations per volume to meet the specific needs of the component utilizing the volume. forests, trees and domains The Active Directory can be carved out into different sections to increase its manageability and performance. Any single Active Directory is logically referred to as “the forest.” The forest is a collection of domains that all share a common set of configuration information, which includes the database schema, as well as a common global catalog for forest-wide queries. The forest also acts as the ultimate security boundary of the Active Directory. The first domain created in the forest is referred to as the root domain. The root domain can never be removed from the forest without dismantling the forest itself. As with all other domains, the root domain has a fully qualified DNS style domain name associated with it, for example hp.com. Additional domains can be added to the forest and can either be created as child domains within the root domains tree or can be created as the root for new trees. While a number of differences do exist, the most pronounced is that the name of the domain will differ depending on how it is created. For example, if a child domain is added to the hp.com tree it might be called na.hp.com, whereas if a new domain tree were created it might be called compaq.com. The domains hp.com and na.hp.com are said to be in the same tree because their naming structure is hierarchical in nature. Each domain itself represents a clear administrative boundary. Each domain is hosted by one or more domain controllers, meaning that those domain controllers retain a complete and writable replica of that domain’s database, also referred to as the domain naming context. Special instances of domain controllers, called global catalogs, host a partial read-only replica of every domain database in the forest; however any domain controller can only host a complete and writable replica of the database for the domain to which it belongs. In order to retain consistency throughout the forest and domains, data is replicated among domain controllers. The data to be replicated is determined by the domain membership of the domain controller. Domain controllers of the same domain replicate configuration, schema, and the local domain- naming context between each other. Domain controllers of different domains only replicate configuration and schema information. In the case of the global catalog, some domain naming context data from other domains is replicated to and from this special domain controller. domain name services Windows 2000 and the Active Directory rely on Domain Name Services (DNS) as the primary name resolution method for all domains, server principal names (SPN), user principal names (UPN) and services. Domain controllers and global catalogs register host, alias and server resource records (SRV) in DNS. These records are used by many processes in the Active Directory to identify domain controllers, global catalogs, Kerberos Key Distribution Centers, among other functional roles. For example, if a domain controller does not properly register its GUID (globally unique identifier) as a CNAME (alias), Active Directory replication to the domain controller will not be possible, and therefore data changes may not be able to be replicated to or from the domain controller. For this and many other reasons, DNS becomes extremely critical to the operations of the Active Directory. If DNS is not functioning properly the Active Directory will typically follow suit. Page 3 hp OpenView Microsoft ® Active Directory white paper sites, site links and subnets Unfortunately, the current implementation of Active Directory cannot interact with routers, switches and the various routing protocols to determine how the physical network is configured. However, this can be done manually by an administrator. The information provided by the administrator is referred to as the site topology. The site topology is typically implemented to represent the physical network, but it does not have to match the physical layout in its entirety. The site topology is used by Active Directory to determine locality and the replication topology. Typically, a site is defined to represent a physical location or a closely tied group of locations. The Active Directory believes a site to be a group of subnets with high speed connectivity. As such, administrators define a site and attach particular subnets to the site to define its boundaries. The result of this, for example, is that a workstation can determine what site it resides in and access resources, such as a domain controller, that reside in the same site. From a replication perspective, domain controllers use site definitions to determine the most appropriate partner domain controllers to replicate with. For example, if three sites exist, New York is connected to Seattle with a T1 link and is also connected to Spokane with a 56Kbps link, and Seattle is connected to Spokane with a T1 link, it may be beneficial for New York to always replicate information with Seattle, even if it is destined for Spokane. An administrator defines this scenario by creating site links to join New York to Seattle and Seattle to Spokane. An administrator can further define the structure by defining a site link between New York and Spokane (a more exact representation of the physical topology) yet still ensure that most replication will occur over the link between New York and Seattle by defining a lower “cost” for that link while at the same time utilizing the direct connection between New York and Spokane in the case where the New York to Seattle link is unavailable. replication Replication is the process of transmitting additions, modifications and removals to the Active Directory among domain controllers. Replication in an Active Directory infrastructure is critical as users and applications always desire up-to-date information. Stale data can provide unwanted outcomes for users and processes that consume the data, which might include security information and policies. In addition, incorrect configurations in the site topology and the inability to reach replication partners in the environment can result in replication queue backlogs, which can further result in delays to replication and at worst the unavailability of services such as the global catalog. In many cases an infrastructure that is not closely monitored may see no symptoms of any outage or delay as Active Directory replication can be designed in a very fault-tolerant manner. Two basic replication scenarios exist: intrasite replication and intersite replication. When replication occurs between domain controllers in the same site (intrasite), how often replication occurs is governed by configuration of the connection object created (manually or automatically) between the two domain controllers. The default configuration for replication between two domain controllers in the same site is once per hour. However, by default, as domain controllers modify objects they will notify their replication partners of such events, which in turn may result in replication attempts being made at a higher rate than that defined by the connection object. When replication occurs between two sites (intersite), how often and at what time of the day replication occurs is governed by configuration of the site link between the two sites. The way in which the site link is configured will also determine the minimum time from when changes are made in one site until they are replicated to other, referred to as replication latency. The default configuration of a site links allows replication to occur throughout a 24-hour period every 180 minutes. However, in some environments heavy network utilization of WAN links might make directory replication unreasonable during certain times (such as normal operating hours of the business). In this case, the site link conPage 4 hp OpenView Microsoft ® Active Directory white paper figuration offers some flexibility, allowing link availability to be defined on an hour-by-hour basis and the replication interval to occur from as few as every 15 minutes to as many as 10,080 minutes. Regardless, as the configuration is adjusted the replication latency between the sites will be impacted. Note: The notification process discussed for intrasite replication can be enabled for intersite replication; however this is typically less than desirable as it may result in increased traffic over the WAN due to more frequent replication attempts than as defined in the site link. A special replication case is that of a global catalog. As previously defined, a global catalog is a special instance of a domain controller that hosts a partial read-only replica of every domain database in the forest in addition to a fully writable replica from its own domain. Some applications, such as Exchange 2000, rely heavily on forest-wide queries returned by a global catalog. As domains themselves may be geographically dispersed, replication latency from the various domains to the global catalogs in the forest may be higher than that of the latency within a domain. Monitoring of global catalog latency becomes an important factor in maintaining consistent data for those applications requiring forest-wide queries. organizational units, group policy objects and SYSVOL Organizational Units (OUs) are logical containers that can be created with an Active Directory domain. OUs are used to organize groups of objects within the directory. Organizing objects in such a way allows the administrator the ability to delegate authority over a group of objects to another user and apply policies to a set of objects quickly and easily. The ease of this is made so by the concept of inheritance; i.e. objects within an OU inherit the policies and security permissions applied to their “parent” container. In most information technology (IT) environments, there are too many tasks to allow a single administrator to handle them all. Therefore, often a variety of tasks are delegated to a number of different individuals. Sometimes these individuals are part of the IT team while other times they are part of the end-user community. Regardless, OUs in combination with access control lists and inheritance provide an IT organization with the means necessary to delegate permissions to objects at a very granular level. OUs are often the point of application for delegated permissions, as it is uncommon that a user is given permission to only a single object. However, it is possible to provide delegated permissions to individuals on a per-object basis. Most IT organizations have written policies reflecting what users, machines and applications should and should not be able to do. The Active Directory allows for the translation of these written policies by an administrator into technical policies that can be enforced by the underlying infrastructure. The application of these policies is done by way of group policy objects (GPOs). GPOs can be applied to a domain, site and OU, and are inherited by the underlying structure. Common usage of GPOs includes the application of: • Login, logout, startup and shutdown scripts • Software deployment and installation • Security policies, such as password length and complexity, account lockout and reset, Kerberos ticket lifetime (applied at the level of the domain only) • Desktop settings, such as background and color schemes, • System control settings like limiting access to the control panel, screen saver or other display settings • And many others … Page 5 hp OpenView Microsoft ® Active Directory white paper While the application of a GPO to a domain, site or OU is stored in the Active Directory, the policy itself and other scripts that the policy refers to are not stored in the Active Directory. Instead these are stored as files in the SYSVOL share. SYSVOL is a distributed file system (DFS) share that is replicated among domain controllers of the same domain using file replication system (FRS). While FRS is a different replication mechanism than what is used by Active Directory, FRS respects the site topology defined by an administrator and the connections created by the KCC and ISTG when replicating SYSVOL data. As with the Active Directory, SYSVOL can be quite fault tolerant, as it is supported by DFS. Also like Active Directory, without a sound monitoring system in place, when problematic symptoms begin to appear with SYSVOL, the problem may be in an advanced stage. operations masters Although Windows 2000 is predominantly a multi-master environment, there are certain roles that handle critical operations which could not easily be resolved in the case that they were generated in more than one place at the same time. Certain changes, such as the addition or deletion of a domain or changes to the Active Directory schema, have a significant impact throughout the entire forest. For this reason Active Directory adheres to a single-master to handle the most critical of forest and domain operations. Schema Master—A single domain controller in the forest owns this role. The schema master is allowed to make changes to the schema. In the event that the schema master is unavailable, changes to the schema cannot be made. Domain Naming Master—A single domain controller in the forest owns this role. The domain naming master controls changes to the domain namespace, including additions, removals and modifications to the names of domains to the forest. In the event that the domain naming master is unavailable, domains cannot be added or removed from the forest and their names cannot be changed. PDC Emulator—A single domain controller in each domain owns this role. The PDC emulator is used for down-level compatibility. The PDC emulator provides a “flat” replica of the directory compatible with a Windows NT® SAM database when replicating to previous non-Windows 2000 (and greater) domain controllers. The PDC emulator will also fulfill all requests made to the PDC by down-level clients. The PDC emulator gets expedited replication of password changes performed by other DCs in the domain. The PDC Emulator also acts as the primary time source for its domain. In the event that the PDC emulator is unavailable, down-level domain controllers will fail to receive replicas of the directory, requests for the PDC from down-level clients (e.g. for password changes) will fail, and time throughout the domain may become unsynchronized resulting in Kerberos ticket, and other time-sensitive processes, to become invalid and function erratically. RID Master—A single domain controller in each domain owns this role. The RID master manages and allocates relative identifiers (RIDs) within each domain. The RID master allocates a pool of RIDs to each domain controller. These RIDs are required when new objects such as users, groups and computers are created. The RID master also is required when moving an object from one domain to another. In the event that the RID master becomes unavailable domain controllers will fail to create new objects once their existing RID pool has been exhausted. Infrastructure Master—A single domain controller in each domain owns this role. The infrastructure master ensures that references to objects outside the local domain can be made, as domain controllers do not typically know about objects outside of their domain. The infrastructure master maintains consistency in group memberships when objects belonging to the group, and objects from other domains, are renamed or moved. The infrastructure master does this by creating phantom objects that essentially act as pointers to the objects of other domains. The infrastructure master should not reside on a global catalog, as the infrastructure master will only create phantom objects for those objects that it does not contain a replica of (even if only a partial replica). A global catalog contains a partial copy of every object in the forest; if the two roles Page 6 hp OpenView Microsoft ® Active Directory white paper existed on the same machine, phantom objects would never be created, which would lead to nonresolvable references on all other domain controllers within the domain. In the event that the infrastructure master is unavailable, object renames and moves outside the local domain will not be reflected in the group memberships of the local domain, thereby resulting in some processes not including a particular user in a group. hp OpenView and Active Directory It is likely that Active Directory is or will be a vital part of the computing infrastructure. Users may depend on it for things such as login and address books, and applications may depend on it for such things as access control and publication of application services. Failure or unavailability of the directory can result in downtime for users and applications, which translates into lost money and business. By monitoring directory services, administrators can learn of outages as soon as they occur. With more sophisticated monitoring strategies, administrators can anticipate problems before they become an outage. In addition, information gathered from this type of monitoring can be used to fine-tune Active Directory server with regard to CPU utilization and the I/O subsystem. HP provides a comprehensive solution in monitoring distributed, heterogeneous e-business infrastructures with its HP OpenView management solution offering. HP OpenView Operations for Windows (OVOW) is a distributed, client/server software solution designed to provide service-driven event and performance management of business-critical enterprise systems, applications and services. It enables management of distributed, heterogeneous infrastructures and includes support for a broad range of Windows systems and applications. Additionally, Operations for Windows provides console and server functionality to monitor performance and events using agents installed on nodes to be managed. Agents evaluate conditional rules, monitor events that occur on managed nodes, and forward appropriate events to the management server or execute specific actions requested by the operator. Rules, threshold values and tools come with the Smart Plug-in (SPI) components, which possess all the knowledge about a specific system or application. HP OpenView Operations for Windows provides several base SPIs that ship with the product. Administrators can deploy additional SPIs to complement the base SPIs or to get advanced monitoring capabilities. Preconfigured policies, conditional rules, threshold values and tools specific to a component or an application are provided through SPIs. In general, the SPI components include policies for service monitoring and reports for consolidating collected data, predefined graphs and tools. Policies allow controlling the monitoring schedule and defining rules and thresholds to filter events with relevant information and status data. Policies also control receipt of collected information in the form of service map alerts and messages. Service map alerts are shown in the HP OpenView Operations for Windows service map, while messages can be viewed in the Operations message browser, as shown in Figure 1. Page 7 hp OpenView Microsoft ® Active Directory white paper Figure 1: Message Browser and Service Map consoles. Starting with releases 6.x and 7.0, HP OpenView Operations for Windows provides support for the Windows 2000 platform. Operations for Windows 7.1 can manage Windows 2000 server nodes. Support for Windows 2003 server is planned with the 7.2 release of HP OpenView Operations for Windows. Active Directory monitoring is provided in two SPIs: • The Windows Operating System SPI (WINOS-SPI) is provided as part of the base product and includes basic monitoring and management capabilities. • The Active Directory SPI adds replication, operations master, global catalog, DNS monitoring capabilities as well as enhanced visualization features. The combination of the two SPIs offers a broad range of possibilities to manage and monitor Active Directory. These SPIs will keep administrators informed about the various conditions that are occurring across the network with regard to Active Directory. how hp OpenView monitors and manages Active Directory HP OpenView provides choices in the levels of Active Directory monitoring implemented at a site. The WINOS-SPI provides Active Directory availability and performance monitoring along with firstlevel discovery, while the Active Directory SPI provides more detailed and thorough capabilities. components of the Windows OS SPI The WINOS-SPI provides preconfigured policies and tools for managing the operations and performance on Windows nodes. This functionality is provided as part of the HP OpenView Operations for Windows product and includes system and application basic management. The WINOS-SPI also includes policies to manage the Active Directory component. Those policies can be classified under the following categories: Page 8 hp OpenView Microsoft ® Active Directory white paper Category Inventory Description Policies of this category perform the following operations: • Discover the infrastructure related to Active Directory and update the service map with domain and site information • Monitor the state of critical system services, such as the Netlogon service and the KCC service • Forward events related to Domain Naming Service (DNS), File Replication Service (FRS), Directory Services (DS) and SNMP logs to the management console Control change Policies of this category, when deployed, report changes in the infrastructure including: • Domain Change: addition, deletion of domains in the forest • Organizational Unit (OU) change: creation of new OU, modification of contents in an OU • Site topology change: addition, deletion of Windows 2000 Active Directory sites Performance data collection Policies of this category, when deployed, collect performance data of the following events: • Authentication request • Replication service • LDAP queries They also send alert messages to the console when threshold values are met Security auditing Policies of this category, when deployed, perform security auditing on access to certain objects Active Directory policies belonging to the WINOS-SPI have their names prefixed with “WINOSSPIADS-” and are located under the Policy Management\Policy Groups\Microsoft Windows Core hierarchy of the HP OpenView Operations for Windows management console. All the Active Directory policies are not deployed by default except for the WINOSSPI-WINSys_AutoDiscovery policy. It is a mandatory policy added to any new Windows managed node to discover the Windows infrastructure. components of the Active Directory SPI The Active Directory SPI adds master operations and replication monitoring capabilities to HP OpenView Operations for Windows. It complements the base WINOS-SPI in monitoring specific components of Active Directory related to replication and FSMO roles. Components of the Active Directory SPI include: • Replication latency—Replication policies measure the time required to propagate a change to all DCs in the domain. In addition, a policy can also monitor the replication time for intersite replication and intrasite replication. • Master operations monitoring—Policies of this category measure the general responsiveness of different FSMO roles servers. • DNS-focused monitoring and reporting. Page 9 • Global catalog monitoring and reporting. hp OpenView Microsoft ® Active Directory white paper • Directory Information Tree (DIT) monitoring and reporting • Visualization and tuning with the Active Directory Topology Viewer tool and Service Map • Web-based reports and graphs related to replication performance data. using hp OpenView operations for Windows to monitor Active Directory Deploying a monitoring solution on Active Directory can possibly be a daunting task, as Active Directory configuration is a distributed and complex environment. Before deciding on a monitoring tool, solution architects should: • Assess the business requirements in terms of service level agreements (SLAs) for the business applications. • Understand the current environment. • Define technical requirements for a monitoring solution. • Determine components of the infrastructure to be monitored—Active Directory replication, DNS, authentication services, etc. • Define and agree on an SLA for each component. Determine acceptable threshold values and level of alerts to be reported to the management console. These planning items result in the selection of policies to be used and possible configurations of threshold values and timing intervals to be used in the HP OpenView Operations for Windows and Active Directory SPI policies. When implementing this solution, administrators can follow the steps below as a guideline for using Operations for Windows to monitor Active Directory. step 1: discovery of the Active Directory environment After installing HP OpenView Operations for Windows on a management console, administrators can add Windows computers into the management database. By default, the WINOSSPIWINSys_AutoDiscovery is deployed to new managed nodes to record its role in the Active Directory hierarchy of the services map as shown in the Figure 2 below. Figure 2: Discovery of new nodes in the services map. Page 10 hp OpenView Microsoft ® Active Directory white paper New managed nodes appear in the services map the day after they have been added as the discovery policy is scheduled to run at 2 a.m. each day. Administrators can change the default schedule by modifying the value in the properties of the corresponding policy and forcing its deployment on targeted nodes, as Figure 3 shows. Figure 3: Modify the schedule of the policy In addition, administrators can update the service map with information related to replication and master operations by running the discovery services policies provided with the Active Directory SPI. step 2: monitoring basic services There are some basic services that HP OpenView Operations for Windows can monitor to ensure that Active Directory is at least present and responding to requests on the network: • Domain Naming Service (DNS)—DNS is the first service used by clients to locate Active Directory Domain Controller (DC) and Global Catalog servers (GC). DCs and GCs register their service record (SRV) in DNS at startup time and DNS uses those records to provide name resolution for those servers. Monitoring the health of DNS is usually the first step to ensure that Active Directory services are present on the network. HP OpenView Operations for Windows 7.2 provides advanced monitoring capabilities for DNS in the Active Directory SPI as shown in the figure below. Page 11 hp OpenView Microsoft ® Active Directory white paper Figure 4: ADSPI policies related to DNS • NetLogon service—The NetLogon service runs on a Domain Controller to satisfy network requests to authenticate users. During its startup, it registers SRV records in DNS to advertise Active Directory services offered by the domain controller. Monitoring the state of the NetLogon service is absolutely critical for continued Active Directory operations. The WINOSSPIADS_NetLogon can be used for this purpose. • Kerberos Distribution Center (KDC) service—Working in conjunction with the NetLogon service, the KDC service is in charge of delivering Kerberos tickets. In Windows 2000, Kerberos provides a more secure authentication service when compared to the NTLM authentication and Kerberos is the default authentication method used in a Windows network. Therefore, monitoring the state of the KDC service is essential to Active Directory operations. step 3: monitoring changes in Active Directory Best practices in management of an infrastructure recommend having processes in place to control deployment and change operations. A deployment control process ensures that the construction of the infrastructure is solid and coherent. A change control process ensures that the infrastructure remains stable and consistent when modifications are made to the environment. Administrators can use HP OpenView Operations for Windows to monitor deployment operations and change operations in a Windows network. Different policies provided with the WINOS-SPI can be used as follow: Process Policy name Deployment control WINOSSPI-ADS_SiteChanges WINOSSPI-ADS_DomainChanges Change control Page 12 Description Monitors changes in the site topology Monitors change in the Domain configuration WINOSSPI-ADS_DirComputerModif Monitor changes in the Domain WINOSSPI-ADS_DirUserModif Naming context WINOSSPI-ADS_DirUserCreationDeletion WINOSSPI-ADS_SAMServerPropChange WINOSSPI-ADS_SecAdminGroupChange WINOSSPI-ADS_OUChanges hp OpenView Microsoft ® Active Directory white paper step 4: monitoring responsiveness of DC/GC The faster systems respond to network requests, the more likely it is that an SLA will be met. Users’ perception of the infrastructure completely depends on the response time to their requests satisfied by the systems. If users can lookup information in Active Directory very quickly, they will perceive that the infrastructure is performing well and will likely meet their expectations as defined in the SLA for directory lookup. Measuring and monitoring the response time for different activities of DC/GC help in determining and validating that different SLAs are being met. ADSPI provides the following policies to monitor response time: • ADSPI-ResponseTime_Bind and ADSPI-ResponseTime_Query measure response time for accessing DC and perform LDAP queries on the DC • ADSPI-ResponseTime_GCBind and ADSPI-ResponseTime_GCQuery measure response time for accessing GC and perform LDAP queries on the GC step 5: monitoring replication Active Directory replication plays a vital role in the directory ecosystem. It ensures that directory information is available on multiple servers, and thus increases the reliability and performance of the Active Directory service. Active Directory reliability is improved because there is no single point of service failure—clients can locate a different server for directory services if the current one fails or becomes unreachable. Having multiple replicas that contain the same Active Directory information improves the performance of Active Directory because directory client requests may be distributed across multiple servers. To achieve those objectives, directory administrators must ensure that replication is correctly functioning and that directory information is consistent across multiple servers locally and in remote sites. Monitoring tools should be deployed to verify that scheduled replication and directory updates are sent to all servers in a timely manner. ADSPI offers some capabilities to monitor Active Directory replication based on the following deployable policies: • ADSPI-Rep_Mon: Checks replication latency between DCs • ADSPI-Rep_InBoundObjs: Monitors the number of inbound replication objects The different steps described above provide the basic foundation to monitor Active Directory with HP OpenView Operations for Windows. Administrators can deploy additional policies to monitor Active Directory services, such as authentication service. what needs to be monitored and managed to maintain the Active Directory The HP OpenView Operations for Windows console provides different views to browse messages reported by agents. These range from managed node and service map views to display alerts in a graphical window. Also, the Operations for Windows console uses a hierarchical view to organize policies and tools that are available from the base product or with the addition of an SPI. Here are some best practices for first-time Operations for Windows operators: deployment of policy • Before deploying a policy to a set of managed nodes, you should verify and eventually change the schedule of the policy. A policy may be deployed immediately on targeted nodes but the agent will run the policy at the next schedule as defined in the properties of the policy as shown in Figure 3 above. • Modifying a property of a policy increases the version number of the policy. You should ensure that the latest version of the policy is currently deployed on a targeted node. Figure 5 shows how to view the resultant set of policies deployed on a specific node. Page 13 hp OpenView Microsoft ® Active Directory white paper Figure 5: Resultant set of policies deployed on a managed node • When deploying a policy, you should always check the contents of the Deployment jobs sub-hierarchy. It shows the status of policies to be deployed on managed nodes. In general, the contents of the folder should be empty. Figure 6: Policies waiting to be deployed Page 14 hp OpenView Microsoft ® Active Directory white paper policy management To ease management of policies, you can cluster policies that are of your interest and create customized groups of policies. Figure 7 shows an example of a customized group of policies. Figure 7: Defining group of policies monitoring DNS As described above, the health of DNS is crucial to the ongoing stability of an Active Directory. HP OpenView Operations for Windows provides in-depth monitoring of the DNS infrastructure. The WINOS-SPI offers basic monitoring of DNS services running on Windows 2000 servers. including the following deployable policies: • WINOSSPI-DNS_LogDNSPagesSec—monitors the pages per second used by the DNS server for capacity planning. • WINOSSPI-DNS_Server_Response—monitors the response time of the managed DNS server for capacity planning and performance service levels. • WINOSSPI-DNS_MsDnsServer—monitors the state of the DNS service and processes running on the server. When coupling the WINOS-SPI with the Active Directory SPI, an organization will realize a greatly enhanced set of deployable policies related to DNS. The result of deploying both the WINOS-SPI and the Active Directory SPI is a robust DNS monitoring system specifically tuned for DNS support of the Active Directory and Windows authentication services. The Active Directory SPI will ensure that DNS has the correct A, CNAME and SRV records for each DC and GC in the forest and report to the management server any missing or erroneous records. The following deployable policies support this functionality: • ADSPI-DNS_GC_StrandedSite—checks each site in the Active Directory to determine if a GC is available within the site. • ADSPI-DNS_Extra_GC_SRV_Chk—checks that all GC SRV records have a matching GC known by the Active Directory. • ADSPI-DNS_Kerberos_SRV_Chk—checks that all KDCs known to the Active Directory have a corresponding SRV record related to the KDC in DNS. Page 15 hp OpenView Microsoft ® Active Directory white paper • ADSPI-DNS_Extra_LDAP_SRV_Chk—checks that LDAP SRV records have a matching DC known by the Active Directory. • ADSPI-DNS_Extra_Kerberos_SRV_Chk—checks that all KDC SRV records have a matching DC known by the Active Directory. • ADSPI-DNS_LDAP_SRV_Chk—checks that all DCs known to the Active Directory have a corresponding SRV record related to LDAP in DNS. • ADSPI-DNS_GC_A_Chk—checks that all GCs known to the Active Directory have a corresponding A record for the GC in DNS. • ADSPI-DNS_DC_A_Chk—checks that all DCs known to the Active Directory have a corresponding A record for the DC in DNS. • ADSPI-DNS_DC_Response—monitors the response time of DNS queries made by the domain controller. • ADSPI-DNS_Island_Server—checks to see if the DC is configured to use itself as a DNS server, which can result in isolating the DC in some cases. • ADSPI-DNS_DC_CNAME_Chk—checks that all DCs known to the Active Directory have a CNAME record registered in DNS which corresponds to their GUID. • ADSPI-DNS_GC_SRV_Chk—checks that all GCs known to the Active Directory have a corresponding A record for the GC in DNS. • ADSPI-DNS_Obsolete_GUIDs—validates all Active Directory GUIDs registered in DNS as CNAME records that correspond to an existing DC in the Active Directory forest. Active Directory Topology Viewer The Active Directory SPI provides one new HP OpenView Operations for Windows tool: the Active Directory Topology Viewer (ADTV). ADTV can be used to generate a unique and powerful visual representation of an Active Directory forest. ADTV queries the Active Directory of a single forest for the following information: • Active Directory partitions, including configuration, schema, domain and Windows Server 2003 application partitions. • Active Directory sites and their associated DCs and GCs. • Intrasite and intersite connection objects, their associated GUID, partners and the partitions that are replicated over them. • Site links, including members and costs. Figure 8: ADTV retrieving data from the Active Directory Page 16 hp OpenView Microsoft ® Active Directory white paper Once ADTV has collected all the data it needs for display, an administrator can organize the objects easily on the display map. Figure 9: ADTV display map If desired, the administrator can zoom in on any part of the display map and view the intra- and/or intersite connection objects. Figure 10: ADTV viewing intrasite connection objects The administrator can further drill down into any DC or GC by double-clicking the object in the display map. Page 17 hp OpenView Microsoft ® Active Directory white paper Figure 11: ADTV property pages for domain controllers In addition to the display map, ADTV provides a data tree that allows navigation throughout the collected data by way of partitions, sites and site links. Page 18 hp OpenView Microsoft ® Active Directory white paper Figure 12: ADTV data tree benefits of using hp OpenView to manage Active Directory HP OpenView Operations for Windows, when coupled with the OpenView Smart Plug-in for Active Directory, provides robust features that efficiently and effectively monitor components of the Active Directory infrastructure. Various Operations for Windows features help ensure the health, performance, accuracy and availability of the Active Directory. Capabilities include: • Understanding the true end-to-end performance of Active Directory with probing of the directory via LDAP. One of the most useful ways to monitor Active Directory is to probe it by binding to it and performing LDAP requests. HP OpenView Operations for Windows has policies that connect to an Active Directory server (DC or GC) and measure the respective response times to LDAP queries. • Monitoring operating system and Active Directory performance data. HP OpenView Operations for Windows provides tools and policies to query operating subsystem functions, such as DNS, Replication Monitoring, FSMO services, and Directory Information Tree. This type of information can help identify the performance of directory servers and associated Active Directory elements. • Event log file analysis. HP OpenView Operations for Windows reports event messages with error conditions that may signal a potential problem on a directory service. • Visualization of your Active Directory environment. The Active Directory Topology Viewer, a patent-pending component of the Active Directory SPI, affords a visual troubleshooting tool for tuning and configuring the Active Directory topology. Its visually unique mapping algorithm maps a forest, associated Domain Controllers and connection objects in a way that allows quick identification of topology and configuration irregularities. Additionally, HP OpenView Page 19 hp OpenView Microsoft ® Active Directory white paper Operations’ dynamic Service Map allows for real-time status reporting and troubleshooting. This allows for quicker identification and resolution of problems and enables the visual mapping of Active Directory elements to a business view. • Unique root-cause analysis and service management visual modeling capabilities for Active Directory provide opportunities for business-focused problem identification and resolution. Using standard features of the HP OpenView Operations for Windows solution, logical relationships for monitoring and alerting are easily created for an Active Directory environment. This affords a great way to manage from the view of the business and not just the organization. You can easily see the Active Directory components and how they relate to your IT organization. moving forward: the future of hp OpenView and Active Directory management Active Directory and the underlying operating system Windows server provide a solid framework to host business applications in the enterprise. On the other hand, enterprise applications leverage features of the infrastructure such as network services and directory services and rely ultimately on those services to run properly. Exchange 2000 server is a prime example of the tight integration between applications and operating systems. In the near future, you can expect that more and more applications will depend on OS services. Therefore, monitoring solutions should cover a large spectrum, from applications to OS and hardware, and should be able to express the dependency of applications with regard to OS services. There is a need to build customized service views and develop knowledge of how to optimize those views. A good example might be to build a service view showing dependency of Exchange components like DSACCESS and GC/DC availability and response time inside the same site and between different sites. Another example is a service view linking the message store service of Exchange and IIS service that updates the IIS metabase. Without updated information in IIS, the store cannot mount and is in conflict with the SMTP service. The ability to provide high quality service for monitoring, identifying and troubleshooting application problems is the proven strength of the HP OpenView Operations for Windows solution As your Active Directory environment evolves, you can depend on HP OpenView to ensure its health and accuracy. for more information For more information on HP OpenView, please contact your local HP reseller or HP sales office. Argentina 0 800 888 1030 Europe openview_ccc@hp.com Philippines +63 2 888 5900 Australia/New Zealand +61 3 8877 4097 openview_events@hp.com Hong Kong +85 2 2805 3551 software_solutions@hp.com Singapore +65 6275 3888 software_singapore@hp.com India +91 11 690 6176 software_india@hp.com Taiwan +886 2 2712 0404 software_taiwan@hp.com Japan +81 3 3331 6111 Thailand +662 661 3900 Korea +82 2 2199 0913 software_korea@hp.com United States of America 1-877-OV-OWNER Chile 800 360 999 Malaysia +603 2698 6555 software_malaysia@hp.com Venezuela 0 800 HPINVENT (0 800 4746 8368) China +86 10 6564 3678 software_china@hp.com México City, Mexico 01 800 468 4247 Or visit: www.openview.hp.com Colombia 9 800 11 47 26; 01 8000 114726 (presales); 01 8000 919200 (post-sales) Perú 0 800 50 500 and 0 800 10 111 (technical support) Brasil 0 800 15 77 51 or 0 800 13 0999 Grande S. Paulo (11) 3747 7799 Central America and Caribbean Main # 1 800 711 2884 © Copyright 2003 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice and is provided “as is” without warranty of any kind. Microsoft, Windows and Windows NT are U.S. registered trademarks of Microsoft Corporation. UNIX is a registered trademark of The Open Group. April 2003 Page 20
© Copyright 2024