4 Replies Latest reply on Oct 27, 2015 1:40 PM by cwinning

    Deployment to another domain status stuck at 'Scheduled'

    PaulFreedman Apprentice

      Since the upgrade to 9.2 when deploying updates to a different domain than the console we are seeing the status stick at Scheduled. I can see the updates being applied by monitoring the system event logs on the server but nothing is reported in to the console.

      This was working before the upgrade so what has changed?

       

      Is there a way to downgrade the system back to 9.1?

        • 1. Re: Deployment to another domain status stuck at 'Scheduled'
          cwinning CommunityTeam

          Hello,

           

          You can downgrade if you have a backup of the 9.1 database.  You can uninstall Protect 9.2, attach the 9.1 database to SQL, install Protect 9.1 and point Protect 9.1 to the 9.1 database during the install.

           

          If you want to troubleshoot , we're going to need logs from the console and the target machine to determine what is causing Tracker update failure. This will tell us where the failure is.

           

          1. Please open the Protect GUI and then go to Tools > Options > Logging and change logging to “All” for both user interface and services.

          2. Close the Protect GUI.

          3. Stop the following services

               a.Shavlik Protect Console Service

                b. ST Remote Scheduler Service

          4. Delete all the logs from

               a.  Windows 7, 8, 2008, 2012 & Vista: C:\ProgramData\LANDesk\Shavlik Protect\Logs

               b.  Earlier OS’s:  C:\Documents and Settings\All Users\Application Data\LANDesk\Shavlik Protect\Logs

          5.  Start the console service and open the Protect GUI.

          6. Attempt to reproduce the issue.  Deploy a patch to a target machine with a Deployment Template with Tracker status enabled.

          a. Collect the logs from the Logs folder mentioned earlier in step 4 (please zip)

          b. On the target system, zip and send a copy of the entire C:\Windows\Propatches folder and its contents (you can leave out the Patches sub-folder).

          7. Zip all the logs and \ProPatches.


          You can should be able to create a case and attach the zip files:  https://support.shavlik.com/CaseLogging.aspx


          Let me know if you have any questions,


          Thanks,

          Charles

          • 2. Re: Deployment to another domain status stuck at 'Scheduled'
            cwinning CommunityTeam

            Hello,

             

            Regarding the Deployment Tracker: In order for your agentless machines to send status messages to the console they need to know the valid name or IP address of the console. The valid names and IP addresses are defined using the Console Alias Editor and are passed to the machines when a patch deployment is initiated from the console. Go to Tools > Console Alias Editor and add a valid IP address for you Protect console at the top of the list.  The Tracker will attempt to use the IP Address then failover to the remaining entries on the Alias list.

             

            Thanks,

            Charles

            • 3. Re: Deployment to another domain status stuck at 'Scheduled'
              PaulFreedman Apprentice

              Thanks Charles, added IP to Console Alias Editor and comms is working again.

               

              Although, this seems strange as I checked my 9.1 console and no IP is defined there but looking in logs I can see machines talk back to console on IP? Guessing this is another change in 9.2.

              • 4. Re: Deployment to another domain status stuck at 'Scheduled'
                cwinning CommunityTeam

                Hello,

                 

                You are correct, this is a change in Protect 9.2, it will help correct many issues associated with Tracker updates in the long run.  Previously, you were able to set IP/Name of the Protect server in Tools > Options, but that wasn't reliable.  The target would attempt to use what was set and fail if it couldn't resolve.  Now target machines 'walk' the alias list until it can connect to the Protect server.  Sorry for the inconvenience this caused you.

                 

                Thanks,

                Charles