What are the effects of having duplicate GUID's?
|Article:TECH133462|||||Created: 2010-07-14|||||Updated: 2014-01-06|||||Article URL http://www.symantec.com/docs/TECH133462|
What are the effects of having duplicate GUID's on the Notification Server?
For an Altiris 7.1 best practice to address this issue see:
Shared GUID cleanup script
When 2 or more machines share a common GUID on the same Notification Server, a number of problems will exist.
The root of the problem lies within the data exchange between client and server. When a client sends in inventory it uses its GUID as an identifier for the data to be stored against. When muliple machines all share a common GUID, their data is all recorded against the same identifier with the most recently recieved 'overwriting' the data currently held. When collections are created based upon this data, clients that may or may not be included in the collection dependant upon the order of data recieved and the frequency of the collection update.
To give a real world example of this in practice:
Customer has three machines all sharing a common guid
Machine1 - Win XP SP3
Machine2 - Win2003 SP2 x64
Machine3 - RedHat
Customer creates a SWD task to deployed to ONLY Win XP SP3 machines. They target a collection built using the following SQL statement
SELECT _ResourceGuid FROM Inv_AeX_AC_Identification
WHERE [OS Name] = 'Microsoft Windows XP'
AND [OS Revision] = 'Service Pack 3'
These three machines will be continually changing the data held for the common guid as they send inventory in. In turn, the collection will continually change focus based on the last data recieved against this common guid. If Machine1 was the last machine to send an inventory to the NS prior to the collection update - the guid will be contained in the resultant set of the SQL statement. When Machine2 and Machine3 do a Policy Request to the NS (and in doing so - supply the GUID that is shared) - THEY WILL ALSO RECIEVE THE PACKAGE. Alternately, if either Machine2 or Machine3 had been the most recent to supply data to the NS prior to the collection update, the two fields in the SQL statement would not be satisfied and none of the machines would recieve the package.
When you extend this concept to Patch Management and now have the added complication of the Software Udpate Inventory cycle and the intersect collections for each software update package, the results are near impossible to predict.
Article URL http://www.symantec.com/docs/TECH133462