Endpoint Protection

We are testing the client upgrade from an IIS server where we published the folder with the setup.exe created on the sepm.

Using the "Upgrade groups with package" Wizard we set up an install package for a test compter group and configure a download location pointing @ the URL of the published folder following hte instructions that can be found on: http://www.symantec.com/connect/articles/using-web-server-auto-upgrade-clients-latest-sep-version

Its been 3 days from the release of this install package, and still no client has updated: something is missing because if I access the shared web folder URL from one of the client I can manually download/launch the package, but nothing works in automatic mode...

Does the client install process start then fail? Have you checked the IIS logs for errors?  Are you running any backup software on the clients?

What OS and version are the clients running?

Thomas

why do you need to use another IIS path for this? you may simply use "Install Packages" tab on each of the Client groups settings and add the new version package there.

Bekir,

You would want to use IIS to deploy the packages if you don't want clients upgrading from the SEPM servers.   If the clients are not in the same location as a SEPM then you would want to deploy via IIS in remote locations othewise all traffic could go across the WAN.

Jeff

The install starts, the shield on the client disapears, then comes back as if the system was updated. But alas, the older version remains. A couple minutes later, the update attempts to run all over again.

Server 2003 running IIS and XP SP2 on the target computer


A way to get around this process though would be to use Symantec's Push Deployment Wizard. You can push the package from each site without having to have the clients download from the SEPM.

I know I had trouble unless the client being upgraded was MR4MP2  otherwise I had to allow the install to happen from the SEPM server.

we opened a case cause of the difficulty of finding detailed infos online: symantec support asked us to run some debugging tools on our sep clients that were supposed to update via IIS.

SEPDebug_1.25
Sep_SupportTool

With this scan we saw that the clients were correctly recieving the policy from the SEPM and that they were recieving an ACL error from the IIS server that was misconfigured.
Our web server had the permission set to everyone in Read for the setup.exe file, but the local folder of the server did not have the everyone-Read permission on the security TAB (not web security that was already set).

Changing the permission from admin-only to everyone read made the web upgrade process to work correctly. Hope this helps someone.