12 Replies Latest reply on Jul 25, 2018 7:19 AM by phoffmann

    "Download pending" status in Portal Manager after Windows suspends.

    NicoLev77 Rookie

      Hi, the reason of this thread is the following.

       

      I use Ivanti Portal Manager in a lot of computers in my organization. When I start Windows and try to install any software from Portal Manager, it works fine. But after the computers get suspended (and resumed), locked or just used for other things for a couple hours, the Portal Manager stops working ok.

      When any user try to install a software, the progress bar in the Portal stays in "Download pending" forever, at the moment the only solution I've found was restart the computer, but is not practical at all for the user...

      I've tried restarting manually the Ivanti services but doesn't work, and looked for similar posts in the community but doesn't found anyone reporting the same problem, which is weird.

       

      Ivanti 2017 v3.

      Windows 8.1, 10

       

      Let me know if I can help adding any other info.

      Thanks in advance!

        • 1. Re: "Download pending" status in Portal Manager after Windows suspends.
          phoffmann SupportEmployee

          Hmm - rather than re-starting the services, see if executing "policysync.exe" gets things rolling again.

           

          None of the services as such are related with the portal -- it's the policysync executable that gets called on a schedule you define which deals with portal stuff (and then hands over to SDCLIENT and such for individual task processing). About the closest one with any involvement would be Local Scheduler (since he calls the policysync executable based on the schedule you defined).

           

          My hypothesis would be that things get put into torpor / shutdown / "slept too effectively" by Windows' suspend at an awkward time ... and don't really run once Windows resumes. But ... since it works once you reboot the box, one of two possibilities should work here:

          • Re-running the executable in general may be enough (in which case, that'd be easy enough to solve via scheduling options).
          • A more complicated scenario would be that you might need to shut down a zombie-state process gracelessly and then start a new copy of it.

            This you can do by checking whether the processes (SDCLIENT / POLICYSYNC) are actually still running post suspend ... and - if needed - killing them by hand & running PolicySync again manually.

            At least that'll help you get a clearer picture of what's what / what needs to happen potentially.

            Creating a script that shoots down policysync & restarts it may be tempting, but should come with quite a few warnings, as you might kill things off when they're legitimately running, for instance. Would need to ponder for some more if THIS scenario is what's happening to you.

           

          Hope that helps a bit.

          2 of 2 people found this helpful
          • 2. Re: "Download pending" status in Portal Manager after Windows suspends.
            NicoLev77 Rookie

            HI phoffmann! Thanks for your attention,

             

            I've checked what you suggest. The PolicySync.exe is always running (even when the installations fails). So I've ended manually PolicySync and SDCLIENT, for then starting PolicySync.exe manually (also with /enforce), both processes start ok, but the Portal keeps without installing.

             

            I've check the logs from PolicySync.exe and from the tasks (folder: LANDesk\Policies\ )

             

            PolicySync.exe - Log from a correct installation:

            05/04/2018 15:38:32 INFO  4252:1     RollingLog :

            Run PolicySync.exe /enforce

            05/04/2018 15:38:32 INFO  4252:1     RollingLog : EnforcePolicies: check and run RunNow and Reoccurring policies

            05/04/2018 15:39:51 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Starting to scrub policies...

            05/04/2018 15:39:51 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Policy [C:\ProgramData\LANDesk\Policies\CP.3881.RunNow.stat] needs to be scrubbed, it's current status is [3], setting it to failed and sending task status to the core...

            05/04/2018 15:39:52 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Policy [C:\ProgramData\LANDesk\Policies\CP.423.stat] needs to be scrubbed, it's current status is [1], setting it to failed and sending task status to the core...

            05/04/2018 15:39:54 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Policy [C:\ProgramData\LANDesk\Policies\CP.427.stat] needs to be scrubbed, it's current status is [1], setting it to failed and sending task status to the core...

            05/04/2018 15:39:55 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Policy [C:\ProgramData\LANDesk\Policies\CP.428.stat] needs to be scrubbed, it's current status is [1], setting it to failed and sending task status to the core...

            05/04/2018 15:39:57 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Policy [C:\ProgramData\LANDesk\Policies\CP.429.stat] needs to be scrubbed, it's current status is [1], setting it to failed and sending task status to the core...

            05/04/2018 15:39:58 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Policy [C:\ProgramData\LANDesk\Policies\CP.484.stat] needs to be scrubbed, it's current status is [1], setting it to failed and sending task status to the core...

            05/04/2018 15:40:00 INFO  4252:1     RollingLog : PolicyScrubber.ScrubPolicies: Finished scrubbing policies, [6] policies needed scrubbing.

            05/04/2018 15:40:00 INFO  4252:1     RollingLog : PolicyScrubber.ConvertEmbeddedPolicyLogosToURLs: Checking for embedded policy images...

            05/04/2018 15:40:02 INFO  4252:1     RollingLog : PolicyScrubber.ConvertEmbeddedPolicyLogosToURLs: No embedded logos to convert, skipping...

            05/04/2018 15:40:02 INFO  4252:1     RollingLog : Exit PolicySync.exe with code 0

             

            PolicySync.exe - Log from a failed installation:

            05/04/2018 14:54:30 INFO  5728:1     RollingLog :

            Run PolicySync.exe /enforce

            05/04/2018 14:54:30 INFO  5728:1     RollingLog : EnforcePolicies: check and run RunNow and Reoccurring policies

            05/04/2018 14:54:33 INFO  5728:1     RollingLog : PolicyScrubber.ScrubPolicies: sdclient or vulscan is currently running, skipping policy scrub.

            05/04/2018 14:54:33 INFO  5728:1     RollingLog : Exit PolicySync.exe with code 0

             

            Log from a failed task - CP.428 (STAT, unique file created):

            <?xml version="1.0" encoding="utf-8"?>

            <PolicyStatusInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

              <TaskIdn>428</TaskIdn>

              <DownloadPercentage>0</DownloadPercentage>

              <TotalDownloadSize>47863624</TotalDownloadSize>

              <Status>1</Status>

              <Result />

              <ReturnCode>229965824</ReturnCode>

              <CurrentInstallingPackage>1</CurrentInstallingPackage>

              <LastRunTime>1525442573</LastRunTime>

              <Deferrals>0</Deferrals>

            </PolicyStatusInfo>

             

             

            I've already read this file About Task Status Scrubber but don't understand an answer for the problem. When I check for the status in the delivery task, it says Failed - Error code 16386.

            • 3. Re: "Download pending" status in Portal Manager after Windows suspends.
              phoffmann SupportEmployee

              Hmm - at this point, I suspect you may need to troubleshoot this with support (/they might need to attempt to duplicate the behaviour).

               

              Seems like there's a bit more involved than a simple "re-starting the relevant check" and something that may be specific to your hibernation / sleep mode config (not "specifically you", but more of a "do you use S1 or S3 sleep states? Does it make a difference?" and such).

               

              Sorry, doesn't look like this'll be a quick thing, and if this needs to be set up for duplicaton, at that point it should already be with support (who can then throw it at dev, once they've got the scenario happening reliably) to suss out as needed.

               

              Sorry that it's not just a simple case of "start X" by appearance .

               

              =============

               

              ONE observation (from your failed policysync log) ... notice this:

              ""

              05/04/2018 14:54:33 INFO  5728:1    RollingLog : PolicyScrubber.ScrubPolicies: sdclient or vulscan is currently running, skipping policy scrub.
              ""

               

              Do you HAVE any SDCLIENT/VULSCAN process(-es) still/again running after your machine wakes up? Could be that there's a "zombie" process that didn't respond well to the sleep, and is now preventing policy checking from effectively running (the "logic" being that log entry being "Hey - we're potentially already installing stuff -- let's not break stuff by running a 2nd installer instance").

               

              So if you shoot down any SDCLIENT / VULSCAN processes, and re-run policysync ... do you see the same entry / does it work any different?

               

              <By and large, this would still be a potential defect / enhancement request you should log with support, but that does stand out somewhat in your scenario. >

              • 4. Re: "Download pending" status in Portal Manager after Windows suspends.
                NicoLev77 Rookie

                I tryed to finish SDCLIENT and VULSCAN proceses after the problems appear, and then restarting POLICYSYNC, without success

                So think I gonna need to contact the support as you said.. If I found a solution with them I will notify over here.

                 

                Thanks again for your time phoffmann!

                • 5. Re: "Download pending" status in Portal Manager after Windows suspends.
                  mmartinvegue Apprentice

                  Any luck on this problem?  I am seeing the same issue.

                  • 6. Re: "Download pending" status in Portal Manager after Windows suspends.
                    phoffmann SupportEmployee

                    If you're seeing the same thing, mmartinvegue , you may want to (both) poke support about this.

                     

                    If there's 2 people seeing the same thing, I'm suspicious of it being more than a "one-off" ...

                     

                    Also - compare your log versus those posted by NicoLev77 -- if you're seeing the same messages (and not just the same symptoms), there may indeed be more to be seen here.

                     

                    As an FYI, SU5 for 2017.3 has just gone up for limited release -- it may include useful additions / fixes (I've not looked at it in depth, just caught the update so far is all).

                    • 7. Re: "Download pending" status in Portal Manager after Windows suspends.
                      NicoLev77 Rookie

                      Hi phoffmann and mmartinvegue, I still looking for solution this issue with the Ivanti support, when we find a solution I will share it in this thread.

                      • 8. Re: "Download pending" status in Portal Manager after Windows suspends.
                        phoffmann SupportEmployee

                        Cool - thanks NicoLev77 - that's very kind of you .

                        • 9. Re: "Download pending" status in Portal Manager after Windows suspends.
                          mmartinvegue Apprentice

                          I realized I get "Download Pending" when a vulscan is already in progress. Vulscan is triggered everyday at the start of our maintenance window.  Since Vulscan actually takes a long time and is silent, all Portal Manager installs get stuck at Download Pending until the Vulscan process completes.  Is there a way to get Portal Manager installs to go through even if a Vulscan is in progress?  This is confusing to the end-user since there isn't an indication why the download has not started.

                          • 10. Re: "Download pending" status in Portal Manager after Windows suspends.
                            phoffmann SupportEmployee

                            Not really - vulscan & SDCLIENT tend to check on each other to make sure that they don't step on each others' toes. Running "install X" while patching "the same thing" is a recipe for all manner of broken things after all.

                             

                            OK - so now that we know where your problem is from, we can address that.

                             

                            I'd argue that the easiest way would be to look at your client config. Check your local scheduler setting(s) for vulscan ... and don't run it during the working hours (you can use filters VERY powerfully like that) if that'll help you.

                             

                            That'll be probably the easiest way out here (Maintenance windows are meant for servers more than anything. End-points are usually easily enough to serve by just filtering the schedule of when you do / do not run the respective action).

                             

                            Does that help / make sense?

                            • 11. Re: "Download pending" status in Portal Manager after Windows suspends.
                              NicoLev77 Rookie

                              Hi all, updating this issue, in my case we found that the AV (McAfee) somehow is blocking the Portal.

                               

                              The test to confirm it, was deploy a workstation without anything about McAfee related and use the Portal several times along a few days, it doesn't present any problems.. An Ivanti support agent suggest me to add some Ivanti paths to the McAfee whitelist, but before to apply this I want be sure that is not other module from McAfee (Firewall, Threat Prevention, Endpoint Security...) that is causing the issue, so I'm doing a few more tests. Not fully resolved but at least in my case I have a direction now.

                               

                              Hope that this help you mmartinvegue.

                              • 12. Re: "Download pending" status in Portal Manager after Windows suspends.
                                phoffmann SupportEmployee

                                Hmm interesting.

                                 

                                So the "bad" news is that the answer could well be "yes" ... Firewall can block things (comms to the Core). Endpoint Security can prevent things (those often don't like things running with elevated / local system privileges), etc.

                                 

                                So yeah, you've got a few bits of work ahead of you there.

                                 

                                But at least you've found the basic culprit, so that's good. Now the real work begins. (I'm still curious that they block the portal - that barely does anything beyond talking to the Core & running policysync ....)