Hi,
Just reporting the weirdest thing Ive ever seen. I had a script that ran regularly that used the add-mailboxpermission and remove-mailboxpermission cmdlets. I specified the GUID in the -user parameter as Im a big fan of identifying everything with guids. Just recently I noticed that the cmdlets errored out with:
Couldn’t resolve the user or group “e8a27845-79b9-4647-853c-77bf71e4cc65.” If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.
I changed the -user parameter to use the email address instead of the GUID and it worked.
When did it start failing? Just after we established an external domain trust from our 2012 DC to a w2k3 domain!!! Go figure…
Cheers
David Z
@David - Did you get the solution for this ? if so please share it with us which will be helpful for others else please update this thread with latest update.
Sadly we have to keep that awful trust relationship in place. So the only workaround is to use the email address instead of the guid in that cmdlet. I use many other cmdlets with guids and they still seem to work fine.
Cheers
David Z
The moment you start messing with trust up / down-level functional levels matter big time, especially if you are talking different mail environments, i.e, co-existence and share / delegated mailboxes. eMail address, like DNS, to the heaving lifting for you. Your using a guid is like pointing mail clients direct at a given CAS (which will work, won’t scale and is an SPOF) vs letting autodiscover do it’s thing.
Can you translate that to English? Especially that the majority of Exchange cmdlets are fine with guids except for the two I mention?