Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Absent Member.. Joe_UW Absent Member..
Absent Member..
2957 views

Zen 11.3 Duplicate Objects

Good Morning,

Since upgrading to Zenworks 11.3 we are having a very weird issue. Sometimes when we reimage an existing Windows 7 machines a duplicate object is created and the machine goes un-managed. We previously saw this issue when we were upgrading machines from Windows XP to Windows 7, but after the 11.3 upgrade it is happening with Windows 7 to Win 7 as well. To resolve the issue, we delete both objects, then remove and re-register the machine with Zenworks.

I am wondering how this can be resolved, and if this is some sort of a bug with 11.3? Thanks for your help on this matter.

Joe
Labels (2)
0 Likes
15 Replies
Knowledge Partner
Knowledge Partner

Re: Zen 11.3 Duplicate Objects

joe_it;2332365 wrote:
Good Morning,

Since upgrading to Zenworks 11.3 we are having a very weird issue. Sometimes when we reimage an existing Windows 7 machines a duplicate object is created and the machine goes un-managed. We previously saw this issue when we were upgrading machines from Windows XP to Windows 7, but after the 11.3 upgrade it is happening with Windows 7 to Win 7 as well. To resolve the issue, we delete both objects, then remove and re-register the machine with Zenworks.

I am wondering how this can be resolved, and if this is some sort of a bug with 11.3? Thanks for your help on this matter.

Joe


Hmm, you're the 2nd person I've seen that's reported this in the forums.

Maybe Craig will stop by an offer some guidance.

I'm *assuming* that you reimaged machines prior to 11.3 and that things worked fine?

Only thing I can think of:
Do your images have the 11.3 agent on them now (vs. the old images maybe had 11.2.x?)
We found we had to use that latest ziswin.exe to properly clear out the ISD.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Zen 11.3 Duplicate Objects

Don't recall hearing this exactly before.

Nor can I think of any reason why this would cause the device to go
unmanaged after being re-imaged.

I could think of ideas of why it may not come back as the same device,
but it would certainly be in a managed state.


On 9/8/2014 11:46 AM, kjhurni wrote:
>
> joe_it;2332365 Wrote:
>> Good Morning,
>>
>> Since upgrading to Zenworks 11.3 we are having a very weird issue.
>> Sometimes when we reimage an existing Windows 7 machines a duplicate
>> object is created and the machine goes un-managed. We previously saw
>> this issue when we were upgrading machines from Windows XP to Windows 7,
>> but after the 11.3 upgrade it is happening with Windows 7 to Win 7 as
>> well. To resolve the issue, we delete both objects, then remove and
>> re-register the machine with Zenworks.
>>
>> I am wondering how this can be resolved, and if this is some sort of a
>> bug with 11.3? Thanks for your help on this matter.
>>
>> Joe

>
> Hmm, you're the 2nd person I've seen that's reported this in the
> forums.
>
> Maybe Craig will stop by an offer some guidance.
>
> I'm *assuming* that you reimaged machines prior to 11.3 and that things
> worked fine?
>
> Only thing I can think of:
> Do your images have the 11.3 agent on them now (vs. the old images maybe
> had 11.2.x?)
> We found we had to use that latest ziswin.exe to properly clear out the
> ISD.
>
>



--
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
Absent Member.. Joe_UW Absent Member..
Absent Member..

Re: Zen 11.3 Duplicate Objects

It is a very weird issue. It has been reported on multiple machines after a reimage.

- We have upgraded the client installation to 11.3 from 11.2.3 and the issue is still occurring. Our imaging is being done via MDT, and we mostly image Win-7 64-bit machines. We slipstream updates into the Win-7 image on a monthly basis to speed up the imaging process, otherwise nothing has changed.

- Before upgrading the server to 11.2.3 we didn't have any issues. We have not started a mass upgrade yet across campus to the 11.3 agent. Right now it gets installed on a machine reimage.

After imaging we are left with 2 objects in Zenworks. 1 will be computerA and the other will be computerb-(huge string of characters), I assume the guid. Delete both objects, run the "zac reg" command and the issue is usually resolved.

Joe
0 Likes
Knowledge Partner
Knowledge Partner

Re: Zen 11.3 Duplicate Objects

CRAIGDWILSON;2332433 wrote:
Don't recall hearing this exactly before.

Nor can I think of any reason why this would cause the device to go
unmanaged after being re-imaged.

I could think of ideas of why it may not come back as the same device,
but it would certainly be in a managed state.


On 9/8/2014 11:46 AM, kjhurni wrote:
>
> joe_it;2332365 Wrote:
>> Good Morning,
>>
>> Since upgrading to Zenworks 11.3 we are having a very weird issue.
>> Sometimes when we reimage an existing Windows 7 machines a duplicate
>> object is created and the machine goes un-managed. We previously saw
>> this issue when we were upgrading machines from Windows XP to Windows 7,
>> but after the 11.3 upgrade it is happening with Windows 7 to Win 7 as
>> well. To resolve the issue, we delete both objects, then remove and
>> re-register the machine with Zenworks.
>>
>> I am wondering how this can be resolved, and if this is some sort of a
>> bug with 11.3? Thanks for your help on this matter.
>>
>> Joe

>
> Hmm, you're the 2nd person I've seen that's reported this in the
> forums.
>
> Maybe Craig will stop by an offer some guidance.
>
> I'm *assuming* that you reimaged machines prior to 11.3 and that things
> worked fine?
>
> Only thing I can think of:
> Do your images have the 11.3 agent on them now (vs. the old images maybe
> had 11.2.x?)
> We found we had to use that latest ziswin.exe to properly clear out the
> ISD.
>
>



--
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.


Here's the other thread
https://forums.novell.com/showthread.php/478824-Duplicate-GUIDs-since-11-3-1-update
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Zen 11.3 Duplicate Objects

That is actually the opposite, where multiple physical "..used loosely
since they are VMs", share one object in the ZCC.



> Here's the other thread
> https://forums.novell.com/showthread.php/478824-Duplicate-GUIDs-since-11-3-1-update



--
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
Absent Member.. Joe_UW Absent Member..
Absent Member..

Re: Zen 11.3 Duplicate Objects

These are definitely not virtual machines. We have a separate VDI environment that is not having any issues similar to this.

I remember something within Zenworks a while back for identifying the machine via hostname, mac address, etc. I am wondering if those settings got reset?
Can anyone point me where to find these settings again?

Joe
0 Likes
Knowledge Partner
Knowledge Partner

Re: Zen 11.3 Duplicate Objects

joe_it;2332616 wrote:
These are definitely not virtual machines. We have a separate VDI environment that is not having any issues similar to this.

I remember something within Zenworks a while back for identifying the machine via hostname, mac address, etc. I am wondering if those settings got reset?
Can anyone point me where to find these settings again?

Joe


ZCC -> Configuration -> Device Management -> Registration
It's in the reconciliation rules section
I believe you want to uncheck "serial number"
I'd think MAC address would be OK
0 Likes
Absent Member.. Joe_UW Absent Member..
Absent Member..

Re: Zen 11.3 Duplicate Objects

kjhurni, thanks for the quick reply. Here is what is currently checked, let me know if this sounds correct.

Device Naming Template:
${HostName}

Registration Rules
Enable is checked for both items

Device Dynamic Rename
Enable Automatic Renaming is checked. What exactly does this item do?

Reconcile Settings
Mac Address, Machine Name are checked, as well as Enable Differentiation.

Any suggestions out of these items?

Joe
0 Likes
Knowledge Partner
Knowledge Partner

Re: Zen 11.3 Duplicate Objects

joe_it;2332622 wrote:
kjhurni, thanks for the quick reply. Here is what is currently checked, let me know if this sounds correct.

Device Naming Template:
${HostName}

Registration Rules
Enable is checked for both items

Device Dynamic Rename
Enable Automatic Renaming is checked. What exactly does this item do?

Reconcile Settings
Mac Address, Machine Name are checked, as well as Enable Differentiation.

Any suggestions out of these items?

Joe


You've pretty much got the same as our environment.
Automatic renaming is like, if you rename your Windows pc, it'll figure out in the ZCC that it's the same machine name and automatically rename the object in the database.

Otherwise you'd have a fun time hunting down the "new" named object.

We don't normally rename machines a lot, but it's useful if you do have to do it and don't want to keep a list of what the old name was, new name, delete the old object, etc.

Craig may more more insights, but if you haven't changed anything, I'd think there's an issue in the code somewhere if it worked fine before.

The only thing I could think of (but you ruled that out) is that if your image has ISD data in it (depends on how you've installed the agent, etc.), and you're using an older ziswin.exe in a script to clear the data, I've seen the old version not clear stuff that a newer agent puts into the ISD.
0 Likes
Absent Member.. Joe_UW Absent Member..
Absent Member..

Re: Zen 11.3 Duplicate Objects

Per the suggestion of a Zenworks consultant who I have previously worked with, we are going to try changing the Reconcile Settings from machine name to serial number. I will let you know if this makes a difference.

Joe
0 Likes
Knowledge Partner
Knowledge Partner

Re: Zen 11.3 Duplicate Objects

joe_it;2332688 wrote:
Per the suggestion of a Zenworks consultant who I have previously worked with, we are going to try changing the Reconcile Settings from machine name to serial number. I will let you know if this makes a difference.

Joe


No, you do NOT want serial #.
That will cause you all sorts of issues.

ZCM doesn't always use the real serial #, and in the cases where it DOES use it, what happens if your staff replaces a system board and "forgets" to put the serial # in like our staff does? WE ended up with hundreds of Dell motherboards without serial #'s and as such, ended up with hundreds of duplicate GUIDs
0 Likes
BMcDowell1 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
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
Anonymous_User 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
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.