Thx Mr.phoffmann! that's what I though, personally, even when I understand the benefits of the Autofix, I'll be using repair tasks just for visibility.
rspychaj I hope this helps you too, sorry for hijacking your thread
Let us know if you have additional questions.
-Best
Using Autofix is good for other reasons -- scaling, for one.
cwarren had a lab/talk on just this topic @ Interchange last year & probably this year again (A Class I'd suggest signing up for, if you're going).
I forgot about that, scaling... hmmmm. Have to check if I can find a happy medium... I like to know when/why.
tnx for the reference!
Happy to help.
Don't use repair tasks for a method of patching. It is horribly slow and inefficient.
There are much better ways that are not using autofix, or repair tasks.
I always say, repair tasks are good for single patches on single systems as a troubleshooting method, that's about all.
I makes the core do all the work, so anything on a more enterprise level will just be horribly slow and inefficient and prone to failure.
You want vulscan doing the work on the client side.
I taught a full class specifically on alternative to autofix at interchange.
I will be teaching the patch class again this year although it will be a more condensed version and trying to cover all aspects, but should still have good info.
The very short and quick answer is.
Setup a separate patch and distro setting that is set to scan by group. Point it to a group you will use for assigning patches you want fixed.
They check the Immediately install (repair) all applicable items box.
Create a security scan scheduled task.
Modify the scheduled task to use the newly created patch and distro setting you created for this run only.
You can also change the reboot settings from the default if you want, or just leave it as the default depending on what you want to happen with the reboot.
Add patches to the group from above that you want applied.
Add computers to the scheduled task that you want to apply the patches to.
Run the job.
Win!
It will run a security scan against the machine using the patch setting specified, patch anything it finds that it needs in that group, regardless of autofix settings of either the patch, or the machine. (including global never autofix)
Similar on the surface to how you imagine a repair task works, but under the covers it is very, very different and much more efficient and reliable.
This scheduled task can be scheduled to run during maintenance windows, it can be run weekly, monthly, whatever, and you just keep the group up to date with the patches you want installed.
You can target a scope with the scheduled task as well, so it will resolve the scope every time it runs.
Many, many options and flexibility with running this method, and the core isn't doing all the work unlike a repair task.
I have patched hundreds of servers with many patches in 15 minutes with this method. Which takes a repair task many hours, if it ever finishes.
No doubt you learn new things every day!
Thx (both) for the detailed explanation.
Dear All,
I have a problem with software distribution and TaskHandlerProxy.exe reports: error: unable to find user 'domain\SYSTEM' in the ConsoleUser table
FYI this is newly installed server
It never yet successfully distributed the patches.
Thanks for hints,
Adam
I've built about a dozen software distribution packages that all silently install quite nicely. When I build a provisioning template and add each of these distribution packages using the "Distribute Software" task, some of them will display windows and other bits of UI on the client-end during installation, despite originally being silent. One of them even had a prompt for reboot that I was forced to decline on the client machine before it would continue to the next task. I've tried unchecking "Show client UI" in the provisioning template's "options" area, but this just disables the UI for the provisioning task itself, not the UI that comes up from the individual distribution packages.
What gives? Is there some way to make all of this silent once again?
Yes... I tried using it when we first upgraded but never was able to get it to work. I contacted support they were not very familiar with it either. I think it was something ported from LANRev. but support guy said he would ask around and was not able to come up with anything. This would be a very helpful tool if it worked.
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?
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:
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.
Ivanti version: 2017.3 su1
Ivanto console version: 10.1.30.401
I have been trying again and it is still not working for some reason. These are the steps I ran through:
1.) I created a new OS Provisioning template named "OS Template - Test Publish to Portal" with the following settings:
2.) I wanted to keep it simple for this test, so I created an "Execute File" action which just launches "%%windir%%\system32\calc.exe"
3.) In the template properties, I changed the following:
4.) In "Distribution Packages", I created a new Provisioning Package called "Provisioning Package - Test Publish to Portal" and selected the "OS Template - Test Publish to Portal" OS provisioning template I created at the beginning. I did not make any other modifications.
5.) In "Distribution Packages", I right-clicked the provisioning package called "Provisioning Package - Test Publish to Portal" and clicked on "Create Scheduled Task", which resulted in a new task being created in the "Scheduled Tasks".
6.) In the "Properties" of this scheduled tasks, I went into the "Targets" properties and added my workstation in the "Targeted Devices" section. In the "Task settings", I changed "Task type" to "Policy".
7.) In "Portal settings", I set "Portal options" to "Recommended (display in portal)", and checked off "Allow users to run as desired (keep in portal after selected)".
8.) In "Schedule tasks", I set it to "Start now", but left everything else alone (should any of these be changed?).
9.) Refreshing the task in the Ivanti Console shows it started:
10.) Refreshed again:
11.) In my local instance of Portal manager, I clicked the refresh button but it does not show up in the list of applications.
Also, this is what I see in the Ivanti Console when I look at the targeted devices. This one device is mine, but it still won't show up in Portal Manager.
Any resolution to your issue mlazovjp? I am experiencing the same issue. I cannot get a Provisioning item to appear in the Portal Manager. Return Code 1001
If you go to C:\ProgramData\LANDesk\Policies and open up the XML and change the
<Name>Type</Name>
<Val>PROVISIONING</Val>
to anything other than PROVISIONING, it will show up in the Portal. Example:
<Name>Type</Name>
<Val>PACKAGE_BUNDLE</Val>
It will show up.
It looks to me that this is a bug, unless there is some agent settings that I am overlooking that is filtering this content out of the Portal.
More troubleshooting...
It appears that a Provisioning Package in the Portal will not show up under "ALL" you have to go to filters and select "Available" and it pops in. See if that happens with you.
Wow, good call! I changed it to PACKAGE_BUNDLE like you suggested, refreshed the Portal Manager, and it shows up and runs!
I went back to the .xml file and restored it back to its original version, refreshed Portal manager, and watched it disappear from the list.
I started going through the filters, and it only showed up when I clicked on Featured.
I cancelled the scheduled task. I went back into the Provisioning Package properties and added a new Category for it. I saved it, reset the hash, created a new scheduled task, and assigned it to my computer. I refreshed Portal Manager and it now shows up only under Available, and no longer under Featured.
Something else odd - There is now a filter for the new category I assigned it, but nothing shows up in the list when I click on that category.
I am getting same behavior. It def. seems like a bug. Hoping someone from Ivanti can chime in. If not, I plan on putting in a support ticket.
Thank you all for great and useful advises. Here is what I found:
1. move system to specific device group
2. Dbl click device group to verify system is there
3. dbl click scope (based on that device group) to update it and verify system is there
4. ... and that's all! Run vulscan.exe /MaintEnable=False /AutoFix=True /showui=true. System will pick up updates with autofix settings for that specific scope.
It works in 100%.
All the best,
Robert.
I am trying to use the Windows Action Connect UNC share.
Diagnostics show the following
| Fri, 06 Apr 2018 14:22:03 PowerShell output: net : System error 53 has occurred. At line:9 char:1 + net use $UNCShare $Password /USER:$Username 2>&1 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | + CategoryInfo | : NotSpecified: (System error 53 has occurred.:Str | ing) [], RemoteException | + FullyQualifiedErrorId : NativeCommandError The network path was not found. |
Fri, 06 Apr 2018 14:22:03 Installation result -1918091202
Fri, 06 Apr 2018 14:22:03 RunPackageInstall: stop on returncode=8dac403e of package=Map Drive Test
Fri, 06 Apr 2018 14:22:03 processing of package is complete, result -1918091202 (0x8dac403e - code 16446)
any help would be greatly appreciated.