Security policies are propagated with warning?

I just installed service Pack 3 on my main domain controller and I have been getting the following errors in my Application Log.

1) "Security policies are propagated with warning. 0x534 : No mapping between account names and security IDs was done.
Please look for more details in TroubleShooting section in Security Help. "

2) The Group Policy client-side extension Security was passed flags (17) and returned a failure status code of (1332).

They appear about every 5 minutes or so. Microsoft says the following:

http://support.microsoft.com/default...EN-US;Q247482&

I edited the registry like they asked, but I am still getting this error in the event log. (Every 5 minutes) MS also suggested the following:

http://support.microsoft.com/default...;en-us;q279432

but that did not affect the problem eitheir. Any ideas anyone?

This is actually a really big problem in Win2k and E2K. If you are running very large E2K installations this problem can cause serious memory fragmentation. We call it zombie ACLs.

What basically happens is that you have either imported information from E5.5 using ADCs and that information contains a SID in the security mappings and AD cannot translate the SID back to an account. The same thing can happen when you do what the Q article references(install software, and then remove it, which removes the account, but not that security mapping.)

You need to follow the instructions in the article.. And then you need to determine where that SID is being assigned permissions and remove it. You can easily see unresolved SIDs in AD users and computers as it will always try to show you the friendly name, and not the SID. If you see a sid that does not translate to a friendly name. Do a LDAP query of AD looking for other instances of that SID. If it is a valid SID, you should be able to easily determine such.

For any instances where you do not find an account associated with a SID that has permissions, delete the permissions for that SID. This can be very labor intensive. I would make sure that you document all changes just in case you whack the wrong permissions.

As a side note---
If this problem is being introduced because of an exchange5.5 to exchange2k conversion. Insure that you run the IS/DS consistency adjuster on the 5.5 mailboxes immediately prior to moving them to E2K. The MS documentation says that you only need to run it once, but we found that if you do not run atleast daily before moving mailboxes, that zombie ACLs will be assigned.

Thanks for the tip. I will try that.