We had the same issue and discovered that if you ran SDIDIAG on the
server and start with (in the SDIDIAG screen) "CHECK -v >>
sys:system\sdinotes.txt", the results will show on the screen. If all
is OK, run "CHECK -v >> sys:system\sdinotes.txt -n <container DN>"
(where users are). We received sync errors at this point and
subsequently ran "RESYNC -T -n <container DN>". This solved the
0xFFFFFA4C error when users tried changing their password. These
instruction can be found in the Deploying Universal Password

Jim Springer

Alan Adams Wrote:
> I can follow the logic of how the evidence appears to be pointing
> towards a client-side issue.
> Question though: Originally you had 'a' 2000 Professional SP4
> workstation which had the issue, and an XP Professional SP2
> workstation running the same client revision which didn't have the
> issue. Then, "this now seems to happen to all our users". Would
> something known have changed client-side for "all your users" within
> that time frame?
> I'm not aware of a "give me more NMAS debug logging"="true"
> configuration or generally available debug builds; an incident with
> Novell would of course open one or both of those possibilities. This
> issue just seems "a bit off" though, to where I expect there are clues
> to something simple that must be in front of us.
> Do you have a place you could make the LAN trace available to
> download? If not, or you didn't want to post it public, you could
> email it to 'com dot dr at alanadams' (listed backwards).
> If you don't have any suspicions about the version or manner in which
> NICI was installed at the workstation, I think my own next step would
> be watching a FileMon log during the password change operation. There
> are going to be plenty of files looked for but not found which are
> normal, but some may gives clues of a direction to look or compare.
> (http://www.sysinternals.com/ntw2k/source/filemon.shtml)
> "Lothar Haeger" <lothar_DOT_haeger@mummert.de> wrote:
> > > I'll take a trace tomorrow and have a look if the error
> > > occurs on the server or client.

> >
> > Well, tomorrow turned out o become next week, anyway, there's
> > no trace of the error in the server and network trace, also
> > local nmas.log does not have it (only nmas version and build
> > information here - no actual processing info).
> >
> > After some more testing, I am quite sure now that it's a pure
> > client problem. In fact we can switch the error on and off by
> > enabling/disabling advanced pw policies in the users nmas
> > password policy. Without advanced policies support there's no
> > problem, as soon as I enable them, we'll get 0xfffffa4c.
> >
> > I already recreated the policy in case it became corrupt, but
> > it remains all the same. Unfortunately I don't know what to
> > try next. Dstrace shows no hint on the error and last thing
> > on a network trace is the client searching and downloading
> > the login policy. Local nmas.log does not show anything
> > helpful either.
> >
> > Is there any other local nmas debug feature available, a
> > debug version of lgnwnt32.dll or some secret reg key ("NMAS
> > Debug"="now turn it really on", REG_SZ) maybe?
> >
> > Lothar

> Alan Adams, MCNE