CA Client Automation

What, no pre-built WinOffline package attached this time? I was so impressed when you included that on your previous update, you’re slipping my friend! (JK)

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Tel: +1-731-676-4223

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

Done

And for everyone's knowledge, the JCL file within the WinOffline package includes an additional tag called, "VERSIONCHECK".  For example, from WinOffline-T5IZ342-System-Update-Inv-r14.0, the JCL file has--

--------------------------------------

PLATFORM:WINDOWS
PRODUCT:DTSVMG
COMPONENT:DTSVMG-DTSVMG
SUPERSEDE:
RELEASE:R14
GENLEVEL:GA
VERSION:20010222
PREREQS:
MPREREQS:
COREQS:
MCOREQS:
VERSIONCHECK:14.0.0.199

FILE:bin\amAdvInvNT.exe

--------------------------------------

This additional tag that WinOffline supports (ApplyPTF does not), will prevent WinOffline from applying the patch to the wrong version of the agent.  This is helpful if you have a mixed environment of agent versions, which is not uncommon.

It also eliminates the Administrator from having to do the homework on which agents should be targeted by the software package, and which shouldn't .

This has been a problem in the last 3-4 releases. Caused us a lot of headaches as we have many queries to check for missing window patches based on these patches being listed in the system inventory. What happens without these TFs is that the inventory times out and the .INV file thats uploaded form the agent does not contain any patch info and hence the system Patches node in the inventory on the DSM explorer gets emptied and all systems then report with no patches

We also had the following for this exact issue:

• 12.8.- T5IZ252
• 12.8 FP1 -T5IZ259 

not 100% convinced this has resolved the issue as I have still seen it with the TFs installed 

We got a fix T5IZ310 for 12.9, where we can disable the collection of the system updates. We are anyway not interested in these data.

I suppose the other fixes work in a different way?

Hi lza,

The fixes I'm referencing are not for disabling the report of Windows System Updates.  The fixes address a timeout issue, with how long the AM agent should wait for the WMI query to return, when requesting this list of system updates.

There are some 350+ patches for Windows 7 SP1 these days.  The AM Agent was essentially at a critical point where sometimes the WMI query would return just within the expected timeout, and sometimes not, causing the agent to delete the full list in one report, and resend a complete list in another report-- which is rather expensive.  The complete list of Windows System Patches can be ~80-100k, which is a significant chunk of the AM Agent inventory, and a significant amount of information for the Engine processing the Collect Task to update in the database.

With the patch applied to the agent, the AM agent should now be consistently pulling the System Update list, and sending a delta report for any changes (i.e. a new Windows KB is applied).  There may be some short-term overhead when rolling out these patches to the Windows Agents, as any Agent currently not reporting System Updates (due to the timeout issue), will now start reporting this data.  But after processing their first report, only delta changes should follow.

-Brian

Hi Brian

Thank you for the clarification!

Leandro

This really needs to be bundled into agents going forward or a parameter to set the timeout added or possible a separate module for operating system updates/patch collection. The path inventory is vital to us and I'm sure other customer. is the custom WBEM inventory subject to the same timoute? 

Hi Shocko,

The fix was merged into ITCM r14 SP1.. so the new agents no longer have this issue.  I'm unaware of the specific details of how it was fixed, but my impression was the previous timeout was unreasonably short given how much more information is stored/available these days in WBEM.  I'm not aware of any configurable value for the timeout, so I'm assuming SE has increased that timeout to some modest/reasonable value.

Regards,

Brian Fontana, CA Support

Thanks Brian! I don't see any explicit mention of it though at Test Fixes with 14.0.1 - CA Client Automation - 14.0 - CA Technologies Documentation 

Getting a few instances of this on R14 SP1. opening a support case now.