locked
Application Detection Method not being honored. RRS feed

  • Question

  • We have a deployment of a patch for Lync 2010.  In the Detection Method we are using the path for communicator.exe and the version number.  We have a few systems testing Lync 2013.  The paths are completely different so we don't understand why these clients are getting prompted for installation of the update.

    The Detection Rule is a as follows:


    David Jenkins

    Friday, January 10, 2014 3:09 PM

Answers

  • The path is there but no communicator.exe.  In 2013 it's part of MS Office so it's in the Office directories.

    I'd expect if communicator.exe doesn't exist in the directory it would mean the check fails and the patch would not advertise.

    I think you're getting tangled up with the logic at play here...

    If this detection rule is on your patch deployment, the logic is this:

    "if this path/file/version is not detected, then I must deploy this patch to this machine"

    So, on your machines that do have Lync2013, they will also *not* have the unpatched Lync2010 binary, therefore, it will attempt to deploy the patch.

    You could consider applying another detection rule (maybe *AND* Lync2013 is not present), or, flip your detection logic around, and instead, detect for the unpatched Lync2010 binary (i.e. if version is less than 4.0.7577.4409) ?


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, January 10, 2014 11:34 PM

All replies

  • Is there a communicator.exe in %programfiles%\Microsoft Lync on those clients where Lnyc 2013 in installed?

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

    Friday, January 10, 2014 3:39 PM
  • No there isn't.

    The path is there but no communicator.exe.  In 2013 it's part of MS Office so it's in the Office directories.

    I'd expect if communicator.exe doesn't exist in the directory it would mean the check fails and the patch would not advertise.


    David Jenkins

    Friday, January 10, 2014 3:53 PM
  • The detection isn't a prerequisite though, its a verification method to ensure that the app (aka the command-line being run by the DT) is/was installed properly and that is continues to be installed in the future (the app model is an enforcement mechanism).

    For pre-reqs, you need to use global conditions and requirements.


    Jason | http://blog.configmgrftw.com

    Friday, January 10, 2014 4:17 PM
  • The path is there but no communicator.exe.  In 2013 it's part of MS Office so it's in the Office directories.

    I'd expect if communicator.exe doesn't exist in the directory it would mean the check fails and the patch would not advertise.

    I think you're getting tangled up with the logic at play here...

    If this detection rule is on your patch deployment, the logic is this:

    "if this path/file/version is not detected, then I must deploy this patch to this machine"

    So, on your machines that do have Lync2013, they will also *not* have the unpatched Lync2010 binary, therefore, it will attempt to deploy the patch.

    You could consider applying another detection rule (maybe *AND* Lync2013 is not present), or, flip your detection logic around, and instead, detect for the unpatched Lync2010 binary (i.e. if version is less than 4.0.7577.4409) ?


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, January 10, 2014 11:34 PM
  • BTW, WSUS/SUM handles all this for you, for patches. (or is this a hotfix?)

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, January 10, 2014 11:38 PM