Client Automation Standard Practitioners Forum
cancel

Patching problem

SOLVED
Go to solution
Highlighted
LeMat
Super Contributor.

Patching problem

Hello,
last time i di patching to group of computers, in main window of reporting I see correct number of patchem computers, but when I see the list there are only few computers scanned some time ago.
In logs of newly patched clients I see the status of the managed service is:
Installed - Server stopped application configuration.

There is an entry in the connect log while processing the patch ZSERVICE:
Radia Error occurred, status: 650

Patches are entitled correctly, I seen in old cases that it is the problem of resolution but nothing changed I think.

What should I check else to solve this problem?

If anyone coold help I'd very grateful.

King regards
Leszek
13 REPLIES
Biju V George!
Acclaimed Contributor.
Solution

Re: Patching problem

Hi Lemat,

650 error stands for resolution error.

Try to troubleshoot

Clear Rcs,client logs
1. Install an application, check the RCS state or any resolution error.
2.Check for compliance report, identify a patch that needs to be applied & assign the patch to the respective client using AD or internal radia policy.
3. DO a patch notify
4. Check for the Compliance reports.
5. post client logs,rcs logs..


Biju
LeMat
Super Contributor.

Re: Patching problem

Hi
I attach a fragment of log with one of PATCHES installed MS04-010 (failed) and a fragment from the same notification where software service called "cmd" is correctly installed.
I don't get why doesn't it work.

At the begining of log of MS04-010 there's different ZAVIS parameter (in sys_expl its YXNX for MS04-010 and here it's changed to YNTN ?!?).

Does anybody get why?
Thompson, Jim
Outstanding Contributor.

Re: Patching problem

An rc:650 means an error occurred on the server. Client logs usually will not help troubleshoot the problem. A look at your RCS log and radish.log will likely provide the answer.

Also, I'm curious as to why you think it's "okay" to call RADPINIT directly? That hasn't been "okay" since Radia 2.x - I don't think it's related to your current problem, but beginning with Radia 3.0, every Radia connect should be launched with Radskman (not Radpinit or Radconct). Radskman does some pre-connect processing that doesn't occur when you call radpinit. Support will likely refuse to troubleshoot the issue if they notice that the connect was initiated by calling radpinit.

Radskman can still be used to initiate a single service install so there's absolutley no reason 'not' to use it.

"Well...it depends..."
LeMat
Super Contributor.

Re: Patching problem

Hello Jim
I gond get why You talk about radconct
I use radskman to do this.
I startedthe process using:
radskman ip=xxxx, dname=PATCHMGR etc.
Thompson, Jim
Outstanding Contributor.

Re: Patching problem

Sorry.

I see now that it's just a 'log snippet' - I thought it was the full log starting with a call to Radpinit.

Forget I said anything about radconct and radpinit.
"Well...it depends..."
LeMat
Super Contributor.

Re: Patching problem

OK

I attach PIECE :) of log from RCS. This piece regarding installing of one of patches.

Maybe somebody can see something strange - incorrect
Thompson, Jim
Outstanding Contributor.

Re: Patching problem

We really need to see more of the logs. Especially the full connect.log from a machine that failed.

My guess at this point is that the DISCOVER_PATCH service didn't run for some reason... not entitled? encountered an error? A full client log would let us confirm or deny that.
"Well...it depends..."
Marko_
Acclaimed Contributor.

Re: Patching problem

Hello.
This is almost the exact problem i had a week ago. I guess you experienced this after upgrading your patch manager to 3.0? Or just using the RPM 3.0, right?
Okay, i noticed you mentioned using dname=PATCHMGR...if yes, this is wrong, you should use dname=PATCH!
Also, new versions of RPM are using new ZSTOP in your PATCHMGR.ZSERVICE._BASE_INSTANCE_ so check that also.

Thats it for now, check these and post your results.

HTH
LeMat
Super Contributor.

Re: Patching problem

Thank You guys for all help, the reason was that I put zstop in Discovery Patches for all windowses except WINXP WIN2K WIN2K3 (it is correct zstop for all services but as I see it can't be a statement of Discovery Patches).


BTW
How to exclude Win98 if this is not correct way?
Marko_
Acclaimed Contributor.

Re: Patching problem

Hi,
if you want to EXCLUDE patches for Win98 OS from downloading them, you should use the Patch Manager Administrator Web page, click on the Configuration Settings->Preferences and in the Excluded Products field enter what you want excluded with:
!PRODUCT1,!PRODUCT2, etc.
Example:
!Windows 98*,!Windows 95*,!*Office*,...

HTH
LeMat
Super Contributor.

Re: Patching problem

But will it exlude services from beeing processed during radskman by Win98 stations?
Or will it exclude whole bulettins from beeing acquired from MS site?
Marko_
Acclaimed Contributor.

Re: Patching problem

It will exclude actual patches (patch files) contained in a bulletin for a certain OS from being downloaded. If i'm not mistaken, bulletin is a description of a security issue regarding an e.g. certain MS Application. But this application could be released for various MS Windows versions, so you can control for which ones you want actual patch files to be downloaded (or not) by excluding Windows versions or entire MS Products.

Perhaps you can use the second ZSTOP (along with the mandatory one for resolving PATCH services) containing OS exclusion (the one you proposed), but i don't have enough knowledge about that. I guess you can use them both, but take care of ZSTOPXXX numbers. Maybe somebody else can verify this idea...

HTH
Biju V George!
Acclaimed Contributor.

Re: Patching problem

Hi Lemat,


ZSTOP is used only in catalog resolutions. The exclusion list Marko is talking about is exclusion from patch download from Microsoft site to your radia database.

Biju