Client Automation Standard Practitioners Forum
Showing results for 
Search instead for 
Do you mean 

Patches deployed but the machine isn't patched - URGENT!!!

SOLVED
Go to Solution
Honored Contributor

Patches deployed but the machine isn't patched - URGENT!!!

Hello all.
I did a successful patch acquisition for all MS05 patches.

I'm testing patch management on a Win XP SP 2 machine. It has a "Discover patches" service assigned through RCS policy and deployed via RAM, and after a scan the machine is vulnerable to 9 patches (device compliance report).

Now i assign those 9 necessary patches to that machine through Policy manager (AD policy) and do another machine Patch Connect to deploy those patches. The patches appear in the client LIB dir but no patches are actualy installed: there is no sign of them in the Add/Remove programs and after another patch scan (to update the patch compliance), the Reporting Server and the Patch Manager web sites are still showing that the machine is NOT PATCHED with those 9 patches.

So for some reason the necesary patches are deployed but they didn't patch the machine.

I'm also seeing some weird stuff in my PATCHMGR.ZSERVICE instances for particular patch services, here's the screenshot for you to tell me if that's okay.

Please help, this is urgent!!!

Tnx
40 REPLIES
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Take a look at the client logs.
Make sure the Patches applied.
You may see something like not eligible or other messages stating that the Patches werenâ t applied.
I am assuming that your client connect has DNAME set to PATCH etc.
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Yes, the dname is set to PATCHMGR (the RCS domain for patch management) in the radskman connect. The connect is definately okay, as well as the ability of Reporting server to update the "Not patched" to "Patched" info, because i have made a test:
1. i decided to test the MS05-054 bulletin because the machine is not patced with it (it is shown in the device compliance report)
2. i assign a MS05-054 patch to a machine and do a machine Patch connect (radskman params are correct, the Discover_patch service was deployed with it earlier and did a scan on a machine so it must be okay)
3. i check the client side, the LIB dir got the MS05-054 ZSERVICE dir,and the client connect log shows the service was processed
4. i check the client add/remove programs (show updates checkbox checked)- no MS05-054 patch there!!! - it wasn't installed
5. i do a patch connect to do a scan, check the device compliance - the machine wasn't patched
6. i copy a WindowsXP-KB905915-x86-ENU.exe (that would be the MS05-054 patch) to a machine and install it manualy
7. it installs the patch, asks for a reboot,after a reboot the add/remove programs now SHOWS the "Security update for Windows XP (KB905915)", meaning the patch now WAS installed (manualy)
8.make a patch connect to scan the machine and check the Device compliance report - it now shows the machine IS patched with the MS05-054 patch!!!

So, patch reporting is working, i guess patch assignment and deployment also (from server to client) but the actual installation is not!

Can you tell me which specific client log to check for patch installation messages?

Perhaps the some ZSERVICE params are somehow preventing the execution of the patch exe file? Maybe ZSERVICE isn't configured properly (see the screenshot - "Connection instance name cannot be determined")?

What next should i do?
Respected Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Marko,

There is usually a log in c:\windows\kbx.log for each patch installed. I'm assuming patches installed via Patch manager would create this as well.

If the connect log is showing the create has run then it may be worth checking the individual patch log to see if this gives any more detailed information.

Hope this helps,

Moaeed
Respected Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

P.S - The reason you are seeing the connection instance name cannot be determined is because the substitution for &(ZOBJNAME)... only happens when you are running a connect. When viewing through System Explorer these values are not populated.

Hope this helps,

Moaeed
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

So this is what I understand:
The patch was deployed but did not appear to get applied.
You manually applied the patch and compliance shows it as ok now.

The ZCREATE method for the Patch appears not to have executed for some reason.
There should be a client connect log as a result.
See if you can find where it attempts to install the Patch and what the ZCREATE method did.
Respected Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

There is no zcreate on the attached gif...

Maybe worth checking the Zcreate on the Zservice against a patch thats working.

Hope this helps,

Moaeed
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

My guess is that the particular patch for that machine was not acquired successfully.

Can you confirm this? You should be able to drill down starting with the Bulletin in the RRS reports to find out which patches were successfully acquired...
"Well...it depends..."
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Okay guys, thanks for your answers.

Moaeed, there is a KBxxx.log in c:\Windows as a result of a MS05-054 patch i have installed manually. I guess then when patch manager installs another patch, there should be a corresponding log file for it to double-check the installation.

Roy and Jim, the patch is definately acquired correctly (see the screenshot) because for my test (manualy installing the patch on the client machine) I have used the patch file WindowsXP-KB905915-x86-ENU.exe from the C:\HPOVRadia\IntegrationServer3468\data\patch\novadigm\MS05-054\66017C28, meaning it's the same resource that should get transfered (or installed) on the client. It's the same file! After manualy installing the patch, the compliance report shows the patch is applied, so yes, the Discover_patch service is doing it's job, the complince check works fine.

All my patch ZSERVICES do NOT have the ZCREATE method defined! All of the service ZXXX methods are blank!

What should be the ZCREATE method? How do I populate all of the ZCREATE methods for all XY patch ZSERVICE instances easily?


Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

I made another patch test. Cleared all policies for patches and made a connect,deleted the connect log.

I assigned a (needed) MS05-047 (successfuly acquired) patch to a machine and did a patch connect to deploy and install it. Of course, the patch wasn't installed.

Here is the resulting connect.log.

Can you guys check it and see what you can find. I'll also check it but i would like your opinion as well.

Thanks
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

There's a lot going on in this log.
It indicates that the RPM client may not be current. Did you acquire and deploy the latest?
I can see where itâ s operating on Updating Service [MS05-053] and gets a RADPINIT pinit_rc:[650] - [Server stopped application configuration.]
I never see it attempt to apply MS05-047 and the 650 may be the cause.
I'm suprised to see RUM activity in a Patch connect.
I see all kinds of dll version mismatches etc.
I'd get another client to work on or refresh this one.
Frequent Advisor

Re: Patches deployed but the machine isn't patched - URGENT!!!

please be aware that dname is merely a name for the folder in which to store the desired state and does not relate to the DOMAIN name in the RCS OODB.

For patch however it is required to specify dname=PATCH (uppercase !) not PATCHMGR as you indicated. (p74 of the Installation and Configuration Guide)

cheers,
Marc
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Roy, i have the modules versions as it came with the Radia Fast Start from January 2006.
So far i have only upgraded some modules of the RMP. Maybe it's not the latest Patch manager client version but i have a collection of acquired MS patches and the Patch manager should be able to control the patch management in the current environment regardless of the "newest" version available, right? I know soon it will not be able to download new patches from Microsoft but at this point, it should deploy and install the patches i have already acquired. We plan to make a general upgrade in the following period.

Marc (I believe we met in Wien, you were the Radia essentials instructor, and i was the attendant :)) can you explain then, if I was using the dname=PATCHMGR all this time instead of (what you say is required) dname=PATCH during the machine patch connect, how come then the Discover_patch service got processed (deployed and installed) on the client? Discover_patch application definately works fine, and since the DISCOVER_PATCH and e.g. MS05-054 ZSERVICES are in the same RCS OODB domain (PATCHMGR), i thought the dname=PATCHMGR in the radskman command would work for both of them...? Can you explain little more about dname parameter for patch management? Are you sure it should be PATCH? can you explain why the dname=PATCHMGR was okay to process the DISCOVER_PATCH service? I'm really confused now...

Here's the SysExplorer screenshot of the PATCHMGR domain. there is a PATCH domain but it seems it's not used.
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

The documentation definitely states that you should use DNAME=PATCH, however I believe there are exceptions in the code which allow DNAME=PATCHMGR to work also.

After looking at the log file you posted, I'm nearly certain that the problem you are having is that you have not deployed the Patch Agent, or that you are using an old Patch Agent.

There are messages in the 'Discover Patch' section of the log such as:
error while autoloading "office2003::verify": couldn't open "C:/PROGRA~1/Novadigm/msoffice.tcl": no such file or directory
"Well...it depends..."
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

To migrate the new Patch Agent from your Acquisition environment to your Production environment, you need to ensure that it's connected to your DISCOVER_PATCH service (via the AUTOPKG.PATCH connection), then simply export the DISCOVER_PATCH service and import it as you would do with any bulletin.

If that doesn't work, you may need to run another acquisition and select the 'Publish and Distribute' option before performing the above steps.

Check the Patchmgr.Package domain and you should see a package (or packages) named 'PATCH_VERSION#_WIN32_#'.
"Well...it depends..."
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Marc and Jim you are right, i have been using the wrong dname=PATCHMGR parameter in the notify, now that i have changed it to PATCH, patch management is working. I guess thats why the RUM was also processed during the dname=PATCHMGR connect.

Patches are now applied and the device compliance report shows the difference (before and after the patching is performed).

Thanks again guys.
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

This is weird!
I'm working Radia Fast Start Environment and it made a PATCH and a PATCHMGR domains in the RCS DB. PATCH domain contains only a PATCH class with a _BASE_INSTANCE_. PATCHMGR domain contains everything a "Patch management" domain should have: PACKAGE, ZSERVICE, PATCH, BULLETIN, etc. classes.
However, doing a notify with dname=PATCH doesn't process the DISCOVER_PATCH application (which is responsible for the first installation of patch manager agent and later on for discovery of patches on the target machine), while notify dname=PATCHMGR doesn't install the assign patches!
So here's the situation:
1. to install the patch agent and scan the machine for patches i have to use the dname=PARTCHMGR
2. when i assign the needed patches to a machine based on a compliance report from the step 1, i have to notify the target machine with dname=PATCH to install the actual patches (they won't install if the dname=PATCHMGR)
3. to see the update in the compliance report(because the machine is now patched), i have to use the dname=PATCHMGR notify again, because the DISCOVER_PATCH application won't be processed if the dname=PATCH
4. compliance report for one machine now shows two records for every patch: one with status "Patched", one with status "Not patched"

This is weird. Why is the domain PATCH changed to PATCHMGR in the RFS implementation? Or why wasn't then the PATCH domain removed entirely (because I HAVE TO USE dname=PATCH to install the patch!?)

Here's the screenshot of my SysExplorer showing the PATCH and PATCHMGR domains.
Any comments from anybody?
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Marko,

In some of my previous posts I've explained that DNAME has no direct correlation with the RCS Domain Names.

The 'Patch' domain you see in the System Explorer has nothing to do with Radia's Patch Management solution. It's there to facilitate a feature for creating Byte-Level-Difference 'patch' files for updating large files that may have only had minor updates. The feature lets you deploy (for example) a 2GB file, and then when the file has been updated, instead of re-deploying the entire file, you can create a BLD patch that converts the existing file into the new file by deploying a file much smaller (maybe only 50k) rather than re-deploying the entire updated 2GB file.

What you are describing should NOT be happening. DNAME=PATCH should work for deploying the DISCOVER_PATCH service and for installing the patches.

I would suggest you check (and report) what the ZSTOP expressions are on the _BASE_INSTANCE_ of your PATCHMGR.ZSERVICE class and post your pm.cfg file. If what you are describing is actually happening in your environment then something is misconfigured and my guess is that it's a ZSTOP...
"Well...it depends..."
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Hello Jim.

Yes I uderstood even before from your previous answers that dname parameter has no connection whatsoever with the domains in RCS DB, but I was just sharing what i have discovered in practical situation. I know that patch management shoud work only with dname=PATCH, but then the DISCOVER_SERVICE isn't deployed, but when I put dname=PATCHMGR or,I guess, anything else like dname=WHATEVER, the ZSERVICE would be deployed under the client lib dir ...\WHATEVER\ZSERVICE\..., but then the patch processing wouldn't work. This is clear... I just want to know what to do to do both (process DISCOVER_PATCH and deploy and install patches) with one dname parameter, an it should be PATCH.

Here's my
PATCHMGR.ZSERVICE._BASE_INSTANCE_.ZSTOP001:
WORDPOS(EDMGETV(ZMASTER,ZDOMNAME),'PATCH PATCHOBJ PATCHMGR')=0
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

here's the patch.cfg file...
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

It was your pm.cfg file that I wanted to see.
(Policy Server cfg)
"Well...it depends..."
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Sorry, i thought you wanted patch cfg file since the problem is about patches...but obviously your knowledge is beyond mine so you know what you want to check :)

Here it is...
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Hi Marko,

The Policy Server has built-in Domain filtering (which is what i wanted to check). The following lines appear in your pm.cfg file:
DNAME=* { * !OS }
DNAME=OS { OS }
DNAME=PATCH { PATCHMGR }

...which look (mostly) fine. I'd recommend adding !PATCHMGR to the DNAME=* line.

These only apply to external policy retrieved by Policy Server, the "!" symbol means 'not'. So, when you run a connect and specify DNAME=OS, only OS.ZSERVICE instances are returned by Policy Server, everything else is filtered or dropped. When DNAME=PATCH, only PATCHMGR.ZSERVICE instances are returned. When DNAME=* (anything other than OS or PATCH in this case - for example SOFTWARE), all policy except for OS.ZSERVICE instances are returned. That line 'should' have a "!PATCHMGR" on it as well, otherwise PATCHMGR.ZSERVICE instances will be returned when you run a DNAME=SOFTWARE connect.

...but...I'm not sure that's what's causing everything you're seeing. Unfortunately, I think you're going to need to retest and then post your client logs, but before you do, please edit the above and restart your policy server. If you have more than one Policy Server, make the change on all of them...
"Well...it depends..."
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Great Jim, this was bothering for a while. Now I guess that's why my Usage manager gets deployed (USAGE.ZSERVICE.CLIENT_INSTALL_ENTERPRISE processed) on any dname. When I look at the client lib directory there is an Usage manager client ZSERVICE in SOFTWARE, PATCH and PATCHMGR dirs, because I have made notifies using all those dname parameters.

I have made a following change in my pm.cfg:
OLD:
DNAME=* { * !OS }

NEW:
DNAME=* { * !OS !PATCHMGR}

I guess the syntax is okay, you didn't specify should I put a comma or any other character between !OS and !PATCHMGR.

I'll make a new patch management test now on a new machine and post my results.

Tnx
Honored Contributor

Re: Patches deployed but the machine isn't patched - URGENT!!!

Some more info:
I'm using external policy (AD) for software management and to apply the needed patches to a mchine.

However, the basic applications like AUDIT.ZSERVICE.RIM_REPORTING, AUDIT.ZSERVICE.NVDM_DISCOVERY_OF_APPLICATIONS, PRDMAINT.ZSERVICE.MAINT_40, USAGE.ZSERVICE.CLIENT_INSTALL_ENTERPRISE as well as PATCHMGR.ZSERVICE.DISCOVER_PATCH are connected to a machine via internal RCS policy system, that is through POLICY.USER._NULL_INSTANCE_. The null instance also has a _ALWAYS_ connection to LDAP method for resolving other policy via AD.

In short, I wanted all machines to get those basic (necessary) applications directly using the RCS internal policy entitlement while all other software would be entitled to a machine via AD policy through Policy Manager.

Making changes you proposed to pm.cfg obviosly affects the second policy model (through AD) but not the DISCOVER_PATCH ZSERVICE since it's not attached to a machine through AD (PM). Or maybe I'm mistaken? Should I attach the DISCOVER_PATCH through AD as well (and remove the connection to POLICY.USER) or do you have any other idea? How to control the dname resolving issue when dealing with the internal RCS policy?

I have made a fresh test with dname=PATCH notify and the PATCHMGR.ZSERVICE.DISCOVER_PATCH wasn't processed. Here's the client connect.log, it was purged before the connect so it shows only this notify.

Please check it out and help me out...

Tnx
//Add this to "OnDomLoad" event