Deployment and Imaging Group

 View Only
  • 1.  Deployment and Patch Don't Always Play Well Together

    Trusted Advisor
    Posted Jun 05, 2019 09:55 AM

    I'm running 8.5 RU2 with persistent connection, and I love how real time many things are.

    I have noticed, though, if I'm deploying an image with many software installs that install as post image tasks, often patch will begin installing titles and this creates a conflict causing my software installs to fail.

    For example, we have a technology lab with several adobe titles, several autocad titles, etc.  It can take these image jobs 80+ minutes to complete.

    The agent should somehow be smart enough to not allow these install conflicts to happen.  Please don't suggest I start building fat images building the titles into the image, that's just bad practice.  If I need to update Photoshop on 3 labs, I don't want to rebuild 3 images, I just want to update 1 post image task used in the 3 lab imaging jobs.

    For now, I'm just disabling all my patch policies when we image those lab machines, but that's not ideal and a little bit of a security risk as someone needs to re-enable them.

    I don't want to not put the patch plugin on the base image because as soon as it attempts to install, it kills the agent mid whatever it's doing.  I thought about having a dummy file placed at end of image time and then scope the patch plugin to only install on computers with that dummy file, but again I think this would also a timing issue because existing machines in the console being reimaged would fall into the filter and attempt to install the agent as soon as they come up.

    Thoughts?  I am sure I posted this issue before, and I looked through my post history, but couldn't find it, so I apologize if I'm repeating myself to some.

    I'll put a ticket in as well.

  • 2.  RE: Deployment and Patch Don't Always Play Well Together

    Posted Jun 07, 2019 02:29 AM


    why not just putting these clients at the beginning of image process into a filter and remove them at the end of deployment. This filter could be used as an exclusion in your patch policy targets? This is just common practice to have a "alone running" deployment job.


  • 3.  RE: Deployment and Patch Don't Always Play Well Together

    Trusted Advisor
    Posted Jun 10, 2019 12:46 PM

    @md - thanks.  The problem is on reimage, the computers still think they're in X filter and there is still a timing issue until they fall out of it (and then back into it).  I don't want to have to remove computers from management to reimage.  Let me know if I'm misunderstanding. 


    I get there's no easy fix, but i do think it's a fair question for a company that offers deployment and patch that those 2 tools work together and don't cancel each other out :)

  • 4.  RE: Deployment and Patch Don't Always Play Well Together

    Posted Jun 14, 2019 10:39 AM


    I don't have this issue, but probably because my default patch install schedule is set at a certain time w. daily repeat. So unless deployment with reimaging coincides with this specific time sw delivery policies are not interrupted. 

    Is your "Client Software Update Plug-in Policy" (or alternate policy) set with a scheduled time without repeat?

    If that's the case the installation time has passed and the agent will attempt to install applicable patches asap. 

    I realize the result is a longer vulnerable window for each deployed machine, until it gets fully patched, but I have added 2 extra policies with a task to initate patching during night time (should the computer be available). 

    Best regards, Mikkel

  • 5.  RE: Deployment and Patch Don't Always Play Well Together

    Trusted Advisor
    Posted Jul 02, 2019 07:46 AM

    We're a K12, there's no maintenance window where I can guarantee machines can be patched.  Students take laptops home, do homework, etc.  Machines are 90% laptops that are often powered off when most maintenance windows probably are.

    We also want patches to go out ASAP (as long as machine isn't in post image tasks), and I think that's a fair feature request that many people would want.  :)