Do you find the Support WebCast transcripts helpful?
Let us know!

Note: This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Heidi Moeller: Hello. Welcome to the Microsoft Support WebCast. We'd like to thank all of you for joining us this morning. Our topic will be "Understanding SMS Network Discovery," and our presenter will be Wally Mead. I am Heidi Moeller, and I'll be your host for today's session. We will start this session with Wally's presentation and follow up with a Q&A period when the presentation is finished.

We only answer questions submitted during the live broadcast. The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. However, one on one-product support issues are outside the scope of what we are able to address during the Support WebCast. If you need technical assistance, please submit an incident on the Web, or call Microsoft Product Support Services (PSS) and speak with a support professional.

I would now like to take just a moment to introduce Wally. Wally Mead has been with Microsoft for the past eight and a half years. He started in the training organization, where he delivered training on Microsoft^® LAN Manager. He began working on Microsoft Systems Management Server (SMS) back in 1994, and has been involved in the development and delivery of all SMS training courses for Microsoft. He now works for the SMS Product group and the Early Adopter Program (EAP) group, and provides training for the EAP members.

Thanks so much for joining us today, Wally. Let's get started.

Wally Mead: Thank you, Heidi. I would like to add my welcome to that of Heidi's. I trust you'll find the presentation worthwhile, and hopefully you'll be able to gather some new insight to Network Discovery through it. Let's get started.

Our agenda for today (slide 2) is, first off, we'll start with an overview of Network Discovery — just a quick recap of the Discovery process and how the different components work. Then we'll branch off into basic Network Discovery configuration. How do you go about configuring the basic network parameters? In other words, how do you configure Network Discovery to do its work? Then we will spend quite a bit of time on seeding Network Discovery. This is the process of telling Network Discovery the scope of the discovery or providing it with a potential list of resources to be discovered. After we talk about how you seed and configure Network Discovery, we'll talk about scheduling, very quickly. Then, we will move on to exporting devices. After we have discovered devices, how do we go about exporting them and getting the devices into the SMS site database? Next, we'll spend a little bit of time on logging and status reporting. There's a wealth of information regarding how Network Discovery works and what it accomplishes during each discovery process, in both the status system as well as in the log file for Network Discovery. We'll spend a little bit of time looking at that.

Last, we'll talk about a couple of the common issues. What are some of the common issues that customers have when they run Network Discovery? One of the most common questions that people have regarding Network Discovery, which hopefully I will be able to answer for you today, is "I ran a Network Discovery session, but it didn't discover all my resources. Why not?" We will discuss that in the presentation, and hopefully by the end of the presentation you'll understand what is required for Network Discovery to do its job of discovery.

Basically, in this presentation we will talk about what Network Discovery does, how it does it, and what gets reported. Again, we'll talk about some of the common issues that people have with Network Discovery.

All right, on to "Network Discovery Process" (slide 3). Network Discovery is one of the many discovery methods for SMS 2.0. Network Discovery is the most far reaching of all the discovery methods in that, while something like Windows Networking Logon Discovery requires a user to sit down, log off, log back on, hit a domain controller, and launch a script, Network Discovery requires nothing of the user. Network Discovery can potentially find any resource on your network. That doesn't mean it's going to find any resources or all resources, but it has the potential for doing so.

Now, the resources here are limited to IP resources. Network Discovery only works in an IP environment. So, if you're in an IPX environment, if you're basically a Novell shop, and you have some SMS for management, then Network Discovery is not going to do a whole lot for you because it does require and only utilize TCP/IP methods of discovery.

There are numerous different ways Network Discovery can go about performing its discovery processes. You see on the slide some of the different things it can discover. It can discover printers, hubs, wiring concentrators, routers, client systems, UNIX workstations, and mainframes. Basically, it has the ability to discover anything on your wire that has an IP address. Again, we'll talk about the requirements a little bit later on.

The different ways that Network Discovery can go about finding these resources on your wire include IP addresses and subnets. So, you can tell Network Discovery to search for this router, and this router can give you a list of IP address, as well as subnets that it knows about. It can use SNMP as a means of communicating directly with resources. It can use domain browsing so you can go out there and do standard Windows NT^® or Windows^® 2000 domain browser calls to find a list of potential resources. You can query DHCP servers for a list of addresses in use. It can utilize and receive Routing Information Protocol (RIP) as well as OSPF "Hello" announcements, and receive those announcements as networks that are available on the wire.

In the basic process for Network Discovery, the first thing you do is configure its scope of discovery. Network Discovery, as we'll talk about a little bit later on, is not enabled by fault. So, you have to configure how you want Network Discovery to run. You can configure the scope of discovery, what subnets you want to query, what domains you want to browse, and what community names you want to use for SNMP calls if you want to use DHCP server discovery. You configure all these seeding mechanisms, then you schedule Network Discovery to run at some sort of an interval, which we we'll talk about later on.

Last, Network Discovery runs. There are numerous different things that happen when Network Discovery runs. As a quick review of those things, which we'll discuss later on, first off, we have some WMI interactions. There are some WMI calls that are made to query the site control file to find the scope of discovery. When the Network Discovery process kicks off, it looks at the site control file. What is my scope of discovery? What are the seed mechanisms am I using? What DHCP servers am I querying? What domains am I browsing, etc? WMI also queries the registry of the site server to find some basic information, such as the site server's default gateway; if you have Use local gateway enabled, then we'll query the default gateway.

Then some different discovery modules are — we say dispatched — but they are basically executed. Those are to discover through Windows NT browser calls, or through SMNP calls through a router, SMNP calls directly to resources, Win32^® API calls directly to resources, and so on. We go out and query the resources and find the information, then we do our evaluation. In other words, do we have enough information about a resource to be able to report it as having been discovered on the wire? We will talk about what the evaluation process covers later on.

If enough information has been discovered about the resource, we will create a DDR, a discovery data record. Network Discovery will then create the DDR and hand it off to the Discovery Data Manager on the site server to process those DDRs into the site database. After they are processed into the database, at the appropriate time, the Collection Evaluator can evaluate those new resources and add them to the appropriate collections. Then, any other kind of process can take place on those resources. For example, you might be using Network Discovery as one of your means to install the SMS client software on Windows NT client computers. That could take place after you have all your information processed into the site database.

Let me give you couple of very quick scenarios that customers have run through. At Microsoft internal, we have run a number of Network Discovery sessions. The last one we ran, I believe it discovered something like 50,000 resources on our network. That's quite a few different resources that we found. We were using DHCP discovery and some domain browsing, as well as some subnets. We were going out more than 10 hops. So, we did find 50,000 resources on our network.

I heard back from some consultants that I was working with. At their site, they ran Network Discovery at something like 1:00 or 2:00 A.M. When they ran Network Discovery, they discovered 21,000 devices and the discovery process ran for 3 hours and 45 minutes. That's again at 1:00 or 2:00 A.M., so that's kind of unusual that you might have 21,000 devices available at that point in time.

Their site server happened to be a fairly high-end site server. It was dual Pentium III 500 MHz, and their site server had 1 GB of RAM. I will give you a few more details about their discovery process as we proceed.

That's a quick review of the Network Discovery process. Now, let's talk about how you configure and execute Network Discovery. On the next slide, we'll talk about "Configuring Basic Network Discovery Values" (slide 4).

The first thing you have to do in Network Discovery is enable it. Network Discovery is disabled by default when you install your site. Even if you do an express setup, which generally enables everything, it does not enable Network Discovery; you do have to go in and enable it. It is a very simple check box. You go to <site server> <site database> <site hierarchy> <site code> <site settings> and then Discovery Methods, and you access Network Discovery properties. On the General tab of Network Discovery properties, select the check box Enable Network Discovery.

One of the key things that people use Network Discovery for is to discover Windows NT clients, and then have SMS push out the SMS client software on those Windows NT clients without having to have any users logged on at those computers to generate logon discovery records or initiate the installation process. Network Discovery can be used for installing SMS software on Windows NT computers.

It's also useful for very large enterprises to kind of rediscover their infrastructure. We have had a number of customers who, when we asked them prior to running Network Discovery what their network looked like, were not really able to answer that question. They were not able to tell us exactly how many routers they had, or exactly how many subnets they had, or where everything was. Network Discovery, after it has run, can provide that information back to those IT environments, telling them that they have exactly this number of routers, and here are the names of the routers, here are the subnets that those routers are connected to, and so on. It's been a good learning experience for a number of customers to basically rediscover their network infrastructure. Those are a couple of good reasons for using it.

On that same General tab for Network Discovery, the next option you have is the Type of Discovery. The type of discovery is basically how detailed you want Network Discovery to get when it is performing its discovery process. There are three different options there. The first option is something called Topology. The Topology option basically means go out and discover routers and subnets, but that's all I want; all you want is routers and subnets — you are basically discovering your IT infrastructure itself.

The second option is Topology and Client. That says, "Not only do topology discovery, which is routers and subnets, but also discover IP hosts on the wire." That could be a printer, that could be a router, that could be a wiring concentrator, it could be a UNIX workstation, it could be a standard Windows NT or Windows 95 client, it does not matter; just discover IP host on the wire.

Your third option is to discover routers and subnets and IP hosts, but then also try to determine the operating system of those IP hosts. If the IP host is discovered through some means that provided a Windows name, like domain browsing, then issue a call directly to that host asking, "What is your operating system?" That is how we discover your Windows NT operating system, to be able to deploy the SMS client software automatically, if you are using the Windows NT Remote Client Installation method.

That's your type of discovery. The last option you have there is Network Speed. If you select the Slow network selection, it indicates that you have some slow links in your environment. When you are doing your discovery, you want to cut down on the number of requests that will be made on the wire simultaneously looking for resources, as well as provide a longer time-out for some of those resources queries to be returned.

There are basically four different parameters that we tweak or we tune when you select the Slow network check box. Those deal with ICMP pings, as well as SNMP connections. Basically, we double the time-out value and we cut in half the number of outstanding requests on the wire. That's what this Slow network check box is for.

Okay, after you have gone through the General tab, now what you need to do is go to the seeding tabs (slide 5). The rest of the property pages are for seeding Network Discovery. Basically, it provides Network Discovery with the list of potential resources to discover.

The administrator, being you, has to configure what level of discovery you want to go through — what type of discovery you want to perform, and how you want to provide potential resources for Network Discovery to run. The administrator can specify which subnets for Network Discovery to query, which Windows domains to browse, which SNMP community names to use to talk to your routers, wiring concentrators, printers, and IP host. If you have any specific SNMP devices that you want to query independently of the other tabs, what devices do you want to query? Then, do you want to query DHCP servers and, if so, which servers do you want to query? You can just specify all those different resource types. Those types, again, are basically seeding values. You're just listing a potential source of resources on the wire. It doesn't mean we are going to report everything that you might have on any one of those tabs, it is just the potential for us to do so.

Network Discovery generally requires more information than what's available from just one of these alone. Not always, but in most cases we do require more than just what you might provide on one of those four or five different tabs. Again, this is just providing the scope of how you want the discovery to be performed, what resources you want to look at. Now what we will do is go through each of the individual tabs and tell you how those are used in the Network Discovery process.

The next one is the Subnets tab (slide 6). The Subnets tab is where we are specifying what subnets you want to have Network Discovery query. By default, no subnets are listed. When you look at your Subnets tab, by default that value for Subnets to search is blank. You have to add in what subnets you want, if you want to add any, as the administrator. You can specify, "I want to query this subnet," and so what you're specifying is a subnet ID, including the subnet mask that you want to go through, and you do your querying through Network Discovery.

You can also have subnets discovered automatically for you by a number of different resources. One way is through your default gateway. If you look at the very bottom of the Subnets tab, there is a check box selected by default that's titled Search local subnets. What that's going to do for you, if that's selected (that's one of those WMI calls I mentioned earlier), is we will go out and query the registry of the site server, finding its default gateway parameter, and then we will query the default gateway to find what information the default gateway can provide to us for Network Discovery.

When you run that, we will discover the local subnet and add the local subnet for you in the Subnets tab that the site server's a member of. We can also discover other subnets from your default gateway. If your default gateway happens to be connected up to four other subnets or routes, then you have those listed automatically for you on the Subnets tab and the Subnets to search list box after you perform your Network Discovery.

We also discover subnets through RIP version 1 announcements. Every so often, your routers will go out and make an announcement and say, "Here are all the routes I know about." Network Discovery, if it receives one of those, will add the routes to the Subnets tab. We do the same thing with OSPF "Hello" announcements. So, if Network Discovery is running and it receives an OSPF "Hello" announcement, it will add those subnets to the Subnets tab.

Any of these subnets that are discovered through the Network Discovery process itself are listed on this tab automatically for you the next time you look, and they will be locked. There will be a locked indicator in front of the subnet ID. That indicates the subnets were discovered automatically by Network Discovery, so you can't delete them. However, you can't delete those subnets because they were added automatically by SMS, and it wasn't administrator controlled.

They are also listed as disabled, by default. The last column of the Search table says Search type, and it will say, Disabled by Default. That means you're not going to search for resources on those subnets, in most cases. There are some cases where we ignore that value and still do our querying but, by default, those will be listed as disabled. The next time that you want to run Network Discovery, you would go to the Subnets tab, you would find which subnets were discovered automatically during the previous Network Discovery sessions, and then enable whichever subnets you want to be discovered, and then resources are discovered on those subnets.

There is also one other way to acquire subnets automatically. That's through the Microsoft DHCP server. On the DHCP tab, if you list a DHCP server to utilize, we'll query it. Scopes in DHCP become subnets for Network Discovery, and they will be added automatically. So, the Subnets tab is where you list IP subnets that you want to query through Network Discovery.

The next tab is the Domains tab (slide 7). The Domains tab is where you list the Windows domain names that you want Network Discovery to query. By default, this list is empty, so there are no domains listed that you want to query. The administrator can configure which domains you want browsed to provide a list of potential resources for discovery.

At the very bottom of that check box, there is also the option that says Search local domain, which is selected by default. If you have the Search local domain option selected, then when Network Discovery runs it will query the local master browser for the site server's domain, retrieve a browse list, and then try to contact each of those resources from the browse list independently to see if they're alive on the network, and try to acquire the information required to exploit that device as a discovery record.

You can list as many different domains as you want to in the Domains tab. For each domain you list, the site server is going to find a local master browser for that domain. It is then going to just basically do a standard browsing call. It uses a standard browser calls to find the local master browser, and then to retrieve a browse list. A browse list, if you ever looked at one before, is just the computer names of all Windows hosts that have registered in that domain. You will retrieve that.

Then Network Discovery is going to resolve each of those computer names into an IP address, and it will contact each one of those addresses independently. We used the Domains tab to find Windows domains we want to use for discovery of Windows hosts. We then find a local master browser for that domain, or each of those domains you have listed, and after we retrieve that list we resolve those computer names into IP addresses, and we query each of those devices independently. We will talk about that a little bit later. After we are done with the seeding mechanisms, we will talk about how we query resources independently.

The next tab we will look at is the SNMP tab (slide 8). The SNMP tab is where you can configure which SNMP community names you want to use when you're querying these devices independently. What is going to happen is (we will talk about this again a little bit later on, when we will talk about we query resources), after you find an IP address from any one of the seed mechanisms, Network Discovery is going to go out there and independently query each of those resources for information.

One of the methods we query them with is SNMP. We will make an SNMP call out to that resource. On the SNMP tab, you have to specify what community name or names you want to use when you're querying through Network Discovery and SNMP. By default, Public is listed. Public is basically the industry standard or the de facto standard community name for SNMP. So, if that is a valid community name for you, you can leave Public there.

In a lot of cases, you may have removed Public from your SNMP agents and implemented your own community name for security. If you've done that, you would add additional community names that you want to use for querying by Network Discovery.

If you have multiple names listed, you can just order them. Two of the buttons on the toolbar for the SNMP tab are Up and Down, so you can order your community in the order you want them queried. Maybe you want to leave Public there, but you want to use your own custom community name first. You add your new community name, then you move it to the top of the list. It will try your community first; if there's no response to the host through SNMP on your community name, then we'll try Public.

Actually, even if you do remove Public, it is used regardless. So, if all the other community names for retrieving data are invalid, we will try Public as a default community name, but we do show it to you.

Also, at the bottom of the tab is the Hops count, the maximum hops. This is the number of routers you want Network Discovery to traverse in order to retrieve data on the appropriate subnets. By default, the maximum hops is listed at 0 (zero), which means you are going to query your local subnet and you are not going to go beyond the default gateway on your subnet. After you discover other routers through your first initial Network Discovery session and you want to go back and query their routes and other routers, then you would go back and reset your maximum hops to some other value, as far out as you want Network Discovery to go. As I mentioned, when we did the discovery through Microsoft, we took this up to 10 hops so we could go out 10 different lengths. That's the number of hops, being IP router hops or RIP router hops. I think 10 is still the maximum we have listed there.

Okay, so that's the SNMP tab. The next tab we have is the SNMP Devices tab (slide 9). Some people get confused on what this is used for. Generally, you don't have to do anything with the SNMP Devices tab. What you may want to put here, however, is an SNMP device that you want Network Discovery to query that won't already be queried through one of the other seed mechanisms. These are IP hosts, whether it's an IP address or host name you supply, that you want Network Discovery to query specifically, treating it as a router, to go out and the query for it.

Again, it's not normally required to be configured; normally this tab is left blank. There are a couple of cases where you might want to use this option, however. Let's say that you have a router that you want to query, and that router would not be discovered through your Subnets tab. If you go back to your Subnets tab and you have three routers listed and the one router you do want to query is not listed in that list of subnets, then you can put the router's host name or the router's IP address on the SNMP Devices tab. Then, we would query that device directly, even though we wouldn't have retrieved that device's address through the Subnets tab or the seed mechanisms.

Another case where this has come into play is with that one customer I mentioned earlier, where they discovered the 21,000 devices by running Network Discovery late at night. In their case, they were using a proprietary protocol. Again, Network Discovery uses RIP and OSPF, and they did not have RIP and OSPF enabled on their routers. What they were using in that case was Cisco EIGRP. Well, Network Discovery does not use that by default, and they had turned off RIP and OSPF. We actually had to add the router's address directly to the SNMP Devices tab in order for it to retrieve any data from those routers. When we add the device address or name to the SNMP Devices tab, we query that device directly using SNMP calls. Through SNMP calls, we can retrieve the subnet mask and route table and other information. It just happened to be that, in their environment, they weren't using the default protocols that we're using, so that's one reason you may have to use the SNMP Devices tab. Otherwise, it would just normally be a router that you want to query that wouldn't be queried independently. Generally, from that, you don't need to use that tab at all.

The next tab is the DHCP tab (slide 10). The DHCP tab is specifying whether or not you want Network Discovery to utilize Microsoft DHCP servers for providing resources on the wire. No DHCP servers are listed, by default. By default, you have no servers listed. You can add you own DHCP servers as appropriate. You may be in an environment where you have 10 different DHCP servers. You can just go in there and manually add the IP address or the computer name of the DHCP servers that you want us to query; however, again, this only works with Microsoft DHCP servers. We don't query anybody else's DHCP environments; currently, it's only just Microsoft servers.

At the bottom of the dialog box, on the property page, you will see the Use local DHCP server check box. By default, that is selected. What that means is if your site server is also a DHCP client, we'll query the site server's DHCP server for a list of active addresses — addresses that have been leased out.

If your site server is not a DHCP client, then that check box has no use to you. Network Discovery cannot just go on your network inquiry and say, "Any DHCP Servers out there? I need to query you." It only knows about the local one, if the site server is a DHCP client, as well as any ones that you add manually in the DHCP servers list box. So, you would type in the address or names that you want to use.

There are a couple of requirements for the DHCP process to work. One I have already mentioned, and that is that it only works for Microsoft DHCP environments. Next is the SMS service account. The SMS service account is the account that's used to query the DHCP server for a list of leases that are active. In a Windows NT 4.0 environment, all that's required is that the SMS service account is a valid account on the DHCP server. It does not have to have any special permissions, it just needs to be a valid user account on the DHCP server itself. That's most likely done from your domain membership. So, your SMS service account would be your Domain Administrator; if your DHCP server is in the same domain, then you have the appropriate rights.

In a Window 2000 environment, if your DHCP server is a Windows 2000 DHCP server, then the SMS service account is required to be a member of the DHCP Administrators group in Windows 2000. That is a special requirement for Windows 2000 because they changed the code on us and require the admin permission now.

What we retrieve from the DHCP server, provided that you've listed one and you have the appropriate credentials for the account, are the scopes. All the scopes you have created on the DHCP server become subnets for your Subnets tab and will be added automatically. We retrieve the leased addresses, so the addresses that have active leases right now are retrieved. We also retrieve reserved addresses. In the released version of SMS 2.0, we didn't retrieve reserved addresses; we do now, with SP1 and higher, as well as we retrieve the subnet mask. Basically, if you are in a Microsoft DHCP environment and you specify it here, through DHCP you can acquire all the information you need from that resource to be able to export it and create it as a device through Network Discovery into your site database.

One of the big misconceptions people have about Network Discovery actually revolves around the DHCP tab, and that is that a lot of people are under the impression that if you're not using DHCP, then Microsoft Network Discovery cannot discover static IP address hosts. That is not correct. We can still discover resources that have static IP addresses through other mechanisms — through the SNMP Devices tab, through the Subnets tab, and through domain browsing; it just requires a little bit more than what was possible through the DHCP tab itself. DHCP, if active, gives us everything we need. If you're not using DHCP, then it requires a couple of different methods to acquire the information we need. We will discuss that.

Those are the different seed mechanisms. The last thing you do is schedule Network Discovery (slide 11). The last tab you have in the Network Discovery Properties dialog box is Scheduling. You would schedule when you want Network Discovery to run. Just enabling it does not make it run; you have to schedule when you want it to run.

What you do when you add a new schedule is you specify what type of scheduling you want to perform. The schedule for Network Discovery is very similar in configuration to the schedule for a lot of other things, such as hardware and software inventory, and so on — the ability of setting a reoccurring schedule, starting at a specific date and time, and so on. You schedule when you want Network Discovery to run, and whether or not you want it to repeat or reoccur at a specific interval.

When you do schedule Network Discovery, if you want it run right now, add a few minutes to your current time. If you enter the time as the exact time that you open up the dialog box and then you hit OK to save those settings, most likely, by the time the site control file is updated and the SMS Executive is notified that Network Discovery has been scheduled, you'll have already missed that time period. We don't go back and kick it off like we do with some other processes, saying, "Oh, I missed that schedule. I was supposed to do it. Let's start now." Network Discovery actually waits until the next scheduled interval. So, by padding your schedule by a few minutes, you allow time for the site control file to be updated, for the SMS Executive to recognize the site control file schedule change, and then to be able to kick off Network Discovery at your scheduled time.

When you schedule Network Discovery you can make it a single event with a repeat or reoccurrence pattern of none, or you can make it a reoccurring or repeating interval. That interval can be whatever you like.

At the bottom of the Property page is the Duration option. The Duration option specifies the maximum length of time for Network Discovery to be running. In essence, you're putting a stop time on Network Discovery. You might say start at 10:30 A.M. and run for three hours. That would mean that at 1:30 P.M., Network Discovery is going to cease operating, regardless of how far it is through the Network Discovery process. Obviously, if it completes its processing in 10 minutes it is going to stop and shut down all the different processing threads and so on, and you'll have no other interaction; however, if it is still running after three hours, it is going to shut down all of its processes and just abort the process at that point in time. Basically, you are putting a stopper on how long Network Discovery can run on the wire. That's useful in the event that Network Discovery gets in some sort of error condition and it keeps repeating its call to the network and never recovers from it. You don't want it chewing up a lot of traffic on your wire when it's not making any progress, so you put some sort of time limit on it. The default time limit is two hours, so you let it run for two hours.

That one customer I mentioned where they discovered the 21,000 devices, let it run for 3 hours and 45 minutes, and that's how much they discovered. I don't remember what the set duration was. It ran for 3 hours and 45 minutes, and they discovered 21,000 devices.

One thing to be aware of here is when we do hit that duration; if you are actively discovering and you hit your duration timer, we do not export the devices we have already discovered. We basically stop all the processes because you've told Network Discovery to cease operating, so it stops all its processing and just aborts. Nothing will have been reported as being discovered because we do all the reporting at the very end of Network Discovery. We don't find a device and immediately credit DDR for it; we cache all the information we find, and then we do all of our exporting or DDR creation at the very end.

Now we've talked about the different methods of Network Discovery working. Let's talk about finding and querying devices (slide 12). When you actually run a Network Discovery session, first off, the site server has to find a device. We have to find an IP address somehow. That can be through a number of different methods, basically, all those seeding tabs we talked about. The router ARP cache, or the route table — we can look at the router, we can pull out its ARP cache; we can also look at its route table for other subnets that it knows about.

Domain browse list — we can go look at the local master browser and pull off a browse list for that domain. The SNMP Device tab — we can specify IP addresses or host names of computers you want to query independently, so we can go find addresses through there. Or, DHCP — going into your DHCP server and finding all the leases that are in use.

We have to find a resource, somehow. After we have found a resource, if we have a name for that resource we need to convert it into an IP address. We do name resolution to turn that name we have for it into an IP address. That can be through any of your normal name resolution mechanisms. Whether it's DNS, whether it's a host file, whether it's a WINS server, whether it's LMHOSTS file, whether it's a b-node broadcast, whatever type of name resolution you're doing, we just need to get the IP address for it.

After we have the IP address, Network Discovery next queries each resource independently to find information about that resource. What we start with is an ICMP ping. Basically, we ping the resource to see if it is alive on the network or not. We do an ICMP ping asking, "Are you alive?" If the resource is not alive, it doesn't respond to the ping and we don't bother trying to talk to that resource anymore during this discovery session, unless it's discovered through some other seed mechanism.

If the resource does respond to the ICMP ping, meaning it is alive on the wire, then we try and retrieve information from that resource. There are many different things we're trying to retrieve from the resource. The most important one, as far as how Network Discovery operates and how it reports data, is that we need the resource's subnet mask. We have the IP address through one of the seed mechanisms and name resolution mechanisms; we now need the subnet mask. Network Discovery will only report devices as being discovered if we have the IP address of the device, as well as the subnet mask for the device.

There are a couple of different ways we can retrieve a subnet mask that we will talk about, coming up. One of those ways is through an SNMP call. We talked a couple of slides ago about the SNMP tab and the community names. After we have determined the device is alive on the wire because it responded to our ICMP ping request, we'll issue a SNMP call directly to that device using whatever community name or names you've specified on your SNMP tab.

If the host responds to the first SNMP call, then we'll issue two more SNMP calls. They are called phases. SNMP works through three different phases, and we discover different things in each of those phases. During one of those phases, we will retrieve from the resource its subnet mask.

We also retrieve from resources the ARP cache as well as the route table if we've discovered that device is a router. Basically, we and ask if is it a router by querying a specific object identifier through SNMP. If the response back is true, that it is a router, then we will issue SNMP calls to ask it for its ARP cache and its route table.

We will also ask that device what its operating system is, if the device has a Windows host name on it. Basically, we have retrieved it from the domain browse list. So, if you've gone out there and contacted a master browser for a domain browse list, we have Windows host names. If they do respond to the ping, then we will query through a Win32 API call, asking, "What is your operating system?" We want to know the operating system so that we can determine whether it's Windows NT because you might be using the Windows NT Remote Client Installation method.

In order to retrieve the operating system, it needs to be the Windows host name and the server service has to be running on the resource because we connect to the server service. That means allowing file and print sharing, or at least file sharing on Windows 95/Windows 98 clients, and you have to be allowing anonymous connections because Network Discovery makes these calls through the Win32 API call that uses anonymous connections. So, if you have anonymous connections or null sessions disabled, we're not going to be able to connect and retrieve the operating system.

After we've found a resource, we contact every single resource on your wire. That should tell you if you're in an environment where you're concerned about network traffic, that you probably want to run Network Discovery at a time period when there will be less user interaction on the wire because Network Discovery will generate a significant amount of discovery traffic. You don't want that to be occurring during your normal business hours when your bandwidth is already precious and you don't have any extra bandwidth. You probably want to be running off-hours, like the one customer who ran at 1:00 or 2:00 A.M., who found the 21,000 devices.

In their case, they actually discovered everything. It was at night, at 1:00 or 2:00 A.M., so you're not going to have a lot of users on the wire accessing resources. In their case, they discovered all the resources from the ARP cache of the router. The routers happened to have had a configuration for a four-hour ARP cache life, and that's not normal for most routers. Most routers are anywhere in the 10-minute to maybe one-hour range; that is the default for ARP cache life. They happen to have set theirs to a four-hour life. You just need to have some way of finding those recourses and making sure you're not using too much network traffic while you are doing this; in other words, running it during off-hours.

So, on to "Retrieving Resource Information" (slide 13). Again, we determine if the host is active on the network using ICMP pings, then we process three SNMP phases. We will only go to phase 2 and phase 3 if the recourse responds to phase 1. During phase 1, we retrieve a couple different things, such as the system description, the object identifier of the system itself, and we ask, "Are you a router?" We ask for IP forwarding, the object identifier, OID, and for IP forwarding. If that comes back with a value of 1 or true, then we know it's a router and we will ask some other information.

If the resource does not respond back to phase 1, we don't even try and ask it phases 2 and phase 3. That means it does not have an SNMP agent running locally, so there is no sense in making more SNMP calls.

If it does respond to phase 1, then we will run through SNMP phase 2 and SNMP phase 3. During SNMP phase 2, that's where we actually retrieve the IP addresses and subnet mask for all interfaces on that host. We also retrieve the MAC address; we also retrieve that host route table to see if there are any new routes that we can learn about.

Phase 3 is where we will actually go through the routers and we will query the router to give us its ARP cache. We will query asking for its net to media table, which is basically the ARP cache. It should provide back a list of all the resources that have been active on the wire through whatever your ARP cache life happens to be. We'll use SNMP calls, numerous calls in those three different phases, to retrieve all the data (for example, an ARP cache or a route table, they may be fairly large so it's multiple calls to walk down through the array of that table in SNMP in the MIB, to retrieve the appropriate data). So, they many have a lot of calls for the single phase.

Lastly, again, if it was a Windows host — so it has a Windows computer name — we will try to determine the operating system. The operating system, again, is determined by a Win32 API call that connects anonymously to the server service. So, if your server service is not enabled or you've restricted anonymous connections, then we will not be able to retrieve the operating system of that computer and it will just be listed as null in the resource, in the DDR that's created by Network Discovery.

Now that we've gone out and we've talked to the all these devices independently, we're at the point where we can export resource data (slide 14). In other words, do we have enough information for the resources that were discovered in order to create a discovery data record for it?

We create discovery data records for two unique architectures. One is the systems architecture, which includes all your hosts — so all the computers, the routers, and so on. That's the systems architecture. We also create DDRs for the IP network architecture, that's subnets. We'll create a separate DDR for subnets; they can be added back into the discovery database.

What this information is very useful for after it gets processed into the database, is Network Trace. A Network Trace operation is a very cool way to allow you to see your routers when you're querying SMS devices. We will talk about that in the next slide.

After we've found an IP address and a subnet mask of a host, we try to acquire its host name. We are going to acquire a host name that uses standard name resolution, so DNS or WINS, or LMHOSTS file or Broadcast, whatever, we're going to try and find a host name for that IP address because we want to associate a name with the address if we can. If we can't, then we just report it with the IP address as the host name.

The subnet mask is absolutely required for the DDR to be created. Even though you found a resource through the Domains tab or through the Subnets tab, even though you may have found a resource there, and even though we may have queried them on the wire — it responded to our ping and we were able to retrieve its operating system — unless we have the subnet mask for that resource, we do not create a DDR for that resource; we absolutely have to have the subnet mask.

There are only three ways we acquire the subnet mask for Network Discovery. One way is through an entry in the router ARP cache. This one customer, again, had 21,000 resources discovered through their ARP cache. If you have resources that are in your router's ARP cache at the time that we perform discovery, then we can use the IP address and subnet mask of the interface for the router itself; however, what that requires is that the router's interfaces have a single IP address and a single subnet mask associated with them. Some customers will configure a single router interface with multiple IP addresses. In that case, we don't trust it; it is not what we call a trusted router ARP cache. We'll use the IP addresses from the ARP cache, but we require the subnet mask to be acquired by some other method. If it's a trusted router ARP cache, we can use the subnet mask of the router itself.

Next is Microsoft DHCP server. If you're in a Microsoft DHCP environment, and you have specified for Network Discovery to use that DHCP server, and the SMS service account is a valid account to retrieve that DHCP data, then we will acquire everything we need from DHCP because DHCP gives us the IP address and the computer name, and it also gives us the subnet mask that is associated with the scope. That way we can discover everything that we want.

In fact, the first couple of times I tried Network Discovery, a couple of years ago, when I ran Network Discovery I used DHCP, and it was reporting back a device that I had not physically turned on the network for two weeks; the device was physically off, but it kept getting reported by Network Discovery. It wound up being that the device still had an active address through DHCP. The lease had not expired yet, so it was an active lease, so Network Discovery said, "Here are this client's IP addresses. Here's the subnet mask for the scope. Here's the computer name," and so it reported that device; you can actually find devices that aren't even alive on your wire yet.

The last way is by having a local SNMP agent running on the client or the resource, and Network Discovery is configured using a community name that is valid at that agent. If you're not using Microsoft DHCP servers, then the two ways that you can realistically perform discovery and be able to create DDRs is by having the entry and their router's ARP cache and that router ARP cache being trusted, or having a local SNMP agent on the client so that we can query through the SNMP calls.

If one of those other two methods is not available, then we cannot report the device because we don't know what the subnet mask is. We may have found them through router ARP cache, but it's not trusted; or we may have found them through the domain browsing process, but it does not have SNMP running locally, so we can't retrieve subnet mask, so we can't report them. We may physically have discovered that resource on the wire but we are not going to export it, which means create a DDR for it unless we have the subnet mask.

The reason why the subnet mask is so important is that the subnet mask was used to determine the IP subnet of that resource. As you know, SMS assigns resources to sites by IP subnets. So, if we don't know what the subnet of the resource is because we don't know the subnet mask, we can't determine whether or not the resources is assigned to the site, so we can't determine whether or not we should be pushing out the SMS client software or not to resources.

In the very early builds of Network Discovery and SMS 2.0, in the pre-beta builds, we were actually doing some guessing. In some customer environments, the way they were set up, we guessed wrong. We assigned resource to sites that shouldn't have had them, to try and push out the client software. In other cases, we did not push out the SMS client software where we should have or where the customer wanted us to. Just to make it safe, we are saying if we don't have the subnet mask, we're not going to export the devices — no DDR, which means no Windows NT Remote Client Installation method.

After you've exported the devices, then we process them (slide 15). The DDR is created if the IP address and subnet mask are discovered, as we have discussed. The agent name in that DDR is listed as SMS Discovery so you can see how that resource was discovered.

Network Discovery does not check to see if the client is an SMS client; it does not do a lot of extra discovery on the resource that other SMS mechanisms would — so things like the client value, or the GUID, the SMS unique identifier, system roles, and so on. Most of those are not discovered by Network Discovery because we don't do a thorough query of the resource. We are looking for an IP address, a subnet mask, and a host name. That's really what we are looking for with Network Discovery, and hopefully an operating system. But we're not asking, "Are you already a SMS client? What is your SMS-unique machine ID?" So, we don't retrieve those with Network Discovery.

You don't want to rely on Network Discovery as your sole discovery mechanism. You can use it to be an initial discovery mechanism or one that discovers resources that are not going to be SMS clients, but for SMS clients, again, you really want to utilize Heartbeat Discovery as your mechanism to retrieve all your appropriate resource data.

The DDRs that are created by Network Discovery are passed directly to the Discovery Data Manager's inbox on the site server. From there, DDM validates that they're valid and processes them in the site database. DDM will also determine whether or not it should create a CCR, a client configuration request. If this is the Windows NT client or Windows 2000, it's within my site boundaries, and it is not already an SMS client, and I've turned on Windows NT Remote Client Installation method, then I can create a CCR and say, "Push out the SMS client software off this new computer I discovered." That's something that's very valuable for a lot of customers, especially in environments where you have a lot of servers in server rooms that people don't log on to.

Another thing that's pretty cool is that the routes and routers will appear in Network Trace. So, now when you do a Network Trace and draw a map of your SMS infrastructure and your SMS servers, you can see the routers and subnets that are involved in you network infrastructure. We have an icon with a little triangle on it that represents a router. It will show you the different subnets that the router is connected to. That's very, very cool to be able to map out your network infrastructure, as far as SMS is concerned.

Collection Evaluator will add these resources to the appropriate collections as the collection comes up for scheduling. With refreshing, all collections, by default, run on a schedule. The default collections run hourly. So, even though you have discovered a resource and the discovery data has been processed in the database, Collection Evaluator may not run for another 50 minutes to process that resource into a collection. You can again force it to occur if you want to by selecting the collection and performing an Update Membership on the All Tasks menu.

As already mentioned, if the CCR is created, the Client Configuration Manager attempts to put the SMS client information or infrastructure down to that client computer itself, which is very valuable for servers.

Now that we have done our Network Discovery, how do we find out what happened during Network Discovery? That's done through logging and status reporting (slide 16).

Status is pretty good for Network Discovery. It does report a number of different values and status messages for the status system; you have some pretty decent data. It tells you when the process was started, it tells you when the process stopped, it tells you when it was exporting devices, and it tells you the DDRs it created. It does not tell you how many were exported; it just tells you it did export devices. It does not give you any names of resources, any addresses, any subnets that were discovered, or the count of resources that were discovered; it just says, "I am starting, I am done now, and I am exporting resources."

If you want full details, you need to turn on logging; you need to turn on logging for the Network Discovery process, and then you look at the Netdisc.log file. The Netdisc.log file gives you all the same data the Status system does; however, it gives you a lot more data. You can see every single resource that was discovered by any single mechanism; you'll see the addresses that DHCP returned, you will see the addresses from the ARP cache, you'll see the routes that were added by the route table entries on the routers, you will see all data, you'll see all the individual calls made to each host, you will see whether a host was alive on the network or not. Did they respond to the ping or not? You can see which hosts had SNMP agents are running on them because you will see phase 1 for SNMP, tried for each host. You'll see which ones respond, and it will tell you which ones did not respond.

At the very bottom of that log file, in the Exporting Devices section, it tells you, "I have discovered this resource but, oops, there's no subnet mask, so I can't create a DDR for it." It doesn't tell you in that kind of language, it just shows you the device. It shows you the IP address but it will not show you the subnet mask, so you'll see that no DDR is created for that device.

The Netdisc.log file is where you have to go to see exactly what happened with Network Discovery and why Network Discovery did not retrieve information that you thought it should have retrieved. The Netdisc.log file is going to be your main source for finding out what Network Discovery did, how it did it, and what it did not do because it didn't have the appropriate information (which was, "I wasn't able to retrieve SNMP data, so no subnet mask was retrieved," in some cases).

Lastly, some of the common issues with Network Discovery (slide 17). Network Discovery is extremely powerful. People absolutely love the power that it has; however, sometimes people get frustrated when it doesn't accomplish what they expected it to accomplish. The most common complaint is the lack of a complete discovery when Network Discovery did not discover everything you thought it should discover. You know that you have 10,000 Windows NT computers on your network, but it only discovered 10 of those. Why didn't it discover the other 9,990 clients? Why didn't it do a complete discovery?

The vast majority of times, the reason is that there is no ability for us to retrieve the subnet mask. The host wasn't in the ARP cache of the router, or the router's ARP cache wasn't trusted because it had multiple IP addresses on the interface. It wasn't a Microsoft DHCP client. It was either a different DHCP client from a different manufacturer, or the SMS service account wasn't valid on the DHCP server so we could not retrieve the data from DHCP. Or, it was a statically assigned IP address with no SNMP agent running locally. We have to have one of those methods for SMS to retrieve the subnet mask.

Another common problem is removal of anonymous connections. Network Discovery does some of its processes through null sessions or anonymous connections — retrieving browse lists, acquiring the operating system from Windows Host. If you remove the anonymous connections from resources, we have no way of retrieving the operating system.

Your scheduled duration is too short. You told Network Discovery to run for an hour, but when you hit that one-hour expiration time it hadn't completed its processing, so no discovery was reported. This occurs because, again, we just abort the process at that one-hour time frame, or whatever you duration is, and there's no data reported. It has actually been discovered but not reported because you didn't give it time to do the exportation.

Then again, there is no access to the DHCP server. This can occur if it's not a Microsoft DHCP server, if you didn't list the DHCP server on the DHCP tab, if your SMS service account was not a valid account at the DHCP server, or, in the Windows 2000 environment, if it wasn't a member of the DHCP Administrators group.

Another one that occurs every once in a while is if you turned off the Guest account and you don't have trust relationships set up, then the SMS service account wouldn't be a valid account. That could be one way that your SMS service account is not a valid account to the DHCP server because the guest is not enabled and you don't have the appropriate trust relationship set up.

As a quick summary for you (slide 18), Network Discovery is a very full-featured method to find resources outside the normal discovery methods of SMS, being Logon Discovery, or Server Discovery, and so on. It has the potential of discovering hundreds or thousands of devices on your wire, but it does have some requirements. You need to be very careful in satisfying those requirements.

It can find routers, subnets, IP hosts (which include things other than Microsoft hosts), as well as computers running Microsoft operating systems and other operating systems. It is the most encompassing of all the discovery methods for SMS 2.0. Again, its requirements are the IP address and the subnet mask. So, if you want to export a device, which means creating a DDR, we need the IP address and the subnet mask for that device. Which means that we need a router ARP cache, Microsoft DHCP server, or an SNMP agent running locally on that client so that we can communicates through SNMP.

Lastly, when people have problems with Network Discovery, most often it is because of no subnet mask retrieval, so we were not able to retrieve all the data and export all the data that they wanted. Again, we go back to, "How do we find the subnet mask?" We find the subnet mask through a router ARP cache, through a DHCP server that is running a Microsoft environment, as well as through a local SNMP agent; those are the different mechanisms. If you can have one of those different methods available for us to do the discovery and retrieve the subnet mask, you'll be very happy with what you get from Network Discovery.

At this, we will turn it back over to Heidi.

Heidi: Excellent. Thank you so much for that presentation, Wally. It is time to move on to the Q&A portion of the Support WebCast. We do only take questions that are submitted during the live broadcast.

As a reminder, the Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic; however, one-on-one product support issues are outside the scope of what we are able to address in the Support WebCast. If you do have a support questions, I would encourage you to either submit an incident on the Web or phone into Microsoft Product Support Services and speak with a support professional.

We have had several questions submitted, so we'll get started. The first question is: I can implement either discovery method: Logon or Network. Which one is preferred?

Wally: I can't give you a qualified answer here because it really depends on a lot of different things. That is, what is your scope of discovery, how many resources might be discovered from Network Discovery versus Logon Discovery, and so on. That's really a thing you're going to have to determine on your own; however, I can tell you that Logon Discovery is generally an ongoing process. So, when you turn on Logon Discovery, you don't normally turn it on and then let it run for a period of time and then turn it off.

Normally, if you're using Logon Discovery you have it turned it on. I don't want to say that you have it turned on permanently, but turned on on a long-term basis. That means any time anybody that has that logon script logs on to the network, you're going to re-create their discovery record. That can generate extra traffic because you are re-creating the same record over and over again, whereas Network Discovery may be a one-off. In other words, you run it one time and you don't run it again, or you run it very infrequently because you are scheduling it.

So, if you want to schedule when you are doing discovery, and you want to control when the traffic occurs, the Network Discovery is better for you because you can schedule when it happens.

On the other hand, with Network Discovery, again, you have to look at your routers, you have to look at what DHCP environment you're running, if you're using it at all, and you have to look at SNMP agents. So, in other words, are you going to discover the subnet mask during Network Discovery? If you're not going to be able to, then Network Discovery may not do as much for you as you want it to. In some environments, the IT department locks it down and they won't tell the SMS guys what the community name is so SNMP won't work. That's one thing you might have to fight about —getting the community name from your IT guys, so you can do the discovery.

Whereas Logon Discovery doesn't require anything from the server side. It's purely this: the client logs on, he gets the logon script; he's going to generate his own discovery data and report it up.

There are advantages and disadvantages to both. It may be that you want to implement both of them. You may want to use Logon Discovery for the hosts that aren't going to be discovered through Network Discovery, and then do a Network Discovery to do other things like the routers, your subnets, and your other IP hosts on the wire. So, you may want to do both of them.

Heidi: Thanks, Wally. Next in line: Does SMS automatically prevent the SMS client install to dial-in clients?

Wally: The only way SMS prevents the SMS client from being installed on a dial-in client is if they are using logon scripts. If the client is using the Windows Networking Logon Client Installation method and using our Smsls.bat file, then that batch file runs a procedure to check or to detect your slow network speed, and if it is slower than the threshold, it bails out of the logon script. None of the other discovery methods or installation methods check for network speed, so they would not prevent that process.

That's something we'll talk about in next month's topic, which is "Systems Management Server 2.0 Client Infrastructure."

Heidi: That next SMS session is scheduled for January 9, 2000, 10:00 A.M. Pacific time, as always. The next question is: Does SMS allow selective install of client software by selecting from discovered clients?

Wally: Not per se. SMS puts all the discovery resources in the appropriate collections as collections are evaluated; however, from there, as an administrator you aren't allowed to say, "Oh I want this resource to be client. I want this one. I don't want that one." SMS assigns a resource to a site based on IP subnets; if that resource is assigned to the site, in other words, its IP subnet matches the IP subnets assigned to the site, so that client is assigned to the site.

Whether or not it's installed is dependent on what kind of installation method you have enabled and how you are doing that. To control that, do Network Discovery, not Logon Client Installation, but do Network Discovery and the Windows NT Remote Client Installation method, or do not use logon scripts, but use Smsman, the manual installation program, to manually install the clients you want.

Heidi: Okay. The next question is: After Network Discovery, I noticed that many of my servers show multiple IP addresses, some of them identified as other servers or routers on that segment. Is this supposed to happen?

Wally: If you're saying that after Network Discovery runs, a resource appears with IP addresses that belong to some other resource on your wire, then no, that obviously is not supposed to happen. One of the things that some customers have run into with Network Discovery is that if they run Network Discovery too frequently, then Network Discovery, as I mentioned, does not discover a lot of other data about your resources. One of the important things that it does not discover, because a lot of the resources it discovers are not SMS clients, is the SMS unique identifier, or the GUID. What will happen is Network Discovery won't know what the GUID is because it doesn't query for it and because a lot of resources won't have it, so it will discover the information that it can: the IP address, subnet mask, computer name, and so on. It hands that discovery record off to the Discovery Data Manager for adding to the database.

If you have an environment where IP addresses are changing frequently because you have a very small or short lease life through DHCP, then different clients can be having the different addresses that previous clients had. When Network Discovery comes and it can't acquire the computer name properly or can't resolve it, it's going to look at the IP address, because there is no GUID, and it's going to say, "Oh, this address belongs to this guy." That potentially has the ability of mixing up discovery records.

That's why you do want to have other discovery methods happening outside of Network Discovery, and why you want to make sure your Network Discovery intervals are not too short — in other words, you're not running it too frequently. But, if those are fine, then no, that should not happen, and you should open up a case with PSS to find out what the story is there.

Heidi: Excellent. I want to take just a moment before moving on to the next question to encourage all of you to take a few moments to submit some feedback for us. We are very interested in your feedback regarding the Support WebCast program overall. If you have any feedback about the topic you participated in today, or any suggestions for topics you would like to see in the future, simply use the e-mail alias feedback@microsoft.com. Please include in the subject line "Support WebCasts." So, once again, we really appreciate any feedback you have; I do hope you have a few moments to send us a quick note.

The next question is: Can I simply enter my class B IP address with wild cards from Network Discovery and discover all IP devices (for example, enter 168.147.0.0 and have it discover every device in one easy step)? Is this a wise decision concerning network traffic?

Wally: Well, that is what you do when you go to the Network Discovery properties and go to the Subnets tab. When you add a subnet into your Subnets tab, you do specify what your subnet information is. So, in this case, you could put in your 168.147.0.0 IP address with the mask of 255.255.0.0, and you are specifying in that case a class B address. The Network Discovery would go through and find the routers of that subnet and do its discovery. You are normally going to do that when you enable your subnets to search, because it is going to go out there and search on the subnets for the routers and that subnet, and so on.

Then what you would do, after you have done that the first time or when you add that, is make sure you enable searching on that actual subnet, so we will go out there and discover whatever resources we can through the ARP cache and other mechanisms. You do actually do that through Network Discovery on the Subnets tab.

Whether or not it is wise, considering your network traffic, that just depends on how many of those —whatever it is —65,000 resources might be available on that class B address as active, and if you want to generate that much traffic by doing so. You probably want to run that in off-hours so the traffic that is generated occurs during off-hours, so you're not affecting your users. Certainly you can do that, and that is something that you would normally do; you can enter your full IP subnet and subnet mask.

Heidi: Are there any special setting to get Network Discovery to operate properly in a switched environment?

Wally: I was not aware there were any problems with Network Discovery in a switched environment because it's a fairly common environment and a lot of customers use Network Discovery. There is nothing that I am aware of; I am not aware of anything special you have to do in a switched environment. You would still just go with the standard discovery mechanisms and list the appropriate submessage you want discovered. So, I'm not aware of anything, no.

Heidi: Okay, the next question is: Where is Netdisc.log and how do you turn it on?

Wally: To turn on the Network Discovery log file, you have to just enable logging. What you would do is go to your SMS Administrator console. The easiest way is probably by going down to SMS Service Manager. Start SMS Service Manager itself, then, after you have connected up to SMS Service Manager, go down to your site server and go down to the component name of SMS_Network_Discovery. Then, enable logging for that component. Enable logging for the SMS Network Discovery component then, when Network Discovery runs, it's going to place the log file in the same location as all the other server log files, which would be in on the site server in the SMS\Logs directory; it is labeled Netdisc.log.

I will caution you that that log file is not for the faint of heart. If you have a lot of resources on your wire and you're enabling all the different discovery methods, you will have a ton of data to go through in that Network Discovery log file, and a lot of that data is going to look the same because we will be issuing all of the same calls over and over again to every single client you have. Just be aware that you're going to have to do a lot of searching in that log file to find what you want because you'll see a lot of data that will be repeated because you're using the same calls and commands and so on, but to each individual IP that was discovered.

It's on your site server in the SMS\Logs directory, but you have to enable Network Discovery logging by default. Use SMS Service Manager to enable it, or go to the registry, in the tracing key, and turn it on there.

Heidi: Next in line: You mentioned the Guest account and how it relates to trusts. Can you please explain this again, and how does this account factor into SMS?

Wally: Well, the Guest account really doesn't factor into SMS at all; however, what is required with Network Discovery is that we have to be able to connect to a resource to be able to retrieve data. In some of these cases, for example with Network Discovery going through DHCP server, the account has to be a valid account on the DHCP server. In the Windows NT 4.0 case, it does not have to be an administrator or anything; it just has to be a valid account. Most environments have the Guest account disabled on their sites. So, if my DHCP server happens to be in a domain that is not trusted by the SMS domain, or wherever the SMS service account is, then the SMS service account would not be a valid account in the domain of the DHCP server or on that server. If the Guest account is not enabled, then we won't have access to the DHCP server to retrieve data.

It was just pointed out to me, by one of the development managers, that we've had a number of customers who have turned off the Guest account and not had a trust set up, and so we cannot query anything from our DHCP servers that we would normally get. Just make sure your SMS service account does have valid access to your DHCP server, whether that's through the Guest account — you probably don't want that, because most people don't want the Guest account — or you have the appropriate trust relationship set up, or pass-through authentication down to the DHCP server, so you have an account you can query for Network Discovery.

Heidi: Next question: Can you give me more details on how to configure slow links? What do you consider a slow network link?

Wally: Unfortunately, we have not come out with a designation on what a slow link is for anything within SMS. About the only thing we have is the 40 Kbps for the client installation process that we talked about in the earlier question. Other than that, we haven't really defined what we consider a slow link to be. We have our scalability group doing analysis on that to find out what should be considered slow. I know that's a lousy answer, but that's the answer we have right now.

Generally, what you should do is run Network Discovery without the Slow network setting selected. Run it without that and see if you're not getting the data that you expect to get from however many hops out that you have enabled in the SNMP tab.

Lets say that you have enabled three hops and when you go up to your third hop, if you're not getting all the data back that you expect to get from that third hop, you then run Network Discovery again and select the Slow network check box. That will not put as many requests on the wire at one point in time, and it will give you longer time while we are waiting for a response from one of the calls. Because normally, in most cases, we wait 1,000 milliseconds and, if we don't get a response in 1,000 milliseconds, we just ignore it and assume that it's not active or it's not going to respond, so we just go on to the next thing. When you select the Slow network check box, it doubles that to 2,000 milliseconds.

So run it without the selection. Then, if you don't get the data you thought you should have gotten from these remote links, run it again with the slow network speed selected and we'll give you longer time-out values and cut down the number of requests. Again, there are only four parameters that are changed: ICMP ping time out, number of outstanding ICMP pings, SNMP retry time-out, and number of concurrent device sessions. Those are the only four parameters we do change because of the Slow network check box.

Heidi: Is there any way to just report discovery of operating systems? I understand that it is necessary at first to discover topology and clients, but I just want the operating system.

Wally: Not through SMS because all the different SMS discovery mechanisms are going to do additional things. As far as specifically through Network Discovery, no, there is not an option to discover the client operating system only. It is a cumulative process. You start with the topology, then you go to topology and client, and then you go to topology and client and client operating system; there is not a way to say, "Okay, you've already done the topology and the clients for me. All I want is the operating system now." Unfortunately, no. You're accumulating your data. You can't reverse that to say, "I don't want the other data. I just want this one specific thing." Unfortunately, no.

Heidi: The next question is leaning toward a support question. So what I'm hoping is that we possibly have some pointers for this customer to where they can look for additional information, or maybe you have a quick answer for them. The question is: With regard to using a VPN Internet connection through the Internet between two buildings, I am not able to discover any resources from the other side of the VPN connection. Do you have any suggestions for where they can get information on getting that resolved?

Wally: Off the top of my head, I have no answers for you. As long as you have the appropriate information designated on the Subnets tab or the Domains tab—whatever the mechanism you're trying to use for your discovery—as long as you have the appropriate information listed there and you have the appropriate hops account set up with whatever information you need there. Other than that, I have no suggestions. I have not heard of any issues or any special configuration for VPNs.

I want to say I remember seeing a Microsoft Knowledge Base (KB) article on VPN connections and SMS. You might check the Knowledge Base and search for VPN and see if there is one there. Other than that, I have no suggestion other than contacting PSS.

Heidi: Excellent. Thanks, Wally. The next question is: I have several SMS sites across the nation connected by T1. Is the central site the best place to perform Network Discovery, or should I have each individual SMS site perform its own Network Discovery?

Wally: It depends on how you want your data to be used. If all you want is your data to be used and available at your central site, then yes, you can perform Network Discovery at your central site yourself; however, if you want that Network Discovery data to be used for each local site and its Network Trace operation or its ability to do Windows NT remote client installations, then, obviously, the discovery has to be performed at those remote sites so that they would have the discovery data locally, and so they can do the Network Trace operation or determine, "Oh, I need to push out the SMS client software." If you just do this at the central site, the central site is not going to push that data down to any child sites unless it happens to be all secondary sites because parents push assigned resources down to secondary sites but not to primary sites. You would want to do the discovery at the primary site where you want the data to be valid.

As with all other discovery mechanisms, any data discovered does flow up the hierarchy. So, if you do discovery at your lower layers, or your child sites, eventually all that data will be represented in the central site's database, so the central site will have all the data as well.

So, it really depends on how you want the data. If it is purely that you just want the data for your central site to do its administrative reports or whatever, then you can run the discovery process there; however, if you want the data to be used at the child sites for pushing out client software or performing Network Trace, then you obviously want the discovery to be used from that location itself, and generated from that location.

Heidi: Next in line: What is the reason that the ARP cache is not used if the router port has multiple addresses? Are there any plans to enhance the product to work with routers that are configured in this manner?

Wally: Well the reason we don't, again, is that if you have multiple IP addresses associated with a single port, you may have multiple subnet masks associated with that single port. In that case, we wouldn't know which address and which subnet mask to associate the client address with.

So, again, that gets back to the point where I said we guessed in some earlier versions of the product, way before the released version of SMS 2.0, and we guessed wrong. To prevent us from guessing wrong and pushing out client software where we shouldn't, or not pushing out client software where we should, we just state that we have to have a definitive subnet mask.

If your subnet mask is not definitive, in other words your router has multiple IP addresses and multiple subnet masks from that interface, it's not definitive or it's not trusted, as we call it, so we cannot utilize it. We need the definitive subnet mask so we can positively identify whether or not that resource is assigned to a site, so we know whether or not to push out client software. Or, in the Assigned column of your discovery data, it will say Yes or No appropriately, so that's why we need the subnet mask.

Heidi: Excellent. When Network Discovery starts, does it rediscover resources that it has already discovered? If so, does it make sense to change the order of the Domain list or the Subnet list?

Wally: Network Discovery does not remember what it discovered previously. It has no history, so it doesn't do any deltas. All it know is what you're telling me to discover on this subnet, what you're telling me to discover in this domain and on this DHCP server, etc. If you leave those exact same parameters every single time, then most likely you're going to get the same set of results every single time. So, yes, it certainly does make sense to do discovery one time on a couple of subnets or a couple domains, or two different DHCP servers, then switch to other appropriate resources, subnets, domains, or DHCP servers for other discovery processes and events. Then, mix them up occasionally so you can discover new resources that were not alive on the network when you did your initial discovery. You do want to mix up what you have there and change those values, but do not forget to use your old values because you do need those to discover new recourses.

Heidi: Excellent. The next question is: If the server has static IP and we can only count on SNMP to get the subnet mask, mustn't that server's SNMP Security tab be set to Accept from any host? If restricted hosts must include IP of SMS of site servers? If so, which site servers? Would it be all primary and secondary?

Wally: Very good question. Yes, if you're going to be utilizing SNMP as your means of acquiring data, including the subnet mask from a resource, obviously that host will have to be configured to accept SNMP calls from your site server; whichever site server is performing the discovery will have to be allowed to make requests of that IP host through SNMP. Either select the Accept from any host option, as is listed, or, if you want to have security and specify IP addresses or host names of which host are allowed to query this host through SNMP on the SNMP properties and Security tab, then you would list the site server.

It's whatever site server you want to be allowed to do that discovery. You probably don't have that many site servers that are going to be discovering the same resources over and over again, so it may not be that many that you have to put there.

For a secondary site server, you really wouldn't have to do secondary site servers because, when they discover something, they push it up to the parent automatically. Then, the parent pushes it down if it belongs to the secondary site anyway. You would want to use primary site servers because, if they have a resource that's assigned to a secondary site, they actually push that down to the secondary site itself. I would not worry about secondaries; I would worry about the primaries. Then, yes, either your clients or your agents would be Accept from any host, Open from everybody, or specifying the IP address or computer name of the primary site servers.

Heidi: The next question is: Do the domain controller server's operating system need to be on a hard drive that is NTSF to be installed as a client, or can the server have a single NTSF drive and the operating system be FAT?

Wally: SMS has no requirements at all, on a client, for the client operating system to be NTFS. We don't care what the underlying file system is. Whether it's FAT, HPFS, or NTSF, or whatever, we don't care. The only time we have NTFS requirements is for the SMS server code, not the client code. So, it doesn't matter at all on the domain controllers or any other client.

Heidi: Next in line: Will Network Discovery discover Windows 95 and Windows 98 clients, and will the Windows NT Remote Client Installation method work with Windows 95 and Windows 98 clients?

Wally: Network Discovery will discover Windows 95 and Windows 98 clients; however, they return the same operating system; you won't be able to differentiate between Windows 95 and Windows 98 just because of Network Discovery because the API call that's used returns the same value for both of them. So, you would have to use Logon Discovery, or Heartbeat discovery, preferably, to actually designate what the real operating system is for those specific resources.

Also, you have to enable file sharing on your Window 95 or Windows 98 box in order to retrieve the operating system because, again, we connect to the server service of that resource, and that's through to the file sharing option.

Lastly, Windows NT Remote Client Installation does not work on Windows 95 and Windows 98. It's Windows NT or Windows 2000 only because of the fact that with Windows 95 or Windows 98, there is no concept of a user versus an administrator, and there is no access if a user is not logged on, as far network connectivity, whereas there is on Windows NT. We can use Windows NT and we can connect remotely, really, regardless of whether anybody else is there or not, and push out the SMS client software. That only works on Windows NT and higher clients.

Heidi: Next in line: Why does Network Discovery sometimes continue way past its scheduled stop time?

Wally: I have never heard of Network Discovery going past its scheduled stop time, the duration time. I have never heard that at all. The only thing I can think of is if it got caught in one of those loops where it says, "Waiting for idle process," and somehow it was not stopping because of that.

I have not heard that it does not stop, and that is the whole reason for the duration, to designate your end time. But, I guess it's theoretically possible if it gets into a loop where it just says, "Waiting for idle process," or something like that, and it just never recovers from that. It is possible that it would not stop from there.

The developer, I talked to him about this, he said there was one issue, but he said he thought all the issues that he knew of were solved in SMS SP2. So, if you're seeing that in the SP2 timeframe, I would definitely let PSS know so they can create a bug report. That would get sent to the developer and he would check it out.

Heidi: The next question is: Because of traffic, it seems to be best to run discovery at night. To get all clients, however, it seems to be best to run discovery during the day. How do you best balance this situation?

Wally: Absolutely correct. You're absolutely correct in that, for traffic considerations, it's best to run at night; however, at night your clients won't be active, which means they may not be able to be queried. So, it depends on what kind of clients you have. If you have Windows NT or Windows 2000 clients and the computer is still left on at night when the user's not there, then Network Discovery can still run and do it's work and probably get the information the same as if it was during the day. If they're Window 95 or Windows 98 clients and there is no network access after hours when the user is logged off, then you wouldn't be able to get the appropriate information from the resource. It depends on what kind of clients you have.

It also depends on how you make the subnet mask available. If the subnet mask is available through Microsoft DHCP, then we don't care. Turn off all your clients and we'll still discover them. Like I said, we discover things, when they are not there, through DHCP. However, if you're relying on an SNMP agent, well, then again, on Windows NT, we can still query those boxes, even though nobody is logged on, through the SNMP agent, and get the appropriate information. With Windows 95 and Windows 98, that's not the case.

If you are relying on the router ARP cache to provide the subnet mask for discovery, then obviously your clients most likely are not going to be in the router's ARP cache after hours, so the discovery process would not be as applicable. This one client I mentioned, they had their router ARP cache life set to four hours, which is very long. They also had routers also at around 256 MB of RAM, so they had plenty of room to hold that longer ARP cache life. It really depends on your environment.

What you may want to do is restrict your scope of discovery during the day. Maybe have one domain you want to browse and one subnet you want to browse on one day, and do discovery during the day, so you get the maximum potential out of your clients. Then, switch to a different subnet, or a different domain, or a different DHCP server, or whatever, the next time you run Network Discovery. Alternate what resources or alternate your seeding mechanisms for different days, for different events, for Network Discovery. You're moving your traffic around or your restricting the amount of traffic on a per-instance basis, but you're still doing it during the day when you have the most potential for discovering your resources.

But again, it depends upon how you plan to do discovery and what type of clients you have. Look at all those options and you just have to look and see what is best in your environment.

Heidi: The next question is in regard to Windows 95/Windows 98 clients. You mentioned the need for the server service to get the operating system name. If we're not running this, is it correct that we'll still get a DDR from these clients just simply with operating system name listed it as null? We are assuming that we can get the mask form DHCP if no SNMP is on the client.

Wally: Correct. Even if your server services is not running on an Windows NT box, a Windows 2000 box, or any box, including Windows 95 or Windows 98, if the server service is not running, we won't be able to retrieve the operating system. However, we still will create the DDR for the resource, provided that we have the IP address and the subnet mask, through whatever mechanisms — we don't care. Then, we will create that DDR; the operating system will just be listed as null. So, yes, we will still create the DDR for it.

Heidi: Are there any issues with running discovery the same time that packages are pushed to remote SMS servers because both could be done during the same off hours?

Wally: The only issues would be the appropriate processing requirements on the site server to do Network Discovery, and then also for Distribution Manager to do its work, as well as the amount of network traffic that's going to be generated during that time because both of them will be generating network traffic to push out a package or to do discovery on your wire through ICMP and SNMP, and the 132 API calls, and DHCP, etc. That's going to be the issue.

If your site server has enough horsepower to handle both of them simultaneously, great. If your network bandwidth has enough resources available to handle both of them simultaneously, that's great as well. If not, one of the two will suffer, and it may be you just may not discover all the resources you want it to discover because of timeouts on the wire when you're pushing down your Windows 2000 package or Office 2000, whatever it happens to be.

Heidi: The next question is in a bit of shorthand again, so I will do my best at reiterating it: What are the security requirements for installation to succeed on a server or workstation? Just to have SMS service accounts be Domain Administrators with Domain Administrators in the local admin groups? Anything else? Does it matter if the system is only in a workgroup versus a domain?

Wally: For Windows NT Remote Client Installation, all we need is either the SMS service account or the SMS Client Remote Installation account to be a local administrator at the client you're trying to push out the software to. We need to have access to the Admin$ share at the client computer from either the SMS service account or the SMS Client Remote Installation account, which is not created by default; you create it manually if you wish to.

If one of those two is an admin, we can connect it with the Admin$, and you haven't locked down your client too much (we will talk about that in next month's session — locked down clients), then we should be able to connect and push down the bootstrap program to force the installation of the SMS client software on your Windows NT or Windows 2000 client computer.

Workgroup versus domain — we do support clients in a workgroup. Obviously, you have to do it by pass-through authentication then, and have a local account that would be used as a local admin. Normally, it is done in a domain environment where the Domain Admin account is a local admin on a local workstation, so everything works perfectly.

Heidi: The action of Network Discovery on expiration of the run time was a surprise. Why does it not process the data it collected during the interval?

Wally: That was just a decision made by the developer and the program managers in charge of that. They had it say, "You told us to stop. We are going to stop. That means we're going to not do anything else, which means not exporting any of the data." That has been mentioned as something they might reconsider in the future, and make it, "Okay, the duration has stopped, let's export what data we have."

Again, you told it to stop, which means you don't want Network Discovery to do anything else, which means creating discovery records. But, theoretically, because you're doing Network Discovery on your site server, your site server is where Discovery Data Manager is to process those, there would be traffic with generating those.

So, yes, it makes sense to export that data, even though the expiration time or the duration has been expired. That is something that they are looking at in the future. I have not heard whether that is something they're going to change in the next release or not. I'll look into that and see. But they have discussed that as something that may be changed in the future.

Heidi: Are there any problems or issues we should be aware of with an environment that has many VLANs?

Wally: This is kind of the same as the VPN and the switched networks questions earlier. Not that I'm aware of. You just have to make sure you have the appropriate addressing information specified in your Subnets tab, as well as whatever seed mechanisms you want. I am not aware of anything specifically for the VLAN or VPN or switched network environment. I have not heard of anything. That does not mean there aren't things, it just means I have not heard of anything in all the research I have done on Network Discovery and all the times I've used it, and so on. I have not heard of any issues with it, so I'm afraid I have nothing other than that.

Heidi: The next question is: I am still on SMS 1.2, but I'm planning to upgrade to SMS 2.0 next month. Can I run Network Discovery on PCs that still have the SMS 1.2 client files installed?

Wally: Network Discovery doesn't run on computers, Network Discovery runs on the site server and it reaches out across the network to computers, to resources, and to IP hosts, to retrieve resource data. From that, we don't care what is on that resource. They can be an SMS 1.2 client, they can be SMS 1.0 — it does not have to have SMS at all because Network Discovery is trying to find for you what resources you have available for you on the wire.

If you do happen to have an SMS 1.2 client installation, Network Discovery won't know that at all. It will see that you have a Windows computer name, here is its IP address, here is its subnet mask, and you're off and running. That's what you would know from Network Discovery. You won't know anything about whether it's SMS 1.2 or SMS 2.0, or whether there is any SMS involved at all. We wouldn't care, as long as you can acquire the IP address and the subnet mask.

Heidi: The next question is: Can the problem with the switched environment be attributed to virtual private LANs created on the script? I am assuming this is probably in reference to the question asked by the individual about their discovery issues with their VPNs.

Wally: Yes. And it could be. I apologize. Here I am not enough familiar with the VPN or VLAN environment, or switched network environment, to know what any of the idiosyncrasies might be there. There could be an issue there. I don't know what it is.

Heidi: Well it definitely sounds like it is an issue for Product Support Services, where you can get some one-on-one interaction going for that issue. The last question of the day is: Where does one easily identify how long discovery takes or has taken?

Wally: All you have to do is go to your <status system> go to your <site status>, <site code>, <component status>, and SMS Network Discovery. Then, look at the discovery data for your site.

I think I can tell you the exact status message numbers for starting and stopping in Network Discovery. Network Discovery starting is status message ID 1300, and Network Discovery stopping is Status message 1308. You can just look at the times between the 1300 message and the 1308 message, and that will tell you exactly how long Network Discovery took.

Alternately, if you're a fan of log files like some presenter you might know, you can just open up your log file and you'll see that SMS Executive started Network Discovery at the appropriate date and time. At the very end, you'll see Network Discovery completed and shut down at the appropriate date and time. You can just subtract the ending time from the starting time, and you'll able to see exactly how long it took.

From there, you will have some idea how long this session took. The next time you run Network Discovery it could be longer or it could be shorter, depending on seed mechanisms, how many clients are available on the wire, whether you've introduced any new abilities on the wire (such as new subnets or new routers), or whether you now have SNMP agents running on your clients, etc. It may not tell you exactly how long the next one is going to take, but at least you will be able to see how long this one took.

Heidi: With that question answered, we've cleared the queue of all the questions that were submitted during today's broadcast. I want to thank all of you for joining us today. I hope you have found the content useful. Of course I want to thank Wally for joining us once again with another terrific presentation.

As a reminder, the next SMS session is on January 9, 2000. Wally will be back with us again, and we hope you find time to join us again in the near future. Have a great day, and good-bye.