Previous Section
 < Day Day Up > 
Next Section


Resource Discovery Methods

In this section we’ll examine the individual discovery methods. You’ll learn how to configure each discovery method if applicable, the mechanics involved in carrying out the discovery process, the network traffic generated, and the elements you might need to troubleshoot when you work with each discovery method.

More Info 

For a detailed discussion of planning issues to consider when choosing a discovery method, see Chapter 10 in the Microsoft Systems Management Server 2003 Concepts, Planning, and Installation Guide included on the SMS CD, and available from the SMS Web site (http:// www.microsoft.com/smserver) and through Microsoft TechNet.

Windows User Account and User Group Discovery

The Windows User Account Discovery and Windows User Group Discovery methods are designed to discover domain user accounts and domain global group accounts and to add them as resources to the SMS database. When you enable either of these discovery methods, you can specify which Windows domains to poll for user and group account information. A corresponding DDR is generated for each user and group account discovered. By default, these resources will be added to the All Users and All User Groups collections, which you can view through the SMS Administrator Console.

The primary purpose in enabling either of these discovery methods is to provide the SMS administrator with an alternative target for advertising programs through SMS. Although we haven’t discussed package distribution in great length yet, we have talked briefly about the advertisement process. (Chapter 12, “Package Distribution and Management,” covers the details of package distribution.) As noted in Chapter 1, “Overview,” in SMS 2003 a package reaches a target destination by advertising a program associated with that package. This program might be a Typical installation of Microsoft Office, for example, or a Custom installation of Microsoft Project. Programs are always advertised to collections. If you want a specific group of SMS clients to receive a particular program, you must create a collection that contains those clients and then advertise the program to that collection.

Enabling Windows User Account and User Group Discovery

To enable the Windows User Account Discovery and Windows User Group Discovery methods, follow these steps:

  1. In the SMS Administrator Console, navigate to the site’s Site Settings folder, expand it, and then select the Discovery Methods folder.

  2. Right-click Windows User Account Discovery or Windows User Group Discovery, as appropriate. The two procedures are essentially the same, so in this example we’ll select Windows User Account Discovery. Choose Properties from the context menu to display the Windows User Account Discovery Properties dialog box shown in Figure 7.1.

    Click To expand
    Figure 7.1: The Windows User Account Discovery Properties dialog box.

  3. In the General tab, select the Enable Windows User Account Discovery check box (or Enable Windows User Group Discovery, if you’re enabling the other discovery method).

  4. Click the New button (the yellow star) in the Properties dialog box to add a Windows domain to the list for the discovery agent to poll. The New Domain dialog box appears, as shown in Figure 7.2.

    Click To expand
    Figure 7.2: The New Domain dialog box.

    Enter the name of the Windows domain for which you want to discover user accounts and then click OK.

  5. Select the Polling Schedule tab, shown in Figure 7.3. Notice that you can choose to have SMS run the discovery method as soon as possible by selecting the option Run Discovery As Soon As Possible or set a specific time for discovery to run.

    Click To expand
    Figure 7.3: The Polling Schedule tab.

  6. To set a specific time for discovery to run, click the Schedule button to display the Schedule dialog box shown in Figure 7.4.

    Click To expand
    Figure 7.4: The Schedule dialog box.

  7. Define the frequency with which the User Account Discovery Agent or User Group Discovery Agent should poll the specified domains for user accounts, and then click OK.

  8. Click OK to begin the discovery process.

Windows User Account and User Group Discovery Process

The discovery process for these two methods is fairly straightforward as SMS processes go. When you enable either method, the corresponding discovery agent on the site server makes a secure connection to the Primary Domain Controller (PDC) emulator of the Windows 2000 or higher domain you specified and according to the schedule you specified when you enabled the discovery method.

The discovery agent enumerates the user accounts or global groups in the Windows domains and generates a DDR for each one it discovers. These DDRs are written directly to Discovery Data Manager’s inbox on the site server (SMS\ Inboxes\Ddm.box). Discovery Data Manager in turn updates the SMS database with the new discovery information. User accounts are automatically added as discovered resources to the All Users collection, viewable through the SMS Administrator Console, and user group resources are automatically added to the All User Groups collection. To view this discovery data, right-click the user resource under All Users in the SMS Administrator Console and then choose Properties from the context menu. A sample user resource discovery record is shown in Figure 7.5.

Click To expand
Figure 7.5: A sample user resource discovery record Properties dialog box.

In terms of network traffic, each user and group that is enumerated generates, on average, 2 KB of traffic. If your Windows account database contains, say, 10,000 users and 100 groups, you’ll experience around 22 MB of network traffic to generate the corresponding DDRs. The frequency at which this traffic is generated, of course, depends on the polling schedule you’ve defined. Remember, too, that for this discovery method, SMS will poll the domain controller that has been assigned the PDC emulator role. That computer might or might not be on the same network subnet as the SMS site server, and you should account for the additional cross-subnet traffic that will be generated. If your Windows account databases are relatively stable and rarely change, you don’t have to poll frequently, and network traffic relating to user or user group discovery will be largely a one-time experience. On the other hand, if your Windows account database is volatile, you might need to enumerate users and groups more frequently, and, of course, you’ll generate a corresponding amount of network traffic.

Each agent generates status messages when it starts, stops, and generates DDRs. You can view these status messages through the SMS Administrator Console. Look for message IDs in the 410x range for SMS_NT_USER_GROUP_ DISCOVERY_AGENT and message IDs in the 430x range for SMS_NT_ USER_DISCOVERY_AGENT. The sample status message window shown in Figure 7.6 tells us that in this case 24 Windows user accounts were enumerated and discovered from the Windows domain. These agents also write detailed processing information to their respective log files (Ntusrdis.log and Ntug_dis.log) if you’ve enabled logging through the SMS Service Manager tool in the SMS Administrator Console.

Click To expand
Figure 7.6: A sample status message window and the Status Message Details dialog box.

Checkpoints

The main problems you might encounter with these discovery methods have to do with access. The SMS Service account or the site server’s computer account must have Administrator rights on the PDC emulator that it’s polling for resources. If this condition isn’t met, user and group discovery will fail. Other possible problems, of course, are that the discovery agent hasn’t been enabled or that the scheduled polling time hasn’t yet been encountered.

Network Discovery

The Network Discovery method is designed to provide the SMS administrator with the means of discovering any network resources that are IP addressable, which means that you can discover not only computers, but also printers, routers, bridges, and so on. The discovery that takes place using this method can be far-reaching. You can discover these resources on the local subnet in which the site server resides, or you can discover resources throughout your enterprise network using DHCP, SNMP, and other mechanisms. Resources discovered using this method are automatically added to the All Systems collection, which is viewable through the SMS Administrator Console.

Network Discovery includes the following information as part of the discovery record:

  • SMS GUID

  • NetBIOS Name

  • IP Addresses

  • IP Subnets

  • IPX Addresses

  • IPX Network Numbers

  • Last Logon User Domain

  • Last Logon User Name

  • MAC Addresses

  • Name

  • Resource Domain

  • User Domain

  • Operating System Name and Version

  • Resource ID

  • SMS Assigned Sites

  • SNMP Community Name

  • System Roles

This discovery method can be useful in a variety of contexts. It can be used, for example, to find computers that could become SMS clients. When a computer is discovered, its IP address and subnet mask are included in the discovery record. This information can help you identify where your potential SMS clients are located and how they are distributed among the subnets, enabling you to formulate a more specific plan for locating and implementing your SMS sites, site servers, and site systems.

You can also use this information to plan the best client installation method for implementing SMS 2003 on those computers. For example, if you plan to use the Client Push Installation method, described in Chapter 8, you need to have first discovered the clients. You can use Network Discovery to create the DDRs for clients that will be installed using the Client Push Installation method.

Network Discovery can make your Network Trace map more meaningful. As we saw in Chapter 6, “System Performance and Network Analysis,” the Network Trace utility provides a graphical mapping of your SMS site structure showing the routes between site systems and site servers. This mapping can include any routers, switches, and the like that the route between systems encounters.

If you don’t enable Network Discovery to discover these links between systems, they will be represented in the Network Trace window as “clouds.” The Network Trace map is built based on the DDRs that have been generated for site systems and devices on the network. Again, since Network Trace provides a means of testing connectivity, you can identify problem links more easily if all possible routes between systems are displayed in the Network Trace window. As you can see, you can gain some unique benefits by enabling the Network Discovery method.

Enabling Network Discovery

Like the other discovery methods, Network Discovery is enabled through the SMS Administrator Console. To enable Network Discovery, follow these steps:

  1. Expand the site’s Site Settings folder and then select the Discovery Methods folder.

  2. Right-click Network Discovery and choose Properties from the context menu to display the Network Discovery Properties dialog box shown in Figure 7.7.

  3. In the General tab, select the Enable Network Discovery check box.

    Click To expand
    Figure 7.7: The Network Discovery Properties dialog box.

  4. Specify the type of discovery you want. Selecting the Topology option will cause Network Discovery to discover IP-addressable resources such as subnets and routers using SNMP. (You would also configure options in the Subnets, SNMP, SNMP Devices, and DHCP tabs, as we’ll see shortly.) The Topology And Client option additionally discovers computers and resources such as printers and gateways using SNMP, DHCP, and the Windows Browser. Topology, Client, And Client Operating System also picks up the computer’s operating system name and version using SNMP, DHCP, Windows Browser, and Windows Networking calls.

    Note 

    The DHCP tab is available only if your site is running in standard security mode.

  5. Select the Slow Network check box for networks with speeds less than 64 Kbps. This option will cause Network Discovery to decrease the number of outstanding SNMP sessions it generates by doubling SNMP time-outs.

  6. Select the Subnets tab, shown in Figure 7.8. Here you can add, enable, and disable the subnets you want Network Discovery to search. By default, Network Discovery will search the local subnet in which the site server is a member. If you want to ignore that subnet, clear the Search Local Subnets check box.

    Click To expand
    Figure 7.8: The Subnets tab.

    Network Discovery displays the subnets it discovered during each previous search. As it discovers the subnets, it marks them with a lock to indicate that they can’t be modified or deleted—in fact, subnets discovered by Network Discovery, unlike those you add yourself, can’t be modified or deleted once they’ve been discovered. However, you can enable or disable those subnets that you want Network Discovery to search on subsequent cycles.

  7. To add subnets to the list, click the New button to display the New Subnet Assignment dialog box shown in Figure 7.9. Provide the appropriate subnet address and subnet mask and click OK.

    Click To expand
    Figure 7.9: The New Subnet Assignment dialog box.

  8. If you’ve selected a discovery type other than Topology in the General tab, select the Domains tab, shown in Figure 7.10, and enter the name of the Windows domain that you want to search for resources.

    Click To expand
    Figure 7.10: The Domains tab.

    By default, the local Windows domain to which the site server belongs is searched. If you want to ignore that domain, clear the Search Local Domain check box.

    Note 

    Network Discovery can find any computer that you can find using Network Neighborhood to browse the network. Once it finds a computer, it still must obtain its IP address and will use one of the other methods (DHCP, SNMP, and so on) to do so. Network Discovery will ping each computer to determine whether it’s active, find its subnet mask, and generate a DDR for it.

  9. To add Windows domains to the list, click the New button to display the Domain Properties dialog box shown in Figure 7.11. Enter the appropriate domain name. The domain must be accessible through the network. By default, the Enable Domain Search check box is selected. This option enables Network Discovery in the domain. Click OK to close the dialog box.

    Click To expand
    Figure 7.11: The Domain Properties dialog box.

  10. Select the SNMP tab, shown in Figure 7.12, and specify the SNMP community you want Network Discovery to search.

    Click To expand
    Figure 7.12: The SNMP tab.

  11. To add SNMP communities, click the New button to display the New SNMP Community Name dialog box shown in Figure 7.13. Enter the appropriate community name and click OK to return to the SNMP tab. If you enter multiple communities, you can specify the order in which you want them searched by using the two Order buttons.

    Click To expand
    Figure 7.13: The New SNMP Community Name dialog box.

    Note 

    It’s not necessary to have the SNMP Service installed on the site server performing Network Discovery. This discovery method uses its own SNMP stack to make requests and discover data.

  12. Network Discovery attempts to access the local router to obtain IP addresses and data from the device. If the Maximum Hops value is set to 0, Network Discovery searches only the default gateway. You can set this value as high as 10. Each successive increment extends discovery to another set of routers. For example, setting Maximum Hops to 1 enables Network Discovery to search the default gateway and any routers connected to it.

  13. Select the SNMP Devices tab (a companion to the SNMP tab) shown in Figure 7.14.

    Click To expand
    Figure 7.14: The SNMP Devices tab.

    In this tab you can identify specific SNMP devices that you want to discover by clicking the New button and supplying the IP address or name of the device. The SNMP devices can include routers, hubs, and token-ring media access units.

  14. If your site is running standard security mode, you can select the DHCP tab, shown in Figure 7.15, and identify which Microsoft DHCP servers you want Network Discovery to query for a list of IP addresses leased to computers.

    Click To expand
    Figure 7.15: The DHCP tab.

    If the site server is itself a DHCP client, Network Discovery automatically queries the site server’s DHCP server. If you want to ignore that DHCP, clear the Use Local DHCP Servers check box.

    Note 

    The DHCP tab isn’t displayed if you’re running advanced security mode.

  15. To add Microsoft DHCP servers to the list, click the New button and provide the appropriate subnet address or server name.

  16. Select the Schedule tab, shown in Figure 7.16, and identify the frequency at which you want Network Discovery to run.

    Click To expand
    Figure 7.16: The Schedule tab.

  17. To add a new schedule, click New to display the Schedule dialog box, shown in Figure 7.17.

    Click To expand
    Figure 7.17: The Schedule dialog box.

  18. To modify a schedule’s properties, click the Properties button (the hand holding a piece of paper) to display the same Schedule dialog box.

    In the Schedule dialog box, enter the time you want discovery to begin. You can also specify a recurrence pattern. Selecting None directs Network Discovery to search only one time for resources. You might select this option as a first pass to find all subnets, for example. The other options direct Network Discovery to perform subsequent searches according to your specified schedule. Duration indicates the period of time Network Discovery has to complete its search for resources. On a local subnet, two hours might be sufficient. However, if you’re performing a search of an enterprise network across several router hops with several thousand potential resources, you might need to increase this number so that Network Discovery has enough time to complete its search. If Network Discovery runs out of time, it will log a message to that effect and complete DDRs only for the part of the search that was completed.

  19. Click OK twice to save your settings and initiate the Network Discovery process.

Network Discovery Process

The discovery process itself is once again fairly straightforward. Depending on the discovery options you enabled, Network Discovery will attempt to search for subnets, routers, computers, and other devices. It needs to retrieve an IP address and subnet mask for each resource in order to generate a DDR for it. Network Discovery uses the information it receives from DHCP servers and SNMP to communicate directly with a device, such as a router, and then uses the router’s ipNetToMedia table and Router Interface table to obtain subnet masks. It also uses RIP, SNMP, and OSPF protocol multicast addresses to discover routers.

Network Discovery uses Windows Management Instrumentation (WMI) to store discovered resource information and generates DDRs based on this information. When Network Discovery generates a DDR, it writes the DDR to Discovery Data Manager’s inbox (SMS\Inboxes\Ddm.box). Discovery Data Manager in turn adds the record to the SMS database.

Network Discovery is capable of discovering literally thousands of devices on your network, and in doing so, it can generate a fair amount of network traffic. For this reason, your choice of schedule will be significant. If you need to find large numbers of devices, you might opt to schedule Network Discovery to run during quiet periods on the network. And as suggested earlier, you might also need to increase the Duration value (shown in Figure 7.17) to accommodate processing of larger numbers of resources. Like the other discovery methods, Network Discovery generates status messages that you can view through the SMS Administrator Console. Figure 7.18 shows a representative set of messages generated by Network Discovery. Message IDs in the 13xx range relate specifically to the discovery of resources.

Click To expand
Figure 7.18: A sample Status Message Details dialog box.

Also, if you’ve enabled logging for Network Discovery, more detailed information will be written to the Netdisc.log file.

Checkpoints

When you’re performing a Topology, Client, And Client Operating System search, the operating system on Windows 95, Windows 98, and Windows Millennium Edition (Windows Me) clients will be returned only if file sharing has been enabled on those computers. In addition, the operating system will be returned as Windows 9x until the SMS client software has been installed, with the exception of Windows 95 clients, which aren’t supported by SMS 2003.

Verify that you’ve identified not only the correct subnet address to search, but also the correct subnet mask. Network Discovery is more concerned with the subnet mask when retrieving device IP address information.

The All Systems collection displays discovered system resources. System resources include any IP-addressable device. Network Discovery also discovers logical networks and subnets. To view these resources, you’ll need to create a query to display the logical networks and subnets that were discovered. Refer to Chapter 16, “Queries and Reports,” for more information about creating queries in SMS 2003.

Heartbeat Discovery

Heartbeat Discovery is designed to keep DDRs up to date. This discovery method is significant because it ensures that resource records won’t be accidentally aged out of the SMS database.

Heartbeat Discovery is installed as part of the SMS client installation and is used to keep existing DDRs up-to-date rather than to create new DDRs. By default, Heartbeat Discovery will run once a week but is configurable. However, even if you configure it to run less than once every 25 hours—the default client refresh cycle—the updated DDR will be reported no less than once every 25 hours.

Enabling Heartbeat Discovery

Heartbeat Discovery is enabled by default and generates DDRs from each client every seven days. If you choose to disable Heartbeat Discovery, you’ll need to have enabled some other discovery method to keep the DDR information up-to-date. Furthermore, Heartbeat Discovery is active only on computers that have already been installed as SMS clients.

To configure Heartbeat Discovery, follow these steps:

  1. In the SMS Administrator Console, expand the site’s Site Settings folder and then select the Discovery Methods folder.

  2. Right-click Heartbeat Discovery and choose Properties from the context menu to display the Heartbeat Discovery Properties dialog box shown in Figure 7.19.

    Click To expand
    Figure 7.19: The Heartbeat Discovery Properties dialog box.

    If you want to disable Heartbeat Discovery, clear the Enable Heartbeat Discovery check box.

  3. Specify the frequency at which you want Heartbeat Discovery to generate DDRs.

  4. Click OK to implement your schedule.

Heartbeat Discovery Process

Heartbeat Discovery runs on installed SMS clients according to the schedule you specified. With this method enabled, Client Component Installation Manager (CCIM) on the client causes the Cliex32.dll to generate a DDR, which is written to the client access point (CAP) by the Copy Queue component (refer to Chapter 8 for details on Copy Queue). The network traffic generated is the size of a normal DDR—that is, about 1 KB per client.

Checkpoints

The only potential problem here is ensuring that Heartbeat Discovery has in fact been enabled and not disabled by accident. Also, be sure that the schedule you create causes the DDRs to be generated frequently enough that the DDR isn’t accidentally deleted from the SMS database.

Active Directory Discovery Methods

There are three Active Directory discovery methods: Active Directory User Discovery, Active Directory System Discovery, and Active Directory System Group Discovery. Unlike the Windows User Account and User Group discovery methods, which poll the PDC emulator, each of the Active Directory discovery methods polls the closest Active Directory domain controller.

These methods are configurable by the SMS administrator. The objects returned reflect those objects contained in Active Directory when the discovery method last ran. Therefore, don’t consider this method to be dynamic.

Active Directory User Discovery returns the following information about the user account:

  • User name

  • Unique user name (including domain name)

  • Active Directory domain

  • Active Directory container name

Active Directory System Discovery returns the following information about the system account:

  • Computer name

  • Active Directory container name

  • IP address

  • Assigned Active Directory site

Active Directory System Group Discovery returns the following information about the group account:

  • Organizational unit

  • Global groups

  • Universal groups

  • Nested groups

  • Nonsecurity groups

Enabling an Active Directory Discovery Method

To enable the Active Directory User Discovery, Active Directory System Discovery, and Active Directory System Group Discovery methods, follow these steps:

  1. In the SMS Administrator Console, navigate to the site’s Site Settings folder, expand it, and then select the Discovery Methods folder.

  2. Right-click the appropriate Active Directory discovery method. The procedures for each method are essentially the same, so in this example we’ll select Active Directory User Discovery. Choose Properties from the context menu to display the Active Directory User Discovery Properties dialog box shown in Figure 7.20.

  3. In the General tab, select the Enable Active Directory User Discovery check box.

    Click To expand
    Figure 7.20: The Active Directory User Discovery Properties dialog box.

  4. Click the New button in the Active Directory Containers frame of the Properties dialog box to specify the location in Active Directory that SMS should search for the container. The Browse For Active Directory dialog box appears, as shown in Figure 7.21. Choose Local Domain, Local Forest, or enter a Custom LDAP Or GC Query in the Domain text box.

    Click To expand
    Figure 7.21: The Browse For Active Directory dialog box.

  5. Select the Polling Schedule tab shown in Figure 7.22. Notice that you can choose to have SMS run the discovery method as soon as possible by checking the option Run Discovery As Soon As Possible or set a specific time for discovery to run.

    Click To expand
    Figure 7.22: The Polling Schedule tab.

  6. To set a specific time for discovery to run, click the Schedule button to display the Schedule dialog box. Define the frequency with which the discovery method should run and then click OK.

  7. Click OK again to begin the discovery process.

Like the other discovery methods that poll for information, the three Active Directory discovery methods can generate a significant amount of network traffic.

Checkpoints

SMS must have at least read access to the containers that you specify when you configure each discovery method when the SMS site server is in the same Active Directory domain. If the site server is in a different Active Directory domain from the domain that you’re polling, SMS must be at least a domain user in that domain. Other than that, check that the scheduling options and Active Directory locations are configured correctly.



Previous Section
 < Day Day Up > 
Next Section