none
Best practise for installing patches for SCCM Client 2012 (Both x86 and x64)) - OSD and Client Push Installation RRS feed

  • Question

  • Hi All,

    What is best practice for automatic installing of SCCM 2012 client Patches (using Patch switch) during installation of SCCM 2012 clients? The challenge is that now there are two versions of clients and updates (x86 and x64).

    I need information for:

    • OSD
    • Client Push Installation

    Thank you in advance.

    Regards,

    Wednesday, April 3, 2013 9:32 AM

Answers

All replies

  • 1) OSD, add the commandline with a WMI query

    2) For existing clients you can use the built-in scup catalog for the CU update. The scup catalog automatically installs the correct update.


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

    Wednesday, April 3, 2013 10:05 AM
    Moderator
  • Hi SinghSharad,

    Thank you for links to blogs but this does not answer my questions.

    I want options to install patches during SCCM client install ... not long after.

    Regards,

    Wednesday, April 3, 2013 10:07 AM
  • Hi, did You find a way for installing both x86 and x64 client patches using client push installation?

    Wednesday, May 29, 2013 1:46 PM
  • Sorry AlwaysRealistic, I think I misread your post.  You're looking to install the sccm client updates not Windows Updates.  Not sure how I missed that.  :-/

    Wednesday, May 29, 2013 2:10 PM
  • So as far as installing a patch for the SCCM Client during OSD, here's what we have as part of the installation properties in the "Setup Windows and ConfigMgr" step:

    PATCH=C:\_SMSTaskSequence\OSD\P1000003\hotfix\KB2817245\Client\x64\configmgr2012ac-sp1-kb2817245-x64.msp

    You will obviously need to change the package ID to whatever ID matches your SCCM Client package as well as change the x64 to i386 if deploying 32-bit OS. ;-)

    We don't use Client Push so unfortunately I don't have any suggestions for you there.  :-/


    Wednesday, May 29, 2013 8:22 PM
  • So as far as installing a patch for the SCCM Client during OSD, here's what we have as part of the installation properties in the "Setup Windows and ConfigMgr" step:

    PATCH=C:\_SMSTaskSequence\OSD\P1000003\hotfix\KB2817245\Client\x64\configmgr2012ac-sp1-kb2817245-x64.msp

    You will obviously need to change the package ID to whatever ID matches your SCCM Client package as well as change the x64 to i386 if deploying 32-bit OS. ;-)

    We don't use Client Push so unfortunately I don't have any suggestions for you there.  :-/


    Does anyone know can I pass it on like this: PATCH="%CD%\hotfix\fix.msp" and I'd put the actual .msp to hotfix folder inside the client package? Would be much nicer... as I said, I haven't tested this.

    How about for client push? Can there be multiple PATCH lines so that it figures out which one applies and which one doesn't (based on the running OS) so that I could pass both .msps for the x86 and x64?

    Monday, July 1, 2013 3:53 PM
  • There is no way to do this as client push is not architecture specific.

    Jason | http://blog.configmgrftw.com

    Tuesday, July 2, 2013 12:10 AM
  • This worked very nicely:

    http://www.m4ttmcg.com/2013/05/sccm-2012-client-push-including.html

    Tuesday, July 2, 2013 5:45 PM
  • There's a reason it's unsupported: it *will* cause issues. *Don't* use the clientpatch folder.

    Use SCUP or the packages.


    Jason | http://blog.configmgrftw.com

    Tuesday, July 2, 2013 5:59 PM
  • Any idea what kind of issues there will be? What I can see from the logs, it firstly installs the client and applies the patch afterwards...
    Wednesday, July 3, 2013 2:57 AM
  • It's abandoned code from SMS 2003. There is at least one known side-effect but that fact that it is explicitly not supported should be enough for you to not even think about using it.

    Do unsupported things, get unsupported results.


    Jason | http://blog.configmgrftw.com

    Wednesday, July 3, 2013 3:37 AM
  • And the side-effect is?

    Wednesday, July 3, 2013 9:20 AM
  • Once again, could be a lot of different things. The side-effect of running a red-light may be nothing, may be death, may be just a totaled car, may be killing a bus load of screaming children.

    Microsoft explicitly says its not supported so why would you go down a path when they say don't do it? There probably is no definitive list because they don't (and can't) test to know what every possible bad thing could happen is. They simply know it doesn't work and should not be used.


    Jason | http://blog.configmgrftw.com

    Wednesday, July 3, 2013 1:41 PM
  • narcoticoo, there are many reason that we do things that aren't "Supported by Microsoft". If this works for you and you see no issues with the clients installing correctly or patching correctly then by all means go for it.  As Jason states, it just means that if you called Microsoft about a client install issue they would tell you to do it differently.

    Being creative is a huge part of our objective as Engineers and in many cases means thinking outside the supported box that Microsoft provides.  Just understand the ramifications for support if you have to call them.  ;-)

    Wednesday, July 3, 2013 2:54 PM
  • ROFL...Jason you are one dramatic dude.
    Wednesday, July 3, 2013 2:55 PM
  • This is getting hilarious... In the whole thread, I haven't asked if it is supported or not, I was asking what the side-effects are? I have no intentions contacting MS for support if something goes wrong. You don't need to turn my head on something that I'm only curious about, that's just lame.

    And where is it said that it is not supported in 2012?

    Wednesday, July 3, 2013 3:39 PM
  • Not everything that can be or is supported or not supported is documented (or ever can be): http://technet.microsoft.com/en-us/magazine/jj643252.aspx

    Your expectation here needs to be adjusted. No one recommended contacting support. William just mentioned that *if* you have an issue and needed to contact support, they may decline to help you because you've done something explicitly unsupported.

    For clientpatch, here's the specific documentation noting it as unsupported: http://blogs.technet.com/b/configmgrteam/archive/2009/04/08/automatically-applying-hotfixes-to-the-configuration-manager-2007-client-during-installation.aspx

    Additionally, I've also been in contact with the sustained engineering folks responsible for the CUs and they've reinforced the statement.

    What can happen? Who knows? Microsoft does not test against unsupported configurations and features -- that's the definition of unsupported. It's not tested so no one really knows. They did find a couple of explicit issues (outlined in that post above) so know that at least those exist and probably more since it is, as mentioned, abandoned code.

    Why does it matter what can happen though? If the folks who write and support the code tell you shouldn't do it, you are simply asking for problems by doing it. Ultimately, you're asking a question that has no defined answer (except "bad"/unsupported things) that really doesn't matter if you follow the explicit guidance. If you don't, as William points out, that's a risk for you take and an answer for you to discover.


    Jason | http://blog.configmgrftw.com

    Wednesday, July 3, 2013 4:18 PM
  • Of for god sake... I'm just trying to figure out if someone has used this method what kind of problems have they seen, if any? I'm not even trying to find something 'official', just the notes from the field.

    And again, you just continue on lecturing about what is supported and what is not, I got your point already, get over it.

    The link you provided is the same I've found, is the behavior exactly the same in 2012?

    Wednesday, July 3, 2013 4:46 PM
  • Yes, the link is applicable for 2012.

    I doubt you'll find any "notes from the field on this", that's my point. Why not use a supported solution?


    Jason | http://blog.configmgrftw.com

    Wednesday, July 3, 2013 5:43 PM
  • Maybe because I'm stupid enough to think that something has changed since 2007 because there are now two different kind of clients (x86 and x64) for 2012.

    Hopefully they get CUs to behave like the SP1 update behaved that you could use automatic client upgrade feature.

    I might use supported solution or not, I'll do some testing with the parameters and see if something breaks.

    Wednesday, July 3, 2013 6:05 PM
  • I've echoed the same desire to the PM (formerly) responsible for client operations and the sustained engineering team.

    However, their point is that you've got an enterprise class software distribution system why not simply use it (via software distribution or SCUP) to deploy the update? There's no specific reason that the update must be there during initial client agent installation and it takes all of 5 minutes to set up a deployment to deploy the updates based on architecture on systems after the initial deployment. There are no cons to doing this and while it seems perhaps a bit un-clean, it is perfectly valid technically.


    Jason | http://blog.configmgrftw.com

    Wednesday, July 3, 2013 7:05 PM
  • Yes, I know that method works, and yes to me it is a bit un-clean.

    I'll test those parameters and post results here, thanks for your opinions! :)

    Thursday, July 4, 2013 3:28 AM
  • Ok, so I tested this a little bit... what it actually does:

    1. Installs the SP1 client WITH the parameters set correctly
    2. After the main client (SP1) is installed, the .msp for the update is called, no paremeters changed here.

    This info can be seen from the client installation log files.. so I personally don't think that using this method breaks any client installation parameter settings, because it installs the full client first and applies the patch afterwards...

    But like Jason here said, DON'T DO IT... or do it if you are brave enough.

    Friday, July 5, 2013 3:30 AM
  • Narcoticoo,

    Thanks for asking the question.  I have been looking for the same thing as of a few days ago.  I can say that I have customers that used the clientpatch folder successfully with no issues on 2007.  I am going to give a new customer options as long as they understand it is not supported.  But I will let them know as well that there are supported ways of getting those clients patched.  I was a big fan of the PATCH= in 2007, but it just dawned on me that x86 clients would be joining the site for a current customer.

    FYI, CU2 is out now.  Patch away! 

    http://support.microsoft.com/kb/2854009

    What would be nice is if we could have a category for these patches through our SUPs so we don't have to use SCUP.  Why not use SCUP?  Because my customers can barely grasp ConfigMgr.  Their eyes glaze over, SCUP would be too much for them.

    -LvilleSystemsJockey


    • Edited by Lville Systems Jockey Monday, July 8, 2013 4:04 PM Changed "client" (for my company) to "Customer" to avoid confusion
    Monday, July 8, 2013 3:12 PM
  • Like I said earlier, the most logical way to do the upgrade would be with the automatic client upgrade feature.. But until then, I think I'm going with This method.
    Monday, July 8, 2013 8:53 PM
  • If we didn't tell you it was unsupported and you walked the line and fell, you'd be back here letting off, so we tell you :-)

    The unsupported "story" Jason unwound on you, we're obliged to keep you working as best we can and to stay in a good shape to take on MS Support beyond our suggestions, so it really should be expected here, sorry!

    Really, you can trash that Site server as much as you want, put it out of shape, it is yours after all, but any assurances from us around stuff outside the norm comes with the usual proviso's.

    Good luck sorting this out, sounds like you are on top of it!

    Do you want to mark one of these postings as an Answer? Kent's one is marked but i see the thread went on a bit ...


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Saturday, January 25, 2014 12:35 PM
  • If we didn't tell you it was unsupported and you walked the line and fell, you'd be back here letting off, so we tell you :-)

    The unsupported "story" Jason unwound on you, we're obliged to keep you working as best we can and to stay in a good shape to take on MS Support beyond our suggestions, so it really should be expected here, sorry!

    Really, you can trash that Site server as much as you want, put it out of shape, it is yours after all, but any assurances from us around stuff outside the norm comes with the usual proviso's.

    Good luck sorting this out, sounds like you are on top of it!

    Do you want to mark one of these postings as an Answer? Kent's one is marked but i see the thread went on a bit ...


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Like I said, it works. I haven't experienced a single problem with four different environments I've been using this method. Supported <> Working solution. And for the record, yes I know it is not supported and I'm on my own when I'm using it.

    Still, it just works and for me, it's the simpliest way to apply patches for the client. I'm not encouraging anyone to use it, like said, unsupported.

    Saturday, January 25, 2014 3:35 PM
  • Gentleman....I happened to be experiencing this issue and watching the punch, counterpunch, duck, weave....and happened to look at the syntax for ccmsetup.  I soon discovered the option to use a /config:<configuration file> (http://technet.microsoft.com/en-us/library/gg699356.aspx)

    Specifies the name of a text file containing client installation properties. Unless you also specify the /noservice CCMSetup property, this file must be located in the CCMSetup folder, which is <%Windir%>\Ccmsetup for 32-bit and 64-bit operating systems. If you specify the /noservice property, this file must be located in the same folder from which you run CCMSetup.exe.

    Example: CCMSetup.exe /config:<Configuration File Name.txt>

    Use the mobileclienttemplate.tcf file in the <Configuration Manager directory>\bin\<platform> folder on the site server computer to provide the correct format of the file. This file also contains information in comment form about the sections and how they are used. Specify the client installation properties in the [Client Install] section, after the following text: Install=INSTALL=ALL.

    Example [Client Install] section entry: Install=INSTALL=ALL SMSSITECODE=ABC SMSCACHESIZE=100

    Saturday, January 25, 2014 9:15 PM
  • There's a reason it's unsupported: it *will* cause issues. *Don't* use the clientpatch folder.

    Use SCUP or the packages.


    Jason | http://blog.configmgrftw.com

    Is it neccassary to install the client patch during OSD after we upgraded to a CU or can i install the patch even after OSD?

    Im looking to install the patch on existings machines and on new machines after OSD is done.

    Wednesday, March 12, 2014 8:26 AM
  • Yes it's acceptable but if the patch contains a fix for something specific to OSD, it won't do you much good to install it after.

    Jason | http://blog.configmgrftw.com

    Wednesday, March 12, 2014 2:23 PM
  • There is no way to do this as client push is not architecture specific.

    Jason | http://blog.configmgrftw.com

    This should really be something that is added in coming releases.  Simply giving us two boxes for command line options (one x64 and one x86) in the Push installation dialog would remedy the issue.  One tiny bit of detection logic and the push determines which to use.  Whalla. 

    We could patch during push in SCCM 2007 since the client was always 32-bit, but not having something for this is missed.  I don't want to have to rely on the client getting the patch through SCUP/SUP when I am deplying new.  It is just not efficient.  I am sure many others agree.

    Is it something that is already scheduled as an upgrade?  If not can you put it in as a request?  Is there somewhere I can put it in as a request?


    Find this post helpful? Does this post answer your question? Be sure to mark it appropriately to help others find answers to their searches.

    Thursday, May 1, 2014 2:49 PM
  • It's annoying at best I agree.

    To my knowledge, yes there are DCRs in for this although filing another on connect.microsoft.com wouldn't hurt.

    Also, you need to work on your French: Voilà  :-)


    Jason | http://blog.configmgrftw.com

    Thursday, May 1, 2014 3:01 PM
  • LOL, I knew it didn't look right, but figured I'd let it fly anyway!

    Looking a bit further, I posted a question in the comments on the site below.  I wonder if the %PROCESSOR_ARCHITECTURE% in method #2 can be used somehow to make it work with push installation also...

    http://setupconfigmgr.com/patch-configmgr-2012-x86-and-x64-clients-during-a-task-sequence-using-the-patch-property-2-2/#comment-652


    Find this post helpful? Does this post answer your question? Be sure to mark it appropriately to help others find answers to their searches.

    Thursday, May 1, 2014 3:05 PM
  • Interesting idea. Not sure, worth testing though.

    I honestly prefer the SCUP method though for 1 main reason: it covers all client agent deployment scenarios without any additional configuration. Yes, it requires an additional step on the client itself and this isn't perfect either because you still need to use the PATCH property during OSD depending upon the issues being fixed.

    The best I can say is that at least it's better than it was in 2007 with the adoption of CUs.


    Jason | http://blog.configmgrftw.com

    Thursday, May 1, 2014 3:12 PM
  • %processor_architecture% can be x64 and you can still have x86 running on it. Not a valid variable to determine what you are running.
    Tuesday, February 2, 2016 1:58 AM