Endpoint Protection

I am currently building a new workstation image and I do not want to install SEP on the machine that will be cloned because future version updates to SEP would mean that I have to update the image. I am planning to stage the install package in the image and then call it via the Altiris DS job that applies the image to the machine. Then in the future I can just replace the install package that is staged in the image.

The reason for staging the install package in the image rather than calling it from a network share is that the images are replicated to branch offices while our Altiris DS fileshare is not. Calling the install package at a branch office over the network will be too slow.

The issue I am running into is figuring out how to make sure that the client gets put in the appropriate group in the SEP Manger.  We are currently achieving this with different install packages: Validated Laptops, Validated Desktops, Non-Validated Laptops, Non-Validated Desktops. I do not want to stage 4 different installers in the image; each one is 250MB.  I've considered staging one expanded installer and then using Altiris to replace sylink.xml and setaid.ini before calling the install. 

Can you suggest a better way of automating the organization of my clients in the SEP Manger?

We're kind of in the same boat, but we have a few more groups. For now, my plan is to have them drop in a default group and then I have a scheduled workflow to move them to the appropriate group based on their AD location.

In you instance, how do you determine the difference between your 4 different options? It sounds like your idea of the different sylinks would be best and copy it down based on the condition you have in place.

For 11.x:

http://www.symantec.com/business/support/index?page=content&id=TECH96808&locale=en_US

For 12.1:

http://www.symantec.com/business/support/index?page=content&id=HOWTO54706

Are you using AD sync? If so, whenever the client is moved in AD, it will also move to the appropriate group in SEPM.

Right now I am only addressing my non-validated machines. I am using an Altiris DS job with different conditions: "default" and "Desktop"

The default condition runs a single task that installs the staged (expanded) non-validated laptop installer. The other condition looks for "Optiplex" in the "Computer Product Name" field; it then overwrites sylink.xml and setaid.ini from the non-validated desktop install package and then runs the installer.

For now, I am documenting the process to move the validated machines to the appropriate group.  I may write a VBS to copy the appropriate sylink.xml file based on the computer name.  This could also address the validated and non-validated tablet computers that I didn't mention.

Hi Brian,

I appreciate your suggestion and I've looked at those articles. They explain how to prepare a machine for cloning after SEP has been installed.  I am following a layered approach to imaging so I don't want to install SEP in the base image.

We are not using AD sync and I am not sure why.  I do know that we have site based OUs in AD but only one site group in SEPM. I'll have to follow-up with someone to see why we didn't mirror the AD structure.

Thanks.

Hi,

As per my understanding I don't see any further scope for automation.

Already you are doing what you can do.

Few points I would like to share:

I believe it's not possible that clients will automatically report to the appropriate group in the SEP Manager without AD synchronization.

You will have to export the appropriate package which you are already doing.

I would suggest let the clients come into the default group and move them appropriately instead of exporting package for each group.In this case you would required only one package. Again for this activity some manual intervention is required.

I am not much convince with the reason that due to future SEP update you are not willing to add it in the base image. In the future you can simply do auto upgrade to upgrade existing SEP clients with the help of SEPM. No need to update image itself.

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

We too replace SYLINK.XML.

I have found that the best way to control the initial group that a machine is placed in. This at least can be automated. Moving objects in the console is a manual process, i.e. not good.

I believe it's not possible that clients will automatically report to the appropriate group in the SEP Manager without AD synchronization.

When you export a package, you can choose to export a managed packagee with the policies for a group. That will force the group. Using the SYLINK.XML from that package solves the group problem as described by the poster.

clients come into the default group and move them appropriately

This requires an operator to do manual processing. It is best to automate these things by planning ahead. Things are less likely to go wrong and will be applied consistently.

I am not much convince with the reason that due to future SEP update

Let me try to convince you.

In the future you can simply do auto upgrade to upgrade existing SEP clients with the help of SEPM. No need to update image itself.

1. Updating one single package is orders of magnitude easier than updating a complete machine image (no matter how well you can do the job)
2. Together with the above point, this means an update can be rolled out a lot faster
3. Together with the above two points, this means a lot less network bandwidth is used.
4. SEPM pushes the package out at a max speed; i.e. not good for the network
5. SEPM pushes the package to every client; i.e. not good for the network, especially across WAN links
6. SEPM does not allow the prestaging of the client to a particular location; i.e. bad for the network because I can't choose when the network usage happens.
7. Without checking, I believe SEPM has very limited time / scheduling functionality; i.e. not possible to do a lights out deployment
8. For SEPM to deploy, the machine must be on; which generally means during business hours; i.e. not good for the user who is impacted by a slow machine & potential reboot.