You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When editing a group in on premise Exchange ECP you get a warning that group is corrupted because object "43061ac1-c8ad-4ccc-b785-2bfac20fc60a" can't be resolved
To Reproduce
Steps to reproduce the behavior:
Go to on premise Exchange ECP
Click on 'Groups'
Select a group and click edit.
See error
Expected behavior
No warning
Screenshots
Access Manager installation
OS: Windows Server 2019
Version 1.0.7941.0
Additional context
The object mentioned above is the Lithnet Service Account created during setup.
I'm guessing the powershell script that sets permissions, doesn't limit itself to just computer objects.
I'm guessing the way around this issue is to only apply the permissions to OU's that contain computers, instead of the domain root but I thought it was worth logging a bug in case you have any other suggestions.
The text was updated successfully, but these errors were encountered:
grumpymojo
changed the title
Lithent Service Account permissions cause warnings in Exchange ECP when editing groups.
Lithnet Service Account permissions cause warnings in Exchange ECP when editing groups.
Aug 10, 2022
Just some additional information. It's specifically the permissions for Bit Locker Recovery Password recovery that cause this issue.
I have solved this my self by removing these permissions from the root of the domain and then running the permission script only against OUs with computer objects.
There is probably nothing for you to fix but it might be worth mentioning in the documentation.
Describe the bug
When editing a group in on premise Exchange ECP you get a warning that group is corrupted because object "43061ac1-c8ad-4ccc-b785-2bfac20fc60a" can't be resolved
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No warning
Screenshots
Access Manager installation
Additional context
The object mentioned above is the Lithnet Service Account created during setup.
I'm guessing the powershell script that sets permissions, doesn't limit itself to just computer objects.
I'm guessing the way around this issue is to only apply the permissions to OU's that contain computers, instead of the domain root but I thought it was worth logging a bug in case you have any other suggestions.
The text was updated successfully, but these errors were encountered: