Duplicate computer resource objects are created when importing computers via the Active Directory Integration component. The duplicates directly correspond to the computers hosted in a virtual session, such as VMWare. Often these will appear with almost no inventory information at all, but will show up in collections and cause problems.
When my virtual machines get reclassified from a standard computer resource to a virtual machine resource, they sometimes drop out of simple reports and are shown as virtual machines in my collections. How can I prevent my virtual machines from changing from a standard computer resource to a virtual machine resource?
The AeX VirtualMachine dataclass is collected by the hardware inventory component of Inventory Solution for Windows.
A scheduled task (which is re-created/repaired on a nightly basis) named "NS.Modify VirtualMachine Item Resource Type" is responsible for:
Finding all computer objects which have data populated in the AeX VirtualMachine dataclass
Each identified Computer resource is then converted to a VirtualMachine resource.
Note: Reversing the conversion process is not safe when other solutions are installed (such as Asset Control). Symptoms of a bad conversion include errors referring to invalid resource associations and failed duplicate insertions into indexed columns on the ResourceKey table.
Because VirtualMachine resources are not considered a default resource type, the NS data loader won't find a match for the NSE data posted by the Active Directory component. The data loader then creates a new default computer object for the record, which causes the duplicate. Duplicates can easily be seen from within the Merge Computer Resource tool, which matches on the combination of the computer-name and domain as gathered by the Altiris Agent's Basic Inventory function.
Path to the Merge Computer tool: Configuration tab > Server Settings > Notification Server Infrastructure > Merge Computers > Merge computers with duplicate names.
2 things need to be done to correct this problem:
Stop collection of the AeX Virtual Machine dataclass (which is causing the confusion).
Clear out the old virtual machine data that has already been collected.
1. Stop collection of the AeX Virtual Machine dataclass
Include the following line in each INI file used by the machine inventory collector (exactly as specified, with spaces and capitalization):
AeX Virtual Machine
The dataclass in the Notification Server is called "AeX VirtualMachine", while the dataclass name used in the Inventory Agent is "AeX Virtual Machine". The Agent needs to exclude the dataclass in the form it uses, not the form the Notification Server uses.
Prior to Inventory Solution for Windows 6.1 SP2, the keyword was just "Virtual Machine".
There is also an unrelated keyword "AeX Srv Virtual Machines" which is used by Inventory Solution for Servers. It is not related to the virtual computer conversion process.
Default files used by Inventory Solution for Windows
All Virtual Machine resources will be displayed on the lower pane of the collection's view under the heading "VirtualMachine".
Shift-select a small group of Virtual Machine records, right-click, and then choose Delete. Repeat as necessary to remove all the entries.
If all resources are listed under "Computer", then either all Virtual Machine resources have been deleted, or all objects remaining in the collection are Virtual Machines (unlikely unless this is a pure test environment).
By performing this step, you will force creation of new computer objects with the previously issued GUID on the NS. On each VM, the Altiris Agent will eventually check-in and post basic inventory data again.
This will cause the loss of any previous event data, such as the status of any recent software delivery activities.
Inventory data will be automatically re-created (if on a repeating schedule).
Patch management vulnerability data will be automatically re-created upon the next scheduled scan (default of 4 hours).
Recovery solution agents will re-associate with their previous RS data store record.
Prior Application metering history for the deleted objects will be lost, but will start accumulating again upon recreation of the object.
You may also need to delete other objects found under Resource Management > Resources > Defaults > Virtual Machines. In at least one case, there were systems there that remained after clearing out the other objects above that still made a mess of some collections.
Verify the dataclass is fully purged
If all virtual computers have been deleted, then the corresponding dataclass table should be also be empty. From within SQL Analyzer, execute the following script against the Altiris database to find any orphaned rows:
select * from Inv_AeX_VirtualMachine
After these steps are completed, you should never see a new row added to the Inv_AeX_VirtualMachine table, and you should never see a computer converted to a Virtual Machine. It is unimportant if the Modify Virtual machine task continues to run, as there will be no data to trigger the conversion.
Note: AD Import creating a new record for Virtual Machines is scheduled to be resolved with NS 7.0
Applies To Notification Server 6.0 SP2 or Notification Server 6.0 SP3 Inventory Solution for Windows 6.x Active Directory Integration component 6.1 Any other solution that creates NSEs that do not contain a resource GUID to match an existing object.
Logged in sydd2 (Altiris - Sydney) database
Imported Document Id
This is machine translated content
Login to Subscribe
Please login to set up your subscription.
Didn't find the article you were looking for? Try these resources.