Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Please consider addressing the following when creating your topic:
What have you tried? We have hybrid exchange in place and run AD after-create rule and powershell script to provision mailbox and enable policy. Mailbox is getting created but Enabling Policy is failing intermittent. We have to go and check the following box manually to enable policy. The issue is with AD propagation timing. Exchange can see the user, but it still treats the object as a plain AD user that cannot be mailbox-enabled yet. This is due to Exchange using a different domain controller than the one SailPoint just wrote to.We have tried adding Sleep-time to wait but did not help. Has anyone faced similar issue? Any suggestion is appreciated.
As a test, could you remove the update-recipient and the first set-remotemailbox commands from your script. My thinking is that the update-recipient is removing the default policy flag and then you can’t add it back with the set-remotemailbox.
Thanks for your response. If I remove first set-remotemailbox, where emailbox get set? The second set-remotemailbox command is removing the address policy. See screenshot below. Thanks
Hi @akamolov You’ve got a sleep in there before that one. I haven’t got time to explain exactly whats going on here, but if you can test and it’s successful, I’ll give you an explanation (maybe tomorrow).
As per my understanding, Email policy was not being applied due to a conflicting configuration. This has been corrected and now you can get the email fomat as firstname.lastname@domain.com
Please find an attachment and try to use and confirm me if its working fine.
Your error message indicates that an Exchange cmdlet was run on an object for which it was not intended. Your error states that it was run on a User object, so the cmdlet generating the error is expecting an Exchange-type User object. enable-remoteMailbox expects a User object, so it is not that one causing the error. Looking at the order of events we can therefore determine that it was the first set-RemoteMailbox that failed. This makes sense because it is run directly after the enable-RemoteMailbox, the cmdlet that converts the User object into a Remote Mailbox Enabled User object (by updating AD attributes msExchRemoteRecipientType and msExchRecipientTypeDetails), so it may well not have completed before the set-RemoteMailbox is run.
This set-RemoteMailbox command is being used to add the object into the Address Policy, but why is it needed?
The presence (or not) of the tick box for automatically updating email addresses is based on the AD Attribute msExchPoliciesExcluded. If the flag is not set, that means that the AD Attribute contains a reserved GUID to indicate all policies are excluded. Any Address Policies that have been applied are included in the msExchPoliciesIncluded AD Attribute.
Your error scenario indicates that msExchPoliciesExcluded includes the reserved GUID, so, how did it get there?
Assuming that you didn’t set it in the Provisioning Policy, the only command that could have added that GUID to the AD Attribute is the update-Recipient cmdlet. This cmdlet only applies to Exchange type recipients. A Remote Mailbox Enabled User is not an Exchange type recipient to on-prem Exchange. This command is therefore not needed.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
