Macs getting duplicate GUIDs

[JAunmc]

We have 2 new Mac laptops. Both fresh out of the box.  Both have the Altiris agent installed.  They get duplicate guids and overwrite data in the system including the asset data which is bad.  We deleted the Guid file from both and they both get a new guid with is also duplicated.  They both get the same IP address but are not on at the same time.  Is the agent GUID generated from the IP address on the Mac?  They have different seial numbers and network names. 

 

This has happened before and we are having data loss from this.

 

Anyone have any ideas?

 

Looked here:

http://www.symantec.com/business/support/index?page=content&id=HOWTO10372&profileURL=https%3A%2F%2Fsymaccount-profile.symantec.com%2FSSO%2Findex.jsp%3FssoID%3D13842755665573aOqx5DnP2W5QmK84F25gxSu6Q1CjW745gbHE

 

But was wondering how this happens on a Mac. 

 

It appears that our network is assigning them the netbios names of other computers on the network that previously had that IP.  This has been going on with macs for years and is not a new issue. 

 

Really confused...

[Migration User]

How are you installing the agents on the Mac's?

[JAunmc]

Using the aex-bootstrap install.  I have a small command script that makes it easier for people.  They unzip a file to the desktop then run the .command.

 

#!/bin/bash

sudo chmod u+x ~/desktop/install/aex-bootstrap-macosx

cd ~/desktop/install
sudo
./aex-bootstrap-macosx http://myaltiris.server.com

killall terminal

[Andrei Fedulin]

Hi JAunmc,

For Mac same keys are generated as you found in http://www.symantec.com/business/support/index?page=content&id=HOWTO10372

IP address is not  included to resource keys.

To find out duplicate keys follow steps from this howto:

http://www.symantec.com/business/support/index?page=content&id=HOWTO77403

This will show you all resource keys, some of which should be duplicate keys between these laptops.

Once you have identified these duplicate keys, then we can see what we can do. 

Can you please post here output from both machines? If it is name.domain key then we can look at Targeted Agent Settings ( there is an option that controlls this key generation)

Also one of the workarounds is  described here http://www.symantec.com/business/support/index?page=content&id=HOWTO60919  ( disable some resource keys). 

Thanks,

Andrei

[Migration User]

I work with JAUNMC and was able to get these details from the two macs. Isnt the unique id supposed to be generated on the NS randomly? Also, where is the aex-helper getting the second name.domain, FQDN and the mac address. None of these are correct after the first name.domain on both, the only way it could be getting this info is if it is grabbing it from DNS rather than on the machine itself. These are nto virtual machines.

 

MAC #1:

an-uh1467-tara:bin tara$ sudo aex-helper query resource

Resource GUID: {895BFA90-E83A-40C6-A288-3E1C233DD787}

Resource Type: Computer ({493435F7-3B17-4C4C-B07F-C23E7AB7781F})

Resource keys:

name.domain=an-uh1467-tara

fqdn=its-watts-v.*******.org

name.domain=its-watts-v.*******.org

macaddress=B8-8D-12-52-FC-27

uniqueid=xRTkhs1HGNwHXQmB9q1Srg==

 

MAC #2:

Resource GUID: {895BFA90-E83A-40C6-A288-3E1C233DD787}

Resource Type: Computer ({493435F7-3B17-4C4C-B07F-C23E7AB7781F})

Resource keys:

name.domain=an-uh1467-w

fqdn=its-watts-v.*******.org

name.domain=its-watts-v.*******.org

macaddress=B8-8D-12-52-FC-27

uniqueid=xRTkhs1HGNwHXQmB9q1Srg==

 

 

[Andrei Fedulin]

Hi DHunmc,

Uniqueid key is generated by agent. It is combined key from mac address, hw serial nr etc.

From the output you have provided, seems that  problem is in the same Mac Addresses.

Can you confirm that mac addresses are the same on both laptops? Can you please post `ifconfig -a` output  from both laptops?

What about second name.domain and fqdn - they are gathering using DNS

(fqdn will be gathered from AD if Mac is binded to AD - this is applicable to 7.5).

 

Thanks,

Andrei

 

[Migration User]

If the uniqueid is being generated by the agent, then how did both of these machines with different hardware serial numbers generate the same uniqueid? The serial numbers for both machines are nearly identical with only one digit being different.

The mac address is being gathered from the usb to ethernet adapter that was used on both macs. This will likey be a problem in the future as some models of macs do not have ethernet adapters and will require this method for setup.

I wonder if the new netbooks used with a usb to ethernet adapter will exibhit the same behavior. One would hope that the actual hardware serial number of the machine would play a role in the process for generating a uniqueid and GUID.

[Migration User]

ifconig's for each machine with the same USB adapter attached:

Walker

 

en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

         options=4<VLAN_MTU>

         ether b8:8d:12:52:fc:27

         inet6 fe80::ba8d:12ff:fe52:fc27%en3 prefixlen 64 scopeid 0x9

         inet 10.104.129.11 netmask 0xffffffc0 broadcast 10.104.129.63

         nd6 options=1<PERFORMNUD>

         media: autoselect (100baseTX <full-duplex>)

            status: active

Tara

en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

         options=4<VLAN_MTU>

         ether b8:8d:12:52:fc:27

         inet6 fe80::ba8d:12ff:fe52:fc27%en4 prefixlen 64 scopeid 0x9

         inet 10.104.129.11 netmask 0xffffffc0 broadcast 10.104.129.63

         nd6 options=1<PERFORMNUD>

         media: autoselect (100baseTX <full-duplex>)

            status: active

 

[Migration User]

I used the exact same adapter on a windows machine. I had the windows machine generate a new guid, and it did generate a new, unique guid. So this issue appears to be limited to macs.

[Andrei Fedulin]

Yep, thank you for pointing this out.

Can you please specify agent version as well?(`aex-helper -v`)

I will try to figure out why uniqueid is the same,however with identical mac addresses computers will still be merged, as mac address is one of the resource keys. Such behaviour should be applicable for windows as well, as both windows and mac agents use it as resourse key. Maybe on windows there was one more ethernet adapter/wifi adapter, so agent was able to update it resource keys on NS before same usb to ethernet adapter was plugged to different windows machine.

Currently I can suggest you to disable uniqueid and mac addresses as resoruce keys for these particular laptops (it is described in this articale  http://www.symantec.com/business/support/index?page=content&id=HOWTO60919 ).

 

Thanks,

Andrei

[Migration User]

Client version: 7.1.8280

We changed our merge rules to merge on serial number long ago.

As for the possability of the windows machine using a different network connection, i disabled both the wireless and wired connections leaving only the usb to ethernet.

If we disable the mac address and unique id, what does that leave us for generating a 'unique' resource guid if we are still using the usb to ethernet adapter on our macs? I dont understand how that helps our situation?

[Migration User]

Andrei, have you had a chance to review this?

[Andrei Fedulin]

Hi DHunmc,

Agent sends 4 types of resource keys (name.domain,fqdn,mac address, uniqueid) based on which NS server decides if resource is duplicate of some other resource or not. In your case mac address is the same on both computers. Unqueid is the same as well and is based only on Mac address ( here we have another  problem with uniqueid generation which doesn't include serial and hw numbers).So the problem is in these keys - Mac address and uniqueid. Disabling mac address and uniqueid  should help to avoid merging, as only name.domain and fqdn will controll resource uniqueness on NS Side.

I am not really sure about your custom merging rule based on hardware serial number and how it works(agent doesn't send any hardware serial numbers as resource keys - only as basic inventory field , which should be correct i (you can check it Aex_AC_Identification dataclass) and your custom rule should probably work as you expect if you use this value)

If you  didn't modified dbo.ResourceTypeMergeKey, then disabling mac address and uniqueid on agent side should probably help. Did you have a chance to verify this?

Regards,

Andrei  

 

 

 

 

[Migration User]

It seems this problem is also caused by the Mac computers pulling down their FQDN and name.domain information from DNS, rather than using the local machines name. (http://reviews.cnet.com/8301-13727_7-10362633-263.html) 

This problem then is two fold.

The macs generate half the problem themselves when used with a usb to ethernet adapter by pulling down whatever name (FDQN/name.domain) that was last tied to the adapter. And then the Altiris client failing to generate a uniqueid. (Uniqueid is the same as well and is based only on Mac address). This can partially be fixed by running the commands in the script above. This should cause the Mac to keep its FDQN/Name.Domain as entered by the tech setting up the machine.

However I was incorrect when I said we were merging on serial numbers. I had confused our inventory to asset merge, which we changed to be based on serial numbers. In this article (http://www.symantec.com/business/support/index?page=content&id=HOWTO61173) It seems that just disabling the mac address and unique id will not be enough to prevent merging during the decision to generate a new guid or issue a current guid already in the system.

There may be a work around then:

We would need to apply both fixes to get a unique GUID generated for a machine. I took your advice and removed the mac and uniqueid from the equation. I also set the mac name like in the article above. When I ran this, the FQDN field was still incorrectly populated and resulted in a duplicate guid. The agent must be using the DNS name attached to the IP still.

Try #2(?), I removed the FQDN from the list in the same way that I removed the mac address and the unique id. Now the machine should be only calculating the guid off of the local name of the mac as I set it. Indeed this worked and a unique GUID was generated.

There seems to be quite a few flaws with the agent in its creation if the unique id, and how the agent obtains the FQDN. This may be something that Symantec may want to look into in the future as more macbook airs are imaged off of usb to ethernet dongles. For now this is a "workable" solution.

[ziggy]

Happening to us as well (for years!)  Good info, lets fix this up (before going to 7.5).

 

NOTE: please let me know if we can modify guid generation for WIndows based computers!!!!!!!

[Migration User]

It appears that you are using the same usb ethernet adapter on multiple machines. In a default SMP configuration, along with a default dhcp/dns configuration, that would result in multiple machines having the same mac address, ip address and fqdn values. (Since the uniqueid on a mac is based solely on the mac address, the uniqueid would also be duplicated across mac clients.) 

 

See: http://www.symantec.com/docs/HOWTO85011 - SMP Resource Key Creation Logic for Mac OS Client Computers

 

It appears you have already found the proper configuration for this scenario, which is: Ensure the Targeted Agent Settings for Mac clients is to use the local hostname for the computer name and Domain name is set to none/empty. Then, set the client's 'ignore_resource_keys' value to exclude all available resource keys. (Note that the hostname cannot be excluded so it will continue to be used as a resource key.) 

 

See http://www.symantec.com/docs/HOWTO60919 - Managing resource keys for event generation on Unix, Linux & Macintosh clients

 

At that point, the only resource key that gets generated should be a 'name.domain' that includes only the local hostname. 

 

That should resolve your issue, if I understand the scenario correctly. 

[Migration User]

Why does the mac agent not use the UUID or hardware serial number when generating the uniqueid and ultimately the guid? This seems like a very important item to include. It is listed in the documentation stated previously in the post, and it is used in generating a uniqueid/guid on windows machines. Is this an acknowledged bug in the mac client? I believe this needs to be fixed regardless of the usb dongle or ethernet issue. It must have been included at one time if it is part of the documentation, and now is clearly not.

 

Also why would FQDN be used in the mac client's creation of a uniqueid if it is a widely known problem that macs adopt any FQDN. Mac merging should not occur on the NS/DB level for FQDN. This is prevelent on non AD domain joined macs, however it can still appear on macs that are domain joined if they connect to a site network.

[Migration User]

The documentation you are reading is for the Windows agent, not the Unix, Linux and Mac (ULM) agent. The OS is different in each case and presents unique challenges. In the case of the uniqueid resource key for mac clients, I am told that the decision was made to use solely the mac address as the other two components were not available on macs. It's not a bug. It's a design consideration. I, personally, would rather not have the uniqueid resource key get created if it's a duplciate of another key, but that's not my decision. 

As for the FQDN resource key, it is a very important unique identifier in a properly configured network environment. The way an nslookup of an ip address works is that the dns/dhcp system goes to the cached value rather than to the 'live' source for fqdn values. That's not a Symantec thing. Rather we are dependent on that source. When the cache refresh interval is long enough that data gets stale, Symantec is provided with stale data. In your case, I imagine that you're connecting the same ethernet usb adapter to multiple physical machines per day, there's no feasible way to keep the dns/dhcp cache current. We're a victim of what the environment provides. There is a way to configure the SMP server and each client machine to work around your scenario, as previously explained. 

[Migration User]

So it is important for the windows side to use the UUID and hardware serial number in generation of the uniqueid/guid, but it is not important for macs? Given the changing environment of macs, where they now come with out ethernet ports, and that the symantec product does mac imaging, I would think that it would be important to evolve the mac agent. The UUID and hardware serial number are not difficult to obtain for the agent (command: System_Profiler SPHardwareDataType). So with it being so simple, and now mac book airs being shiped with out ethernet ports requiring the use of USB dongles for imaging... Doesnt it make sense to now add this simple and effective way of creating a unique identifier?

[Migration User]

Regarding the mac agent not taking into account the known issue of macs adopting incorrect FQDN's:

Apple has known about this for some time and does not care. They will not change how their operating system works and absoutely do not care if it negatively affects symantec's products. On the other hand, syamntec knowing about this issue and that it can be fed easily incorrect data should then be looking to overcome the issue rather than use data that is known to be faulty. The NS will merge based off any of the keys fed to it by the agent, and the one in question in our case is the FQDN. We acknowledge that the mac agent will pick up an FQDN regardless of source and then use it to look for known computers in the database. If that FQDN shows up, and it likely will in this scenario, it will merge, and issue the guid based off that with out any additional checking. This may be quick but it is not intelligent.

 

FQDN merging from macs and GUID generation are simple fixes of now known problems. It seems it would be important to improve the product.