1 Reply Latest reply on Mar 28, 2018 3:05 AM by phoffmann

    Office 2010 Uninstall (OffScrub10)

    cfrediani Rookie

      Hey Folks,

      Been having an issue with false positives when deploying the OffScrub10.VBS script to workstations. Within Endpoint Manager the task succeeds, however Office 2010 is not actually removed from the workstation. when you examine the logs generated by the VB script you get the following message at the end of the log.

       

      Successfully rolled back the uninstall of package: Office64WW path:C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\Office64WW.MSI

      SystemRestore : Attempting to cancelling System-Restore-Point for Product [Microsoft Office Professional Plus 2010] (with RestorePointType [1, Removed]).

      SystemRestore : Successfully cancelled System-Restore-Point for Product [Microsoft Office Professional Plus 2010] (with RestorePointType [1, Removed]).

      Not showing completion dialog because it was not requested.

      Reboot requested never.  Skipping reboot attempt.

      Catalyst execution finished: 03/26/2018 21:21:08.  Return code: 1913.

      PERF: TickCount=266371 Name=RunSetup Description=End function

       

      i have added the 1913 return code to the Default non MSI template to return a failure, but i am still encountering a scenario where the task succeeds according to Endpoint Manager but does not "actually" succeed.

       

      Has anyone had any experience with this particular issue? Also how have you been tackling office 2010 uninstalls during the migration to O365?

        • 1. Re: Office 2010 Uninstall (OffScrub10)
          phoffmann SupportEmployee

          So I am guessing that's not one of our logs you're looking at .

           

          You may want to look at the task log on the affected client(s) -- they're in "C:\Program Files (x86)\LANDesk\LDClient\Data\" and check the relevant log based on Task ID.

           

          What I suspect is happening is that you're running that VB-script effectively via wrappers, and that those don't kick the exit code up the chain. (That's why you want to look at our logs, to see what return code we're actually getting).

           

          So the following sitation (which is surprisingly common, actually) in effect:

          1. We kick off a batch-file (or some other wrapper) on the client.
          2. Batch file kicks of "stuff" and then calls the VB-script.
          3. VB-script comes back with non-0 exit code (but finishes).
          4. Batch file continues / finishes (Hey, VB-script ended up with non-0 return code, but *I* am OK ... so I'm going to return a 0 return code)
          5. ... our Software Dist components pick up a 0-return code from the batch and "everything is well" as far as we're concerned.

           

          That's usually how that particular "trap" works.

           

          You may also want to enable debug logging (if you need more info), which is documented here:

          -- How to enable Xtrace Diagnostic Logging

           

          ... between those two, you should have a much clearer picture of "what our stuff gets told".

           

          Hope that helps.