none
ClientPatch folder method for including client updates - supported? RRS feed

Answers

  • It is not supported, it is not tested by the product team, and it does not necessarily just work.  There are times when using the ClientPatch folder will cause certain client properties to not be honored which can cause all sorts of problems in a task sequence like being unable to install Applications or Software Updates. 

    PATCH= may require slightly more effort. But, it is supported, is tested by the product team, and it does work.


    • Edited by NPherson Tuesday, September 2, 2014 6:15 PM
    • Proposed as answer by yannara Tuesday, September 2, 2014 6:49 PM
    • Marked as answer by Garth JonesMVP, Moderator Wednesday, February 3, 2016 5:37 PM
    Tuesday, September 2, 2014 6:14 PM

All replies

  • It Works but the thing is that you now have a 32 and a 64 bit agent. You need to somehow make sure that they apply the correct patch.

    Kent Agerlund | My blogs: blog.coretech.dk/kea and SCUG.dk/ | Twitter: @Agerlund | Linkedin: Kent Agerlund | Mastering ConfigMgr 2012 The Fundamentals

    Thursday, May 30, 2013 3:00 PM
    Moderator
  • To add on to Kent's note - While it works, it does appear to still be unsupported.

    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Thursday, May 30, 2013 3:18 PM
  • To my knowledge, clientpatch is left over code from SMS 2003. It is known to break things and is completely unsupported. I would never use it.

    Just to provide ammunition (because this is a "battle" I've been waging with the product team and support), why do you need this functionality? Specifically, why does the Windows Installer PATCH property not work?


    Jason | http://blog.configmgrftw.com

    Thursday, May 30, 2013 5:33 PM
  • Hey Kent,

    I found that creating the clientpatch folder under both x64 and i386 folders of the client, and copying the appropriate architecture hotfix to the right clientpatch folder works fine

    creating a clientpatch folder at the same level as the i386 and x64 folders does not work

    Thursday, May 30, 2013 11:50 PM
  • Hey Jason,

    for some background and ammo for you, we have an environment with thousands of distribution points spread across Australia servicing their local subnets.

    Our links are so bad to these sites, that in SCCM 2007, client push was not feasible except in one off type remediation scenarios, because the client package always came from the site server.

    In SCCM 2012, one of the changes that is really great for us is that client push will leverage the local DP for the client package files, so I've been testing this.

    Adding the PATCH=  property to the client push command line means hardcoding the location of the patch file. Thats fine if you're pushing from the site server ala 2007, but that means it wont leverage the patch files on the local DP.

    I know there are other supported methods, we can use a dynamic collection with a query based on client version and a mandatory deployement of the patch etc, but this seemed like a solution that would cater for the local DP requirement, work for client push, and work for OSD task sequences without modifying command lines or using scripts.

    Essentially, if it works, this is a perfect "out of the box" type scenario. 

    *Edit* - also, if you review the ccmsetup log, the patches are applied last. They dont get appended to the client.msi cmd line. I'm not sure if thats different to how 2007 worked, but if it is, then maybe it wont affect cmd line switches anymore ?

    Cheers,


    Matt


    Friday, May 31, 2013 12:14 AM
  • Not sure what you mean by your edit. The PATCH property is a Windows Installer function and has nothing to do with ConfigMgr so there can't be a behavior change there.

    Also, to add more detail, why doesn't simply deploying the updates after client installation work for you?


    Jason | http://blog.configmgrftw.com


    Friday, May 31, 2013 12:52 PM
  • It would be nice to know as a fact, is clientpatch supported or not in CM12? It is so much easier to implement than "PATCH=", since there are patches comming all the time to CM :)

    Please note that since even CM12 R2 has some bugs in OSD, CU1 patch needs to be applied during OSD setup confmgr step, before any apps and update installations.

    Tuesday, September 2, 2014 8:44 AM
  • It would be nice to know as a fact, is clientpatch supported or not in CM12?


    It is not. 

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, September 2, 2014 11:46 AM
    Moderator
  • Like stated many times before, it isn't supported BUT it just works.

    Tuesday, September 2, 2014 5:00 PM
  • It is not supported, it is not tested by the product team, and it does not necessarily just work.  There are times when using the ClientPatch folder will cause certain client properties to not be honored which can cause all sorts of problems in a task sequence like being unable to install Applications or Software Updates. 

    PATCH= may require slightly more effort. But, it is supported, is tested by the product team, and it does work.


    • Edited by NPherson Tuesday, September 2, 2014 6:15 PM
    • Proposed as answer by yannara Tuesday, September 2, 2014 6:49 PM
    • Marked as answer by Garth JonesMVP, Moderator Wednesday, February 3, 2016 5:37 PM
    Tuesday, September 2, 2014 6:14 PM
  • Still to this date I haven't heard any of the real issues someone is always posting that might happen when using clientpatch method. I'd be happy to hear in what situation and with what other properties were used when it didn't work as expected?
    Tuesday, September 2, 2014 6:29 PM
  • Back with CM 2012 RTM CU1 and CU2, it would cause Applications and Software Update steps to fail because the SMSMP property didn't get fully listened to.  The response from the support team was "How many times do we have to tell you guys we don't test or support this?".

    I have not tried it since because they have been very clear about the fact that with any CU or Hotfix, whether it seems to work or not, they aren't going to spend time testing to find issues with the process or fix issues if they are reported... because it is not supported.

     


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.



    • Edited by NPherson Tuesday, September 2, 2014 6:53 PM
    Tuesday, September 2, 2014 6:35 PM
  • Never tested with RTM CUs, with SP1 or R2 CUs, never seen any problems with the SMSMP.
    Tuesday, September 2, 2014 7:00 PM
  • I'm glad to hear that you haven't had any problems.  However, since PATCH= works just fine and is supported (and isn't really much more work than a custom ClientPatch folder), why not use it?

     


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.

    Tuesday, September 2, 2014 7:16 PM
  • Well, if the clientpatch works, why complicate things? And to me, using patch property is much more work. Like I noted earlier, it isn't supported, but it just works, it's up to admin to use it or not. And if something goes wrong, warnings have been given.
    Tuesday, September 2, 2014 8:15 PM