Skip navigation

So there was a recent security update for RHEL that breaks a library dependency for the Configuration Manager client and OMI.

/opt/microsoft/configmgr/bin/ccmexec.bin: error while loading shared libraries: cannot open shared object file: No such file or directory

The issue is simple enough to fix with a sym link update.

sudo ln -sf /usr/lib64/ /usr/lib64/
sudo ln -sf /usr/lib64/ /usr/lib64/

Simple enough.  If you are on x86 then change /usr/lib64 to just /usr/lib/

Special thanks to Morten Vinding for the best library to use.


  1. We had the same problem.
    All through your solution works, it is not the best way to solve it, since it will not work next time RedHat upgrade the libraries.

    What we did was:
    sudo ln -s /usr/lib64/ /usr/lib64/
    sudo ln -s /usr/lib64/ /usr/lib64/

    Interesting enough it seems that Microsoft linked correctly to the major version of the libraries in SCOM 2007: => /usr/lib64/ (0x00000037a1800000) => /usr/lib64/ (0x000000379dc00000)

    • Thanks, I’ll review our systems and see. I had attempted linking to several libraries but found that these were the only ones that worked (in a pinch on time as usual).

      I’ll have a look at the libraries you have listed.

      • Tested and verified. I’ll update my post shortly to reflect the change.

        Thanks again Morten.

  2. I have seen this issue yet again with the Dec 2015 OpenSSL update for RHEL6. Is there a way to avoid this with future OpenSSL updates? We’ve automated our RHEL patching and you only really notice this once you see the RHEL clients are no longer showing as active in SCCM

    • Hey Alan, short of finding a way to set a static link against a dynamic target there isn’t a good way I’m aware of to avoid this issue. I’m not saying it’s impossible, but I haven’t got the answer off the top of my head. I’d just be wary in the future of release bulletins involving openssl and review the potential for changes in this libraries naming.

Leave a Reply