When performing an Administrator Driven Batch Migration, the following error may be seen in the logs:
DEBUG: ACL: GW_UserName.GW_PostOffice.GW_Domain 1024
DEBUG: PstTgt::GetRecipInfo() [GW_UserName.GW_PostOffice.GW_Domain] - no cache hit
DEBUG: PstTgt::SearchGal - Searching GAL for 'SMTP:GW_UserName.GW_PostOffice.GW_Domain'.
DEBUG: PstTgt::GetRecipInfo() [gwise:GW_Domain.GW_PostOffice.GW_Username] - no cache hit
DEBUG: PstTgt::SearchGal - Searching GAL for 'gwise:GW_Domain.GW_PostOffice.GW_UserName'.
ERROR: [5004-24-270-00000000] Unable to process acl for 'GW_UserName.GW_PostOffice.GW_Domain' on folder 'Cabinet'
User/group not found in the GAL:
[00000000] The operation completed successfully.
This can be caused by one, or a combination of the following:
- Incorrect or no entry in the 'Source Address' column 'AddressTranslation.CSV' file for the said object
- Exchange latency in setting mailbox attributes
- Target object not mailbox-enabled
- Old ACL information is on share, in some cases we have seen where internally GW knows that for example "user1@olddom1.olddpo1" = "user1.po1.dom1" and can resolve this name internally, but our tool can not as we are looking at the addresstranslation file for a match
WORKAROUND1:
1. Determine if the target object is mailbox-enabled and has the value listed in the logs (from the example above):
'SMTP:GW_UserName.GW_PostOffice.GW_Domain/gwise:GW_Domain.GW_PostOffice.GW_UserName' (or the value stated from current logs)
2. Add these addresses to an additional column called 'TargetAlias' of the 'AddressTranslation.CSV' file.
WORKAROUND 2:
Manually add the failed address to the addresstrasnlation file. For example if you see error "Unable to process ACL for 'User22.GW_PostOffice.GW_Domain' on folder 'Cabinet'" You could add the following to the addresstrasnlation file.
User22.GW_PostOffice.GW_Domain,User22@YourDomain.com,User 22,1,0,user22,GW_PostOffice,GW_Domain,"",User22,O=halifax/CN=User22
Solution 13273: https://support.quest.com/SUPPORT/index?page=solution&id=SOL13273, describes how to disable setting security, but setting ACL is desired.
Additional Notes:
As per the example verbose log provided in the above Problem Description, Groupwise Migrator for Exchange is scanning the ACLs from the source GroupWise shared folder:
=====
DEBUG: ACL: GW_UserName.GW_PostOffice.GW_Domain 1024
=====
...it then looks in the 'AddressTranslation.CSV' file for a match...
=====
DEBUG: PstTgt::GetRecipInfo() [GW_UserName.GW_PostOffice.GW_Domain] - no cache hit
DEBUG: PstTgt::GetRecipInfo() [gwise:GW_Domain.GW_PostOffice.GW_Username] - no cache hit
=====
...which (as stated from the logs) it did not find.
Then it searches the target Exchange Global Address List (GAL) for a *MAILBOX-ENABLED* (not mail-enabled) account that has one of the following addresses...
=====
DEBUG: PstTgt::SearchGal - Searching GAL for 'SMTP:GW_UserName.GW_PostOffice.GW_Domain'.
DEBUG: PstTgt::SearchGal - Searching GAL for 'gwise:GW_Domain.GW_PostOffice.GW_UserName'.
=====
...and the result (for this scenario) is that it did not find 'SMTP:GW_UserName.GW_PostOffice.GW_Domain/gwise:GW_Domain.GW_PostOffice.GW_UserName' on any mailbox-enabled object in the GAL at the time of the migration...
=====
User/group not found in the GAL:
=====
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy