Highlighted
Absent Member.
Absent Member.

Re: Zen 11.3 Duplicate Objects

As the consultant to whom joe_it refers, let me add a few thoughts and some historical perspective.

The reconciliation feature dates back to the Tally Systems product TS.Census, much of which is now native technology in ZENworks (inventory engine, HW/SW recognition, a lot of other less obvious stuff). We set the reconciliation feature up with the three fields - serial number, MAC address, and machine name - as those seemed reasonably useful, if not perfect. In practice, the general recommendation - and one I carry forward to today as a best practice - is to use SN and MAC and to deselect machine name. Machine name is a label that can be changed quite often and has no physical tie to the hardware. Take as an example a migration from one OS to another where the hardware does not change. In such a case the preferred reconciliation would be to the exiting record in the database - the hardware didn't change, only the OS - with the OS change reflected in the change history. If you performed an OS migration for 1,000 machines, attempting to reconcile on machine name, but changing the machine name on every device to include the new OS (I've seen this at countless customers) then the reconciliation would create a new record for every new machine name and you'd be stuck manually deleting all the old device records, even though each old record links to useful history (HW/SW changes, software usage).

The note about Dell motherboard replacement - or any motherboard replacement for that matter - is valid and points out the one hole in the scheme that can't really be filled by the technology as it exists today. The inventory engine has to be able to auto-discover some number of data points on which to base reconciliation. Most of the time, when you re-image a machine, the motherboard has not been replaced, and a SN+MAC reconciliation will align to the existing record in the database. (The original use case for the feature was a customer who re-imaged every one of their 7,000 machines three times each year; SN+MAC reconciliation worked perfectly.)

If a new motherboard is introduced, the SN match will fail and you'll have to clean-up manually. Actually, in the case of Dell, they give you a chance to prevent this from happening by providing a utility to insert the service tag (a.k.a. their serial number) into the BIOS, where ZENworks will find it and reconcile as expected. I'm not aware of other hardware vendors who do this, though there may be others. So if you "dot the i's" reconciliation will perform perfectly.

Bruce McDowell Technical Services Consultant, McDowell Consulting LLC bruce@consultbruce.com
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Zen 11.3 Duplicate Objects

BMcDowell;2332792 wrote:
As the consultant to whom joe_it refers, let me add a few thoughts and some historical perspective.

The reconciliation feature dates back to the Tally Systems product TS.Census, much of which is now native technology in ZENworks (inventory engine, HW/SW recognition, a lot of other less obvious stuff). We set the reconciliation feature up with the three fields - serial number, MAC address, and machine name - as those seemed reasonably useful, if not perfect. In practice, the general recommendation - and one I carry forward to today as a best practice - is to use SN and MAC and to deselect machine name. Machine name is a label that can be changed quite often and has no physical tie to the hardware. Take as an example a migration from one OS to another where the hardware does not change. In such a case the preferred reconciliation would be to the exiting record in the database - the hardware didn't change, only the OS - with the OS change reflected in the change history. If you performed an OS migration for 1,000 machines, attempting to reconcile on machine name, but changing the machine name on every device to include the new OS (I've seen this at countless customers) then the reconciliation would create a new record for every new machine name and you'd be stuck manually deleting all the old device records, even though each old record links to useful history (HW/SW changes, software usage).

The note about Dell motherboard replacement - or any motherboard replacement for that matter - is valid and points out the one hole in the scheme that can't really be filled by the technology as it exists today. The inventory engine has to be able to auto-discover some number of data points on which to base reconciliation. Most of the time, when you re-image a machine, the motherboard has not been replaced, and a SN+MAC reconciliation will align to the existing record in the database. (The original use case for the feature was a customer who re-imaged every one of their 7,000 machines three times each year; SN+MAC reconciliation worked perfectly.)

If a new motherboard is introduced, the SN match will fail and you'll have to clean-up manually. Actually, in the case of Dell, they give you a chance to prevent this from happening by providing a utility to insert the service tag (a.k.a. their serial number) into the BIOS, where ZENworks will find it and reconcile as expected. I'm not aware of other hardware vendors who do this, though there may be others. So if you "dot the i's" reconciliation will perform perfectly.


Craig can give more details (he's out this week) on why the serial # shouldn't be used and in what cases that serial # isn't really the serial #, it's some internal value that ZCM cooked up.

All I know is that when we had it enabled, we had no end of issues, even with motherboard replacements being properly done, and that's when we found out that the serial # isn't always read from the system board in time, and that's when bad things happen.

The serial # gets more weight in the reconciliation than the other two, I believe.
0 Likes
Absent Member.
Absent Member.

Re: Zen 11.3 Duplicate Objects

As Kevin points out, the "Serial Number" ZCM will use to reconcile may
not be the devices actually Serial Number. If the Serial Number is not
picked up soon enough, this field will be populated with a "Device
GUID". This value is not permitted to be updated. Furthermore, if the
Motherboard ever fails, there will always be a mismatch.

However, If a "Machine Name" is updated, this will be updated in the
records and if the device is restored it will use the current device
name, since this information is retained in ISD on the HDD.

Now, If I was to begin an OS Migration where I was going to
automatically re-image 10,000 Devices overnight so they received a new
OS and a new OS name that had the OS as part of the name again would not
be an issue.

In this case, you would want to make sure that "Differentiation" was not
checked and ZCM would do a "Best Match" and find that the MAC addresses
matched and link the device up in the ZCC as well as rename the device
in the ZCC. No duplicate records. No manual Tasks Required.

However, in most cases you may want Differentiation Enabled because lets
say a physical device is re-imaged and moved to a different dept and
gets a new name. Perhaps you want this to be treated as a completely
new and fresh device. If you do, enable differentiation and the old
device will eventually go away. If you want the continued use of the
same record, keep it off so even with the same name you are good.

I'm not trying to argue one way or another.
There is a reason that a slew of options exist.
But I did want to point out that ZCM easily handles all of the problems
stated below.




On 9/10/2014 11:36 AM, kjhurni wrote:
>
> BMcDowell;2332792 Wrote:
>> As the consultant to whom joe_it refers, let me add a few thoughts and
>> some historical perspective.
>>
>> The reconciliation feature dates back to the Tally Systems product
>> TS.Census, much of which is now native technology in ZENworks (inventory
>> engine, HW/SW recognition, a lot of other less obvious stuff). We set
>> the reconciliation feature up with the three fields - serial number, MAC
>> address, and machine name - as those seemed reasonably useful, if not
>> perfect. In practice, the general recommendation - and one I carry
>> forward to today as a best practice - is to use SN and MAC and to
>> deselect machine name. Machine name is a label that can be changed quite
>> often and has no physical tie to the hardware. Take as an example a
>> migration from one OS to another where the hardware does not change. In
>> such a case the preferred reconciliation would be to the exiting record
>> in the database - the hardware didn't change, only the OS - with the OS
>> change reflected in the change history. If you performed an OS migration
>> for 1,000 machines, attempting to reconcile on machine name, but
>> changing the machine name on every device to include the new OS (I've
>> seen this at countless customers) then the reconciliation would create a
>> new record for every new machine name and you'd be stuck manually
>> deleting all the old device records, even though each old record links
>> to useful history (HW/SW changes, software usage).
>>
>> The note about Dell motherboard replacement - or any motherboard
>> replacement for that matter - is valid and points out the one hole in
>> the scheme that can't really be filled by the technology as it exists
>> today. The inventory engine has to be able to auto-discover some number
>> of data points on which to base reconciliation. Most of the time, when
>> you re-image a machine, the motherboard has not been replaced, and a
>> SN+MAC reconciliation will align to the existing record in the database.
>> (The original use case for the feature was a customer who re-imaged
>> every one of their 7,000 machines three times each year; SN+MAC
>> reconciliation worked perfectly.)
>>
>> If a new motherboard is introduced, the SN match will fail and you'll
>> have to clean-up manually. Actually, in the case of Dell, they give you
>> a chance to prevent this from happening by providing a utility to insert
>> the service tag (a.k.a. their serial number) into the BIOS, where
>> ZENworks will find it and reconcile as expected. I'm not aware of other
>> hardware vendors who do this, though there may be others. So if you "dot
>> the i's" reconciliation will perform perfectly.

>
> Craig can give more details (he's out this week) on why the serial #
> shouldn't be used and in what cases that serial # isn't really the
> serial #, it's some internal value that ZCM cooked up.
>
> All I know is that when we had it enabled, we had no end of issues, even
> with motherboard replacements being properly done, and that's when we
> found out that the serial # isn't always read from the system board in
> time, and that's when bad things happen.
>
> The serial # gets more weight in the reconciliation than the other two,
> I believe.
>
>



--
Going to Brainshare 2014?
http://www.brainshare.com
Use Registration Code "nvlcwilson" for $300 off!


Craig Wilson - MCNE, MCSE, CCNA
Novell Technical Support Engineer

Novell does not officially monitor these forums.

Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Zen 11.3 Duplicate Objects

Interesting. I've not observed the "device GUID as serial number" condition in the field, with the exception of course of VMs. My personal experience has been that device serial number is quite consistently picked up and reported, allowing for the motherboard swap issues as previously discussed here. However, I'm hoping to have my hands on a particularly large ZENworks database later this month (60,000+ devices) and I'll just have to run some reports and see what's to be seen.

Bruce McDowell Technical Services Consultant, McDowell Consulting LLC bruce@consultbruce.com
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.