Forum Discussion
Solved
Unable to change Teams Upgrade policy - Modify User policy failed using Lros
We have a weird scenario which I can't seem to find any information online for and MS Support are directing me to remove all AD attributes for users that I have migrated.
In my past experience - doing this will render the 'hybrid' null and void as conversations from onprem users will disapear as onprem SFB is unaware of the user etc.
The error we are getting is
PS C:\Users\user> Grant-CsTenantDialPlan -PolicyName "ZA-01" -Identity user@domain.com
Command: Grant-CsTenantDialPlan. CorrelationId: 5a4936...[removed]....0756cc651. Modify User policy failed using Lros.
+ CategoryInfo : NotSpecified: (CN=253d5ff8-2ae...c1e001,DC=local:OCSADUserOrAppContact) [Grant-CsTenantDialPlan], LrosClientErrorException
+ FullyQualifiedErrorId : GrantPolicy,Microsoft.Rtc.Management.AD.Cmdlets.AssignOcsTenantDialPlanCmdlet
+ PSComputerName : admin1e.online.lync.com
The same error is displayed when trying to set the other 'policies' and a generic error when attempting via the web ui.
SFB 2015 onprem with aadconnect and hybrid sfb deployed. Unfortunately I don't have access to the onprem sfb or onprem AD as this s client managed. But from the views I have. users can be migrated and reflect the correct HostingProvider on prem and cloud.
Any thoughts?
I had this problem with a user
Turns out, we had a duplicate proxyaddress being synced through AAD Connect
See if you can update an email address for the user, either on-prem or in ExO (i.e. get the customer to do it)
if it fails, it'll tell you the offending object or attribute that caused the update to fail. Find that/fix that, this problem should go away
I had this problem with a user
Turns out, we had a duplicate proxyaddress being synced through AAD Connect
See if you can update an email address for the user, either on-prem or in ExO (i.e. get the customer to do it)
if it fails, it'll tell you the offending object or attribute that caused the update to fail. Find that/fix that, this problem should go away
Could you be a little more specific on your comment. "Turns out, we had a duplicate proxyaddress being synced through AAD Connect"
Are you saying multiple users had the same smtp address being synced into the cloud? so to check if idfix picks up the issue / or see if the offending user has duplicate addresses in their email addresses.I have look in EOL and at least the one user has unique addresses. Including x500 and SPO (presume all coming from onprem) where new fresh user created on prem and synced (without first assigning on prem SFB) is able to get the policies assigned fine... So not a simple as 'AD users are the problem'
Will ask the client to run idfix to check for errors and give me multiple users I could try set... So far only given me two users and had issues with both.
We have an odd AAD Connect setup here - not a lot of default settings
It should be impossible to have a duplicate proxyaddresses attribute within AD (and therefore synced by AAD connect) but a perfect storm of two different admins doing two different jobs on the same set of objects caused duplicate attributes in AD. Everything looked fine in AD and AAD, but we were unable to update Exchange attributes on-prem and had strangeness within ExO.
It wasn't multiple SMTP addresses in AAD in our case, but instead AADC decided to link the incorrect objects to the cloud object, and then the Teams admin had a problem with this error message on this particular object.
I can't say for certain if the problem is fixed, but as said before, this is an internal error message from the cloud service; there is nothing you can do to know exactly what the problem is, without MS OL Services telling you - and that means a support ticket through the portal.
I don't think it's as simple as an error found by IDFix - but it won't harm in having this done again.
If I do get confirmation it's fixed (I have a ticket raised as well), I'll post back here.
What you could do is- remove all the user's licenses
- take the single user out of scope of AADC- get the user removed from the AADC Metaverse
- couple of delta syncs
- bring it back into scope and it should link back up with the tombstoned cloud object
I've fixed a few odd issues like this, I certainly wouldn't remove "all AD attributes for all users" - get your call escalated.
Thank Tosh
I'll give it a go. And let you know
I'd say open a support case as this seems to be something on the backend.
- Already been logged for a over a week - They currently wanting me to decommission on premises users.
thanks anyway.
