Video Screencast Help

"The SMP agent CAN and SHOULD be cloned." -- Thomas Baird

Created: 02 Aug 2011 • Updated: 25 Apr 2013 | 17 comments

Please make this sticky for a while.  It is good for all to read.

 

Ooohhhh! That's what you mean by clone...

The NS agent in SMP 7.1 is SUPPOSED to be in the image.  Never remove it, if possible.  Some prefer to do things differently, but truth be told, that's the hard way.  WAY hard way.  We built the product on the ASSUMPTION that the SMP agent with the deployment plugins would be in the image.  Just like DAgent needed to be in the image for it to be managed once it came back up, so too, the SMP agent needs to be in the image so that it's managed when it comes back up.  It's the exact same principle.  The SMP agent CAN and SHOULD be cloned.

The difference?

If you simply capture the image and let it report back in - say with another product - the SMP agent will muck up the entire DB.  This is where the rumor of "it can't be cloned" comes from.  However, IF you do as the product is designed and actually use the "prepare for image capture" task, then we clean up the SMP agent install so it CAN be cloned.

THIS is the step that people miss.  For instance, they may run Sysprep manually - not supported.  Or they may simply capture the image without sysprep - also not supported.  

To "clone" a PC in DS 7.x, the SMP agent SHOULD be on the system, and you NEED to use the "Prepare for image capture" task.

If you review the Support Quick Start guide  http://www.symantec.com/docs/HOWTO30267 we put out, you'll see that we specify this task.  It's a very short KB compared to the very antiquated and nearly useless one that we published way back in DS 7.0 days.  But it's still valid.

Oh, and use Ghost, or there's a missing task in that guide... I need to update that some day......

 

Anyway, it's all there and all works.  :D

Thomas Baird
Endpoint Management Specialist 

Comments 17 CommentsJump to latest comment

bhawver's picture

Hi readzzz,

This is good info.  I would suggest that you add a link to the document that you are referring to so that it is in one spot for the search engine challenged.

You also might message Cheryl (ohzone) so that she can put it as a sticky in case she doesn't see it.

Brian Hawver
Systems Engineer
Yaskawa America, Inc.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

bhawver's picture

Thomas is not 100% correct when it comes to the 6.x days and dagent/aclient.  It actually is NOT best practice to include the dagent/aclient in the image.  I've seen that posted many times and don't believe that has changed in the later versions of 6.9.  It's actually better to have the dagent/aclient installed via a post sysprep script (i.e. cmdlines.txt).

Regarding the SMP agent, that I can't say for sure, but I assume he is correct in that arena in the 7.x world.

Brian Hawver
Systems Engineer
Yaskawa America, Inc.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

readzzz's picture

I have never had a problem cloning the 6.x deployment agents.  I do purge all log files.

To build a sysprep image via the DS console as designed, the aclient of dagent must be installed on the machine .

 

This is a chicken before the egg issue if you are using DS to create your sysprep base images.

DS + SVS = IT Bliss

bhawver's picture

Potential for duplicate GUIDs.

And you would need to update your image everytime you updated DS.  Doing it the best practices way ensures that you always have the latest version of the dagent and aclient your server has to offer.

We can do a lot of things that aren't best practice and get them to work just fine in our own environments.  I was only pointing out what was considered best practices in the 6.x days.

Here's a link to the blog that refers to this.

https://www-secure.symantec.com/connect/blogs/installing-aclient-part-sysprep

Brian Hawver
Systems Engineer
Yaskawa America, Inc.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

readzzz's picture

It is a best practice to update your images and certify them to a specific DS version. 

 

Minor changes in the imaging formats .img / ,gho could cause you issues.

DS + SVS = IT Bliss

Thomas Baird's picture

The previous poster misunderstood what I said in my reply.  In 7.x, the NS Agent (take note, not DS - NS) should be included in the image because it is how DS gets everything done.  In the 6.x Days, DS did it's work with DAgent / AClient, but the NS agent would not be included.  That is a distinct change because DS is now a part of NS, but in 6.x, it was not.

My post was 100% correct, so long as you distinguish 1) the versions (which was specified) and 2) the agents.

In fact, if you want to include the DAgent and AClient in the 7.x world - you can still.  No problem there.

Now, if you're using DS 6.9 to image a 7.x NS client/system, then you'd still want to remove the NS agent.  This is a supported scenario, but note: you're not imaging in the 7.x world at that point, you're using 6.x DS, so again, my rules still apply.

Please remember everyone that DS 6.x is a 100% separate product from Notification Server of any version or type.  Those two products never were truly connected, though we made a valient effort to do so in v6.  In v7, we simply dumped DS 6.x and put Deployment functionality into the Symantec Management Platform.

Thomas Baird
Private Consultant & open to full-time opportunities.
That means I CAN help beyond the forum (directly).

 

readzzz's picture

The point of this thread is to identify:

  1. The NS 6.x altiris agent was not intended to be cloned.
  2. I was unsure of SMP 7.1 agents clonability, and until I saw this comment, I did not have that answer in any documentation.
  3. The information sharing component of this post assumes that other 6.x NS users who have not yet made ANY jump into 7.X may not know that the 7.X agent can be cloned, but only when using the 7.X deployment engine.
  • (As always the aclient/dagent can be cloned for Heritage 6.9 Deployment Solution users.  Those agents contain no unique GUIDS.)

For the rest of us using 6.9 up to SP5 MR1 to image, we will need to push the SMP 7.X agent after the image and provisioning occurs.

This of course will add delays during post provision if there is a software rollout dependency tied to the SMP 7.x agents. 

We had a script to "Tickle" the NS agent for 6.X NS post provision to get it to quickly update it's initial communications and inventories to the NS database.

Is there a method to "Tickle" SMP agent to check in with the 7.x codebase?

If so we can start a new thread on this one.

DS + SVS = IT Bliss

DustinW's picture

Thomas - does this also mean that you should also allow your master image to download every plug-in successfully prior to "cloning"? I just ran into a problem today where, on my master image, I had allowed every plugin except for the Software Management Solution plugin to download and install successfully. When I deployed that image, I found that that plugin was in kind of a hung state. It indicated that the last download attempt failed, and gave a date of 7/16 - the day I created the image. But it wouldn't make any attempt to re-do the download. In the SMA, under Application Tasks, if I clicked on the plugin, it would re-attempt download and install the task, but without manual intervention it was screwed. I fixed this by disabling the policy installing the plugin, then re-enabling a short time later.

I haven't seen this problem on many computers, just on a few. But the behaviour is easy to correct - I can create a brand new image from scratch in less than an hour and a half, thanks to the SOI!

Sally5432's picture

We have all plugins on our base image and so far patches etc downloading ok (knock on wood)

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Thomas Baird's picture

As a rule of thumb, installing all the plugins into the master is faster/better/easier.  Yes.

However, we've seen some ... interesting issues with this I should at least mention.  What happens is that the SMP agent will check in while sysprep is still running, and try to actually perform work.  We've not yet firgured out a good way to prevent this other than to make sure the new systems don't immediately get into any collections, OR to make sure that the agent on these systems is given a 5 minute delay on startup.

This Delay on startup is a feature of the Symantec Management Agent, not Deployment.  It literally tells the agent to chill for the first X minutes and do nothing.  That could be used to prevent conflicts with various things when starting a computer, including the initial virus-scan from SEP or something.  Imagine for yourself the impact of SEP and Patch doing a full scan, oh, and for fun, toss in a full Inventory every time a computer starts.  By putting in a delay, you can allow for other "initial" processes to complete.

In this specific case, the 5 minute delay would allow Sysprep to complete before connecting to the NS and pulling down the latest policy.

Just a thought.

Thomas Baird
Private Consultant & open to full-time opportunities.
That means I CAN help beyond the forum (directly).

 

Sally5432's picture

Thomas,

Are you saying cms/ds has some way to introduce the 5 min delay built in? If so, can you point me in the riight direction where that is ?

For now, I'm introducing delay using update client configuration task and run win sys assessment scan tasks to introduce delay before my post image tasks run. I suspect the update client configuration task will break my job later when the agent needs to update plugins or something ( I saw the breaking of the job when I took pcanywhere off my image and the update client configuration task would blink whole agent, thus failing the DS job). Other posts have suggested using a ping but this ping task fails when sysprep reboots the machine.

Thanks for any ideas.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Thomas Baird's picture

We just recommend a server-side script that does the equivelent of wScript's "sleep" - but for cScript (which is what we call in our VBScript tasks).  Sadly, we have nothing better.

Thomas Baird
Private Consultant & open to full-time opportunities.
That means I CAN help beyond the forum (directly).

 

Thomas Baird's picture

"Best Practices" differ based on your own experiences, what your comfortable doing, and what your environment is.  When Symantec creates best-practice docs, they involve how the software was designed from our perspective relative to how we think a good network should be built.  Obviously, that wont fit every scenario.  There are, however, a few given that, if you don't do them, well, it'll catch up with you.

1) Having a Lab.  Simply put, how can you know if a best practice, or any practice, will work for you if you don't test it?  It's really a scary thing we hear about quite often when someone tries something for the first time in production and break everything.

2) Making Backups.  <sigh>  I don't know how to say this more, but if you upgrade your production environment without a backup, or purge some SQL tables without a backup...  I just don't know what to say.  Our current fav was a call the other day from someone with a hard drive failure that wanted us to recover the data.  Nice wish I'll admit, but seriously, if you have a backup plan, you'll be better off.  We have some pretty nice software for that BTW at Symantec called Backup Exec...  (shameless plug)

3) Searching the KB, or at least Google.  Save yourself a lot of time and grief.

From there, we'll try to help get you started with our best practice guides, but you'll eventually have to make your own.  Ultimately, there are pros and cons to nearly every practice out there, and what will work for you WILL ultimately be different than for nearly everyone else.

GL everyone!!

Thomas Baird
Private Consultant & open to full-time opportunities.
That means I CAN help beyond the forum (directly).

 

Sally5432's picture

Thomas - what's recommended in terms of how to backup CMS?

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Bourdin Laurent's picture

Hello,

I've checked what DSPluginIsntall do after SOI to accelerate SMP agent configuration. This Agent poulate some registry key (MachineGUID) pulled from C:\MacGUID.txt

Removing every MachineGuid key on registry before capture should do the trick or not?

 

Regards

Laurent

chris.vanderlinden's picture

What do you mean by using Ghost?

 

Are you saying that the Ghost format should be used over the Rapideploy format? 

(Specific to CMS deploy and capture image options - not Norton Ghost the application).