10-22-2018 03:12 PM
To clarify - this also occurs when using SCCM to deploy Windows updates, despite the notes in the bug report.
We have 10,000+ PCs currently being affected by this bug, with all updates being deployed by SCCM.
On testing, updates are taking at least 30-40% longer to install (even greater on non SSD PCs). Without manual configuration on the individual update settings, many of the updates don't install with our maintenance windows and the SCCM client will abandon checking for the installation outcome.
This is a really poor design, please fix it properly. We've never had this issue with any other AV. TiWorker.exe is a normal Windows function.
11-20-2018 02:58 AM
I had to do a Wilcard exclusion to solve this issue. Can't use Process exclusion as the path/hash may vary a lot
11-20-2018 02:34 PM - edited 11-20-2018 02:35 PM
Yes, the path/hash varies a lot, it's very annoying.
However we weren't comfortable using a wildcard exception of TiWorker.exe as it has too many security implications.
It's a very common Microsoft executable, and renaming any virus executable to TiWorker.exe as a means to circumvent all of Cisco AMP's functionality if detected is too great of a risk for our organisation.
11-28-2018 06:50 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide