3 Replies Latest reply on Mar 6, 2008 7:23 AM by phoffmann

    Policies not downloading following upgrade

    Rookie

       

      Following the upgrade toLDMS 8.8 we have a problem with the policy deployment portal.  Dispite over 50 policies been available to a machine which has also had the client upgraded to 8.8 no policies are available.

       

       

      Looking in various log files we have the following problem:

       

       

      policy.sync.log

       

       

      Thu, 06 Mar 2008 12:09:13 Policy synchronization stated.

      Thu, 06 Mar 2008 12:09:13 Sending update request to core server.

      Thu, 06 Mar 2008 12:09:16 Web request returned 404 Not Found

      Thu, 06 Mar 2008 12:09:16 Error: policy update request has failed.

       

       

      Any help would be great.

       

       

       

       

       

        • 1. Re: Policies not downloading following upgrade
          phoffmann SupportEmployee

          Well - you will want to look on your Core's IIS log to find out what is throwing the 404 error. "Not found" is "not found" - you need to find out first what it is that's causing the problem before you can then check whether it's an access problem or whatnot.

           

          Paul Hoffmann

          LANDesk EMEA Technical Lead.

          • 2. Re: Policies not downloading following upgrade
            Rookie

             

            Forgive my ignorance but which IIS log file, I have looked in C:\WINDOWS\system32\LogFiles\W3SVC1 but there doesn't seem to be anything obvious.

             

             

            • 3. Re: Policies not downloading following upgrade
              phoffmann SupportEmployee

              You're on the right track.

               

              "C:\WINDOWS\system32\LogFiles\W3SVC1\" is the right location for IIS-log files, but you could also find something in the HTTP-error logs (which are in - "C:\WINDOWS\system32\LogFiles\HTTPERR\" by default). Don't ask me why they're split, it doesn't make much sense to me either :).

               

              If NEITHER of those logs have an entry for your client, it means that the client never reached the Core (thus your 404) - and you'll want to start looking at network traces and such, to see what blocked you off.

               

              Just to make sure you know what to look for, here's a line from one of my Core's IIS-logs:

               

              2008-03-04 10:44:44 W3SVC1 10.100.44.152 POST /WSVulnerabilityCore/VulCore.asmx - 80 - 10.100.44.61 Microsoft-ATL-Native/7.00 200 0 0

               

              Where...

              - "10.100.44.152" is the IP of my Core

              - "/WSVulnerabilityCore/VulCore.asmx" is the page being accessed - i.e. "http://WSVulnerabilityCore/VulCore.asmx"

              - "80" is the port used (80 == HTTP // 443 == SSL).

              - "10.100.44.61" is the IP of the client (this is what you're looking for)

              - "200 0 0" are the status codes - in this case "200" meaning "all is well".

               

              Paul Hoffmann

              LANDesk EMEA Technical Lead.