Previous Section
 < Day Day Up > 
Next Section


Hardware Inventory

The Hardware Inventory Client Agent (Inventory Agent on the Advanced Client) collects a broad assortment of hardware properties from the client. For the purposes of this discussion, I'll refer to the client agent for both client types as Hardware Inventory Client Agent, and I'll make distinctions between the behaviors of each when necessary.

When we think of hardware inventory, most of us, especially those of us familiar with earlier versions of SMS, think of the basic data: disk information such as space used and space available; memory, video, processor, and operating system data; and MAC, IP, and subnet addresses. To be sure, some of this hardware information sounds a lot like the discovery data stored in the discovery data records (DDRs) we looked at in Chapter 7, 'Resource Discovery.' However, hardware inventory is nothing like discovery data.

In fact, a great deal more hardware information is collected than just these basics. The hardware inventory process is designed to query the Windows Management Instrumentation (WMI) that's part of the SMS client installation to obtain its data. Windows Management itself can expose a vast amount of information about the client, obtaining information from various providers, including the WIN32 subsystem of Windows, the registry, the computer's basic input/ output system (BIOS), and so on.

SMS uses an inventory collection file to determine how much information is collected from WMI classes and queries for approximately 1,500 different hardware properties. The inventory collection file is a Managed Object Format (MOF) file and is named SMS_def.mof. The master version of this file is stored on the SMS site server. The amount of data reported about each of the basic hardware components is considerable and can actually be extended further. For example, you could report on program groups created on the client, or network printer connections, or account information such as the user's full name or security ID (SID). This extension is done by modifying the SMS_def.mof file to include additional WMI classes. We'll talk more about this file later in this chapter.

You can also add data to the inventory data normally collected. For example, you could add asset-related information, or contact names, and so on. You accomplish this reporting through the creation of text files known as Management Information Format (MIF) files that you present to SMS as an update to the database record for a specific SMS client.

If information isn't available directly through the Hardware Inventory Client Agent, you can update client records with your own manually generated data- or even create whole new classes of object types, such as 'multimedia equipment.' Or you can obtain one of several new third-party add-ons to SMS 2003 to obtain data such as OEM-specific DMI-based information. Once hardware inventory has been collected at the client, it's passed on to the client access point (CAP) if the client is a Legacy Client or the management point if the client is an Advanced Client. The CAP or management point, in turn, forwards the hardware inventory to the site server. Hardware inventory is ultimately stored in the SMS site database, so it's important to draw a distinction between primary and secondary site servers. As we saw in Chapter 4, 'Multiple-Site Structures,' the main difference between a primary and a secondary site server is that a primary site server maintains access to an SQL Server database.

In the case of hardware inventory, this doesn't mean that you can't enable the Hardware Inventory Client Agent on a secondary site server for its clients. In fact, you can, and the agent's configuration settings can even be different from the secondary site's parent site. When hardware inventory is passed to the secondary site server, the secondary site server forwards the information to its parent primary site, where it can be added to the SMS database. The Advanced Client will pass its inventory to the management point of the parent site, unless a proxy management point has been installed at the secondary site.

Enabling Hardware Inventory

Let's begin by getting the Hardware Inventory Client Agent enabled and installed on our SMS clients. Then we'll explore how inventory is actually collected. You can enable the Hardware Inventory Client Agent through the SMS Administrator Console. To do so, follow these steps:

  1. Under Site Settings, navigate to the Client Agents folder and expand it.

  2. Right-click Hardware Inventory Client Agent and choose Properties from the context menu to display the Hardware Inventory Client Agent Properties dialog box shown in Figure 9.1.

    Click To expand
    Figure 9.1: The Hardware Inventory Client Agent Properties dialog box.

  3. Select the Enable Hardware Inventory On Clients check box.

  4. The default inventory collection schedule on the client is once a week. With the Simple Schedule option, you can specify collection to run once every 1 to 23 hours, 1 to 31 days, or 1 to 4 weeks. Or you can select Full Schedule and then click the Schedule button to display the Schedule dialog box, shown in Figure 9.2. Here you can designate a more specific start time and recurrence pattern. When you've finished, click OK.

    Click To expand
    Figure 9.2: The Schedule dialog box.

  5. You can modify the default value for the Maximum Custom MIF File Size if you anticipate using custom MIFs larger than 250 KB to append data to the inventory data being collected.

  6. Use the options in the MIF Collection tab shown in Figure 9.3 to identify whether to collect custom MIF files (IDMIF and NOIDMIF) from the Legacy Client and the Advanced Client.

    Click To expand
    Figure 9.3: The Hardware Inventory Client Agent Properties dialog box MIF Collection tab.

  7. Click OK again to begin the site update process.

When you enable the Hardware Inventory Client Agent, you are, of course, making a change to the site properties, and the site's site control file (Sitectrl.ct0) will be updated as a result (as described in Chapter 3, 'Configuring Site Server Properties and Site Systems'). The following three files are written to the SMS\Inboxes\Clicfg.src directory on the site server:

  • Hinv.cfg Contains the Hardware Inventory Client Agent configuration settings

  • Hinv.nal Contains the CAPs from which the Hardware Inventory Client Agent can be installed

  • Hinv.pkg Contains the instructions for installing the Hardware Inventory Client Agent on the client for various platforms

In the same directory, the client offer (.OFR) file for Legacy Clients and the Advanced Client policy is also updated to indicate that the Hardware Inventory Client Agent needs to be installed on all SMS clients for the site. This file is named Cli_xxx.ofr, where xxx represents the client operating system platform. The site server uses the client offer file to notify its clients of any client components that need to be installed, updated, or removed. It's created on the site server and copied to each CAP for the site. The Advanced Client policy acts similarly for Advanced Clients and is propagated to the management point.

The next time the SMS client restarts or at the next client update interval- every 25 hours-the client obtains the updated client component information and the agent is installed. In the case of the Advanced Client, the agent was already installed but not enabled when the Advanced Client software was first installed, so it's simply enabled. At this time, the SMS_def.mof file is compiled into the WMI layer on the client, the agent support files are installed, the hardware inventory log files are updated, and the agent is started. Ten minutes after the Hardware Inventory Client Agent is started, the first complete inventory is collected from the client as specified by the SMS_def.mof file through WMI and is then copied to the CAP.

Client Requirements and Inventory Frequency

A complete default inventory will generate a hardware information file about 200 KB in size. A copy is stored on the client as part of the WMI Common Information Model (CIM) repository. The initial inventory is also passed to the CAP and then to the site server. Subsequent inventory files generally report only changes to the hardware inventory, however, so you can expect a corresponding amount of network traffic associated with the installation (one time), with the first complete inventory (one time), and with subsequent delta inventories (according to your schedule). The delta inventory is an inventory cycle that creates a delta inventory file containing the information that has changed since the previous inventory.

The schedule you specify should reflect the frequency with which you need to collect or update your clients' inventory record. If your clients have fairly standard hardware installations and don't make, or aren't allowed to make, substantial changes on their own, you could collect inventory less frequently-say, once a week or even once a month.

However, if your client computers are volatile regarding hardware changes, you might need to report changes to the inventory more frequently-perhaps once a day or once every 12 hours. The more frequent the inventory, the more potential network traffic will be generated. The Hardware Inventory Client Agent reports inventory regardless of whether a user is actually logged on to the client. If the client isn't currently connected to the network, the agent will still run and store the collected data on the client until the next time the client can connect.

Tip 

The Hardware Inventory Client Agent can be forced to run through Systems Management in the Control Panel. Double-click the Systems Management icon to display the Systems Management Properties dialog box and then select the Components tab. On Legacy Clients, select the Hardware Inventory Agent entry in the Components list and then click the Start Component button. On Advanced Clients, select the Hardware Inventory Cycle in the Actions tab and then click the Initiate Action button.

Caution 

Inventory stored in the SMS database is historical in nature, meaning that it's only as accurate as the last time you collected the inventory record. If your clients are volatile, as described earlier, and you rely on the inventory to identify clients' available disk space for installation applications, you might require an inventory schedule that's more frequent.

Hardware Inventory Collection Process Flow

Now let's explore the hardware inventory collection process in more detail. Recall that the Hardware Inventory Client Agent uses WMI to obtain hardware inventory data about various classes of objects designated in the SMS_def.mof file. When the Hardware Inventory Client Agent is scheduled to run, it reads the SMS_def.mof file and queries the CIM Object Manager component of WMI for the object properties it needs to report on. The CIM Object Manager, in turn, retrieves the current information from the appropriate object providers, such as WIN32, and then passes the data to the Hardware Inventory Client Agent.

The first time the Hardware Inventory Client Agent runs-approximately 10 minutes after its installation-a complete inventory is collected and its history is maintained in the CIM repository on each client. Each subsequent inventory generates a delta file only, detailing only those inventory properties that have changed since the last interval.

At this time, the agent looks for any NOIDMIFs that might reside in the %Windir%\MS\SMS\Noidmifs folder on a Legacy Client or the %Windir%\System32\CCM\Inventory\Noidmifs folder on an Advanced Client. Refer to the section entitled 'MIF Files' later in this chapter for details about MIF files. If the client deems the MIF file to be valid, it's included as part of the inventory file. If not, a Badmifs subfolder is created under the Noidmifs or Idmifs folder, depending on the MIF type, and the invalid file is moved there.

Note 

The Badmifs folder is created only if a bad NOIDMIF or IDMIF is detected. By default, the maximum MIF file size is set to 250 KB, although you can change this value through the Hardware Inventory Client Agent properties described earlier. A NOIDMIF or an IDMIF is considered bad if it exceeds the maximum size or if it can't be parsed successfully because of syntax errors or because, in the case of IDMIFs, it's being used to update the system architecture for an existing client record.

The MIF data is appended to the inventory data already collected and a temporary inventory file is created on the client. The Legacy Client sends the inventory file to the CAP_site\Inventry.box folder on the CAP. The Advanced Client sends the inventory file to the SMS_CCM\Inventory folder on the management point.

Note 

Once the inventory file is copied to the CAP or management point, the temporary inventory files are deleted. This process generally happens in a matter of seconds, so you might not see the files unless you're watching closely.

Inbox Manager Assistant running on the CAP, and the SMS Management Point File Dispatch Manager on the management point, in turn moves the file to Inventory Processor's inbox (the SMS\Inboxes\Inventry.box folder) on the site server. If the site server is a primary site server, Inventory Processor adds a binary header to the .NHM file, renames it with the extension .MIF, and moves it to Inventory Data Loader's inbox (the SMS\Inboxes\Dataldr.box folder). Inventory Data Loader then reads the .MIF file, parses the data, and writes it to the SMS database on the server running SQL. If a parent site exists, Inventory Data Loader forwards the .MIF file to Replication Manager, which forwards it to Inventory Data Loader's inbox on the parent site server.

If the site server is a secondary site server, Replication Manager forwards the .MIF file to the parent primary site server's Inventory Data Loader inbox, where it's processed as described earlier.

Hardware Resynchronization

Occasionally, Inventory Data Loader might determine that the inventory data it receives is somehow 'bad' or out of sync with the SMS database. In these instances, a resynchronization (resync) will be triggered automatically. Resync is a corrective process that can cause the client agent to ignore the history file and collect a complete hardware inventory. Specific events that trigger hardware inventory resync include the following:

  • The SMS_def.mof file has changed since the last inventory (Legacy Clients only).

  • The inventory delta contains updates for a database record that doesn't exist.

  • The inventory delta itself contains bad or corrupted data.

  • The client has attached to a new SMS site.

  • The client has upgraded from SMS 2.0 to SMS 2003.

    Note 

    Resync doesn't change the hardware inventory schedule-the next inventory cycle will start at the scheduled time.

When a resync is triggered for a Legacy Client, Inventory Data Loader creates a .CFG file for the client and writes a resync request to it. This file is maintained in the SMS\Inboxes\Clidata.src folder on the site server. Inbox Manager writes this file to the corresponding folder on the CAP (CAP_Site\Clidata.box). At the next client update cycle or when an update is forced, the .CFG file is read, the client's registry is updated with the resync information (on 32-bit clients), and the SMS Client Service directs the Hardware Inventory Client Agent on the Legacy Client to generate a complete hardware inventory.

When a resync is triggered for an Advanced Client, the Inventory Data Loader purges any NOIDMIF data that was received from the client. The Policy Provider on the site server creates a resync policy and sends it to the management point. At the next policy refresh period on the Advanced Client, the resync request is received, and a full hardware inventory is run.

Status Messages and Log Files for Hardware Inventory

Status messages and log files are generated throughout the inventory installation and collection process. Let's begin with the log files. Unlike log files generated on the site server, client logs are enabled by default and written automatically to the \MS\SMS\Logs folder on each Legacy Client and to the %Windir%\System32\Ccm\Logs folder on each Advanced Client. When monitoring hardware inventory on the Legacy Client, you should view the Ccim32.log file for entries related to the detection of the Hardware Inventory Client Agent offer. For example, the notification that the Hardware Inventory Client Agent needs to be installed is made to the client through the client offer file, as discussed in the section entitled 'Enabling Hardware Inventory' earlier in this chapter. Monitor the SMSapm32.log file for entries related to Advertised Programs Monitor scheduling the installation of the Hardware Inventory Client Agent. Inhinv32.log tracks the installation of the agent.

Hinv32.log tracks the generation of inventory files as well as updates to the SMS_def.mof file, as illustrated in Figure 9.4. Notice the start of the inventory cycle as well as the enumeration of object classes.

Click To expand
Figure 9.4: Sample entries for Hinv32.log in Wordpad.

Cqmgr32.log tracks the copying of inventory and status messages to the CAP, as illustrated in Figure 9.5. Notice when the client connects to the Inventry.box folder on the CAP.

Click To expand
Figure 9.5: Sample entries for Cqmgr32.log in Wordpad.

You should also monitor the respective log files for Inventory Processor (Invproc.log), Inventory Data Loader (Dataldr.log), Inbox Manager (Inboxmgr.log), and Inbox Manager Assistant (Inboxast.log) to monitor their part in the inventory collection process.

On the Advanced Client, monitor the Policyagent.log file for updates received by the client, which would include enabling Inventory Agent on the client and configuring hardware inventory collection. Monitor the Inventoryagent.log file, a portion of which is shown in Figure 9.6, for collection of inventory data.

Click To expand
Figure 9.6: Sample entries for Inventoryagent.log in Notepad.

You can view status messages regarding inventory activity on a client by running a status message query through the SMS Administrator Console. To do so, follow these steps:

  1. Navigate to the System Status folder, expand it, and select the Status Message Queries folder.

  2. Right-click the query All Status Messages From A Specific System and choose Show Messages from the context menu to display the All Status Messages From A Specific System properties page, as shown in Figure 9.7.

    Click To expand
    Figure 9.7: The All Status Messages From A Specific System properties page.

  3. In the Prompted Value list, select Machine Name. Click Specify and enter the name of the client computer you want to report on or select Load Existing to have SMS query the database and compile a list of all client names it has recorded.

    Note 

    This process can take a while for large databases.

  4. Select Time in the Prompted Value list. The options in the Value frame will change. Either specify a starting date and time from which you want to see status messages or choose Select Date And Time to enter a range of hours (1, 2, 6, or 12 hours ago).

  5. Click OK. The SMS Status Message Viewer will display all the status messages recorded for that client during the period specified.

Look for message IDs of 10500, indicating that inventory has been successfully collected; 10505, indicating that the inventory schema (SMS_def.mof) has been updated; and 10204 from Client Component Installation Manager (CCIM), reporting that the Hardware Inventory Client Agent was successfully installed. Note that CCIM made this report an hour later, which is its verification cycle.

For a list of clients that have installed the Hardware Inventory Client Agent, run the status message query Legacy Clients That Installed The Hardware Inventory Client Agent. To view status messages for clients based on their collection membership, run the status message query All Status Messages For A Specific Collection At A Specific Site. Of course, you could create your own status message query as well. Refer back to Chapter 5, 'Analysis and Troubleshooting Tools,' for more information on how to create status message queries.

On the site server, monitor the status messages of Inventory Data Loader. Look for messages in the 27xx range identifying successful processing of MIFs. Monitor the status messages for Inventory Processor for resynchronization or the processing of .RAW files from 16-bit clients and monitor status messages for Replication Manager for forwarding of MIF files to a parent site.

You can also use the SMS Report Viewer to view status information related to the inventory process. To launch the SMS Report Viewer, follow these steps:

  1. Navigate to the Reporting folder in the SMS Administrator console.

  2. Right-click the Reporting folder. From the context menu, select All Tasks, then Run, then the name of the reporting point site system (if there's more than one) to display the SMS Report Viewer shown in Figure 9.8.

    Click To expand
    Figure 9.8: The SMS Report Viewer.

  3. Expand SMS Site-Discovery and Inventory Information and select an appropriate report. In Figure 9.8, I selected Computers Not Inventoried Recently. Enter whatever prompted information is required and then click Display. The results are displayed in a results window, as shown in Figure 9.9.

    Click To expand
    Figure 9.9: The results window for a report run through the SMS Report Viewer.

Viewing Hardware Inventory

You view hardware inventory through the SMS Administrator Console. To do that, complete the following steps:

  1. Navigate to the Collections folder and expand it.

  2. Select the collection that contains the client or clients whose inventory you want to view.

  3. Right-click the appropriate client entry in the right pane, choose All Tasks from the context menu, and then choose Start Resource Explorer.

  4. In the Resource Explorer window, expand Hardware to view a list of object classes for which properties have been collected, as shown in Figure 9.10. Select each object to view its instances and properties.

    Click To expand
    Figure 9.10: The Resource Explorer window, with Logical Disk selected.

The Resource Explorer window lists properties horizontally across the viewing screen, requiring you to scroll across to see all the properties. However, if you right-click an object and choose Properties from the context menu, you can view the same properties listed in a vertical column, as shown in Figure 9.11.

Click To expand
Figure 9.11: The Logical Disk Properties dialog box.
  1. Expand Hardware History to view information collected from previous inventories such as Logical Disk History, Memory History, and Operating System History, as shown in Figure 9.12.

    Click To expand
    Figure 9.12: The Resource Explorer window, with Hardware History expanded.

Tip 

You could use Hardware History to develop resource usage trends for your clients-for example, to track how much disk storage is utilized over a period of time or whether paging might be excessive due to a lack of RAM.

The entries listed under Hardware in the Resource Explorer window represent the object classes identified through the SMS_def.mof file and any MIF files that were created to be appended to or modify the client's inventory record. As you can see, it's quite a thorough list. You can actually collect more than 10 times the amount of data than you could through the hardware inventory process in earlier versions of SMS.

Customizing Hardware Inventory

There are two ways to customize the inventory that you collect from a client or add to the database as a new class of object: you can modify the default SMS_def.mof file or you can create custom MIF files. Either method requires some planning and testing on the part of you, the SMS administrator. As we've seen, the default SMS_def.mof file collects a large amount of data-around 200 KB per client. Modifying the file could result in larger amounts of data to track, more network traffic when sending the data to the CAPs and site server, and so on. Adding an MIF file can also result in additional inventory data being reported. Also, although the SMS_def.mof exists as a template that can be modified, in general, MIF files must be created.

SMS_def.mof

As mentioned, you can consider the SMS_def.mof file a template that defines for Windows Management on SMS clients which inventory objects, or hardware classes, should be queried and how much data should be collected for each. The master SMS_def.mof file is maintained in the SMS\Inboxes\Clifiles.src\Hinv folder on the site server. This file is copied to the CAP (CAP_Site\Clifiles.box\Hinv) and ultimately to each Legacy Client (%Windir%\MS\SMS\Sitefile\site\Hinv). For Advanced Clients, the SMS_def.mof file is used to create an inventory rules policy that's propagated to each Advanced Client through the management point.

You can modify the class and property settings contained in the SMS_def.mof file or add new classes and properties by opening the file with any text editor such as Microsoft Notepad. Figure 9.13 shows a portion of an SMS_def.mof file as displayed using Notepad. Each class and property includes a flag named SMS_Report. When this flag is set to True, the property is collected as part of inventory. In Figure 9.13, you can see that the SMS_Report flag for the class SMS_LogicalDisk is set to True and that the values for the properties Availability, Description, DeviceID, DriveType, FileSystem, and FreeSpace will be collected from the client. Figure 9.14 displays a list of the Class Qualifiers and their descriptions as outlined in the SMS_def.mof file.

Click To expand
Figure 9.13: Sample of SMS_def.mof file displayed using Notepad.
Click To expand
Figure 9.14: List of Class Qualifiers as listed in SMS_def.mof file.

If you want to prevent a class or property from collecting inventory data, set the SMS_Report flag to False. If you want to enable a class or property to collect data for inventory, set the flag to True.

More Info 

A detailed explanation of the use and editing of the SMS_def.mof file is included in Chapter 2 of the Microsoft Systems Management Server 2003 Operations Guide, available for viewing and download through Microsoft TechNet, and available as a print book from Microsoft's SMS Web site (http://www.microsoft.com/smserver) as well.

MIF Files

Another way to modify the hardware inventory is through the creation of MIF files. MIF files modify the database by creating architectures, object classes, and attributes. Architectures define entire new classes of objects, whereas object classes and attributes are generally added to existing architectures.

You can create two types of MIF files: NOIDMIFs and IDMIFs. NOIDMIFs are used to modify or append object classes and properties to existing client inventory records-hence the term 'no id.' You're not creating a new architecture; you're simply appending to an existing architecture-namely, System Resources. You could use a NOIDMIF to add a client system's asset number, information about peripheral devices attached to the computer, or even the department name or code to the existing client record.

IDMIFs, on the other hand, are used to create new architectures of object classes and attributes. For example, suppose you want to report on all the multimedia equipment you have in your organization. Through an IDMIF, you could create a new architecture (say, Multimedia Equipment) with its own object classes-(perhaps Audio, Video, CD, Tape, or PC Conferencing), each of which would have one or more attributes (Model, Manufacturer, Asset number, Cost, and so on). You can also use IDMIFs to update existing architectures-for example, to add stand-alone computers to the database or to associate an architecture with existing computer records for the purpose of creating queries and collections that can be linked to unique properties.

More Info 

Although it would be nice to present examples showing how each of these types of MIFs can be used and explain their basic structure, we don't want to reinvent the wheel here with an in-depth explanation of MIF usage and interaction. You can find that level of detail, along with a detailed discussion of MOF files, in the Microsoft Systems Management Server 2003 Operations Guide, available as a print book from Microsoft's SMS Web site (http://www.microsoft.com/smserver) and also through Microsoft TechNet. Be sure to read Chapter 3, 'Advanced Inventory Collection,' which discusses customizing hardware inventory, if you want to use MIF and MOF files to their greatest advantage.

The basic structure of IDMIFs and NOIDMIFs is essentially the same. Because they're text files, you can create them using any text editor. Actually, most third- party add-ons for SMS 2003 are capable of generating MIF files that update the database with various kinds of information. SMS Installer can notify the site server about the successful or failed installation of an application through a status MIF file. The MIF file format is an industry standard format. If you've created any kind of scripts or batch files in the past, you'll find it easy to create an MIF file. Let's start with the NOIDMIF.

Creating a NOIDMIF

NOIDMIFs are perhaps the most commonly used MIF file because they add to existing computer records and they're the easiest to create. Figure 9.15 shows a sample of a NOIDMIF designed to add the client computer's department name and department code to its existing hardware record in the SMS database.

Click To expand
Figure 9.15: A sample NOIDMIF file.

NOIDMIFs always begin with Start Component and a general component name. The next step is to create an object class. You do this by adding the Start Group statement, a name describing the group, an ID, and a class. The Name attribute is the string displayed in the Resource Explorer that refers to this class. The ID attribute represents this group in relation to any other group in this MIF. For example, if you add another group, you would give it an ID of 2, and so on-the number is unique. The Class attribute is used by SMS internally for processing the group information.

Next you list each attribute that you're adding for this object. In this case we're adding three attributes: Department Name, Department Code, and Department Manager. Each attribute entry begins with Start Attribute and ends with End Attribute. For each attribute you must provide at a minimum Name, ID, Type, and Value settings. These attributes are fairly self-explanatory. Name is a descriptive attribute name. ID represents the attribute in relation to other attributes. Type indicates whether the value is a text string, a number, or a list, and gives the value's length when appropriate. Value, of course, is the current value you're assigning to the attribute. You end the MIF file with End Group and End Component statements.

Save the NOIDMIF with a descriptive filename and the .MIF extension. You must place the file in the %Windir% \MS\SMS\Noidmifs folder on each client you want to update. You can do this using SMS 2003's package distribution process, which will be discussed in Chapter 12, 'Package Distribution and Management.' At the next hardware inventory cycle, the MIF file will be read, evaluated for syntax, and added to the client's inventory file, as described in the section entitled 'Hardware Inventory Collection Process Flow' earlier in this chapter, and then updated to the client's SMS database record. You can then view it through Resource Explorer, where it will be listed along with the other classes that were collected.

Caution 

Be sure that the MIF file you create using a text editor is saved with the .MIF extension. Text editors such as Notepad append a .TXT extension. It's easy to miss this, and if you do, you'll spend an inordinate amount of time trying to figure out why the MIF file isn't working.

Creating an IDMIF

As mentioned, the basic structure of an IDMIF is similar to that of a NOIDMIF. The main difference comes at the beginning of an IDMIF file, as you can see in the example shown in Figure 9.16.

IDMIFs require that you include the following two statements at the top of the MIF:

  • //ArchitectureIdentifies the name of the new architecture (object class) you're creating

  • //UniqueIDDefines a single unique value that identifies this specific instance of the architecture in the database

    Click To expand
    Figure 9.16: A sample IDMIF file.

IDMIFs also require that you include a top-level group that has the same name as the architecture and that has at least one attribute defined. Also, if a class has more than one instance within an architecture, you must have defined at least one key attribute to avoid overwriting previous instances with subsequent information. A key value is simply one of the group attributes. As with NOIDMIFs, you must save the file with an .MIF extension. You can place the file in the %Windir%\MS\SMS\Idmifs folder on any SMS client.

Viewing an IDMIF

Unlike NOIDMIFs, which are associated with specific clients, IDMIFs generally add new object classes to the database. Therefore, you can't view this information through Resource Explorer. Instead, you must create a query to extract and view the relevant data from the SMS database. For details on creating queries, refer to Chapter 16, 'Queries and Reports.'

As mentioned, NOIDMIFs are generally associated with individual client records, and, as such, they must be placed in the %Windir%\MS\SMS\Noidmifs folder on each client. Of course, you can use SMS package distribution to accomplish this. IDMIFs can also be placed in the Idmifs folder on the SMS client. However, since IDMIFs generally aren't associated with any one client, you can place an IDMIF in the Idmifs folder on any SMS client. For that matter, you could also place the IDMIF in the CAP_Site\Inventry.box folder on the CAP or in the SMS\Inboxes\Inventry.box folder on the site server. The result will be the same.



Previous Section
 < Day Day Up > 
Next Section