CA Client Automation

Hello Everyone,

It’s been a while and attached is the latest WinOffline version -- 2017.11.07

This release focuses primarily on long overdue WinOffline patching improvements and bug fixes.  Here are some highlights—

Improved Patch Handling

While prior releases of WinOffline would read and report the agent history file, it made no assumptions if a patch was already applied or not.  The logic was always to re-apply the same patch, even if it may have been previously applied.  One consequence of this approach was clogging of the history file and DSM\REPLACED folder, as WinOffline would create an endless history of the same patches, over and over, if the agent received the same patches again and again.

New logic has been added, and for patches that have any number of file replacements, WinOffline will now do a byte by byte comparison of each file to be replaced, to determine if the patch is already applied or not.

In the GUI-based mode, you can preview what patches will or will not be applied before pressing the “Start” button:

Whether the GUI-based mode or Software Delivery mode, the WinOffline log or software job output will reflect the actions taken by WinOffline:

WinOfflineClient.exe -- “This application could not be started.”

I’ve received several reports of this problem when delivering WinOffline via Software Delivery to targets in the environment:

This should be addressed now, and I’ll need feedback if this error is still occurring.  It’s a .NET SHIM error, and the cause was the .NET framework for some reason unable to determine the proper version of .NET to use for the client executable.

Command Line Attachment

By request, command line usage has been separated from the GUI.  So effectively there are three operating modes for WinOffline…

1- Standalone GUI (local execution):

2- Standalone Command Line (also for the local execution only):

Note: Be careful, WinOffline gets right to business.  It will scan the working directory for patches, and whether there are any, WinOffline will recycle all ITCM product services!

You can also invoke /help to see what switches are available:

3- Software Delivery mode

-gethistory option (software delivery mode only)

By request I’ve added the /gethistory switch for software delivery mode.  This switch simply reports the contents of the agent’s patch history file, as job output to software delivery.  WinOffline won’t recycle CAF or make any changes to the target system.

ITCM Removal Tool

By request I’ve introduced an ITCM removal tool.  It works via the Standalone GUI, via command line, or via software delivery…

1- Standalone GUI

Note: There are options for retaining the HostUUID, if your intent is to reinstall the agent.  There’s also a “normal uninstall” mode, which can be used to safely uninstall ITCM without harming other CA products that might be installed.

2- Command Line

WinOffline.exe -removeitcm

  Or

WinOffline.exe -removeitcm -keepuuid

  Or

WinOffline.exe -uninstallitcm

3- Software Delivery

There’s no screenshot for this.  Just package WinOffline.exe, and add the “/removeitcm” or “/normaluninstall” switch to the procedure parameters.

Software delivery will send WinOffline to the target.  WinOffline will copy itself over to %windir%\temp.  The SD job will then finish and report back to the DM that WinOffline arrived successfully.

As WinOffline will proceed to clean ITCM from the target system, nothing more than arrival of WinOffline can be reported back to software delivery.

The detached process running from %windir%\temp will proceed with removal.  When it’s finished it will clean itself up.

Minor fixes:

- Addressed an issue when removing patches, where sometimes the history file would gain an extra header at the top, “PTF Wizard created history file”.

- Fixed a bug in the helper thread that is designed to expedite WinOffline’s “caf stop” operation, where the helper thread wasn’t being too helpful, and wasn’t killing processes accordingly.  Now it’s more helpful.

- Many more fixes/minor improvements since last June that I’ve lost track of.

Enjoy,

Brian Fontana

CA Support

As usual – great work, looks like some nice additions to Brian’s Magic Toolbox.

Did you also include updates to the help dialog we discussed last week? Specifically for the reboot ptions.

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

Yes, the Help and Command Line Switches have been updated:

Also for the command line:

WinOffline.exe /help

Hi Brian

We tested the removal feature on Win7/Win10 clients.

It works fine on 64bit systems, but it fails on 32bit.

Is 32bit not supported, or is there something missing?

Thanks for the fantastic tool!

Leandro

My intent is to support 32-bit... let me runs some tests on my end to confirm the problem.  Thanks for reporting and I will keep you posted...

Hi Leandro,

This version should solve the removal tool problem on 32-bit Windows:

Latest WinOffline -- 11 December 2017 

Let me know!

-Brian

Hi Brian

Now it works! 

Many thanks!

Awesome, thanks for confirmation.

Hi Brian,  As always great tool.   Looks like this needs .NET Framework 4.0 or later.  When run from GUI error makes it  clear missing .NET requirement.  Would be helpful if when running from SD the job output log would output .NET Framework requirement is missing.  Currently job will exit with errorcode 5888, but may be helpful if SD log provides detailed info too.

Thanks

,

,

Hey Mike,

It's a catch 22... the .NET framework is not available, so the application actually never launches.  The 5888 error code is actually what Microsoft returns to the SD agent when it fails to launch my application due to lack of supported framework for the executable.  Thus I'm unable to adjust the error code or provide any meaningful feedback to software delivery job output.

For now, I do have it documented in the help section, not that it really makes anything better...

I've thought about implementing a wrapper in C++ for WinOffline, so I could implement a .NET framework check, and either 1-Launch the CLR 2.0 version, 2-Launch the CLR 4.0 version or 3-Report a meaningful error that no .NET framework is available.  I've also thought about re-implementing entirely on C++ for wider compatibility, but that would take considerable time, given how much WinOffline has evolved over the years.  The project actually started back in October 2011.

When I first got the idea for WinOffline (Windows Offline Patching-- shorted to "WinOffline" as the Visual Studio project name, and never renamed due to lack of creativity on my part), I knew nothing about the Microsoft .NET framework.  WinOffline became my excuse to see what the buzz was about.  I took for granted that not every customer out there would have the .NET framework available.

I suppose through the years I expected Microsoft to eventually integrate .NET support into Windows, so it worked natively, out of the box, yet all these years later, the .NET framework is still treated as an addon.  I've always been deeply disappointed that Microsoft doesn't stand firmly behind their framework, even as they utilize it more and more in their applications these days.

I am thinking about splitting the utility-- re-implementing the WinOffline patching in C++, and carrying on all the GUI utilities in .NET.  I've only scratched the surface on the database tools, just there's no time these days to just block out the world and program.

Okay, /rant.  Always more improvements on the horizon...

-Brian

I told you already, it should be renamed Brian's Magic Toolbox

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com<mailto:Stephen.McCormick@ca.com>

Done.

There ya go!

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com<mailto:Stephen.McCormick@ca.com>