manage what is Active Directory? how to manage Microsoft with hp OpenView is a central and inseparable component of the Windows 2000 operating system when used as a network operating system. The functions as a distributed, replicated, multimaster and fault-tolerant directory service. In a Windows 2000 infrastructure, the 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. The 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 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 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 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 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, 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, 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, is and will continue to be a formidable force. why does Active Directory need to be managed? and directory services in general can be an extremely far-reaching technology component in an enterprise infrastructure. As the reach of expands, day-to-day business dependencies on Windows and 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 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, 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. Page 1
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 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, 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 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, 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., 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 is seen as loosely consistent or not immediately convergent. Applications that rely on 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 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 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. From the file system perspective, JET Blue manifests itself as a series of files. The 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
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 can be carved out into different sections to increase its manageability and performance. Any single 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. 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 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 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), 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. If DNS is not functioning properly the will typically follow suit. Page 3
replication Replication is the process of transmitting additions, modifications and removals to the Active Directory among domain controllers. Replication in an 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 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 conhp OpenView sites, site links and subnets Unfortunately, the current implementation of 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 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 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. Page 4
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 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 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
While the application of a GPO to a domain, site or OU is stored in the, the policy itself and other scripts that the policy refers to are not stored in the. 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, 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, SYSVOL can be quite fault tolerant, as it is supported by DFS. Also like, 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 schema, have a significant impact throughout the entire forest. For this reason 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
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 It is likely that 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 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
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. 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 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. how hp OpenView monitors and manages HP OpenView provides choices in the levels of monitoring implemented at a site. The WINOS-SPI provides availability and performance monitoring along with firstlevel discovery, while the 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 component. Those policies can be classified under the following categories: Page 8
Category Inventory Control change Performance data collection Security auditing Description Policies of this category perform the following operations: Discover the infrastructure related to 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 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 sites 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 Policies of this category, when deployed, perform security auditing on access to certain objects policies belonging to the WINOS-SPI have their names prefixed with WINOSSPI- ADS- 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. Page 9 components of the SPI The 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 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. Global catalog monitoring and reporting.
Directory Information Tree (DIT) monitoring and reporting Visualization and tuning with the Topology Viewer tool and Service Map Web-based reports and graphs related to replication performance data. using hp OpenView operations for Windows to monitor Deploying a monitoring solution on 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 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 SPI policies. When implementing this solution, administrators can follow the steps below as a guideline for using Operations for Windows to monitor. step 1: discovery of the environment After installing HP OpenView Operations for Windows on a management console, administrators can add Windows computers into the management database. By default, the WINOSSPI- WINSys_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
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 SPI. step 2: monitoring basic services There are some basic services that HP OpenView Operations for Windows can monitor to ensure that 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 services are present on the network. HP OpenView Operations for Windows 7.2 provides advanced monitoring capabilities for DNS in the SPI as shown in the figure below. Page 11
Figure 4: ADSPI policies related to DNS Page 12 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 services offered by the domain controller. Monitoring the state of the NetLogon service is absolutely critical for continued operations. The WINOSSPI- ADS_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 operations. step 3: monitoring changes in 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 Description Deployment control WINOSSPI-ADS_SiteChanges Monitors changes in the site topology WINOSSPI-ADS_DomainChanges Monitors change in the Domain configuration Change control 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
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 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 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 service. 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 information improves the performance of 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 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 with HP OpenView Operations for Windows. Administrators can deploy additional policies to monitor services, such as authentication service. what needs to be monitored and managed to maintain the 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
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
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. 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 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 SPI is a robust DNS monitoring system specifically tuned for DNS support of the and Windows authentication services. The 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 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. ADSPI-DNS_Kerberos_SRV_Chk checks that all KDCs known to the have a corresponding SRV record related to the KDC in DNS. Page 15
ADSPI-DNS_Extra_LDAP_SRV_Chk checks that LDAP SRV records have a matching DC known by the. ADSPI-DNS_Extra_Kerberos_SRV_Chk checks that all KDC SRV records have a matching DC known by the. ADSPI-DNS_LDAP_SRV_Chk checks that all DCs known to the have a corresponding SRV record related to LDAP in DNS. ADSPI-DNS_GC_A_Chk checks that all GCs known to the have a corresponding A record for the GC in DNS. ADSPI-DNS_DC_A_Chk checks that all DCs known to the 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 have a CNAME record registered in DNS which corresponds to their GUID. ADSPI-DNS_GC_SRV_Chk checks that all GCs known to the have a corresponding A record for the GC in DNS. ADSPI-DNS_Obsolete_GUIDs validates all GUIDs registered in DNS as CNAME records that correspond to an existing DC in the forest. Topology Viewer The 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 forest. ADTV queries the of a single forest for the following information: partitions, including configuration, schema, domain and Windows Server 2003 application partitions. 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. Page 16 Figure 8: ADTV retrieving data from the
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
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
Figure 12: ADTV data tree benefits of using hp OpenView to manage Page 19 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. Capabilities include: Understanding the true end-to-end performance of with probing of the directory via LDAP. One of the most useful ways to monitor is to probe it by binding to it and performing LDAP requests. HP OpenView Operations for Windows has policies that connect to an server (DC or GC) and measure the respective response times to LDAP queries. Monitoring operating system and 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 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 environment. The Topology Viewer, a patent-pending component of the SPI, affords a visual troubleshooting tool for tuning and configuring the 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
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 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 environment. This affords a great way to manage from the view of the business and not just the organization. You can easily see the components and how they relate to your IT organization. moving forward: the future of hp OpenView and management 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 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 Australia/New Zealand +61 3 8877 4097 openview_events@hp.com 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 Chile 800 360 999 China +86 10 6564 3678 software_china@hp.com Colombia 9 800 11 47 26; 01 8000 114726 (presales); 01 8000 919200 (post-sales) Europe openview_ccc@hp.com Hong Kong +85 2 2805 3551 software_solutions@hp.com India +91 11 690 6176 software_india@hp.com Japan +81 3 3331 6111 Korea +82 2 2199 0913 software_korea@hp.com Malaysia +603 2698 6555 software_malaysia@hp.com México City, Mexico 01 800 468 4247 Perú 0 800 50 500 and 0 800 10 111 (technical support) Philippines +63 2 888 5900 Singapore +65 6275 3888 software_singapore@hp.com Taiwan +886 2 2712 0404 software_taiwan@hp.com Thailand +662 661 3900 United States of America 1-877-OV-OWNER Venezuela 0 800 HPINVENT (0 800 4746 8368) Or visit: www.openview.hp.com 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