OES Client 2 SP4 (IR11) - Error 0xFFFFFA27 Lenovo 300e

Just another follow up on my previous post about this same issue. I ran some test on the latest release of IR11 on our Lenovo 300e winbooks. I get the same results with the fix being to back rev the NICI to 2.77 to get the login to work. I noticed this seems to be something with the 300e and N23 series of laptops.

I would normally start an SR with MicroFocus to start working on this but working for k12 schools I don't have a cheap way to do so. I have talked with Lenovo support twice on this issue with the same results both time. Call MicroFocus.

Not sure if anyone else is seeing this or not. If Someone in MicroFocus wishes to work on this and would like to use my systems as a test bed to get this resolve I am more then willing to provide logs and a system to test against. Just can't afford to create an SR.


  • rhuhman wrote:

    > I would normally start an SR with MicroFocus to start working on this
    > but working for k12 schools I don't have a cheap way to do so.

    Hi Richard,

    Have you seen this?

    > It is Novell's policy not to charge customers for technical support
    > incidents that result from previously unknown or unpublished Novell
    > software defects. If you want to contact Novell regarding a software
    > defect, you may register a "bug report" by filling out the form
    > below. You will not be contacted by a Novell support engineer unless
    > Novell needs additional information to resolve the issue.


    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • I hadn't seen that before. Thanks for sharing. I will submit this via that route!


  • rhuhman;2492178 wrote:
    I hadn't seen that before. Thanks for sharing. I will submit this via that route!



    You might try TID 3576402 https://support.microfocus.com/kb/doc.php?id=3576402

    Earle Wells
  • As mentioned in the TID linked to by Earle, the
    CCS_E_AUTHENTICATION_FAILURE (-1497, 0xFFFFFA27) error can be returned
    under multiple circumstances. The most common of which, among
    otherwise successful installations of NICI, is when Windows
    permissions to the NICI user directory no longer allow access.

    However, note the permission issue is one that should only occur after
    the user has successfully logged on to Windows itself; e.g. when
    unlocking an already logged-on session, or logging into
    eDirectory-only from the user's desktop.

    Because for the "logged out Windows machine" case, there is a
    different NICI directory for "System" being used. And unlikely to
    have lost it's permissions, because the LocalSystem user's SID never
    changes, unlike user accounts. So if you're seeing a
    CCS_E_AUTHENTICATION_FAILURE even when you reboot and try to login to
    eDirectory Windows through the credential provider for the first
    time, that's typically an issue other than NICI user directory
    permissions. But in theory could still be "NICI user directory
    related", if the NICI user directories are simply deleted or similar.

    CCS_E_AUTHENTICATION_FAILURE can also occur because the installed NICI
    registry information doesn't match the actual NICI .DLLs and other
    binary files. e.g. If there was some kind of failed NICI
    installation, or somehow older NICI files are still being loaded from
    an alternate location and trying to use the latest registry info.

    CCS_E_AUTHENTICATION_FAILURE can also occur because the "handshake"
    that goes on between software that wants to use NICI and the NICI
    version actually available for use fails. This normally isn't a
    possibility unless the handshake process itself changed, but between
    NICI 2.7.x and NICI 3.0.x its expected the process did change.

    Which is why there was an updated version of NMAS (9.0.4) in addition
    to the updated version of NICI (3.0.3), because NMAS needs to be built
    to handshake with the version of NICI it expects to use.

    That would also be my concern with "back off to NICI 2.7.7 with an
    otherwise IR10 installation", because that would be knowingly putting
    a non-NICI 3.0.x version under NMAS 9.0.4. Unless you happened to
    also back off to NMAS 8.8.x, e.g. by running the IR10 custom install
    and de-selecting both NICI and NMAS when upgrading a machine which
    already had NICI 2.7.7 and NMAS 8.8.x currently installed.

    We do have at least one other customer who is seeing this kind of
    issue (upgraded to IR10, and now see a CCS_E_AUTHENTICATION_FAILURE
    which has nothing to do with NICI user directory permissions), and
    they do have a case open and we're investigating. It's still early
    and there is an exchange of machine images