Absent Member.
Absent Member.

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.


Labels (1)
4 Replies
Knowledge Partner
Knowledge Partner

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.
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
Absent Member.
Absent Member.

I hadn't seen that before. Thanks for sharing. I will submit this via that route!


Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

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
Micro Focus Expert
Micro Focus Expert

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 & live debugging against
the issue that currently needs to occur. But eventually you'll at
least benefit from knowing the outcome of that investigation, if
nothing else.

It's not clear yet what or how the issue seems "specific to some
machines." For the case besides yours its "only our Dell 3190
machines show this issue when upgrading to IR10", as opposed to Lenovo
300e. It's certainly presumed that it's not actually the hardware,
and is more likely to be some software component that is unique to the
machine software image(s) loaded on the models where this issue is

Alan Adams
Client for Open Enterprise Server
Micro Focus
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.