Client Management Suite

Introduction

Inventory Solution provides hardware and software details on devices in your environment. Understanding how Inventory works, and how to troubleshoot problems, will give you the confidence needed to report accurate, relevant data. This is essential when managing assets and software licenses in the environment. Know what you have and where you have it. This document strives to provide both an understanding of how Inventory works, and how to troubleshoot problems that may arise, enabling you to succeed.

Table of Contents

Server Components
    Custom Data Classes
    Standalone Inventory Packages
    Application Metering Settings
    Data Classes
Policies versus Tasks
Inventory Policy
    Policy Scheduling
        Default Schedules
        Custom Schedules
        Scheduling Considerations
    Inventory Types
        Hardware and operating system
        Software - Windows Add / Remove Programs
        File Properties
        Server Applications
    Inventory Policy Advanced Run Options
        Delta Inventory
        System Resource Usage
        Throttle Inventory Scan
        Run Inventory User
    Applies To / Compliance
Gather Inventory Task
Inventory Execution Considerations
Identifying the Problem Location
Inventory Process Flow

Server Components

This section covers the Setting and configuration items located in the Symantec Management Console. These are used for administrative and troubleshooting purposes.

Custom Data Classes

To run Custom Inventory, a custom data class to contain the data needs to be created. This is done in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Discovery and Inventory, Inventory Solution > and select Manage Custom Data Classes.

Consider the terms as such:

• Data class = Database Table - What is entered will become a table, as in the following example:
  Name entered: My Custom Table
  Resulting Table name: Inv_My_Custom_Table
• Attribute = Database Table Column - Name given the attribute will be the name of the column in the database
• Data type = What type of values are allowed in the column - Make sure you get this one right for the data that is being returned. String works for most values, though data can be manipulated via reporting if it is a specific data type based on the attributes of that data type.
• Size = How many characters are allowed in the field in total - Provide a buffer for expected characters. For example if you believe you'll have about 50 characters, give it a limit of a 100 so data isn't truncated.
• Key = The table requires a unique value from each computer that returns data - This is not typically used for Custom Inventory, but something like Serial Number may be considered Key since it should not have duplicates.
• Required = The table requires data to be returned for the indicated column, so no NULLS are allowed - Only use this if you are sure all computers will return data for this column, because if this value is blank the row will not be added to the database.

In essence, these are details set into a SQL table, but the Platform will require these attributes before it attempts to process data into the database.

NOTE: The biggest item of consideration is to ensure you setup your table correctly the first time. Due to the nature of SQL, making changes after data has been inserted can cause failures based on the existing data. If a change is required, consider the following:

1. Adding a column is not an issue as long as it is not key or does not allow NULLs
2. Changes to existing columns will likely require the table to be truncated first. Custom Inventory would then need to be run again to repopulate the table.
3. Changes to the data class require changes to the Custom Inventory script to account for the change.

Standalone Inventory Packages

These packages are used to gather inventory on systems that are not managed by a Symantec Management Agent. Components of the agent, including Basic Inventory, are contained within the package, including the ability to post to the Notification Server. The page is found in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Discovery and Inventory > Inventory Solution > and select Stand-alone Inventory Packages.

When you create the packages, you'll get many of the same options found in an Inventory Task and Policy. Please note the following when creating and using a Stand-alone package:

• The output location specified is, by default, the Notification Server. If this location is not available when Inventory finishes, the data will not make it to the NS and the execution is considered a failure.
• If specifying a local folder, the completed NSEs will be copied and it is then up to the user to get those files to the notification server.
• If specifying a network share, that share must be available when inventory finishes executing as the files will be posted. If it fails to post, the execution is considered a failure.
• The links provided on the page can be sent out to the environment to be clicked and executed automatically.
• Previous to 7.5, a stand-alone package would fail if execute on a system that was managed by the Symantec Management Agent. In 7.5 the execution works just fine.

Application Metering Settings

There is a settings page for Application Metering. The configuration provides a series of purge settings allowing you to control how long data is kept for application metering. This includes events, reports, and summary data. Reach this page in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Discovery and Inventory > Inventory Solution > and select Application Metering Configuration.

The default purge settings appear adequate in most environments. If performance becomes an issue, the purge window can be made smaller, allowing reports to run faster. If a longer period of data is required, the values can be increased to account for this. In larger environments performance may be impacted by any increase in the time frames. Another factor is how many applications or EXEs are being metered. The more metered the more data the database will have to handle.

Data Classes

Due to the nature of Inventory, data classes are key to the entire Inventory process. Data classes are basically tables with inventory data inserted into them. The Notification Server uses the data class definitions to manage the tables, mostly when data is to be inserted into them.

To view data class definitions browse in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Notification Server > Resource and Data Class Settings > Data Classes. For Inventory expand the Inventory folder. The following list provides feedback on how this section of the console can be used.

1. In the Custom folder all custom inventory data class you have created can be found.
2. When selecting a data class, a summary page appears providing feedback on that data class.
   
   1. Data table name - You can use this to see the exact table name if you are not sure
   2. Guid - Knowing a data class's GUID can be useful when working in auxiliary tables, such as ResourceUpdateSummary.
   3. Multi-rowed - This lets you know if a resource can insert more than one row into the table. Most Inventory data classes are multi-rowed.
   4. Number of resources reported data - This lets you know how many computers have reported inventory for this data class. Good for checking health on data with in a class.
   5. Last reported data - Useful for checking if inventory is being inserted. Note that it does not mean inventory hasn't come in, just for the last time changed or new inventory reached the database to be inserted.
   6. Attributes - This gives you the columns and their data types, including if they are key or not. The default is non key and allow nulls unless otherwise listed.
3. For custom data classes you can delete data classes from this location (right-click, delete).
4. You can export a data class to import at another Notification Server, if so desired (right-click, export).

Policies versus Tasks

Both policies and tasks have their pros and cons. I recommend using Policies for most use-cases, but there may be times when a Task is the right choice to be used. The following table provides the pros and cons for each type.

Inventory Policy	Gather Inventory Task
Execution can occur offline	Computer must be active on the network to run the task
Self-contained, all definitions cached locally	Requires a working Task Server to get definitions
Data will be saved until the client connects	Won't run if not connected
New Policies must be downloaded through the client configuration XML	New Tasks will run virtually immediately as long as computers are active
Supports a wide variety of schedules with accurate execution times on the client	Supports schedules, but computers must be online at scheduled time or they will not run
Cannot be added to a Managed Delivery	Can be added to a Managed Delivery

Highlights for a Policy - With a policy you can enable and then let it go. Clients will get the policy and run it per the schedule regardless of connection state. For a situation where data is needed immediately, a policy may take time to propagate down and return data. Policies cannot be added to a Managed Delivery from Software Management.

Highlights for a Task - Computers must be online at the scheduled time or they will not run it. For situations where data is needed immediately, tasks will very quickly run on active computers. Tasks can also be added as part of a Managed Delivery policy.

An example of a Managed Delivery Policy running Inventory was provided in the section 32-bit Plugin failing on 64-bit. This gives you more capabilities per what a Managed Policy can do.

Inventory Policy

This section will cover most options and advanced options relating to running Inventory. The Policy will be the main focus as opposed to viewing a Gather Inventory Task.

Policies offer the best option for most Inventory scenarios. Once a policy is setup, clients will download their client configuration XML to obtain the policies, and will thus have it ready to execute on the client when the scheduled time arrives, regardless of what connection state the system is in. Note that Inventory Policies ignore Maintenance Windows due to the nature of inventory capture. Each section here covers areas of the Policy configuration.

Policy Scheduling

Scheduling is an important part of Inventory Solution. To ensure Inventory remains relevant and up-to-date, how policies are scheduled should take careful consideration.

Default Schedules

Each Inventory Policy has 3 default schedules that can be used. The default schedules execute at 6:00pm (18:00 military time). The Weekly schedule executes on Monday, and the Monthly schedules executes on the first Monday of every month. Note the following items concerning these default schedules:

• If a computer misses the scheduled time, it will execute as soon as possible afterwards.
• There is an ASAP function built into the schedules. The first time a computer receives the policy, regardless if it is a designated day or time, it will execute the policy.
• Default is Agent time for these times.

Custom Schedules

A custom schedule changes the rules. These schedules are determined by the user when Custom schedule is selected. The Custom schedule is also a hyperlink that opens the page to create and edit the schedules associated with the policy.

Note the following items when using a custom schedule:

• If a computer misses the scheduled time, it will execute as soon as possible afterward unless the Advanced option "Only run at the exact scheduled time" is checked. Also note that if the policy is added to the queue at the scheduled time, it may not execute until later if other jobs are being run. For Inventory, it is not advised to use the exact scheduled time option as it will create the possibility of missing a scheduled inventory run.
• Reoccurring schedules (one with a repeat selected) do not have an ASAP function built in. This means if a monthly schedule arrives at the client the day after the scheduled time, it will wait until the next month to run inventory. To avoid this, a run once schedule with no repeat should be created. The start date in the Advanced options should be set in the past. This way when a client first gets the policy, the client will see it is after the scheduled time and run it immediately. The screenshot above shows how the two schedules can be configured to act this way.
• The Start date should be the day the policy is enabled or earlier. For Inventory it does not make sense to use an End date unless this is a special policy you only want to run for a limited duration.
• Most of the Advanced options should be left as they are when the policy is created.

Scheduling Considerations

For most schedules another major factor to consider is how other Inventory policies are scheduled. There are considerations that must be taken into account to avoid bad inventory integrity. Please review these when setting up your Inventory Solution schedules.

1. Full Inventory - Should be scheduled often enough to avoid out-of-sync issues. The default is weekly due to issues encountered where inventory would not be in sync from client to server. In many instances a full inventory capture will resolve these issues. Full Inventory should at least be run Monthly.
2. Client-Server integrity - One current limitation with how inventory works is a lack of confirmation or validation from the client to server, and vice-versa. The client keeps track of what Inventory it has sent, but has no way to validate if the server received it, or if that inventory has been lost in some way on the server. At the same time the server keeps track of what data it has inserted into the database, which may not match what the client thinks it has sent. The following list include ways inventory can get out of sync:
   1. Computers merged - The merging process can delete inventory data from a record. Only one record's inventory is kept.
   2. Duplicate Guids - If a system shares a GUID with another, inventory is overwritten at the server, so the inventory will be inaccurate or nonexistent when the duplicate issue is resolved.
   3. Computer record deleted from the database - Through Purging Maintenance or a deliberate delete action a record's inventory is deleted. Once deleted, the computer can be added again, but that inventory is now gone.
   4. Data deleted from tables - without a deletion or update to the ResourceUpdateSummary table. This table contains a hash-check. The data sent from the client includes a hash that the server will compare to what is in the ResourceUpdateSummary table. If they match, that data is not inserted into the database. At this point the server does not check to see if the data is actually in the table or not.
   The first 3 issues are resolved when a full inventory is run. The 4th one requires additional work to resolve (covered in the troubleshooting section).
3. Schedule Overlap - Inventory has intelligence to avoid capturing inventory simultaneously for two policies. Each time a policy executes, it checks to see if another inventory thread is running. If so, it puts its own thread to sleep and waits for the first one to finish. This can be avoided, and should be. Consider the following when scheduling multiple inventory policies:
   1. Do no schedule different Inventory Policies to run on the same day.
   2. Account for the weekend where systems are typically turned off so multiple policies don't execute Monday morning.
   3. Judge performance to see how often inventory should be running in the environment. Too aggressive inventory can cause the server to be busy, affecting general and console performance.
4. Delta Inventory - Delta inventories should be limited to specific data points. For example, running a frequent Delta with only the option "Windows Add / Remove Programs..." checked can yield good results in keeping track of what software is being installed. If this included all other data classes, it would send more data each time it ran. By limiting the scope of what is collected, it can be scheduled more often to meet specific requirements, as for software tracking in this example.

Inventory Types

On the main page there are four general Inventory types. Each type may include additional break-down in what is gathered.

How each type works and is configured varies as each has a unique method or properties.

Hardware and operating system

This option contains a myriad of inventory data classes and data points. Under the data classes tab in the Advanced options you see all of the data classes represented by this check box. These Advanced options allow you to select and deselect data classes as needed.

All data classes under the Inventory data classes section apply to the first checkbox, even the Software category. Consider this software category specific for hardware and operating system elements, such as bios data, Fonts, and Anti-virus. Any data class unchecked will not be gathered during the inventory process when the policy executes. This is useful when wanting to capture just certain data and excluding what isn't needed. For example memory can be checked for frequently, with all other options not included so the policy can run frequently, catching any change in memory levels.

The only items not applying to this checkbox is the bottom category: Server Inventory data classes.

Software - Windows Add / Remove Programs

The configuration for this item is simple: Delta or full. This is determined under the Advanced options, under the Run Options tab.

This option does affect the entire policy. The Software checkbox runs the Software Discovery, which is actually a Software Management component. Inventory makes the call to this component to run it, since it falls within Inventory's typical use-cases. Take the following considerations when dealing with this checkbox:

• The largest consideration is that the data returned from this inventory component is large. Typical NSEs of this data is 2000kb, when a full is run. Delta is considerably smaller.
• Verbose Logging does not apply to this option, since the code being run is part of Software Management and not Inventory Solution. For logging on this component, use Agent Trace only.
• Software Resources are created from this, so it is an essential part of the Software lifecycle and should be treated accordingly (run fairly regularly to ensure accuracy). Audits of Software depend on accurate data from this.
• This process also gathers file information for installed software. This means we do get File Resources created and linked to Software Resources at this time.

File Properties

This option has the largest impact on the time it takes for Inventory to complete. Due to the nature of a File Scan, it can take system resources and time to gather and filter all the data. Conversely the amount of File Resources created can be significant depending on how the scan is configured. Please take the following considerations when running the File Scan as part of your Inventory Policies:

1. For System Resource issues, including high CPU or Memory consumption, please use the System resource usage: option in Advanced settings. Low is the default, but Very Low can be selected. Keep in mind that lowering the resource usage will prolong the duration of the Inventory Policy.
2. Only include file types you need. Too many file types will not only bloat the data transmitted up to the Notification Server, it creates many File Resources that can create load or timeout problems for any data selecting from the associated tables.

3. Do not scan network drives by type. Use an include to pinpoint where on the network location you wish to scan. Scanning network locations can cause the following issues:
   
   1. Too much data - if the network location contains a lot of files, like a file server, the results will significantly bloat the file results.
   2. Extended Policy run time - Scanning network locations takes time, significantly in cases where the target has a lot of files. Multiple network shares compounds the problem.
   3. Many clients accessing the network location at the same time can cause the file server to become unavailable or even crash. If the data on the server is vital for business operations, this is a serious issue.
4. Question to ask: Are you using this data? This data is not used to automatically associate files under the File Inventory tab of a Software Resource. Unless you have a specific report you are using on files, this data remains as collected inventory only. If you are not using it, you could consider disabling this option until it is needed.
5. Exclusions override inclusions - If you are including a drive, but want to only scan specific files, adding exclusions will be messy. It is easier to remove the inclusion of the drive, and only add inclusions for the specific locations you want to scan.

Server Applications

This option requires that the Inventory Pack for Servers Plug-in is installed. It is an extension of Inventory for Server-class operating systems, but is not required for standard inventory. The same configuration considerations apply to these data classes as with the Hardware and Operating system ones discussed earlier (in that they can be unchecked to not gather them). If a system does not have the plug-in, these data classes will be skipped when the policy executes. In other words it doesn't hurt to have it checked when targeting both servers and workstations.

Inventory Policy Advanced Run Options

Many of the Advanced options were discussed in the previous section. This section covers those options under the Run Options tab, and expands on what was listed earlier. Some of the Advanced Run Options have significant impact on how the Inventory Policy executes.

Delta Inventory

This option makes a huge difference on what is sent to the Notification Server. If checked, after data is gathered it will be compared to what has already been sent. This is done in the following ways:

• For the Hardware, Operating System, User, and Server Inventory data classes, the data is checked against what is stored in the NSI fragment files. These are located at C:\Program Files\Altiris\Inventory\NSI. If the data is the same, nothing will be sent up to the server for that particular data class.
• File Scan data is gathered, and then checked against what is listed in the InvData.mdb database file, located at C:\Program Files\Altiris\Altiris Agent\Agents\Inventory Agent, or C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent (the drive letter may be different if a different install path was chosen for the Symantec Management Agent). Files not previous recorded are compiled into the NSE, and files that have been removed are compiled in a separate NSE. These are then sent as the delta updates to file data.
• For the Software - Windows Add / Remove Programs option, after the data is gathered it is compared to the softwarecache.xml file, located at C:\Program Files\Altiris\Altiris Agent\Agents\Software Management\Data. Software both added and removed is compiled into a single NSE to be sent to the Notification Server for processing.

System Resource Usage

This option only refers to the File Scan. Low has been found to be sufficient for most environments, and is the default setting. Very Low has been used when impact to targeted machines has been noted. The side-affect is to increase the time it takes for the file scan to run. Hardware, OS, User, Server, and Software inventories are not affected by this setting. An algorithm is used to determine how much CPU is being used by our process, and by other processes. The scan will be throttled back if a system is in heavy use, and will increase resource usage if a system is idle. How throttled or how much utilization to use is determined by the setting. Development did create a chart on what the projected usage is, however due to so many factors it was not published as it is too difficult to predict.

Throttle Inventory Scan

This option provides a much needed tool to avoid both network clogs and Notification Server load balancing issues. The text indicates: Throttle inventory scan evenly over a period of: X hours. The throttling refers to the overall execution of the Policy on all target systems. Not only can network and NS loads be alleviated, virtual environments can avoid stressing the host servers that run the virtual machines. For example if all virtual machines started running a file scan, the I/O on the host server would hit the roof and bring the server down. Please take into consideration the following items when using this feature:

1. When this setting is consulted, the Inventory Policy is already executing according to the client Task state. You'll see the policy executing in the Client Task History. It will remain in this state until it has waited and finally gathered and sent inventory.
2. The clients will use an algorithm to determine how long it will wait to gather inventory with the window provided. For example if 8 hours is chosen, the client will randomly generate a wait time within that timeframe. If 4 hours and 30 minutes is randomly selected, it will wait that amount of time before beginning the gathering process. The law of averages typically spread out the executions to throttle when those clients gather and send inventory.
3. When the gathering is complete the data will be sent to the Notification Server, ending the policy's execution with a success. In the above example if the gathering took 20 minutes, the entire length of the policy execution would be 4 hours and 50 minutes.
4. Since the execution is active during the wait period, if the machine restarts, or the Symantec Management Agent service is stopped or restarted, the execution is then considered a failure when the Agent reloads. When this happens the policy is considered failed and will not retry. Use caution on when policies execute and how long they can wait based on this potential adverse effect.

Run Inventory User

Typically this should be left alone. The System account, and the impersonation it is capable of, provides the access it needs to gather the pertinent inventory. There are a few items that may require this to be changed. For example if you want to gather what drives are mapped, and what shares are open for a user the policy needs to run under the Logged in user. Mapped drives are typically user-based, so this would be required to gather this data properly.

Another example is in situations where the System Account has been locked down. In those cases selecting a specified user that has administrator rights on target systems may be required.

Applies To / Compliance

By default every Inventory Policy, including new ones created, are targeted to the filter: Computers with Inventory Plug-in. The default filter cannot be edited, so it should be deleted and a new one added if you wish to change what systems are targeted.

One useful view is to see how the breakdown is for the Policy per Computer.

In one way this section can be useful is if multiple policies are being created to target different groups of systems. In very large environments this can be done in conjunction with the Throttle Inventory scan setting in order to control how much inventory arrives at any given time. The grouping can be done via OU from an Active Directory Import, or any other designation in individual filters. The key is to schedule different times for identical policies to make the division useful.

Gather Inventory Task

When using a Gather Inventory Task, the Inventory Types and Advanced Options are exactly the same as a policy. The scheduling and applies to sections, however, are different and combined in one place. After Inventory is configured properly, use the Task Status section to schedule or immediately run Inventory. When clicking a New Schedule, you'll get options for when to run it, and on what computers to run it on.

While the interface is different than in the Policy, the main elements are the same. Note that there is not advanced options here, so not all scheduling options will be available in the task.

Override Maintenance Windows should be checked if maintenance windows are in effect. This will ensure inventory will be captured regardless of what restrictions may apply to the target systems. Unlike Policies, clients who are not connected to the Notification Server to get the task may not run it after the server officially expires the task. Since the task is pushed down through the Task Server, it needs to be online to run it.

Computers or filters can be added to the task via the typical targeting Task interface.

Inventory Execution Considerations

To consolidate what has been discussed in the previous sections, this list can be used as a checklist on what to take under consideration when setting up your Inventory Policies:

• Resource Utilization - on local systems, on the network, on the Notification Server, and remote file shares
• Randomization of Execution - To alleviate Resource Utilization, the Throttle Inventory Scan setting can be used, and multiple policies with target systems split up between them can be used
• Delta Inventory versus Full - To avoid stale or out-of-sync inventory, be sure to run Full Inventory often enough
• Exclusions versus Inclusions - Remember exclusions override inclusions
• Frequency of Inventory - Balance resource utilization and need for up-to-date inventory in how frequently you schedule policies
• Simultaneous Executions - Avoid scheduling two policies for the same day on target systems

Identifying the Problem Location

The key to fixing Inventory problems is identifying what is causing them in the first place. The difficulty is that a myriad of problems will result in the same basic symptoms:

• Inventory is out of date or stale
• Inventory reports are not accurate - This includes specific data points, such as reporting on Processor only
• Inventory is missing from some to many systems - this may include all inventory, or only specific data

To overcome this problem, the process needs to be understood and then tracked to identify where the issue occurs. The next few sections cover this process and are the bulk of how to troubleshoot Inventory problems. The previous sections setup things to watch out for and provide understanding in how various components work, and what problems and solutions may arise from that. When facing one of the symptoms above, ask the following questions:

1. Is Inventory running on all expected targeted systems?
2. Are the target system's executions successful?
3. Does the data get properly captured by the client?
4. Is the data accurate during the capture?
5. Does the data make it to the Notification Server over the network?
6. Is the data properly inserted into the database?

Each of these questions have items to review, and troubleshooting steps to try. First, understanding the full Process Flow of Inventory will help when walking through these questions.

Inventory Process Flow

The following process flow gives details about what occurs from start to finish for the entire process.

1. Inventory Policy enabled for the Target Filter. This specifies what computers will receive the configured policy. Enough policies should be enabled to cover the requirements of the environment. For this example. The Full will be considered so all appropriate data is gathered.
2. The Resource Membership update occurs (Delta) that lets the NS know to include the policies in the clients configuration.
3. The clients request their updated configuration by hitting the page: http://Servername/Altiris/NS/Agent/GetClientPolicies.aspx. This page may be https if SSL certificates are being used.
4. The server compiles the configuration XML and the client downloads it to C:\Program Files\Altiris\Altiris Agent\Client Policies.
5. If a new Inventory policy exists, the Inventory configuration XMLs are downloaded to C:\Program Files\Altiris\Altiris Agent\Agents\Inventory Agent\InvTaskConfig or C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvTaskConfig.
6. The Policy is executed according to the scheduled time.
7. Hardware, Operating System, Users, and Server Inventory Processes place data files (*.nsi) at: C:\Program Files\Altiris\Inventory\NSI when collected. NSEs are generated from these and passed to the Symantec Management Agent.
8. File data and Software Discovery information is compiled in memory and written to C:\Program Files\Altiris\Inventory\Outbox in NSE format. These are then copied out to the Symantec Management AGent
9. After the NSEs are passed off to the Symantec Management Agent, the Agent posts Inventory to the URL: http://servername/altiris/ns/agent/postevent.asp (https if SSL is implemented)
10. The Receiver will move the inventory into the queue to be processed. If the NSE is large enough, it will split the NSE into multiple files as it is received, copied to the C:\ProgramData\Symantec\SMP\EventQueue\Temp folder, then reassembled when all data has been received, at which point it is placed in the queue. The queue is located at: C:\ProgramData\Symantec\SMP\EventQueue\EvtQueue. In 7.1 SP2 and 7.5 the other queues are not used.
11. As the server picks up each NSE to be processed, it consults ResourceUpdateSummary to determine if data really needs to be loaded in the database. It does this by taking the HASH for each Data class and compares it to the stored hash in the ResourceUpdateSummary table. If the hashes match, it simply drops the data and does not insert. If the Hashes are not the same, the Hash in the table is NULL, or no row exists for that computer and data class, then a row is generated based on the new data.
12. Per data class being processed, the Data Loader loads the Inventory into the associated data class table.

Here is a visual representation of this process:

Return to Part 1: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 1

Continue Reading Part 3: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 3

Part 4:  Troubleshooting Inventory Solution 7.5 (also 7.1), Part 3