OIM 11gR2SP error Failure occurred in the execution of deployment request with ID '1265037897937' for task '6'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(p13n_ejb.jar)

After shutting down one of the managed servers in a multi-server cluster, unable to re-start that managed server due to a WebLogic Portal (WLP) application deployment failure. The managed server can be started after deleting (undeploying) the WLP application that it hosts.  Any attempt to deploy the application results in the following errors and the application won't deploy:

Error:

<Error> <Deployer> <TDAB-MAWLP-CP02> <wlpServer2> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1265037908033> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1265037897937' for task '6'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(p13n_ejb.jar)
Unable to deploy EJB: PropertySetManager from p13n_ejb.jar:
Exception while attempting to deploy Unchecked or Excluded Security Policy: weblogic.security.service.ResourceCreationException: weblogic.security.spi.ResourceCreationException: [Security:090310]Failed to create resource
weblogic.application.ModuleException: Exception preparing module: EJBModule(p13n_ejb.jar)
Unable to deploy EJB: PropertySetManager from p13n_ejb.jar:
Exception while attempting to deploy Unchecked or Excluded Security Policy: weblogic.security.service.ResourceCreationException: weblogic.security.spi.ResourceCreationException: [Security:090310]Failed to create resource
...
weblogic.ejb20.interfaces.PrincipalNotFoundException: Exception while attempting to deploy Unchecked or Excluded Security Policy: weblogic.security.service.ResourceCreationException: weblogic.security.spi.ResourceCreationException: [Security:090310]Failed to create resource


Note: This issue is only possibly when WLP uses Embedded LDAP.  In WLP versions 10.3.2 and above, WLP should be using the RDBMS Security Store in place of the Embedded LDAP in which case this issue wouldn't exist.  However, the RDBMS Security Store isn't mandatory so it is still possible to be using the Embedded LDAP.  It is highly recommended that the RDBMS Security Store be used in place of the Embedded LDAP In WLP versions 10.3.2 and above.

CAUSE
Managed server's LDAP is out of sync with the Admin server's master LDAP which causes deployment failures due to corrupt security policies.


SOLUTION
LDAP is stored on all servers, admin and managed.  The admin server has the master copy of LDAP and any updates get pushed out to the managed servers from the admin server.  Sometimes the LDAP in a managed server becomes out of sync with the LDAP on the admin server and can cause deployment issues.  Please make sure the managed servers' LDAPs are in sync with the admin server's LDAP.  This assumes that the LDAP on the admin server is not corrupt.
Backup all LDAP directories on the admin server and the managed servers.  They are located in the server's .../data/ldap directory.
First try the following:
Shut down the managed servers and delete the managed server's ldap folders.
Login to the WLS Console.
Click on the domain in the left panel.
Click on the Security Tab.
Click on the Embedded LDAP Tab.
Select "Refresh Replica At Startup".
Reboot the Admin and managed servers.
This will refresh the managed server's LDAP with the admin server's LDAP.
If the above procedure doesn't work, do the same exact procedure except this time select "Master First" instead of "Refresh Replica At Startup". This will force the managed servers to use the admin server's LDAP.
If the above two don't work then there might be an issue with the admin server LDAP or it could be something totally different. At this time you can try using the automatic LDAP backups. They are located in the server's .../data/ldap/backup directory.  Use the most recent backups from each server and make sure the timestamps are from the same date.  Notice that these files are just the files from the .../data/ldap/ldapfiles directory.  Those are the only files that need to be replaced.  The only risk with going to a backed up LDAP is that it might be out of sync with the DB.  LDAP and the DB need to be in sync with each other.  So if you go to an older LDAP backup it might be out of sync with the DB, unless you restore the DB from the same time period.