Video Screencast Help

Deploying SEP 12.1 via Startup Script

Created: 03 Dec 2012 | 9 comments

We are about to undetake updating all of our client computers to SEP 12.1 from SEP 11.x.  In deploying SEP 11.x, we utilized the software deployment GPO feature of AD.  This worked OK, but we ended up going down the road of MSI transforms, which proved to be an exercise in frustration.  We are also looking for something a bit more flexible in terms of the deployment source (for example, we want the deployment to be delivered from the closest source to minimize traffic over the WAN), so we are seriously considering scripting it this go around.  

I've already got a VB script that does something very similar for another application we use, but that deployment is much simpler (no installer, it's just simply copying files).  I'm fairly confident I can modify it to suit our needs for SEP, but I'm envisioning two big problems/unknowns that I'm wondering if anyone could assist with:

1.)  Share permissions - I can envision permissions being an issue.  We want to run this as a startup script, before there is any user even logged in.  I'm honestly not sure how we would go about making sure that the script has the necessary elevated permissions to access the shares.  Any thoughts on how this might be accomplished?

2.)  Context of installation/Where it runs - This one might be a bit tricky to explain.  The VB scipt would do some logic to see where the user is located, then point them to a deployment share based on their location.  This would then simply kick of a batch file that would run the Symantec isntaller from the command line wiht the desired settings and options.  The script is then done at that point, but we'd then have a command window running the Symantec installer floating around somewhere (I'm honestly not sure where, since there wouldn't be a user logged in at this point).  

   a.)  Is there a way to delay user login until the batch file finishes running the install?

   b.)  If not, what does this look like to the user?  Are they going to see a command prompt windo appear when the login?

These are the two big points that concern me a bit.  If anyone has any experience doing anything similar, I'd love to hear your thoughts or hear how you accomplished something similar.  

Thanks!

Comments 9 CommentsJump to latest comment

.Brian's picture

Do you have SCCM in your environment?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

aparkerSIA's picture

We do not.  I'm honestly not incredibly familiar with SCCM--what would that get us in this particular instance?  

Honestly though, I don't want to overcomplicate this too much.  We are willing to fall back on our GPO method if necessary, but were wanting to purue the scripting route first.  

.Brian's picture

The installer should run in the SYSTEM context so permissions shouldn't be an issue.

You can create the SEP package you're going to use to run silently and not force a reboot.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

aparkerSIA's picture

I'm not so much worried about permissions with regards to how the installer runs as I am about permissions for accessing the installer (which will be on a hidden network share).  

From what I've gathered up to this point, I don't think permissions will be a huge deal, it will just take a bit of testing.  What I'm really getting hung up on at this point is my second issue above.  Once the installer is kicked off from a batch file, I'm not at all clear what happens to that process once the user logs in (and if the user logging in poses any issues to the installation/upgrade process itself).  

.Brian's picture

Assuming the install is silent, I don't think you will see much of anything. If it's not silent, than you will see the install going on.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

pete_4u2002's picture

do you have altiris or any tjird party managment which can push the s/w?

 

aparkerSIA's picture

We do not.  That would definitely be the preferred method if that was available, but that is unfortuantely not an option at this point.    

Mithun Sanghavi's picture

Hello,

Here are few Articles which may help you with Installation - 

Installing client software using third-party tools

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

About installing clients with Microsoft SMS 2003

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

Installing clients with Microsoft SMS 2003

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

A Thread with a Similar Issue. 

https://www-secure.symantec.com/connect/forums/installing-endpoint-protection-microsoft-sms-2003

In addition to this - 

When Installing Symantec Endpoint Protection 11 by Active Directory Group Policy Object, Which Method of Deployment is Supported?

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

About installing clients with Active Directory Group Policy Object

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

Creating a GPO software distribution

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

Reference: https://www-secure.symantec.com/connect/forums/ad-syncing-and-client-deployment

https://www-secure.symantec.com/connect/forums/problem-installing-endpoint-protection-11-12-through-sms-andor-sccm

https://www-secure.symantec.com/connect/forums/sep-121-any-tips-sccm-deployment

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

aparkerSIA's picture

As mentioned above, we do not have SMS or SCCM implemented in our environment (nor do we have any 3rd party deployment software in play).  

The GPO links are great, but I'm already familiar with most of those things (as I mentioned, we are using GPO software deployment currently).  We were hoping to get a little more control over how SEP gets deployed, hence the research on scripting the process.