MicrosoftIsmael_Justiniano, I'd like to clarify your issue to determine if it will hit us as well. Is it that you aren't able to assign users as approved senders, the permissions do not work, or you are not able to verify that the correct users are set once it is done?
Many of our DDGs are set to receive email only from a couple of people that have been around awhile, and a shared mailbox owned by the communications group which also doesn't get translated to a GUID. Eventually I am going to get a request to assign someone sender ability who wasn't hired until after the Big Change.
Sorry for the late reply. The behavior is as such: you can assign the email of the user to the authorized sender group of a particular DDL. Save. The moment you refresh or exit and come back, it shows the exchguid. The problem, assumingly, is that when a hybrid based account is assigned the ability to send to the DDL, exchange doesn't know how to process who a/the "guid" is and the message fails. A work around is using a shared mb created in EOL and giving full delegated rights to the mailbox for the effected users and granting that mb the ability to send to the DDL. Only thing I have tried that has worked at the moment. So you can assign, with no issues. The ability to send is then crippled because of the change... and remember, it is only impacting hybrid based accounts because of how it is syncing and chaning the display name to the guid that was resolving another issue. Ironically enough causing this one... but it's MS LOL. Everything made in the "cloud", native azure/eol only, is not impacted... based on what i've read thus far. Hope this helps.
