M100327: Duplicate GUIDs in the ManageSoft database

Errors in some ManageSoft versions can cause duplicate GUID entries to be added to the ManageSoft database. This article describes why, and how to identify and fix them.

Introduction

This document describes how to repair the problem of duplicate GUIDs in ManageSoft database tables that are populated from Active Directory (AD).

Before you proceed

This document assumes the following knowledge:

You are familiar with terms and concepts associated with Active Directory (AD)
You are familiar with Microsoft SQL Server 7 or 2000, or MSDE
You are familiar with the ManageSoft database schema. For further details, refer to Technical Note #1: ManageSoft database schema.

What is the purpose of the GUIDs?

Computers, Users and OrganizationalUnits (OU) are among the other Active Directory records that AD must keep up-to-date across all AD Domain Controllers in the Domain. Because the names of these records may change over time, AD assigns each record a unique value for an attribute called objectGUID.

The GUID is a 16-byte (128 bit) number chosen with a random value to ensure its uniqueness, even amongst a large population of GUIDs. Whenever an AD Domain Controller (DC) must propagate a change to any AD record to another DC, the objectGUID is used to uniquely identify the object. ManageSoft also uses the GUID values to propagate these changes into the ManageSoft database.

For greater detail on this topic, refer to Knowledge Base article number 100214, Reconciliation with Active Directory.

How are GUIDs entered into the ManageSoft database?

GUIDs are entered into the ManageSoft database upon migration from NETDEPLOY GLOBAL, and whenever a new Computer, User, or OrganizationalUnit is added to the database. These new entries may arise from processing of installation event logs, inventories, or during calculation of resultant (merged) policy.

OUs may also be added during AD Reconciliation.

Why are duplicate GUIDs added to the database?

Errors in populating the Users and Computers tables in some versions of ManageSoft (up to and including 6.1.2 in all three areas ((inventory, installation logs, and policy merge)), and in ManageSoft version 6.1.3, only in policy merge) may cause duplication after a User or Computer has been renamed or moved to a new OU but reconciliation has not yet run (or has run, but has not reloaded AD data because existing data is deemed recent enough).

When a User, Computer, or OU is to be associated with new database records, it is first looked up in Active Directory ? this returns the full name and the objectGUID.

The objectGUID is used to query the ManageSoft database to determine whether the appropriate record already exists. If it does, the new data is associated with that record. This should occur even if the record is associated with the wrong name reconciliation repairs that when it next runs.

If the objectGUID is not found in the ManageSoft database, a search is conducted by name, which seeks a record that has not yet been associated with an Active Directory object. This might happen if, for example, a computer is added to the domain on a remote Domain Controller, and the computer uploads inventory or installation status records, which are processed before the remote DC has replicated the new entry to the DC adjacent to the ManageSoft Warehouse.

These computers are added to the "unknown" OU in the ManageSoft database and do not have a GUID value.

A new entry is added to the database only if the ManageSoft search by GUID and by Name fails ? but this was not always the case in previous versions of ManageSoft.

What effect does the duplication have?

When new data arrives for a Computer or User, the named principal is sought in AD. The ManageSoft database is then searched using the GUID, but in the case of duplication, more than one candidate may be found. This error is not consistently detected.

In most cases, the new data is associated with the object the ManageSoft database found first ? this can change from time to time and cause confusion, as data which should be associated with one computer is actually associated with more than one occurrence of the record.

Only one of these records has the correct name according to Active Directory. In the case of the inventory gathering process, ndtrkres, a duplicate GUID in theComputer table, causes it to fail to process that inventory file. Contrary to most similar errors in processi