Deployment and Imaging Group

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

 

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

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.

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.

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!

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

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.

Link added.  We should sticky still.

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

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.

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.

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, 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.

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.

"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!!

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.

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

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).

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