Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

RE-Imaging of existing computers causing computers to be blacklisted

Created: 28 Aug 2014 | 14 comments

We have been fighting this issue for some time and have not gotten much help from Support.  We are seeing an increase in the number of computers that get blacklisted as a result of being re-imaged.

Our computers are named based on the 3 charecter facility code followed by the last 6 charecters of the MAC address.  We have devices that can move from one facility to another as a result of a repair of hardware.

 

Our image process includes determing the computer name while in WinPE and injecting that into the unattend.xml so that the computer is named correctly for the facility when it is joined to the domain.  We also specifiy the OU to place the computer in when it joins using the unattend.xml.

 

That whole process works great for new computers.  For a while it worked great for existing computers.  Now, we are seeing when the Boot to Production task runs, once the computer checks in, the agent gets black listed.  Any remaining jobs in the image job as a whole are lost.  This was not an issue in 7.1 but seems to have gotten worse the longer we have been using 7.5 SP1.

 

Any ideas?

Operating Systems:

Comments 14 CommentsJump to latest comment

jms97's picture

Hello.  That sounds VERY familiar.  You are not alone.  We have resorted to deleting the machine name from Altiris prior to re-imaging that machine.  It is not a fix, but it will get you by.  If anyone else has any thoughts or ideas, please let us know.

If you come up with anything on this, please share.  I would appreciate it.

 

Thanks!

 

JannasTo's picture

Just curious but why would you not use the Computername token in unatend.xml for managed machines ?

J.

 

Thomas Baird's picture

Can't in 7.5, well, can't without scripting...  Using the computer name in the Unattend works great in 6.9, just not in 7.5 IF you have a custom Unattend, which they obviously have.  That said, it can be scripted

Remember too, if the system is being "moved" then the old computer name may not want to be the new one.

Thomas Baird
Looking for opportunities
(translation: unemployed!  LOL)
Yes, able to help people beyond the forum if need be.

 

JeffCarlson's picture

We have 9 different facilities, it is possible that a device would be removed from one faciilty and taken to a different one.  Since our naming scheme is faciity code + last 6 of the mac address, the name would change if the device changes facility.

We have a centralized repair team.  When a facility has a computer that needs hardware repair, bad hard drive, video, etc, it gets sent to the repair group.  Instead of waiting for the device to be repaired and sent back, they swap the device.  Once the broken device gets repaired, it would likely make it to a different facility in exchange.

Thomas Baird's picture

Duplicate Guids involved in any way?  Do you have the remove duplicate GUIDs script running in your environment on a regular basis?  That script purposely blacklists computers...

 

Just wondering...

Thomas Baird
Looking for opportunities
(translation: unemployed!  LOL)
Yes, able to help people beyond the forum if need be.

 

JeffCarlson's picture

I do see duplicate guids.  I have been running the duplicate guid cleanup scripts.

There are also a number of duplicate items in the ResourceKey table.  Multiple duplicates of uniqueid KeyValues that are listed with different guids.  Not quite sure the best way to clean those up.

david_evans's picture

Is there a case for this issue? I've had somebody from backline take a quick look and they need some more detials.

Thanks,

David

________________________________

David Evans
Senior Product Manager
Deployment Solution, Server Management Suite, Task Server
www.symantec.com
________________________________
 

Lark's picture

This has probably already been asked by support but is your Symantec Management Agent captured in your image(s)?  If so are you absolutely sure its guid has been reset?  Has it been updated to the 7.5 SP1 agent?

JeffCarlson's picture

Good question.  Yes, the agent is in the image, yes the guid has been reset.  The blacklist doesnt always happen.  We have noticed that it happens more frequently when a computer changes its name and OU it is in.

Lark's picture

Does it ever happen for computers that are rebuilt and re-deployed in the same facilty?  In that scenario it sounds like the computer would get exactly the same name (and same OU?) as previous.

Also, have you tried delaying the first (post image) start-up of the agent?  So in the image, set the SMA to disabled and add a command late in the unattend.xml to re-enable it?

JeffCarlson's picture

I need to check the same facility issue.  I dont think it does.  As for the agent starting up.  It already waits for sysprep to finish before starting.  We can see it in the logs.  The agent isnt starting until after minisetup is complete.

Lark's picture

My comments about delaying the agent are a little historical - the SMA used to be terrible at not waiting until mini setup was finished.  It sounds like you've checked for that and its not.

My next suggestion would be to isolate the problem some more.  For example:

  • Change name, leave in same OU
  • Change OU, leave name same

 

Btw how do you set the name and OU?  Is it a script prompting for details in WinPE that then injects this into the unattend.xml?

JeffCarlson's picture

We have done some testing like that.  Since we have stopped the AD import updates from happening it doesnt seem to be happening as often.

As for the Name and OU, in our unattend, we have %COMPUTERNAME% and %OUMEMBERSHIP% tokens setup.  We are running a vbscript to read the unattend that the deploy image task lays down and replace the tokens with the name and ou we specify in the script.  The OU is hardcoded in the vbs, the name is generated off the last 6 of the mac address.