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

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

Heidi Moeller: Hello and welcome to the Microsoft Support WebCast Program. I'd like to thank all of you for joining us today. Our topic will be "Windows Management Instrumentation: What Is It and How Does SMS Use It." Our presenter today is Wally Mead. I'm Heidi Moeller, and I'll be your host for today's session. We'll start this session with Wally's presentation and follow that up with a question-and-answer period when the presentation is finished.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of the Support WebCast. If you do need technical assistance, please submit an incident on the Web or call Microsoft Product Support Services and speak with a support professional.

With all those details aside, let me go ahead and introduce Wally. Wally Mead joined Microsoft over eight years ago in the Training Group. He now works for Product Support Services, developing and delivering training focused on SMS 2.0 to the support professionals. During his time at Microsoft, Wally has developed training materials for all versions of SMS. Thank you so much for joining us today, Wally. Let's go ahead and get started.

Wally Mead: Thank you, Heidi, and good morning. One clarification: I forgot to tell Heidi that I've switched to the SMS Program Group now, so I'm in the Product group itself as a Program Manager working with the early adopter customers. That doesn't affect what I do for the most part, or participation here. Anyway, welcome, and I trust you'll find something worthwhile out of this presentation for you on WMI, what it is, and how does SMS use it.

So what I want to cover in this presentation is first off, basically four different areas. The first area will be Web-Based Enterprise Management, or WBEM concepts. So what is WBEM, what is WMI, how do the two relate together. So just a little background around what is WBEM and what is WMI.

Next I want to talk about how Systems Management Server (SMS) 2.0 uses or integrates with Windows Management Instrumentation, so what are the different areas where SMS uses their WMI technology and WBEM technology to accomplish different tasks.

The third area will be different methods you can use to access your SMS data outside the SMS Administrator console. So if you don't want to use the SMS Administrator console to access your SMS data, how can you go about creating utilities or other avenues of access in that SMS data.

Lastly is a little bit of troubleshooting. So, the scenario might be you're attempting to launch from the SMS Administrator console and you get a connection failure there. How you troubleshoot the connection fail there? How is it that SMS accesses the data into the SQL database through WMI, and how you go about troubleshooting any issues in that area?

One thing I'm not going to cover at all is scripting or programming itself. So I'm not going to cover how you write scripts to WMI calls, or how you go about doing any programming through VBA (Visual Basic for Applications) or Windows Scripting Host or those other utilities and languages to WMI. I'm not a programmer; it's beyond my level of expertise.

So basically I'm going to talk about what is WBEM; how does SMS use it; how can you access SMS data through WMI outside the SMS Administrator console; and finally, some troubleshooting issues between accessing SMS data through WMI.

So the first topic, again, is going to be Web-Based Enterprise Management concepts. So we want to talk about what is the WBEM initiative; so what is it, and how does it relate to what Microsoft uses for WMI. We'll hit a little bit of WBEM terminology, just so we're on the same level and background information as far as what WBEM is. Then we'll specifically focus on WMI, the Windows Management Instrumentation service: what it is, and how it relates to WBEM. And then lastly we'll focus for a while on how SMS uses WMI itself.

Okay, so what is the WBEM initiative? WBEM stands for Web-Based Enterprise Management. And it was started by a number of different companies, primarily BMC Software Inc., Cisco Systems Inc., Compaq Computer Corporation, Intel Corporation, and Microsoft Corporation, a number of years ago. Basically what the WBEM initiative was designed to do is to provide a common method of accessing management data through any type of utilities. Basically you can think of the WBEM initiative and what its goal is for providing management data to applications the same way that, if you can remember what printer drivers have done for applications and printing. In the past (the old days), each application manufacturer that wanted to do any printing had to write separate printer drivers for each printer they wanted to support in their application. So if one manufacturer had three different applications, they might duplicate those same drivers in all three applications. Each manufacturer would have to write its own printer drivers for those printers for the specific applications. So there was a lot of redundant data, a lot of coding that was redundant between different manufacturers.

Then, a number of years ago, the OS started to implement the printing process. So the code for printer drivers was built into the operating system. And all the application manufacturer had to do was provide a little stub driver for its application to hook into the printer APIs and then the printer manufacturer only had to write one driver for the operating system. Then apps just called that driver, and everything worked properly. So it made it much easier for the applications to do printing, because they just had to worry about writing direct calls to the printing APIs that the operating system created and enclosed. The printer manufacturer had to write a driver for the OS, so it was much easier. So that's what the WBEM initiative is trying to do for management data. So, if you look at the example on the slide where at the very bottom we show you SNMP, Registry, DMI and Other, those are things called providers. And we'll talk about the terminology on the next slide or so.

The scenario or a comparison or analogy to the printing thing would be, in the past a lot of manufacturers had SNMP agents. And a lot of customers were implementing an SNMP agent on their desktops. That SNMP agent is going to sit there and gather data and respond to management requests from some SNMP management application, saying I need this particular piece of information: IP address, subnet mask, number of sessions, number of interfaces, number of packets sent and received and so on. So an SNMP agent is running on a desktop or some device, and it's creating management data and providing it to a management application, in this case, to an SNMP management application.

Well, nowadays a lot of PC manufacturers are developing DMI agents, and those DMI agents do basically the same thing as the SNMP agents do. They sit on the desktop. They gather specific data, and they'll provide that data to management applications, some sort of application that would request that data, so some DMI program. The data that the DMI agent gathers may be the exact same data, in some instances, as the SNMP agent. However, each of those agents are written to talk only to their own specific type of management application. So the SNMP agent is going to provide SNMP data. The DMI agent is going to provide DMI data to some interface or some application using those DMI interfaces. So it may be duplicate data that a single application might want; however, you have to use two different programs (management applications) to access that data. So what the WBEM initiative does for you, it provides a common layer of management infrastructure so that any type of agent can gather data, store it in this common repository and then any management application can pull that information out from that common repository.

So if you look at the slide and the little graphic there, at the very top of the page would be the management application. And we list a number of different programming interfaces there, that you could use to access that data. That management application, whatever it is, goes down to the central repository called WBEM (Web-Based Enterprise Management) with its CIM (Common Information Model) layer, and it just requests specific data out of that CIM repository. That data could be provided or added to that data structure through any of those different agents down at the bottom. So my management application could say, give me the IP address of the subnet mask of my host, and that data would come from the WBEM database, or the Common Information Model repository.

That data could be provided by the SNMP agent, using an SNMP call; it could be provided by the registry provider, going to the registry; a DMI agent. It doesn't really matter. We don't care how the data got gathered or what type of provider gathered that data. It's in a common repository, and my management application can gather it without having to know specific SNMP calls or DMI calls or whatever the case is. So just common calls to the central repository, and I get the data that was generated by any means. So it's a unified interface for accessing management data. That's what the goal of the WBEM initiative is.

The WBEM initiative is now owned by the Distributed Management Task Force (DMTF), so they are now in control of the WBEM initiative. It's not owned by Microsoft or Intel or any of the other companies we mentioned. They're members of the DMTF task force for WBEM; however, again, the initiative and all the specifications are owned by the DMTF now.

Okay, on slide 5, a little bit of terminology for WBEM, just so we have a common playing field here for everyone. Schema, the schema is the Common Information Model, the CIM itself. This is the data format. This is the type of data and how the data is laid out in the central repository. So basically it's a database layout. The CIM repository is that physical store unit, so in the previous slide, it was where we had WBEM and then we had this Common Information Model, the CIM. It's the data store where all the information is stored locally. So all hosts that install WBEM, they'll go ahead and have a repository, and that repository is this physical data store.

The provider is the entity at the bottom of the previous slide, those triangles that I was referring to as agents. Those are the agents or the pieces of code that go out and physically gather the data, so go out there and gather the SNMP information through the IP address or subnet mask; they gather the DMI agent, whatever the case is. They gather the data as providers, and they place the information into the CIM repository.

Management Object Format, or a .mof file, is an ASCII text file that's used to provide data to the CIM repository. So generally when these providers gather data, they'll write it in the CIM repository. It can be done in the form of a .mof file. Some of you may be familiar with .mif files from SMS in the past; .mif files are also ASCII text files, but they're providing data to the SMS database as opposed to the CIM repository. So .mof files are used to provide data to the CIM repository. They can also be used to somewhat provide extensions to the schema, or control what the database layout is.

And then lastly, is the consumer application. A consumer application is that management application that sits at the very top of the architecture that requests data from the CIM repository. In our case, you might think of the SMS Administrator console as the consumer app. It's sitting at the top of the architecture and it's making requests of SMS data down through the CIM repository. So that's a little bit of terminology on WBEM and how it all lays out. So that's a little background around WBEM itself.

Now let's focus in on WMI (slide 6). WMI is the Windows Management Instrumentation. And what this is, this is Microsoft's implementation of the WBEM initiative. The actual implementation of WBEM rests with the OS manufacturer itself, so the specifications of WBEM are owned by the DMTF. So they own the schema. They own the specifications of the initiative; however, the physical implementation and delivery of that technology is owned by the manufacturer itself. So Microsoft's implementation of WBEM is called WMI, Windows Management Instrumentation.

So we follow the CIM schema; we follow the WBEM initiative. We're just implementing that on top of a Windows platform. So if you look at the graphic on your slide, you'll see a number of different things here. First, in the upper left-hand corner, you'll see the SMS Administrator console. And you'll see, if you can remember the slide two slides ago, that that is a management application, or from the terminology slide, it's a consumer app. It's sitting at the top of the layer, making a request of data from the Windows Management Instrumentation layer.

Now, in our case, the way we implement the CIM schema is through something called CIMOM. The CIM (Common Information Model) Object Manager. So this is our manager application that controls the CIM repository itself. So whenever you go to a command prompt or to Control Panel Services or whatever utility it is, and you look at the services, you'll see the Windows Management Instrumentation service on any of the Microsoft platforms that have WMI installed. And that is our CIMOM, or Common Information Model Object Manager. That's basically the database engine controlling the CIM repository itself.

Then down below is a series of different providers that Microsoft implements, and we now have well over 30 different providers available through WMI, some specific to applications, like there are Exchange providers. You see the SMS Provider here. Office has providers. So there are numerous providers. Some are just generic providers like Win32^® or registry providers.

WMI, as far as Microsoft is concerned, is now standard as of Windows^® 2000. So when you install a Windows 2000 desktop, whether it's a Server or a Professional Client, WMI or the Windows Management Instrumentation service, is installed automatically. There are numerous different things inside Windows 2000 that rely inherently on WMI data. For example, if you go out and stop a WMI service, you won't be able to do much of your disk administration work through a disk management application. It all relies on WBEM or WMI. So there are numerous different pieces of Windows 2000 that use WMI interfaces to access their data.

SMS also installs WMI on any 32-bit desktops that don't already have WMI installed, that don't already have a version of WBEM installed, so we will install that. And we'll talk about the different versions coming up very shortly. WMI or Windows Management also comes with Windows^® 98, and it's optional for Windows NT^® 4.0, as well as Windows^® 95. It's on the CD, or you can get it separately for those different platforms as well. So just as a quick recap, Windows Management Instrumentation, or WMI, is Microsoft's implementation of the WBEM initiative.

In our next slide (slide 7), we'll touch on very quickly the different methods or different ways that SMS uses WMI. SMS uses WMI for many different tasks throughout the entire environment of SMS. Probably the one most of you are familiar with is hardware inventory. On our 32-bit desktops, hardware inventory is accomplished through WMI. And I have individual slides on each of these coming up, so I'll hold off on the details on them coming up fairly shortly.

HealthMon, so if you use the Health Monitor utility, the agent itself runs as a WMI Provider. Network Monitor Control Tool uses WMI. Network Discovery uses WMI to gather some data. Network Trace uses WMI to do some polling as well as pinging. Same with the SMS Service Manager, to poll the different components, it uses WMI. And then, the SMS site database access itself. So anytime you use the SMS Administrator console and perform any actions such as viewing, displaying, viewing details of, creating, deleting, any of those different operations you can perform in the SMS Administrator console; all that information and all those commands and requests go through the SMS Provider, which is part of WMI. So they go through the provider, through WMI, down to the Microsoft^® SQL Server™ database itself.

So SMS itself was written very tightly around WMI, and it uses it very much. So if you were to turn off WMI, stop the Windows Management Instrumentation service, you would find that a lot of things in SMS would stop operating, primarily the SMS Administrator console, and you wouldn't be able to do any administration. So before we go on to the details of each of those different uses of WMI and SMS, let's just talk for a minute about the different versions of WMI and SMS itself, and how they interoperate.

I mentioned a slide ago that WMI is optional for Windows NT 4.0 and Windows 98. It's available on the CDs for those two OSs; for example, on Windows NT 4.0 Service Pack 4, it included the WMI code that you can install separately. And it's also available for Windows 95 as well. So it's optional there, whereas again as I mentioned before, Windows 2000 installs WMI natively, and it relies on it quite a bit.

SMS 2.0 will install WMI version 1.1 on any 32-bit desktop that doesn't already have a later build of WMI installed. So, for example, on your Windows 95, your Windows 98, your Windows NT 4.0 desktops, it may not already have WMI already natively installed. When SMS installs that computer as an SMS Client, it is going to automatically install WMI version 1.1. I have the build number listed there for you, which is 698. So what SMS 2.0 supplies for you is WMI version 1.1 for any desktops that don't already have it. If you already have a later build of WMI installed, something beyond build 698, we will not install 698 on top of some later version. But we do require it to be on all of our 32-bit desktops, whether it's installed prior to SMS installation or through SMS itself.

Windows 2000 installs WMI version 1.5, which is build 1085. So that gets installed by default, and as mentioned before, it's relied upon very heavily in Windows 2000 itself. If you want to standardize your WMI platform throughout your entire SMS architecture and all your desktops for all the 32-bit clients, you can go ahead and manually upgrade their WMI version to WMI version 1.5. You can download this from the Microsoft Web sites. You can download WMI 1.5 for Windows 95, Windows 98, and Windows NT 4.0.

I have a couple of KB articles listed for you. The first one (Q262317) mention the fact that SMS 2.0 Service Pack 2 does indeed support WMI 1.5, which makes sense, because that's the version that ships with Windows 2000, so we have to support it. But it also does state the fact that we do support it, and that you can install it on down-level platforms, being non-Windows 2000 systems. And Q269411 talks about one of the ways that you can solve a problem with Windows 95 clients locking up or hanging after the upgrade of Service Pack 2. One of the ways you can fix that, is by upgrading that Windows 95 client to WMI 1.5.

Now, the issue there is actually a WMI issue in 1.1, that SMS 2.0 Service Pack 2 exposed. It wasn't found previously. So when you upgrade to Service Pack 2, this issue is found. It's actually just one DLL for WMI that needs to be replaced. We now have a hotfix for that, and you can get that by contacting PSS and telling them that you have Windows 95 clients that are locking up after you've upgraded to Service Pack 2, and they can get you that hotfix. And again, it's just basically a new WBEM implementation for SMS 2.0 Service Pack 2.

If you want to download WMI 1.5, you can either go to http://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/MSDN-FILES/028/000/015/topic.xml and download WMI 1.5 from there or if you just go to http://www.microsoft.com/downloads/, and then do a keyword search on WMI, you'll be able to find the links to that previous location as well.

One gotcha you have with Windows 95 is that, in order to successfully upgrade your WMI to version 1.5 on a Windows 95 box, you must have DCOM version 1.3. So if DCOM 1.3 is not already installed on your Windows 95 desktop, you will be required to install DCOM version 1.3 prior to installing WMI 1.5. And, if necessary, you can download DCOM 1.3 for Windows 95 from http://www.microsoft.com/com/dcom/dcom95/download.asp. That's where you can download the new version of DCOM.

So SMS 2.0 itself provides WMI version 1.1. Windows 2000 supplies WMI version 1.5. The two can happily coexist, so you can leave your down-level platforms at WMI 1.1, and your Windows 2000 desktops at 1.5 if you wish, or you can upgrade everybody to 1.5. Again, WMI is not used on 16-bit platforms because of the lack of COM and DCOM support that is required for WMI.

Now let's return to the different methods that SMS uses WMI for. So first off is the SMS Administrator console. The SMS Administrator console uses WMI very heavily. The SMS security rights are validated by the SMS Provider before the requested action is completed. So the SMS Provider is one of those providers at the bottom of the hierarchy, if you think about your hierarchy slide, at the bottom of the hierarchy. And that provider is controlling the access to the SQL Server data, which is where SMS stores most of its data in SQL Server. The provider is controlling the access to that SQL Server data by specifying whether or not this user can or cannot perform the requested operation. So all of the actions that you perform inside the SMS Administrator console (when it's running), go through the SMS Provider, which means they're going through WMI, down to the SQL Server database, and validating whether or not you can perform that operation as the logged on user.

All these actions use SMS Software Development Kit (SDK) calls. The SMS Administrator console itself was written using the SMS SDK. What that means to you is that we rely totally on WMI for all the SMS administrator operations and actions. And that also means that for the most part, any action that you can perform inside the SMS Administrator console, you could write a WMI utility, either through VBA or whatever other programming language you want to use, and duplicate that same action through a command line or some other utility without using the SMS Administrator console.

That gives you very, very powerful administration of SMS so that you can have specific users tasked with administering a specific function in SMS. And you could write, for those users, a command-line utility or VB application that would go out and perform this operation for them without them having to have the full SMS Administrator console installed locally.

Some of these tasks are already scripted for you in the SMS 2.0 Resource Guide. For example, there is a folder called the Import folder in the SMS 2.0 resource guide in the Bin\I386 directory. Under Import, there are a number of scripts there for you that will go out and perform specific functions through SMS. For example, some of those utilities allow you to make client access points, so basically assign the client access point role to a Windows NT computer or Makedist.exe allows you to turn a Windows NT server computer into a distribution point for SMS.

There's another utility that allows you to make collections from a command line. There's another utility, I think we mentioned it in one of our other Support WebCasts earlier this year, that allows you to import and export queries from the SMS Administrator console to a text file. So that's very useful if you have a set of queries that you've developed as an administrator and you want to pass those queries on down to a child site or maybe to a parent site or just a parallel site. By default, we don't pass query syntax up and down the hierarchy as we do collections or advertisements or packages and so on.

So you could use the Query Edit utility, which is Qryedit.exe. You could use it to export any custom queries that you've written, to a text file, take that text file, send it through e-mail or whatever means necessary, to another SMS administrator. They can use the Query Edit utility to import those custom queries into the SMS database without having to run a command-line tool to put those into the SMS Administrator console. So very, very powerful utilities that will allow you to go out there and customize utilities, actions, or just perform actions outside the SMS Administrator console. So that's just a quick recap of some of them. There are other utilities in the resource guide that allow you to do many other things that also use WMI.

The one exception you have is anytime there's any kind of an SMS Administrator console function that's going to create a password or encrypt a password or account, that cannot be done through the SDK. The SDK currently does not have the encryption technology in it to allow you to create and encrypt those passwords. So if you create an account inside the SMS Administrator console and encrypt a password, such as maybe the Software Metering Service Account or another account, that can't be done through the SDK. All of the other actions, however, of normal administration mode can be.

There's also in the SMS 2.0 resource guide, there are Microsoft Excel and Microsoft Access utilities that allow you to run the SMS queries from inside Excel or Access, so this is another option for you as far as running SMS operations outside of the SMS Administrator console.

Hardware inventory relies on WMI as well. So hardware inventory in all 32-bit clients use WMI. So WMI Providers gather data when it's requested. When the Hardware Inventory Agent kicks off, either prior to SP2 (when it ran as an executable launched by the SMS Client service), or in SP2 (where it is now a separate SMS service), the providers will go out and gather the appropriate data, whether it's registry data, whether it's Win32 provider data, or whatever the case is.

That data is then written to the CIM repository. Now, in some cases, the data is dynamic data where you don't physically write the instance of the data or what the value is; you just write which provider gathers that data for you there. But we do have access to the old or previous inventory information, so we can perform delta inventories. So we do store on 32-bit clients, we store the previous inventories in the CIM repository, or at least the data for it. So that when current inventory takes place, you can determine what is current data, what is new data, what is updated data, so you can create your delta inventory, so you're not passing full inventory files across the wire.

The WMI implementation gathers much, much more inventory data than we did in previous versions of SMS. Where in SMS versions 1.2 or previous versions, it was basically MSD calls, Windows MSD calls, now we're using WMI, which is a much richer and fuller set of attributes and data that can be gathered.

WMI 1.5, which again ships standard on Windows 2000, WMI 1.5 automatically can retrieve the serial number and manufacturer information from PC BIOS, if your hardware supports SMBios 2.1. So if your hardware supports SMBios 2.1 and you're using WMI 1.5, SMS hardware inventory will natively gather serial number and manufacturer information from the PC BIOS. So you don't have to use your DMI utilities or your OEM manufacturer utilities to gather that data, provided you're running WMI 1.5 and your hardware supports SMBios 2.1. If not, then you'll still be required to have those utilities to provide that data to SMS through NOIDMIFs is what most of them do.

And again as we mentioned before, you can manually install WMI 1.5 on your non-Windows 2000 systems, so your Windows 95, Windows 98, Windows NT 4.0 platforms, you can upgrade to WMI 1.5. And as long as the hardware supports the SMBios 2.1 spec, then you can go ahead and pull the serial number information from PC BIOS. Again, that's provided you haven't turned off the PC BIOS information from the standard hardware inventory we're going to take. And that gets into the next point.

Default inventory is controlled by a special file called the SMS_DEF.MOF, or SMS Default Managed Object File, which controls what the hardware inventory classes and attributes are to be inventoried. There's a default SMS_DEF.MOF, which has a number of different classes and attributes enabled, which does include PC BIOS and serial number and manufacturer. However, it doesn't have all the classes or all the attributes enabled, because that would generate a lot of network traffic.

So if you do want to modify how hardware inventory takes place, in slide 11, we talk about modifying hardware inventory through WMI. There are a couple of different ways you can do this. The preferred method is to use a utility called MOF Manager. MOF Manager, is available from either the SMS 2.0 resource guide, or preferably from your SMS 2.0 Service Pack 2 CD in the Support.exe bundle. Just run Support.exe, unbundle that utility, and then MOF Manager is in the "Discovery and Inventory Tools" folder. You can use that utility to tune your hardware inventory. In other words, tell SMS which classes of data and which attributes for those classes you want inventoried.

The default gathers a certain set of data, which is fairly rich and most people are somewhat happy with that. However, a lot of customers have specific needs to gather more inventory data, or in some cases, less inventory data than what we do by default. So MOF Manager allows you to modify that hardware inventory template, the SMS_DEF.MOF. The SMS_DEF.MOF is an ASCII text file, so you could use Notepad or any other ASCII text file editor.

However, it's a little bit cumbersome using an ASCII text file editor to go through and look at that file. It's fairly large for one aspect; and another thing, you have to find out what class you want, what the attributes are, and change the attribute reporting from Off, which is false, to On, which is true, and then recompile the MOF. MOF Manager makes it much simpler, because it's a graphical interface to the SMS_DEF.MOF and it parses things very easily for you, and it's much easier to enable or disable attributes that you don't want.

You need to be careful if you modify hardware inventory, however, because some classes and attributes that you may enable may actually require network access to acquire the data. So if you go out and turn on Win32 Account, or anything that goes out to a file server or a print server or a domain controller to acquire the data, obviously it means you're going to generate network traffic. And in some cases, that can be megabytes of network traffic that's going to be generated just to collect the data. That doesn't necessarily mean report the data. So you may need to be very careful with that so you don't turn on classes that you don't want turned on, because that it is going to generate network traffic. So the best thing to do is to test it out in your lab environment to see whether or not it does generate excess traffic, remembering that when you modify it for one client, you're modifying this for every single client in your environment.

Outside that, you can also modify your hardware inventory through WMI extensions. As I mentioned before, there are over 30 providers available to retrieve additional data for inventory outside what the SMS_DEF.MOF will do for you. Some of this also includes registry parameters. If you want to do hardware inventory of specific registry values, there are registry providers that allow you to query registry values.

The advantage of using these WMI extensions and providers over using NOIDMIFs, which I know a number of you are using NOIDMIF files to extend your hardware inventory. Basically that's just a static text file that's accompanied with your hardware inventory data, and it associates that new attribute and class directly with your hardware inventory. The advantage of using these WMI extensions is that, because you're using WMI instead of a static .mif file, the data is available to any other WMI consumer application, not just SMS. Whereas if you're using the .mif files, your application won't be able to pull that data directly from the CIM repository of the client. You'd have to go through the SMS database itself.

And the bottom bullet, I list for you an online seminar that you can view, if you want to get more information about some of these WMI extensions and the providers that you can use for customizing hardware inventory. This seminar was done by one of the gentlemen in the SMS User Education department, who is very good at using WMI and scripting and additional providers. So his seminar talks about how you can write applications and use these other providers for gathering additional data.

The next area where SMS uses WMI is in HealthMon. HealthMon (or Health Monitor as it's called), the HealthMon agent is a WMI Provider. So what it does is it monitors performance-monitored counter data, and when anything changes in that area that needs to be reflected to the console, it will go ahead and gather that data, package it up, and send it using RPC calls over to the HealthMon console. So the console will be running on a Windows NT or Windows 2000 box, and it would be connected to this client agent.

And the agent, when it detects a change in the configuration or the performance of this one provider, through WMI — let's say a processor or a logical disk or memory, whatever — when it changes from a good condition to a fault condition, an error condition, warning, whatever, it will notify the console using WMI calls. So it's WMI gathering the data and then using RPC calls to transfer the data across the wire. A single agent can be added to multiple consoles simultaneously to pass data off to multiple administrators.

The next area is the Network Monitor Control Tool. The Network Monitor Control Tool uses WMI for one specific access, one specific point. So the first point is that you have to have the Network Monitor Control Tool started. This tool does not start by default, so you have to launch it either from the SMS program group or from the SMS Administrator console.

After you start the monitor, you'll find that there's a series of about eight or nine different what are called monitors that you can enable. So you have to select the appropriate monitor that you want, such as the IP Range Monitor or the Security Monitor or the IP Router Monitor, you have to select the monitor. You have to enable the monitor. Configure what your thresholds are or what the specific addresses are that you want the monitor to monitor, and then start the monitor. And when it's started, it will proactively watch your network for those conditions to occur.

For example, if it's the IP Range Monitor, you specify a range of IP addresses that are valid for your network, or a range of addresses or individual addresses that are invalid on your network. And if the monitor ever finds an IP address on your wire that's outside that acceptable range of addresses, it will generate an alert. That alert will be written as an event. The event is written in the Network Monitor Control Tool through WMI. So when the Network Monitor Control Tool finds an event through the monitors it's running, it will write that event to the event window through WMI, so the data is stored there. And basically the event will say something like, "Invalid destination address was detected on the network," and it will tell you where it came from and what the destination address was. So the Network Monitor Control Tool uses WMI for its access and to write events.

Network Discovery stores some temporary configuration data in the CIM repository. So when Network Discovery starts up, it goes out and retrieves data from the site control file. So it goes out and retrieves data from the site control file as well as from the site server's registry, and it stores that data in the CIM repository temporarily.

And it does that so you've got the data gathered when it starts, and then when Network Discovery is running, it can just look at the CIM repository for what its scope of operation is: what subnets to query, what domains to browse, what DHCP servers to go to, what the local site server's IP address and subnet mask are, default gateway, and so on. So it stores that data in the CIM repository for a temporary period of time.

Network Discovery does not store discovered resources in the CIM repository. Some of you may have heard that we do that, but that was only done in some of the 2.0 beta versions. That was changed in the release of 2.0, to not store the discovered data in the CIM repository itself. So it just uses it for temporary storage of configuration data for Network Discovery.

Network Trace and WMI. Network Trace will go ahead and retrieve the list of site systems from WMI. So it will use WMI to pull the site systems from the site control file. When you do a network trace, a component poll operation, the component poll provider will access the SMS services and threads in the remote site systems. Network Trace Ping Operation allows you to ping a remote site system, testing network connectivity. When this happens, there is a ping provider that's used to actually redirect that ping from the SMS Administrator console to the site server. So when you're doing that ping operation, you're actually pinging from the site server to the remote site system, not the SMS Administrator console. So again, that's done using WMI as well.

And then lastly is SMS Service Manager. SMS Service Manager uses WMI for a number of different tasks. First off, when you try and connect up to a site through SMS Service Manager, WMI is what is used to find that site, find the site server, and validate that you, as a user, have access to that computer. So the first thing we have to do is find the site server itself; then we find where the SMS Provider is for that site, and then we go ahead and validate that you, the user, do have rights to perform the SMS Service Manager operations on that site.

Lastly, we have the Component Poll operation, so when you've got a list of services and you poll those services, again we're using WMI calls just as we were with the Network Trace operation, and how it was using WMI calls.

So the next slide shows a visual look at how SMS uses WMI. So it basically just recaps what's been in the last few slides, showing you the SMS Administrator console, Network Discovery, Network Trace, and Hardware Inventory Agent, as consumer applications above the CIM repository. And then the providers, being down at the bottom, the SMS Provider, the ICMP Provider, Component Poll Provider, and Win32 Provider, for actually gathering the data that is requested by these different operations.

The next thing we want to talk about is SMS Provider access. We talked about basically how SMS uses WMI. Let's focus in on the provider, because that's where most of the concerns that people have around WMI and SMS are, are to the SMS Provider. The SMS Provider controls who has access to the SMS site database, so it is our security layer to the SMS database, which is stored in SQL Server.

There are three different ways to grant a user access to the SMS Provider, which is basically granting them permission to WMI. And you actually have to connect to WMI prior to connecting to the SMS Provider itself. The first way is by placing that user in the SMS Administrators local group. So you just take the User or the Group account and place that account in the SMS Administrators local group. The SMS Administrators local group will be on the site server as well as on the SQL Server computer, if the SQL Server computer is remote from the site server.

Some people are confused and concerned about the name of that group that says SMS Administrators, and it doesn't really mean that if you put a user account in the local group, that that user is now an administrator of SMS. All that account means is that the user has access to the SMS Provider. It doesn't mean it can do anything inside the SMS Administrator console; they just physically have access to the provider. You still have to give them SMS security rights to control what they can do in the database itself.

The next way is through a utility called Wbemperm. Wbemperm is a utility for Windows NT 4.0 systems that allows you to specifically add rights to a user or group for WMI. Now, Windows 2000, the utility Wbemperm is not there anymore; it's now an administrative tool called WMI Control. So you go to WMI Control in Windows 2000 under Administrative Tools, and then Computer Management, and then you would go to the Security tab. And that would allow you to specify who has access to the SMS Provider.

And lastly is if you're a member of the local Administrators group. So if you have a local Administrators account, you automatically have WMI permission, so nothing else is necessary. So if you go in and use Wbemperm or WMI Control in Windows 2000 to manually add a user or group to the provider, what you have to give that user is Execute Methods. You have to select the option for Execute Methods. And then under Schema Access Level, you have to give them an option called Write Instance. So give them Execute Methods and Schema Access Level of Write Instance, and that will give the user the appropriate attributes and permissions they need to connect up to the SMS Provider through WMI. That is exactly what the SMS Administrators local group has. It doesn't have any other permission, only that.

One additional note is in Windows 2000, the Everyone group automatically has rights to the local WMI implementations. So it has local rights for the Everyone group. But Everyone does not have remote access, however, so if you're going to use remote access, in other words, going from a remote SMS Administrator console or the utility, you still have to select the Enable Remote option.

Access to the provider is logged in the Smsprov.log, which is one of the two automatically enabled log files in SMS Server. So you can look at the Smsprov.log and there's a lot of what you might call garbage in there, but if you search on the user name or search on the object you're going to, like Collections, you'll be able to find who's doing what inside the Administrator console. And that can be very powerful for doing your troubleshooting.

Okay, on the next slide we'll talk about the SMS Provider location. The SMS Provider can reside in two different locations. One is the site server, and the other is the SQL Server computer. So if SQL and SMS are separated on two different computers, then the provider can reside on either one of those two locations. In that environment, it's recommended that you have the provider running on the SQL Server, unless that SQL Server is going to become bogged down by adding the provider to it. Now, the provider doesn't add a lot of overhead, but normally when you're separating SMS and SQL Server, it's because you already have a SQL implementation and you want to use that same SQL Server for SMS, as well as your other applications. So if the other applications and SMS itself have caused performance issues on your server, then put the provider on the site server instead of the remote SQL Server.

The logged on user requires access to the SMS Provider, so you need Windows NT security. You have to pass Windows NT security. You have to have RPC security. You have to have DCOM security rights in order to be able to connect up to the provider. And by default, that's done automatically through the Everyone group; so the Everyone group would have the appropriate RPC and DCOM security rights to run and access the SMS Provider itself, if you give them the SMS requirements.

So then you need the SMS rights, which again can be from the SMS Administrators local group. So the physical structure below, which is DCOM on top of RPCs and Windows NT, by default you'd have permissions. From there, you need the WMI rights, which is the SMS Administrators local group.

Now let's talk about how you can access SMS data using WMI. So there are a number of different ways you can access SMS data using WMI. The first way is through the SMS Administrator console, and we've hit on that fairly well throughout the presentation so far. We very heavily rely on the SMS Provider through the SMS Administrator console.

The next way, I mentioned this before. There is an SMS Query spreadsheet (SMSQuery.xls) on your SMS 2.0 CD in the Support.exe bundle. That uses WMI calls through VBA to the SMS Provider. So that's an example on how you could write a hook for another application, in this case Microsoft Excel, to access SMS data outside the database. This one uses VBA and WMI calls.

Crystal Info for SMS, or what we commonly refer to as Crystal Reports, uses the WBEM ODBC driver. So you can use WBEM ODBC driver as a way of accessing SMS data as well. Microsoft Access, for example, could use the WBEM ODCB driver. And then you could write your own custom utilities, such as some of those in the resource kit, that either can make direct WMI calls, or you can use the WBEM ODBC driver. Any of those would be available for accessing your data outside of the SMS Administrator console.

So just a couple of slides on using the WBEM ODBC driver. It requires the WBEM SDK. The WBEM SDK is automatically installed with the SMS Administrator console. So if you installed the SMS Administrator console on a site server or on another Windows NT computer or a Windows 2000 computer, then you automatically have the WBEM SDK. If you want to install it on another computer, you can just run Wbemsdk.exe from the SMS 2.0 CD. So find Wbemsdk.exe in the Smssetup\I386 directory, and that will install the WBEM ODBC driver for you.

For the next three slides (21, 22, 23), I'm just going to real quickly run through example ways on how you could use Microsoft Access to access SMS data. The three different options are creating links to SMS data, creating tables to import SMS data, and creating SQL pass-through queries through Access. And I'll go through each of those quickly on the next three slides.

The key for each of these is when you open your data source. You select WBEM source during your data access. So whatever you're specifying for the file to open, or your Get External Data option, you specify WBEM Source and then specify your site server name. You do a double backslash site server (\\siteserver), and then the site server will tell that utility, in this case Microsoft Access, where the SMS Provider resides.

I'm just going to go through these fairly quickly for you. The first option is creating links to the SMS data using Microsoft Access. You could use other utilities and applications, but it's fairly commonly used. The advantage of creating links to SMS data is that the data is up to date. So anytime you refresh that link, you're looking at the current data from the SMS database.

The disadvantage, however, is that you cannot modify that data that resides in Access. So that data is actually pointing back to the SQL Server database through the SMS Provider, and you can't modify that data. So I'll give you the commands on how to set that up. On the File menu in Access, you point to Get External Data, then click Link Tables. Then you go to the WBEM source of \\siteserver. That will connect you to the site server's provider. Then you expand out \\siteserver\sms\site_sitecode.

Then you select the appropriate table from the SMS site database, and then you'll be asked to select a unique identifier, kind of a key to set for that data itself. And then that will create a link for you for that table.

The next option is to create tables by importing SMS data. The advantage of this operation is that data modifications of the data that you import are possible, but not modifying data in the SMS database and SQL again, only data in Access itself. The disadvantage is that data is not current. It's a snapshot of the data at the time you did the importing. So again, the path there, how you get there is in Microsoft Access. You go to the File menu, click Get External Data, then click Import. Again, you connect to your WBEM source for your site server, then expand out \\Root\SMS\site_sitecode. And then select the table from the SMS site database itself.

The next method is by creating SQL pass-through queries. SQL pass-through queries have the advantage because they're very fast. It bypasses the Jet engine of Access and goes directly to SQL. The disadvantage again is that you're going directly to SQL, so no modification of the data is available. So in Access, on the Insert menu, you go Query, and then select Design View. Then on the Query menu, you point to SQL Specific, and click Pass-Through. Then again you connect to your WBEM source. You build whatever the appropriate query is you want, such as SELECT * FROM SMS_COLLECTION, and then run the query. And it will be running the query directly from Access through the SMS Provider through to the SQL Server database. So those are three different ways of using Access to access data from the Microsoft database.

Okay, the last part of our discussion will be on troubleshooting. How can you troubleshoot some of the issues that you have with the SMS Provider and Access? So the first thing is the SMS Administrator console itself. So the scenario is, you're trying to launch off the SMS Administrator console and it responds with a connection failed error. So it was not able to connect with your site database. What are the different things you troubleshoot here?

First thing is you verify that Windows Management is running. The SMS Administrator console uses the WMI Provider, SMS Provider through WMI, so it requires Windows Management running. So make sure it's running. It also requires that SQL Server is running, so make sure your MSSQLServer Service is running. Verify that the user you're logging on as has provider permissions. So make sure that user is either added to the SMS Administrators local group on the site server and the remote SQL Server, if it's separate. Or you manually use Wbemperm or WMI Control and give that user Execute Methods and Schema Access Level of Write Instance rights to the provider.

Then you can go ahead and verify or test your access through some other utility, like WBEMTest or CIM Studio. And I'll talk about those in the next couple of slides for you. Test from another SMS Administrator console. So if one console doesn't work, try from another Administrator console. Go directly to the site server and try running that same operation from the site server and see if you can connect.

The next bullet says, delete the repository files. And this is something that you need to be very, very careful of. It's not as important on a Windows NT 4.0 platform, but on Windows 2000, definitely. And that is, deleting the repository files are kind of like the last resort, because if you delete the repository files, any other applications that rely on data in that repository will now not work, because you've just removed all their data. However, it has solved some issues with SMS in the past, and sometimes, if you talk to PSS, they might have you remove your repository.

So basically the steps would be to stop Windows Management, the service. Delete the Systemroot\System32\Wbem\Repository directory (there are a couple of files in there), and just restart Windows Management. And that will re-create a CIM repository, and it will also recompile all the SMS MOFs, because they all have an option called AutoRecovery Set; so it will just automatically re-create the MOFs in there, as far as database structure and any appropriate SMS data.

Running upgrades from the SMS 2.0 SP2 CDs is a viable option, because that helps you reinstall the SMS Provider. Running a site reset does not reinstall the Provider, so that won't help you out; so you need to run the Upgrade option even if you're already running SP2; running the upgrade option again will reinstall the SMS Provider, which generally fixes any provider problems.

The next slide just shows you a utility called WBEMTest. WBEMTest is a utility that's nice to use, and that allows you to connect directly to the SMS data through the SMS Provider. And it is installed automatically when you install WMI, so it's local on all your Win32 clients and your site server and so on, so it's a nice utility to use.

The next slide will talk about how you would use WBEMTest. So to test your connectivity issues with the SMS Provider, you'd want to connect through WBEMTest to whatever your provider computer name is, either the site server or the SQL Server, to the root SMS name space. So an example here where you might need to use this is, finding out what name space the SMS Provider is trying to connect to. You can connect to the root SMS name space and that will let you see what site code your site is looking at. If everything is proper, you can connect to \\Providercomputer\Root\Sms\Site_sitecode; that will let you connect directly to the SMS data.

Now, you can use WBEMTest or the next utility at the bottom of the slide called CIM Studio, and connect up to the \Root\Sms\Site_sitecode_name space, and you can actually see data. Go out there and look at the instances and see instance data like Collections, then the issue is not a SQL Server issue, it's not an SMS Provider issue, because you're going through those utilities to get that data. If you don't like to use WBEMTest because it's not very fancy, an alternate would be to use CIM Studio. That's a graphical interface that gives you much better relationship views of the data inside the CIM repository and the SMS Provider. It's available from the Web location I've listed there: http://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/MSDN-FILES/028/000/015/topic.xml. And from there, you can install the WMI SDK, which will include the CIM Studio.

The next slide shows you a picture, a screen shot, of CIM Studio. So it's a much easier way of accessing your SMS data, provided you don't mind installing the WMI SDK, which is where you get this. It's a free utility available on that Web site, so you don't have to worry about any costs involved; just download and install it, and then you can use this to access your data. And you can see it expose your data in an easier to use fashion than does WBEMTest.

Regardless of which one of these utilities you use, either WBEMTest or CIM Studio, one of the things you might have to verify is that you don't have DCOM issues when you're having SMS Provider issues. So if you can't get to your data at all, you can't connect to the name spaces or you can't get to any instance data through the SMS Provider, either through WBEMTest or CIM Studio, it could be a DCOM issue. WMI, or Windows Management, uses DCOM. And by default, your permissions are enabled for DCOM, so you should be okay. However, we've had some customers who have gone in there and changed their DCOM permissions, so that's caused some issues.

So if your WMI connections don't work, run Dcomcnfg. And then on the Default Properties page, verify that your Authentication Level is set to Connect, and that your Impersonation Level is set to Identify. Then, on the Default Protocol page, verify that Connection-oriented TCP/IP is at the top of the list. This is especially important if you have a Windows 2000 SMS Administrator console connecting to a Windows NT 4.0 site server. By default, Windows NT 4.0 doesn't always put Connection-oriented TCP/IP at the top where Windows 2000 is using that. So you need to just rearrange that. Put Connection-oriented TCP/IP at the top of the list on Windows NT 4.0 and your Windows 2000 Administrator console should be able to connect. This is documented in Q242022 (http://support.microsoft.com/support/kb/articles/Q242/0/22.asp).

Okay, now if you want to do some troubleshooting. So again the scenario is you try and connect to your Administrator console and it fails on you. A couple things to check before we end our presentation. First thing is, how does the Administrator console figure out where to go? So that's a registry entry. So the Administrator console looks at this local registry, HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\AdminUI\Connection. And that will list the site server name. So the Administrator console is going to go to this computer, assuming that the SMS Provider is there and that's the Administrator console. So it's going to make a call to that computer, asking that computer where the SMS Provider is installed.

Then, when the site server tells it where the provider is installed, either locally or on the SQL Server, then the SMS Administrator console is going to connect to \\providercomputer\root\sms, and then try and go to the specific name space for that site code. If you want to try and verify your name space, you can manually connect to the \\Providercomputer\Root\Sms_name_space, and then you can run a query inside WBEMTest or CIM Studio. The query would be

Run that query, and then that will return to you the site code the provider is trying to gain access to.

There are a couple instances where this fails. The most common one is, if you've installed an SMS site, it's been working properly, you deinstall that site, then you reinstall with the new site code. If that new site code is alphabetically later in the list than the original site code, you won't connect to your new site. You'll try and connect to the old site. Because when you deinstall SMS, it doesn't remove the provider location from that site code from the provider through WMI, so it tries to connect to the one earliest alphabetically.

So if you go to this location through the query and just delete the wrong site code – so if it comes back with two site codes, it will say SMS\site_site code. Just delete the instance that has the bad site code or the old one, and then you'll be able to connect fine. There are a couple other name spaces that are worthwhile, like \Root\Cimv2, which is a CIM name space; and \Root\Sms\Inv_schema, that's our inventory schema as designated by the Sms_def.mof.

From there, you can verify that you have access to the provider and to your SQL Server data that relies on the SMS security rights. So you always when you want to access the SMS data, you always want to go through the SMS Provider, never go directly to SQL Server. If you go directly to SQL, you're bypassing all the security and you have a possibility of corrupting your data. So you connect to \\Providercomputer\Root\Sms\Site_sitecode. Then you can do an Enum Classes, which is one of the options of WBEMTest, do it recursively, and then view Instance data. And if you can view Instance data for one of those classes, then you're seeing the data directly from SQL Server through the SMS Provider, so you know the problem is not a SQL issue, it's not an SMS Provider issue. Most likely it's an Administrator console issue. So do an upgrade again, and that will reinstall everything properly. Or you can do a query such as

and if you can see data, you're all set and are retrieving the data from SQL. And if that works fine, then your problem is like an Administrator console failure, and an upgrade will fix that issue.

Another thing that has had to happen a couple of times as far as fixing errors is fixing a corrupted Smsprov.mof. And we've had a couple of cases where customers' .mof files have been corrupted and this caused a failure of connecting. So first off, verify your normal sources, Windows Management is running, SQL Server is running, the user has permissions to the SMS Administrator console and the SMS Administrators local group.

If that all works and you can't access your data through WBEMTest or CIM Studio, it might be your Smsprov.mof is corrupted. So to fix that, what you want to do is, go to your \SMS\Bin\I386 directory, look at your Smsprov.mof, and see if it looks corrupted. It's an ASCII text file, so you should be able to read things in it. If it's corrupted, then that's what your problem is.

So you can create a brand-new one from your SMS 2.0 CD and the \Smssetup\Bin\I386 directory. It's named _ Smsprov.mof. Just change it to Smsprov.mof. Change any references inside the text file that say replace provider code or site server name here. So just search for REPLACE in uppercase characters. Anytime you find that, change it to the appropriate code they want. Then take that modified .mof and drop it into the systemroot\System32\Wbem\Mofs directory. And then that will recompile that .mof for you.

There's another .mof file that might be appropriate called Smsstub.mof, and that's appropriate if your provider is not on your site server. And again, you would just modify that .mof file, specifying your provider computer, and then drop it in that same location and it will be recompiled automatically.

And then lastly, your SMS Provider connection issues, prior to Service Pack 2, there was a limit on the number of Administrator consoles that connect to the SMS database simultaneously. And what would happen is that the SMS Provider would basically use two connections per Administrator console, sometimes more, depending on what operations were being performed in the Administrator console. And prior to Service Pack 2, those connections were not shared or released when you closed your Administrator console. So that would cause a lack of available connections, so sometimes you had to go out and increase those connections.

And that again was by modifying the \SMS\Bin\I386\Smsprov.mof. And there was a code in there called MaxSQLConnections. It defaulted to 60, which meant about 30 consoles. So you'd have to increase that, then recompile the .mof. Service Pack 2 fixes that, so there's no longer a need to modify that code any longer. So you don't have to do that in Service Pack 2, but if you're still running Service Pack 1, you may have to do that.

Okay. And lastly is a quick summary, just a recap of what we talked about here, because I know we're running late. WBEM is a management initiative for common data sources for management data. WMI is Microsoft's implementation of WBEM. SMS 2.0 uses WMI for many different processes; primarily anything in the Administrator console uses WMI. SMS data can be accessed from within the SMS Administrator console. Can be accessed outside of the console using WMI, using VBA applications using WMI, or the WBEM ODBC. In the future, we'll have some SQL views that will be released either to the Web or in Service Pack 3 or the next resource kit; we're not sure yet.

Troubleshooting WMI issues usually involves using some utilities like WBEMTest or CIM Studio, verifying your services are running, that your user has appropriate permissions, and that your provider .mof files aren't corrupted. And again, you have to rely on DCOM security as well as Windows NT security and WMI security to gain access to your data.

And that will do it, and we'll turn it back to Heidi now.

Heidi: Excellent, thank you, Wally. It is time to move on to the Q&A portion of this Support WebCast. A couple of notes before we do so. If some of the details on the PowerPoint^® slides were a little bit difficult to view in your browser, or you'd simply like to have a copy of those slides, be sure to download the file from our Support Web site. The URL is http://support.microsoft.com/webcasts/. That's the location where you can get information on all upcoming Support WebCasts and access the archives from all of our past sessions.

In addition, the transcript will be available within about three weeks of the live session; we also have the PowerPoint slides and on-demand streaming media is made available within about eight hours of the live session.

We have had several questions submitted, so we're going to go ahead and get started. The first question is: I am developing an application in VB that prescreens targeted distribution. My question is, does the SMS Client store the GUID information in WBEM, and is there a way to gather this information from the client through a WMI query?

Wally: No. The SMS Client does not store its local GUID information in WMI. It stores it in the registry, so it is in the registry, and you could use the Registry Provider to query the information from the registry. However, it's stored in the SQL database on the SQL Server, and you can query it through a call there; but directly on the client, no, that information is not stored. The SMS unique identifier or the GUID.

Heidi: Okay, next question: Is there any Java support for WBEM?

Wally: Yes. If you look back at my first slide that showed the "What is the WBEM Initiative," which is slide 4, Java was listed at the top for one of those programming interfaces as a management application to the CIM repository through WBEM.

Heidi: Okay. Next question: I want to install the WBEM ODBC driver on a stand-alone PC that is not an SMS 2.0 Client and does not have the SMS Administrator console. Can this be done? Where do I get the WBEM driver and how do I install it?

Wally: It depends on what version your Client is. If it's a Windows NT 4.0 or other platform like that, then you can run Wbemsdk.exe from the SMS 2.0 CD. On the SMS 2.0 CD in the \Smssetup\Bin\I386 directory, you should run Smssdk.exe, and that will install the appropriate code you need. If it's Windows 2000 on a Windows 2000 system and you upgraded, then it removed that WBEM ODBC driver that used to be there before and you can do the same thing. Just run Wbemsdk and use the /server switch: wbemsdk.exe /server; and you can put the /s switch to make it silent (wbemsdk.exe /server /s) and that will reinstall the WBEM ODBC driver for you.

Heidi: Excellent. Before we go on to the next question, I do want to encourage all of you to submit some feedback to us. We're very interested in your feedback regarding the Support WebCast program overall. If you have any comments about this session, or you have any comments about sessions you'd like to see in the future, we're very interested in that feedback. We do have about one System's Management Server Support WebCast every month, so do stay tuned, if you're interested in visiting and seeing more of these sessions.

Okay. The next question is: Is DMI a WMI Provider? If so, are there any white papers on how to get the DMI information into the SMS database?

Wally: DMI itself is not a WMI Provider. However, I've heard of some of the third parties writing DMI providers for WBEM. So technically DMI is a separate thing from DMTF. So from the distributive management task force, DMI is something that was a little bit older, and the CIM schema, WBEM is the newer initiative. But I've heard of people creating DMI providers to write data to WMI. I've not heard of any white papers on it, per se. I know there's a white paper on the SMS Web site (http://www.microsoft.com/smsmgmt/) about accessing other data using other utilities to provide data to SMS, like querying your serial number and so on, and I think it talks in there about DMI. But technically, no, DMI is not a WMI Provider.

Heidi: Okay. Moving right along: Is it true that any third-party application needs to leverage COM to access WMI services? Like how could a CIM-aware client running on UNIX get SMS/CIM-compliant data?

Wally: WMI does run on top of DCOM, and DCOM obviously has COM interfaces. So, yes, you need COM and DCOM support to use WMI. And that is why we don't use WMI on our 16-bit platforms, because there is no COM and DCOM support for the 16-bit platforms like Windows^® for Workgroups and Windows^® 3.1 and so on. So it's just the 32-bit platforms. So yes, you would need to have a COM and DCOM interface, because WMI does run on top of DCOM. So a CIM-aware client on a UNIX system, unless they had COM and DCOM support, I don't know of any way you would be able to use that, because you do have to have that support.

Heidi: Okay. Next in line: Does Windows NT 4.0 have to be at SP 4.0 to support WMI at any version?

Wally: No. SMS 2.0 supports Windows NT 4.0 clients without any service pack on them at all, and we will go ahead and install WMI 1.1, if it's not already there. It's just that Windows NT 4.0 Service Pack 4, that CD did have, in one of the subdirectories on that CD, did have WMI code on the CD itself. However, we do support "vanilla" Windows NT 4.0 itself for WMI.

Heidi: Okay. With regard to migrating SMS 2.0 clients to WMI 1.5, if we update our SMS 2.0 primary site server, will it automatically propagate to all secondary servers and clients?

Wally: No. There is no automated way of making SMS supply WMI 1.5 to all your site systems and clients. Even though Service Pack 2 does support WMI 1.5, it doesn't provide WMI 1.5. So if you upgrade a site server to WMI 1.5 that will not propagate out to any other site system. It would just be like upgrading Word or Excel to a new version, or Office 2000. It's not going to push Office 2000 out to all your systems that already have Office 97 installed. Now, you could use software distribution techniques of SMS to distribute WMI 1.5 out to all your clients, but automatically within SMS, no, it's not going to happen just by upgrading your site server.

Heidi: Okay. Next in line: I'm looking for a sample WMI script because I'd like to do remote control, allow user to remote control without MMC available.

Wally: You don't need a script, because there's already a utility built in for you. So if you go to your \SMS\Bin\I386 directory on your site server, there's a utility out there called Remote.exe. You can just run Remote.exe and that does not require the MMC itself. So it's a command-line interface to perform a remote control. Now, you do have to have permissions to run remote control; you have to have permissions to the SMS database so we can validate that you have permission to do remote control on this client and use remote tools and so on. But that is a command-line version to run remote control without the MMC.

Heidi: Okay. The next question is: How can I determine if my PC BIOS supports SMBios 2.1?

Wally: That is a very good question. And I've got a system here I can look at and see. The only way I know is there was something in the registry that was written SMBios, and if I don't find it quickly here, then we'll just have to check on it later on for you. But – yes, I don't see it in the registry. There's someplace in the registry where information is written for SMBios, and I can't find it off the top of my head. So I'll have to do some research for you and see if I can find that.

Heidi: Okay. Well, what we'll do is, as long as the individual who submitted that question included your e-mail alias when you logged on, we have that, and we have a note of the question here. We'll go ahead and research that, find an answer, and send that answer out to you. For anybody else who's interested in that response, we will include that in the transcript. Once again, the transcripts do take about three weeks to publish to the Support WebCast site.

Follow-up answer: These are some fields in Win32_BIOS

which might help if you have WMI, but otherwise I don't know.

The next question is: You mentioned that the serial number and manufacturer information can be retrieved if WMI 1.5 and SMBios 2.1 exist. What about monitor serial number, model and manufacturer?

Wally: I'm not aware of that being provided anywhere locally. If there's some common specification for that, then there's an option for it; but I've never heard of monitor information being specified in a central location like PC BIOS, where it is for the computer serial number and manufacturer information. So I've not heard that requested at all or even being an option. So that would be something we'd have to find out from the WMI folks to see if there's any way to do that. But to my knowledge, there's no simple repository or central storage location for that, so it would be very hard to pull that out.

Heidi: Okay. Next in line: Will SMS slipstream the current WMI and DCOM into an SMS hotfix anytime in the future?

Wally: Into a hotfix? Most likely not. However, in a future version of SMS, we probably will have WMI 1.5 or whatever will be current at that point in time and DCOM there as well. The reason we didn't for Service Pack 2, is just because it would have meant doing a lot more testing with Service Pack 2 and changing the CD and a lot of other issues, and changing the minimum requirements for the code. So it meant a lot of other issues with supporting Windows 95 clients. So currently, no, and we will look at that in the future when we come up with another release of SMS.

Heidi: Okay. Terrific. The next question is: How does one determine what to delete to avoid causing problems to the OS beyond SMS Console?

Wally: Boy, I have no idea what you're asking there, unless it's in reference to — oh, I mentioned talking about the CIM repository. And if you remove the CIM repository, we mentioned that's one of the ways we've had to do some troubleshooting at some customer sites. You won't know necessarily what other utilities are using the CIM repository. On Windows 2000, just don't do it, because a lot of things in Windows 2000 are using the CIM repository. And use the other methods I talked about, like recompiling the Smsprov.mof or running the upgrade utility to reinstall the provider. Outside of that, there's not much way of knowing without having other utilities and just stopping Windows Management and see if those utilities fail to retrieve their data.

Heidi: Okay. Next in line: With regard to bypassing WMI, if you run a DTS job to extract the SMS data, bypassing WMI, are these SQL SMS views available?

Wally: Oh, you're talking about stuff that we don't want you to do. We don't want you to bypass the provider and WMI to gain access to SQL data, because now you're bypassing all of our security systems. So that is not recommended at all. So right now, the currently recommended method is by going through the provider and WMI, accessing your SQL data. In the near-term future, which I can't qualify any better than that what "near term" is, there will be a release of SQL Views for SMS 2.0, and at that point in time, that will become the recommended method because of the speed of doing the SQL Views. And these SQL Views will be much more comprehensive in the amount of data they support and the speed than they were in SMS 1.2. But we're not sure whether that's going to be like the next resource kit or wait for the next release of SMS. We're still debating on that stuff right now. But there will be SQL Views available in the future. They're not there right now unless you upgraded from SMS 1.2 to 2.0.

Heidi: Okay, excellent. So just to be clear, what this customer is asking for is something that we don't recommend and we don't support; is that correct, Wally?

Wally: We don't recommend you bypassing WMI at all to get access to your SQL data, no.

Heidi: Okay. Next question: Is WMI upgrade recommended for Windows 9x clients? SP2 is installing without issue, and most of our older PC's don't support SMBios 2.1. Are there any other reasons to upgrade?

Wally: If your hardware doesn't support SMBios 2.1, and you're not having the Windows 95 lockup issues that were resolved with the new WMI code, then no, there's not really a compelling reason to upgrade from 1.1 to 1.5. It's primarily, in that case, if you want to have a standardized platform so that you don't have to worry about, okay, is this an issue with 1.1 only, or is it because of 1.5; does it work on some systems and not other systems? So having a standardized platform can mean something to a lot of customers. So in that case, then sure, go ahead and upgrade. Otherwise, if that's not a big issue for you and your hardware is not locking up and your hardware doesn't support SMBios 2.1 anyway then, no, there's no real reason to do so.

Heidi: Okay. With regard to slide 26, just where does one enter and execute a test query in WBEMTest?

Wally: You would launch off WBEMTest, and when WBEMTest is opened up, then you would go ahead and go to the Connect option. You connect up to the \\Root\SMS\site_sitecode name space. After you're connected there, then you're back at the main menu or the main window, basically the only window, for WBEMTest and just click the Query button. So if you click the Query button, then you type your query and click the Apply button, and provided you've given it the correct name space and the correct class information, it should come back with the appropriate data for you.

Heidi: Excellent. Next in line: Does a CIM repository or SMS Provider use XML?

Wally: Well, the CIM repository doesn't do anything. Again, it's just a repository. The provider uses DCOM and named pipe stuff, so I don't think it uses any XML calls, although I'm not a big XML person. So I'd have to verify that for sure, but I don't think so at this point. Maybe in future stuff. And there may be a way to write a utility using XML to gain access to the CIM repository. Again, that's getting into programming, which is beyond my knowledge level.

Heidi: Okay. Well, we'll certainly have a go at looking into that and see if we can come up with an answer for you.

(Editor's note: After further investigation, we found that although it does not currently, that capability is being investigated for a future release.)

I do notice that several people have submitted some feedback, so I wanted to quickly say thank you to all of you who have taken the time to do that. We do appreciate that feedback, so for those of you who haven't had an opportunity yet, you can use the alias, feedback@microsoft.com. If you do use that alias, be sure to include "Support WebCast" in the subject line.

Okay, next question: Can WMI 1.5 be installed on a Windows 98 machine or PC that is ghosted for images, or is it unique to each PC?

Wally: Boy, since Microsoft doesn't officially support ghosting at all. I know everybody in the world does it, but as far as creating computers by ghosting, I don't think there's anything specific to an individual computer stored in the CIM repository or in WMI, because like we don't store the GUID for the SMS unique ID. Generally the problem is the SMS data. So if you're ghosting with an SMS Client on there, the problem comes in to the fact that you've got the SMS Client, the unique ID and its GUID associated with the database and you're ghosting that and reimaging that. So to my knowledge, there's nothing specific that would be a problem with ghosting WMI itself. It's really when you get the SMS Client on top of it, you don't want to ghost the SMS Client the way it sits.

Heidi: Okay, next in line: Are you familiar with the product TrackIt? It's a third-party application, and if you are familiar with it, do you know if it uses WMI?

Wally: I am not familiar with it, so I have absolutely no idea. If it's a fairly recent application and is trying to do any kind of management data, then it may very well. If it's an older application, or it's not there to provide management data, then most likely not.

Heidi: Okay. And if you do want some more information, I would encourage you to go specifically to that company.

Okay, the next question: Would using WMI give you more or less information than say Dell DMI, such as serial numbers, etc. for Windows NT 4.0 clients?

Wally: It depends on what the DMI agent is providing for you. WMI is such a rich way of gathering and maintaining data, that it can contain tons of different data outside of what just a DMI agent itself might provide for you. So off the top of my head, I would say, yes, WMI can certainly give you a lot more information than just DMI. Now, I know some of the DMI agents will do some hardware inventory as well. So you may have some commonality there or some overlap, but it just depends on what their agent is doing and what your needs are. But most likely, you have many more opportunities with WMI because of the fact that it's an industry-wide initiative, not just a single DMI agent by a single manufacturer and what they might want to expose.

Heidi: Next in line: Does SMS use WMI for the software inventory?

Wally: No. Software inventory is done by opening up each individual file header of the type of files you're scanning, so it does not use WMI at all. Now, the data is stored in the SQL database, so you can retrieve it through WMI, but on a client itself, hardware inventory does use WMI to perform the inventory; software inventory does not.

Heidi: Okay. Will SMS slipstream the most recent versions of WMI and COM into its client installs?

Wally: Very similar to the question earlier. At some point in the future, we will upgrade our WMI implementation for clients. However, when and at what point that's going to take place, we haven't made that determination yet. It depends on what else is more important; it depends on other factors, such as additional testing bundles and so on. So we do plan on doing that in the future, but I don't have a timetable for you.

Heidi: Okay, moving on to the next question: Would repackaging an SMS Installer of DCOM and WMI be a good idea?

Wally: Repackage an SMS Installer of DCOM and WMI implementation. If the client doesn't already have an existing implementation of DCOM and WMI there, where you might have DLLs that are in use, not being able to be overwritten by the Installer until the next reboot, that may be something you could do. But their installs are fairly simple. They can both be command-line scripted and run silently, so it's like dcom95.exe /s, and wmi95.exe /s. So they're very simple to be done, and you could use SMS Software Distribution to push those out. If that's the case, that they are run as easily as from what I've seen, then I would just do that and not to any SMS Installer repackaging. Because you never can tell the differences in individual computers, because not every computer is the same as you think it's going to be, in most cases. So having them installed specifically on each individual client would be the best bet, to make sure that they did get installed and upgraded properly.

Heidi: Okay. The next question is: Are there any advantages to upgrading all of my SMS site systems to WMI 1.5?

Wally: Very similar to the previous question. Again, it's primarily, if your hardware can support SMBios 2.1. So by upgrading to WMI 1.5 you get your serial number and PC manufacturer data directly in hardware inventory, that's great. That may be a compelling reason for you. There certainly are enhancements to WMI 1.5; however, SMS doesn't necessarily expose those or take advantage of those fully, other than like the serial number thing. So it would be more just a commonality.

If, in your corporate environment you want to have a common base, a common infrastructure and all the same support utilities, then yes, go ahead and upgrade. If that's not important to you and you're not worried about the hardware inventory stuff, then I don't know of another compelling reason to say "Yes, go ahead and upgrade," unless you just always want to be on the cutting edge and always have the latest and greatest.

Heidi: Okay. The next question borders on technical support; I'm going to go ahead and read it anyway. However, if that is something that needs one-on-one support, we're going to need to point you back to Product Support Services. During a recent deployment, we installed the resource kit which installed WMI, prior to SMS. The SMS install didn't replace the WMI install, and caused an Mmdexe failure when trying to use the SMS snap-in. What is the workaround for this?

That sounds like it is a Product Support question, but do you know anything off the top about that, Wally?

Wally: The only thing I could think of is if you're running Windows NT 4.0 with Service Pack 5, there was an issue where you actually had to get a different WMI bundle, WBEM SDK, to support that in Service Pack 5, depending on the version of SMS you're installing. Other than that, I've not heard of any issue at all. And again, if it's installing WMI from the resource kit (I don't know which resource kit), but it's installing WMI from the resource kit, it should be the same version, probably the 6.98 build of WMI 1.1, so it shouldn't matter. So it may just be a matter of doing that upgrade process, running the upgrade from the SMS CD to reinstall the provider may be all you need. Or maybe one of these other troubleshooting things we talked about during the session.

Heidi: Okay, we are getting down to the end here. The next question is: If I want to create a third-party application that will create DDRs containing information it has about clients, is that machine running on my custom application only required to have WMI installed to create DDRs to send to the SMS site server? Or does it need the whole SMS Client to create those DDRs?

Wally: It actually doesn't need any of those. You can use any utility you want to write a DDR, provided you know the DDR format, and you don't need DCOM or WMI or anything else to do that. So you can just use a utility, there's a couple in the resource kit, that will create DDRs for you, and they don't use those. They create the appropriate file and then just copy it to either a client access point, DDR.box directory, or to the site server's DDM.box directory. So you don't need to have any of that underlying support of the full SMS Client or WMI support to create a DDR at all.

Heidi: Great. Next in line: What is Microsoft's plan for SMS in light of Windows 2000 having SMS features in it?

Wally: What I would do is point you back to, I believe it was the May Support WebCast we did, where we had a Support WebCast that talked about integration of Windows 2000 and SMS 2.0, and did a comparison between the management features of Windows 2000 and the management features of SMS. And you'll find that SMS has a lot of additional management features that Windows 2000 cannot touch, or it can take what Windows 2000 can do, such as software distribution, and give you many more administrative options and control over those features. So I'd go back and look at that, as far as what the comparison is between the two.

As far as futures, there is future for SMS. I can't give you any details today, but there is future for SMS. It is not dying. The Microsoft philosophy is to always have a management product that will add upon what the operating system gives you. So even though Windows 2000 has some management features, there is going to be an SMS or some management product that will add additional functionality and features to what the OS has. So there is life for SMS.

Heidi: Okay. And for anybody who wants to view that on-demand Support WebCast, the link is http://support.microsoft.com/webcasts/. You scroll down to the bottom of that page and select Past WebCasts. You'll see a Technology link for Systems Management Server, and all of our archives are saved there by date, so the most recent ones at the top.

The next question, and at this time last question in the queue is: What are the risks inherent in using third-party SMS reporting tools that only use SQL Query directly against the SMS data versus through WMI?

Wally: The two downsides are, first off, you're not using any security, so you're bypassing all the security environment of SMS. So let's say you're the person that runs the query and you know who you are and you know what your permissions are; you know what you can do, and you're smart enough to know what you are doing. Let's say somebody else happens to gain access to this utility that you're running, or this query you're writing, and they are not a person that should be accessing the SMS data. So now they're out there going directly to SQL Server and unless SQL Server security blocks them out, SMS is not going to, because you're not going through the provider, so you're going directly to SQL, and you lose your security there.

And the second downside is that you can go out there and modify data. And modifying data directly outside SMS is not a good thing, because you are bypassing the security, and secondly, you never know when SMS is going to change the schema of that format. In every version of SMS we've changed the database layout, our schema inside SQL. So writing your own utilities to pull data directly from a specific table, that might work for this version of SMS, but when 2.x comes out or 3.0 or whatever the future may be, that may not be applicable anymore, because we may have changed something on you. So going through the SMS Provider, you're guaranteed the data is going to be there, because we'll always expose those classes for you through the provider and through WMI. And you have the security layer so that you're guaranteed that whoever has logged on, they either can or cannot perform that operation, depending upon the security rights that are specified in the database through the SMS security rights, as well as the SMS Provider. So those are the two biggest reasons: security as well as you're guaranteeing that the data is not being modified that way.

Heidi: Okay. And it looks like we have just a couple of additional questions slipped in at the last minute, so we'll go ahead and address them. They both seem to be a little bit more marketing-related, but we'll at least touch on them. The first one is: What is the status on a Microsoft Web-based reporting tool becoming available? Are you able to comment on that at all, Wally?

Wally: We do have a Web-based reporting tool coming out that will be in lieu of, or in addition to, the Crystal Reports utility we have now. We're working on that. We're getting things going. That will be released at some point in the future. Again, we don't have a specific date in mind of when it will be available or what the release mechanism is going to be. It will certainly be in the next release of SMS, when the next version of SMS comes out, but we don't know if it will be available prior to that or not. So yes, we are working on that.

Heidi: Okay. Next question is: You mentioned a commitment to an SMS-type product by Microsoft. Does this mean an SMS 3.0, or will there be a new tool in the future?

Wally: As of today, we're still planning on having SMS. You never can tell what Marketing may do as far as changing product names, so they may not want to call it SMS in the future. But as of today, there are future versions of SMS in the works.

Heidi: Okay. The next question is: How can you tell what version of the WMI client has been installed?

Wally: A couple different ways. If it is an SMS Client itself, you can go to Control Panel. You can go to the Systems Management program in Control Panel. Then you can go to the Components tab, and at the bottom of the Components tab, it will give you Windows Management, and it will tell you what version of Windows Management is installed. For Windows 2000, it will say 1085; for non-Windows 2000 boxes, or for WMI 1.1, it will say 698.

If it's not necessarily an SMS Client or you just want to view separately, you can go to the registry, HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM. And then under the WBEM key, you'll have a build number, and the build number will tell you what version of WBEM is installed there. And again in my case, I'm on a Windows 2000 box, which is build 1085. And that would say 698 if it was just version 1.1

Heidi: Okay. And the last question of the day: Is there one comprehensive Microsoft white paper for WMI technologies?

Wally: Probably not. I know of a number of different white papers available; most of them are on the management Web site, so http://www.microsoft.com/ntserver/management/. There's a number of different white papers up there, so I'm not aware of a single white paper that tells you everything you want to know about WMI, because it's probably more than what you want to know, or it certainly won't hit everything that everybody wants to know. So I'm not aware of a single one. There are a number of them up on the Web site, though.

Heidi: Okay. And with that question answered, we're going to go ahead and wrap up our Support WebCast for today. I want to thank all of you for joining us and I want to thank Wally for once again participating. As a reminder, we do encourage you to send any feedback you have and use the feedback@microsoft.com alias. Once again, if you use that alias, be sure to include "Support WebCast" in the subject line. We do hope you found this content valuable, and find time to join us again in the near future. Have a great day, and good-bye.