Deployment Solution

We are ordering systems from Dell and have uploaded an image for this purpose. I used sysprep manually, then created a backup image to send to Dell. My process included using /resetguid on the agent and I felt at the time this would be good enough to prevent issues with shared GUIDs etc.. I now know after reading more forum discussions that I should not have done this. However, using "prepare for catpure" was not an option since I needed more customization of sysprep etc... I downloaded the reports for the shared GUID troubleshooting and found that I do infact have machines showing up with an AKA of my original system name after we deploy the image to test machines. Updating the image and sending back to Dell is not an option right now, so I need to find a solution for after the systems arrive.

Thank you very much for any assistance you can provide. Right now as I understand, I'll need to have our technicians delete the computer account within SMP and run the /resetguid switch again. Unless I want to reinstall the agent.

Other information if it helps:

1. I have sysprep configured to prompt for a computername on first boot. Therefore, the computer is named after the agent is installed.

2. In the registry under HKLM\Software\Altiris I found that machineGUID is blank in most places except not under the Inventory Agent section.

Hi,

have you checked the guids on the computers, so that you  know they are really duplicate? The report searches for systems which change names and your process includes that the name is changed, after the agent registers. Also it would be typical for duplicate guid issues, that the name of the resource with the duplicate guid changes several times (every time a agent with that guid sends a basic inventory).

Well... not really.  The main problem you may have is that of NOT assigning a new name to the system when you customized your Unattend.XML file.  If the system boots back up with the same name/domain, it tries to update the existing record in the console as it "found a match".

So you may be seeing a combination of problems.

It should be noted that when a system comes up and looks to see if it's "new" or "known" it checks for a match against 3 different "unique identifiers."  Any one of the 3 will find a match.  The 3 are:

• Name/Domain
• FQDN
• SN + UUID Hash

So if the computer image you have has either of the first two the same, then it will be a match and over-write records in the console.

The concept of /ResetGuid is a good one in general, but not a very safe method.  It would be much safer if you had a newer version of our config service IN the image.  Basically, we found an issue you're probably not aware of documented more here: TECH203390  The short explanation is that we start the Altiris Agent so fast, that at times, we send up inventory before the Unattend.XML has even been processed!!  So your "resetguid" probably never hit.

Ideally, you'll get that new config service to Del and inserted into your image.  The only difference is that we no longer start the altiris agent - we let it happen natually after MiniSetup is done.  My guess is that this alone would help your issue significantly.

Without that, I'm afraid that we're just to stupid fast for all your customizations.  <sigh>  Clean-up may be your only option.

I think you hit the nail on the head. Since it's too late to update our image with Dell (those guys are quick so we already have all of the hardware). What would be the best clean-up solution? I already have a policy that gets applied to these boxes once they check in for other "clean up" items we've been finding. I wonder if I could have a filter based on the shared GUID report query that will delete computer accounts that have duplicate names automatically?

Thank you very much for the insight!

Dustin,

You will probably find the Duplicate GUID tool kit useful for your scenario and needs. You can find it here;

http://www.symantec.com/docs/TECH142625

This should help you address clients that "connect up" in the bad state.

Another thought would be to build a USB or other boot device media with some OS on it, that has the capabilities of modifying the registry of the OS / filesystem on the machine. You could make the AexNSClient (Symantec Management Agent) service be in a stopped non starting state and potentially replace some of the unattend.xml informatoin if you're at that state, so that it (the SMA) gets enabled and starts -after- the computer rename takes place? Just some alternate thoughts, that may be way more work/complex than you want to worry about.

Regards,

Rasmus

ideally, when a system like this starts, you'd prevent the Altiris service from running so it can't check in.  Then, that system could have the AexAgentUtil run on it to reset the GUID, and THEN start the service, or clear the registry key with the GUID or something so that it doesn't report in with the same GUID at any time.  

How to do that?  Hmmm...  Not sure.

Otherwise, mop-up may be your only option.  it might be ugly for a short time, but with some diligence, you should be able to clean things up.

I think, were it me mopping things up, I'd send out a GPO disabling the agent, then ensure that all the systems were uniquely named, clean up the DB from all the bad records, wipe the GUID from the registry on those systems via GPO again, and re-enable the agent.  Or, alternatively instead of wiping the GUID, pull the agent, and then re-push it.  Either one might work.

My fear is that anything less thorough might leave you never knowing if everything is cleaned up or not. :P