Endpoint Protection

I work for a school district supporting a number of schools. Recently we updated to SEP 12.1.2 and one of our system engineers provided an installer package we could use (via ARD or direct install, etc.) Or possibly even an Altiris policy, we'll see.

My question is that the 12.1.2 Mac package he provided to us was odd...unlike any Mac .pkg installer I've ever seen. Here's the directory of files:

Hi Bryan,

Thanks for the question.  Yes, the installer for SEP for Mac changed in 12.1 RU2.  This is for compatability with new security architecture in MAC OS X 10.8.2.  Apple has introduced a gatekeeper which ensures that all software getting installed is signed, similar to putting software onto an iPad or iPod I believe. 

OS X: About Gatekeeper
http://support.apple.com/kb/HT5290

This new approach has necessitated some changes to the way SEP is structured.  There is no longer a metapackage (.mpkg file), but a flat installer package (.pkg file) which is signed with a new Apple-issued certificate.

The general install should occur just like in previous releases of SEP.  Download (or push) the .zip file which contains the Symantec Endpoint Protection.pkg and the Additional Resources folder.  Then just double click to unzip the downloaded archive file .pkg file. It will automatically use what is needed from that new folder.

Hope this helps - please keep this thraed up to date with news of how you get on!  
 

Just installed 12.1 RU2 here on my OS X 10.8.2 machine.  I can confirm it goes on exactly as described above.

Two extra notes: there's a requirement to log out and then back in afterwards, and SEP for Mac will need to run LiveUpdate right after install to get itself back up to date. 

Cheers again, Bryan!

Thanks, yeah, I've been able to copy the .pkg and Additional Resources file to multiple computers via ARD and then install via 

Glad to help, Bryan! &: )

For the benefit of future Mac admins with the same question, can you mark this thread solved?  (It is still currently "Needs Solution.")  Content from solved threads are included in various searches.

Bryan:

As a fellow mac admin, I feel your pain. This new flat package format is difficult to work with, no question. For example, I used to follow this procedure to slipstream virus defs into the SEP installer pkg:

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

However, this appears to be impossible as of 12.1.2. I am experimenting with a method of replacing the contents of the SEPDEFS.zip file (in the "Additional Resources" folder) with the guts of the latest virus defs pkg. This seems to work, but is very clunky (and undocumented).

It would be fantastic if Symantec were to update the instructions for slipstreaming virus defs into the installer pkg in 12.1.2. Until then, we are stuck with the immediate forced liveupdate run, which does not work well for our unattended/lab machines. I suppose that I could try to script a liveupdate run as a part of the install, but again you see the complexity that we are now forced to deal with.

Mick, your thoughts?

Andrew Cunningham

Hi all,

Cheers for the forum posts.  The following KB has now been updated from SEP for Mac RU2 and above:

How to slipstream newer virus definitions into the Symantec Endpoint Protection for Macintosh installer package
http://www.symantec.com/docs/TECH144098 
 

Hope this helps! &: )

Hi Mick,

With all due respect, this thread is hardly "solved".

I'm glad that they addressed the issue of slipstreaming newer virus definitions issue and updated the KB article (TECH144098).  Kudos and yay.  

I'm also glad that Bryan was able to find a workaround for deploying clients without the native ARD package push option.  However, that's only a workaround and breaks one of the features of previous installers (deployment through native tools)

And as annoying as both of those issues are, there's a much bigger issue plagueing this new distribution model; particularly for those of us that have to distribute the actual installers to our end-users.


The big issue that is preventing us from distributing this package is that the "pkg" file can be easily re-distributed without the "Additional Resources" folder.  The reason this is a major issue is that the "Additional Resources" folder contains, not only the virus defintions, but the client management information as well; without it, the installer defaults to a non-managed state and requires a 300+MB post-install download of virus definitions.

Let me repeat, the PKG flat file WITHOUT the "Additional Resources" folder is an easily distributable NON-MANAGED client installer.  Granted, this was also possible for the more tech-savvy end-users to accomplish using the old mpkg bundle, but one had to at least know the backend workings of OSX installers.  But this new bundle makes it easy to, intentionally or unknowingly, distribute a vanilla SEP client that doesn't report back into the enterprise nor follow any pre-set policies.



On behalf of Mac Admins supporting SEP infrastructures in an enterprise environment, the two major issues that need to be addressed before I would consider this issue "solved" are:

1. installers for managed clients should stay managed client installers when transported from machine to machine

and

2. the installer bundle should be deployable through native desktop administration tools (i.e. package push via ARD).


Both of those issues have been relayed to our SE and Account Rep.  If the above is also a concern for any other Mac Admins, I would encourage you to speak to your Account Reps also.

 

Let me add that, though I find code-signing installer to be a great effort, it is neither fully necessary at this time nor consistently applied across the product.  Case in point, the Windows installer isn't signed (which is why users get an annoying UAC warning when trying to install SEP for Windows).  I'd settle for the same annoying warning for my end-users on Mountain Lion, than lose two bonus features already afforded to us in previous SEP for Mac versions (namely, native deployment options and "locking" the managed-vs-unmanaged option).

I could be wrong on the code-signed installer not being fully necessary, but since the SEP for Mac 12.1.1 un-signed installer works just fine on Mountain Lion, I'm guessing its not fully necessary.  I'm going to try ripping apart the code-signed pkg file and re-create a non-signed mpkg bundle.  If anyone has successfully done that, I'd love to hear your results.


Also, there is a third bonus "feature" that is gone and overlooked with this new model: double-click to begin installation.  

End-user instructions using the old installer bundles:
1. download installer (note: the OS should automatically unzip and mount the dmg and launch the mpkg installer)
   1a. if using another browser besides Safari, double-click on the downloaded zip file
2. follow the installer wizard
3. Log out and log back in

New end-user instructions:
1. download installer
2. find and double-click the zip file to uncompress the installer
3. find the folder that uncompressed
4. Verify that there is a pkg file and an "Additional Resources" folder
5. double-click the pkg file
6. follow the installer wizard
7. log out and log back in
8. delete the the folder from step 3.

Those are my thoughts regarding the installer.  The client itself, I have mostly positive thoughts on, but the installer is quite janky (to use a technical term)
 

Had some problems with the forum so this may be a repost:

Step 1: Get Java 6 out to your workstations. In Mac OS X 10.8, it is not installed by default and will need to be if LiveUpdate is to work. That should be easy, deploy with ARD or use whatever mechanisms you normally would.

Step 2: Run the uninstaller script from this Symantec article on your machines. http://www.symantec.com/business/support/index?page=content&id=TECH103489

Could be done with ARD or in my case I use an managed client solution such as Jamf Casper, Absolute Manage or FileWave. I could also see this script being used as a properly developed self-destructing login hook in Workgroup Manager or locally based. If using ARD, make sure you use the second script on the page that works with tools such as ARD.

Step 3: Use Apple's PackageMaker or Jamf Composer to build a new package. You are going to take the sylink.xml file located in the Additional Resources folder and package it up and set proper permissions on it. Installing this by hand I have found that Symantec put this file on with root:staff ownership and seems to assign it 666 permissions.

Basically you need to get this sylink.xml file to /Library/Application Support/Symantec/SMC as per Symantec article http://www.symantec.com/business/support/index?page=content&id=TECH131585 which talks about converting an unmanaged Symantec Mac client to a supported managed Symantec client. Optionally, a customer could use his or her Apple Developer account certificate to digitally sign the package if you are in a Gatekeeper secured environment. ARD could also be used if you simply wish to just push out the sylink.xml file without fancy repackaging.

Step 4: Install the PKG WITHOUT THE ADDITIONAL RESOURCES FOLDER  like you would any other package using ARD or a managed client solution. When you install this package without the Additional Resources folder, it is the equivalent of installing Symantec Endpoint Protection to your Mac clients in unmanaged mode. That plus the sylink.xml file in Step 3 should equal a managed installation.

Step 5: reboot the workstations you sent these packages out to.

Step 6: after the reboot, use the SEPM console to require a LiveUpdate or in the case of my devices, they checked for a LiveUpdate on first login anyway.

I am disappointed at Symantec for this terrible installer, but think I have found a way to mitigate it that seems to work in our environment. For those with Jamf Software's Casper, I can provide directions to turn all of this into a simple policy.

<note: I updated this post to reflect a reality I discovered after mass deploying to a small group of machines. For whatever reason, if you don't get the sylink.xml file out first before pushing the main package, some machines seem to have trouble checking in with the SEPM server. Don't really know why...have filed a case with Symantec for clarification on the issue.>

Brian Martin

Lafayette School Corporation

Hello vickg,

First of all, thank you for your candid feedback.

To address your first comment about msi files, the Windows installer is different than the Mac installer.  For Windows we sign the msi files just like we do for Mac.  In Windows if UAC is turned on then UAC will prompt anytime an application tries to change a system setting regardless of whether it is signed or not.

For Mac if an installer is not signed then Mac will prompt before installing.  This prompt for Mac is different than the UAC Windows prompt because it is telling the user that this product is not trusted and may not be a good/valid product, whereas the UAC message is just asking the user if he wants to allow this program to make system changes.  In both cases the installer is signed.

Apple is working to get companies to sign their own packages to help differentiate between good packages (signed packages) and bad packages (unsigned packages).  This is required in Mac 10.8 Mountain Lion to avoid getting the Gatekeeper alert.  Based on this, files that change (such as the sylink.xml file) need to be placed outside the pkg file.  A user could still run or install an unsigned package but then there would be no way to distinguish between a package that is bad verses a package that is good.  In addition this would be going contrary to what Apple is recommending that vendors do.  Here are comments directly from the Apple web page:

“For apps that are downloaded from places other than the Mac App Store, developers can get a unique Developer ID from Apple and use it to digitally sign their apps. The Developer ID allows Gatekeeper to block apps created by malware developers and verify that apps haven't been tampered with since they were signed. If an app was developed by an unknown developer—one with no Developer ID—or tampered with, Gatekeeper can block the app from being installed.”

Currently in SEP 12.1.2 we wrap both the pgk file and the other files that change into a single zip file to make it easier to distribute.  One idea we had was to use a different file format other than a zip file to distribute the packages.  We cannot use a pkg file for this since we need to sign the pkg file and once it is signed we cannot make changes to it.  However, if we used a dmg file rather than a zip file for this would it make the process easier for you?

Thanks,

Coming from our situation, a DMG file seems irrelevant. With the debut of Gatekeeper, I think you folks need to rethink how you get your product loaded onto a Macintosh computer.

My advice would be to formally test the idea I posted below from experience in our locationand include a formal write-up of the process. Your zip file would have the signed, standalone PKG installer and your "Additional Resources" folder would contain "a documented process for admins to add a single file (or two if you need to have one more for whatever reason) using Apple Remote Desktop (or similar product) to the client machine that makes the installation managed." I could even tell you how I was able to get the sylink.xml file repackaged into a signed PKG installer using my personal installer developer key.

Right now I have developed such a workflow organically for our institution, but I feel that Symantec needs to get reviewer on it. Hopefully, it is acceptable and close to supported.

Now, in closing here's the acid test that I can recommend for an enterprise deployment friendly installer. You ask yourself this question:

Does our product have a easy and documented method that admins can use with Apple Remote Desktop (or similar deployment tools on the Mac side) to mass push your fully-managed product out to lots of clients at one time with maybe only a single reboot or logout? If you can answer 'yes' confidently to that question, then you should be set. If the answer is 'no', then I feel you folks need to honestly try harder to make your Mac product more enterprise deployment friendly. 

If you are looking for help on the developer side, consider posting to the MacEnterprise mailing list or AFP548. These folks deploy and write installers for products daily. I can also recommend another mailing list called JamfNation (http://jamfnation.jamfsoftware.com). Most people on these forums are enterprise deployment experts on the Mac side.

Kind regards and hope to get some feedback

Brian Martin

Lafayette School Corporation

Hi my question will be a bit different but can i get MAC sep clients to take updates from our windows sepm server. we are now 12.1.2 latest version.

Hi Pandher,

Hi my question will be a bit different but can i get MAC sep clients to take updates from our windows sepm server. we are now 12.1.2 latest version.
 

SEP for Mac clients must still download their content from the Internet or from an internal LiveUpdate Administrator 2.x server.  They cannot update from the SEPM.

We are working on a KB article that will describe how to use Apple Remote Desktop to deploy the SEP 12.1.2 Mac client.  I will update this thread once we get the KB posted.

Was hoping to see an article out by now outlining an official solution. My solution continues to work, but we are having to go through summer reimaging and it would be nice to know that the current build plays nice with ARD. Please post here once a KB article on the subject is posted.

HI, 

MAC clients cannot update from SEPM. Mac clients can only took updates from LUA servers (internal or external aka liveupdate.symantec.com)

Regards

Ajin

We have created a KB article on this.  See: http://www.symantec.com/docs/TECH160427

haven't had a chance to look at 12.1.4, but was this issue resolved in the latest version?  or is the 'additional resources' folder still separated from the pkg/mpkg bundle?

Yes.  SEP 12.1.4 has a new package format for the Mac client.  When you export the package out of SEPM it will be in .app format.  Then when you run the .app file on a Mac system it has an option to export into a single .pkg file.  You can use the .pkg file to deploy the package from virtually any Mac remote deployment software, such as Apple Remote Desktop or Casper.

Excellent news!

Here's more on what's new for Macs:

Overview for Symantec Endpoint Protection 12.1.4 for Mac
https://www-secure.symantec.com/connect/forums/overview-symantec-endpoint-protection-1214-mac

 

Can anyone help me out with this.

https://discussions.apple.com/thread/5866445?tstart=0