Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Upgrade from SEP 11 to SEP 12 - package not downloaded by SEP client

Created: 28 Jan 2014 • Updated: 28 Jan 2014 | 14 comments
S_K's picture

Hello,

We are experiencing the following issue. We are upgrading few environments (having workstations Vista, Win 7 and servers 2003, 2008) from SEP 11 to SEP 12 (RU2/RU4). There are many workstations and servers that are not downloading the upgrade package. In one of the environment we use SEPM for pushing the package (auto-upgrade), in another via SCCM. But in both cases we have machines that are not downloading the package. Is there a way to find the reason for this, some Symantec logs etc? Since the package is not downloaded, I don't think SEP_inst.log will give us any info. 

Operating Systems:

Comments 14 CommentsJump to latest comment

James007's picture

Prepare Windows Vista, Windows Server 2008, or Windows 7 computers: Windows User Access Control blocks local administrative accounts from remotely accessing remote administrative shares such as C$ and Admin$. You do not need to fully disable User Account Control on the client computers during the remote deployment if you disable the registry key LocalAccountTokenFilterPolicy. For more information, see the following Microsoft Knowledge Base article: http://support.microsoft.com/kb/951016

If the Windows client computer is part of an Active Directory domain, you should use domain administrator account credentials for Remote Push.

In addition, perform the following tasks:

  • Disable the Windows Firewall, or configure the firewall to allow the required traffic.
  • Disable the Sharing Wizard.
  • Enable network discovery by using the Network and Sharing Center.
  • Enable the built-in administrator account and assign a password to the account.
  • Verify that the account has administrator privileges.
  • Disable or remove Windows Defender

 

Steps to prepare computers to install Symantec Endpoint Protection 12.1.x client

 

Article:TECH163112  |  Created: 2011-06-23  |  Updated: 2014-01-15  |  Article URL http://www.symantec.com/docs/TECH163112

 

Upgrade clients to SEP 12.1 by Auto upgrade feature

 

http://www.symantec.com/connect/articles/upgrade-clients-sep-121-auto-upgrade-feature

S_K's picture

Actually we are not using Remote push (or Push deployment wizard), we are doing it via Auto-upgrade (assigning the package to the SEPM group) or via SCCM, so the above may not help

SebastianZ's picture

For updates via Auto-upgrade enable sylink debugging on client - this will show client communication with SEPM alongside with entries if upgrade package has been rejected an why:

http://www.symantec.com/business/support/index?pag...

Run the debug within the time client is expected to download the package. Collect sylink.log afterwards.

On a side not SEP_INST.log will only be created after the installation in a fact started on the client.

.Brian's picture

Enable sylink debugging and let it run, post the log here for review

How to enable Sylink debugging for the Symantec Endpoint Protection 11.x and 12.1 client in the Windows Registry

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.

James007's picture

Did you check restart sep client ?

Check client properties->Deployment target version are showing or not ?

Please check (SEP_INST.log and SIS_INST.log

What logs do I need to gather in order to troubleshoot a failed SEP 12.1 client installation?

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

Tony K.'s picture

Another thing - look at the settings on the install packages tab check and see the upgrade schedule box is unchecked and also the distribute packages over X days are set to 0 --- this will open up the flood gates but if any clients missed that window to get the package, I have seen some clients sit there indefinately (also make sure that you have assigned the latest version of the 32bit and 64bit packages to each of the groups...a little thing, but easily missed)

 

At least that might eliminate some possiblities on the SEPM side - SCCM I haven't really ran too much of that on my test environment (but then again, my test environment is only about 3 machines running 2012, 2008 R2 and a Win 7 box so must of my work has been done through the SEPM)

 

Furthermore the SEP_INST.LOG / SIS_INST.LOG would be useful from any of the machines that failed to upgrade - as long as the package was uploaded and executed, that log will be generated. The only way it would not is if the package was not deployed over to that machine or not executed (installs were not copied or attempted to run) - worst case scenario - if the number of machines are manageable - say 10 or fewer, maybe just creating a network shared install file (w/o defs - basic content package) could eliminate issues with bad patterns and reduce the file transfer size and executing it locally...say if this was 10 ouf of 2000 machines, not bad - anyhoo, any logs or info would be of some help

raju123's picture

Have you find any error message in system log of that client where you deploy.

post the sep_inst.log.

It also help to find the problem.

S_K's picture

Just faced again an issue where package was pushed from SEPM to a server and it couldn't download it. Enabled Sylink debug and it showed the below:

02/04 12:02:46 [3872] <DownloadNow:> Cached install size: 215981852, Package size: 317172804, Space required: 1498273016
02/04 12:02:46 [3872] <DownloadNow:>Setting the session timeout on ClientPackage download session to 2 min.
02/04 12:02:46 [3872] <CDownloadManager::mfn_StartDownload()>
02/04 12:02:46 [4040] <gDownloadThreadProc()>
02/04 12:02:46 [4040] CDownloadManager::mfn_CreateInetSession => Creating System Proxy (default) Session ..
02/04 12:02:47 [4040] <CDownloadManager::mfn_DownloadOneFile()>
02/04 12:02:47 [4040] <CDownloadManager::HttpDownload()>
02/04 12:02:47 [4040] CDownloadManager::HttpDownload() Insufficient disk space available. At least 1498273016 bytes are required.
 
 
Why it requires so much free space?
 
 
 
 
 
For the push upgrade via SCCM still I don't have anything new. SCCM team is looking from their side. But we may need to enable also SyLink debug on some of these machines. 
.Brian's picture

I've seen the packages go up to 300MB, make sure you have enough space. I would recommend at least 1GB free space and that's still cutting it close.

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.

S_K's picture

I had around 1,3 GB free on the server, upgrade package (full zip, because it is from SEP 11 to SEP 12) around 300 MB, but it shows that at least 1,4 GB free are needed from the log above

.Brian's picture

You'll need to free up space on that drive.

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.

S_K's picture

Yes, on this particular machine we cleaned some space and upgrade completed. So for the other cases where SEP was not downloaded by the machine, we will try with Sylink debug, it really helps and show the reason why :)

Rafeeq's picture

check with sccm too if cleaning theh space fixed the push deployment from sccm..