Kaseya Community

3 days for initial updates?

  • We bot a box (XP SP3) in for some work (more RAM, new DVD-R and a basic once over) we also installed Office 2k7, so we ran the initial updates on it thinking it would be a quickie, normally it is...

    Now we're on day three and it's still "Update processing OS service packs". Sitting in the office over the weekend, the machine reboots (seems like it does every 2 or three patch installs... I'm really concerned about this because we've still got about 200 more machines for this company to do...

    So I'm wondering anyone ever have this happen before, if so, any cause, rhyme or reason?

    Legacy Forum Name: 3 days for initial updates?,
    Legacy Posted By Username: thirteentwenty
  • I just reported 2 instances to K support where Initial Update gets stuck in an infinite loop, doing a Patch reboot every 10 to 15 minutes. In both cases it was an Office patch. See the KB article http://kb.kaseya.com/article.asp?article=305870&p=11855

    I recommend creating a ticket with K support asking them to fix Patch Management - as it should not loop forever when it encounters a problematic patch. Kaseya should be flagging the fact that they already tried to install a particular patch and ignore it on any subsequent patch scans that belong to the same Initial Update process. They could then list that patch as "failed" and generate an alert...

    thirteentwenty
    Now we're on day three and it's still "Update processing OS service packs". Sitting in the office over the weekend, the machine reboots (seems like it does every 2 or three patch installs... I'm really concerned about this because we've still got about 200 more machines for this company to do...

    So I'm wondering anyone ever have this happen before, if so, any cause, rhyme or reason?


    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: ReedMikel
  • ReedMikel... You're my hero!

    Filed a complaint with our sales rep as I had some other things to mention to him about BU-DR.

    Also, going back on track I found that a couple of machines that were having this (read similar) issue had botched installs of XP SP3 (no office installed on these). I had to manually do updates until SP3 could install... YAY just another 45 to go...

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: thirteentwenty
  • K support found that in my most recent ticket the Initial Update looping problem was because the LAN Share (Patch Mgmt->File Source) had its share permissions set to READ-ONLY. At some point the Initial Update process writes to (or attempts to) a .txt file located at \\\. I think it tries to write patch results to this .txt file. Later it then deletes this .txt file. K support found this Agent log entry:

    10:31:23 am 31-Jan-10 ERROR: The doDeleteFile() task could not delete the file \\SBS\Patches\87239568837083487656822462.txt because it is read-only


    I checked the patch share's permissions and it was set to EVERYONE: READ. I'm thinking that is the default permissions that Windows assigns to a newly created share? I must have forgotten to check/change it to FULL. Once I did change it to FULL, I ran another Initial Update on same machine and it ran without error.

    I wonder why Initial Update was able to *create* the file, but then unable to delete it? I guess the creation of the file is done locally by a process running on the KServer, so share permissions do not affect it. But you would think that deleting the file would be handled by a KServer process too, right? Confusing...

    It would be a nice feature if Kaseya could test the PM File Source - making sure permissions were adequate.

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: ReedMikel
  • I've just checked the File source and it's marked as Full Control for everyone, but the little checkbox in the Attributes for the directory is "Read-only"...

    I've re-run the "test" on the Patch Status page and it results in "Passed"...

    I'll do more poking around and see what happens

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: thirteentwenty
  • Being a bit curious, I decided to check whether Patch Status->[Test] would pass or fail if the File Share's permissions (share perms) were set to READ only? Surprisingly (well, I'm not really surprised Smile ) the [Test] PASSED. One would think it should fail if it couldn't write to the folder, right? I guess they forgot to include that in their test code...

    I have an open ticket and mentioned this quirk. I'll update this thread once K replies...

    thirteentwenty
    I've just checked the File source and it's marked as Full Control for everyone, but the little checkbox in the Attributes for the directory is "Read-only"...

    I've re-run the "test" on the Patch Status page and it results in "Passed"...

    I'll do more poking around and see what happens


    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: ReedMikel
  • ReedMikel
    Being a bit curious, I decided to check whether Patch Status->[Test] would pass or fail if the File Share's permissions (share perms) were set to READ only? Surprisingly (well, I'm not really surprised Smile ) the [Test] PASSED. One would think it should fail if it couldn't write to the folder, right? I guess they forgot to include that in their test code...

    I have an open ticket and mentioned this quirk. I'll update this thread once K replies...


    OK dude stay out of my head, I did the same a bit earlier today... now it's a race to see who support gets back to first!

    EDIT: This will be a good "test" too Big Smile

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: thirteentwenty
  • We shouldn't be required to give more than read access to the share containing patch updates. If it is trying to write any kind of file, it should do it to the local temp/working directory, NOT the patch location.
    We've had the "initial update" problems too and I'm very interested to hear the final resolution on this.

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: kentschu
  • This does raise something i have been pondering lately.

    We long since did away with using shares for patches. With broadband being cheap enough we just let machines get everything direct from MS. Saves a lot of hassle.

    However, if you REALLY wanted to download a patch once, what about getting an IPCOP box that caches windows updates. There is an add-on that does this and it will even list which update files are there in case you want to have a clean-up every now and then.

    Couple this with setting the gateway to the IPCOP and using 'transparent proxy' you've got a box on site that will save you re-downloading files.

    There are three downsides to this solution. It needs a box setup (could be VM but you still have to put it somewhere and on smaller sites this could be an issue). Secondly, you'd have to run this IPCOP as the gateway. You just gotta hope it's stable. Thirdly, it's yet another machine to maintain.

    Just an idea but I'll probably never go with it. ISA does this as well doesn't it?

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: chris@busy.co.nz
  • chris@busy.co.nz
    This does raise something i have been pondering lately.

    We long since did away with using shares for patches. With broadband being cheap enough we just let machines get everything direct from MS. Saves a lot of hassle.


    We use the patch source so that we don't kill the bandwidth for that site. (300+ machines), we'll download to patch source with the "test" machines and if the patch is good then approve for the "commons" and they can get it there.

    For smaller companies I sometimes go with just getting them from the net...

    chris@busy.co.nz

    However, if you REALLY wanted to download a patch once, what about getting an IPCOP box that caches windows updates. There is an add-on that does this and it will even list which update files are there in case you want to have a clean-up every now and then.

    Couple this with setting the gateway to the IPCOP and using 'transparent proxy' you've got a box on site that will save you re-downloading files.

    There are three downsides to this solution. It needs a box setup (could be VM but you still have to put it somewhere and on smaller sites this could be an issue). Secondly, you'd have to run this IPCOP as the gateway. You just gotta hope it's stable. Thirdly, it's yet another machine to maintain.

    Just an idea but I'll probably never go with it. ISA does this as well doesn't it?


    I hadn't thought about using somthing like IPCOP, but like you said there are downsides and the biggest I see is having to use that for the gateway.

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: thirteentwenty
  • K support (Andrew D) has pretty much chosen to not answer the questions I asked about why a File Share that I set to read-only still passes when you run a Patch Status->[Test]. He says that since K2 is out, there are no more changes being made to 5.1. Now I understand that logic, but he still could have taken the time to explain our observations. I imagine a lot of the PM code will work (or not work Sad ) the same way in K2...

    kentschu
    We shouldn't be required to give more than read access to the share containing patch updates. If it is trying to write any kind of file, it should do it to the local temp/working directory, NOT the patch location.
    We've had the "initial update" problems too and I'm very interested to hear the final resolution on this.


    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: ReedMikel
  • PM just seems to have more holes than Swiss cheese Smile

    - a scan of a XP Prof SP1 machine does not find it to need SP3, even though I have entered SP3's KB# into PM->KB Override. So I have to manually approve SP2 and schedule it to run using PM->Machine Update. Once that completes, then a subsequent scan does find it needs SP3. This process wastes several hours Sad

    - an Initial Update (IU) on a XP SP3 machine keeps attempting to install Office 2003's SP3 over and over, with a Patch Reboot and scans in between each cycle. I have to cancel the IU, then discover a MsiInstaller event ID 11309 in the Appl log: "Error reading from file: D:\SKU112.CAB. System error 21. Verify that the file exists and that you can access it." I found a solution on the Internet that changes an Office key named CDCache from 2 to 0. Why couldn't PM auto-assist in matters like this? Surely I am not the only PM user to run into this. Be proactive Kaseya - when you find a solution integrate it back into your product. Automation - that's what I want for my monthly monies!

    - I could list more of these IU failures. The point is that Kaseya's PM code needs to be made more intelligent. Ideally, they could check the Windows event logs for certain types of failures, as well as WindowsUpdate.log file. Realizing that might be difficult, they should at least add some smarts so that IU does not get stuck in an infinite loop processing the same patch over and over. If they can't make their code smart enough to detect that a patch has failed, at least flag it as failed if a another patch scan reports the same patch that was executed in the previous IU phase as being needed.

    Thinking more about the MsiInstaller error 11309: why wouldn't PM check the Windows logs for something as obvious as an MsiInstaller error? I would think that should be part of the process used to determine if a patch failed, right?

    I only have a few hundred agents. I can't imagine the using K's PM on thousands of machines.

    End of rant Smile

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: ReedMikel
  • Well said Reed, I'm currently "massaging" just under 300 machines by hand so that we can use PM on them, bad XP SP3 installs, screwed patch scans, and couple of other reasons prevent me from just pulling the trigger on the initial updates...

    The frist few clients went very well, the fourth and fifth went pretty good too, that is unti'l a software limitation came into play (custom apps + no support agreement == patches breaking stuff left and right)... After a couple hundred botched patch management runs, I'm almost afraid to pull the trigger on the inital updates... with any luck we'll get things sorted on whats going on now... and K2 will bring some welcome changes...

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: thirteentwenty
  • Boy do I HOPE PM code has been improved in K2. OTOH, it won't surprise me if PM pretty much works (or doesn't work) the same as in K2008...

    K2 gives support an excuse to say, we don't want to hear about any more 2008 bugs or deficiencies Sad

    thirteentwenty
    ... with any luck we'll get things sorted on whats going on now... and K2 will bring some welcome changes...


    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: ReedMikel
  • thirteentwenty
    We use the patch source so that we don't kill the bandwidth for that site. (300+ machines),



    Yeah ... I'll give you that one...

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: chris@busy.co.nz