none
CsCommonAreaPhone commandlets fail via remote powershell - Active Directory operation failed on "mydc.domain.com". You cannot retry this operation: "Insufficient access rights to perform the operation

    Question

  • I have stumbled upon this blocker: Set-CsCommonAreaPhone, New-CSCommonAreaPhone and Remove-CsCommonAreaPhone seem to have issues when being run remotely.

    If I RDP into the FE, start the Lync Powershell, I can run those commands just fine, but run over a remote session I get the error mentioned in the title.

    Other commandlets I'm using remotely (user management, policy management, pins) all work, which seems to indicate that it's not a permission issue (all users I've tried for have CSAdministrator rights as well as RTCUniversalUserAdmin - and I've tried users with and without domain admin rights).

    Full errors, e.g. for Remove-CsCommonAreaPhone:

    Active Directory operation failed on "CHDEVAD02.nxodev.intra". You cannot retry this operation: "Access is denied
    00000005: SecErr: DSID-031522EC, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
    "
        + CategoryInfo          : InvalidOperation: (CN=testphone 78...nxodev,DC=intra:UserIdParameter) [Remove-CsCommonAr
       eaPhone], ADOperationException
        + FullyQualifiedErrorId : ProcessRecord,Microsoft.Rtc.Management.AD.Cmdlets.RemoveOcsCommonAreaPhoneCmdlet

    And Set-CsCommonAreaPhone

    Active Directory operation failed on "CHDEVAD02.nxodev.intra". You cannot retry this operation: "Insufficient access ri
    ghts to perform the operation
    00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
    ".You do not have the appropriate permissions to perform this operation in Active Directory. One possible cause is that
     the Lync Server Control Panel and Remote Windows PowerShell cannot modify users who belong to protected security group
    s (for example, the Domain Admins group). To manage users in the Domain Admins group, use the Lync Server Management Sh
    ell and log on using a Domain Admins account. There are other possible causes. For details, see Lync Server 2010 Help.
        + CategoryInfo          : NotSpecified: (:) [Set-CsCommonAreaPhone], ManagementException
        + FullyQualifiedErrorId : Microsoft.Rtc.Management.AD.ManagementException,Microsoft.Rtc.Management.AD.Cmdlets.SetO
       csCommonAreaPhoneCmdlet

    It also doesn't matter if I log into the remote powershell using the currently logged in user's credentials (

    (New-PSSession -ConnectionUri https://chdevocs04.nxodev.intra/ocspowershell/ -Authentication NegotiateWithImplicitCredential) or specify another lync admin's credentials - New-PSSession -ConnectionUri https://chdevocs04.nxodev.intra/ocspowershell/ -Credential $UserCredential).

    Any ideas on how I can get those commandlets to work remotely?

    Tuesday, April 10, 2012 4:34 PM

All replies

  • Hi,Stephan,

    Would you please add the account you run remote powershell to CSVoiceAdministrator,CSUserAdministrator and CSServerAdministrator group then try again?

    When you run any command from Lync management shell on the FE server the RBAC policy is not applied & AD permission are applied,and it only requires RTCUniversalUserAdmins permission,but if you run it remotly the RBAC policy will be applied and you have the accout have all the required permission.

    You can run the following command from the Windows PowerShell prompt to get the required RBAC roles.

    Get-CsAdminRole | Where-Object {$_.Cmdlets –match "Set-CsCommonAreaPhone"}

    B/R

    Sharon


    Sharon Shen

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.

    Thursday, April 12, 2012 3:32 AM
  • I tried, no such luck.

    The thing is... CSAdministrator is supposed to be the all encompassing permission set anyway so I'm not sure why you'd have to bother assigning those other rules (voice admin, user admin, server admin).

    Thursday, April 12, 2012 6:23 AM
  • Oh, Oh, I can answer this one!

    I went through Premier Services support to get it.

    Remote PowerShell commands do not use your credentials to authenticate to Active Directory, so any Lync command that modified properties stored in AD will fail.

    Friday, April 20, 2012 12:03 AM
  • The solution to this is to use the Invoke-Command with -authentication CredSSP to enable second hop authentication to the AD controler with credentials specified. You will need to enable server-side SSP for winrm on the server that you will be invoking commands on.

    In PowerShell running as Administrator on the Front End Server Run: Enable-WsManCredSSP -Role Server

    Sample PS Commands to Remotely Modify CommonAreaPhone

    $S = new-PSsession -computername lyncfe01 -authentication CredSSP  -Credential domain\username

    invoke-command -session $S -scriptblock {import-module lync}

    invoke-command -session $S -scriptblock {get-csanalogdevice -filter {displayname -like 'displayname*'}| set-csanalogdevice -displaynumber "####"}

    remove-PSsession $S

    Click here for more information on the Invoke-Command

    Click here for more information about credssp for 2nd hop remoting

    Click here for more information about WSMan Limits

    Thursday, April 26, 2012 2:39 PM
  • Thanks Carolyn.

    I tried real hard, but could not make that work.  Is there anything else you had to do to the FE besides Enable-WsManCredSSP -Role Server ?

    Friday, April 27, 2012 2:17 PM
  • Hmm - I have my doubts about that one. Seeing as I can use the CSUser commandlets via PS remote just fine, and that they, too, do modify certain AD attributes (e.g. sip uri is still in AD, as is whether the user is enabled for Lync or not), it should either work for all or none - or there's a bug in Lync (can't help but think the whole administration stuff isn't quite all worked out yet.. there's so many limitations, missing features one one of the admin interfaces and inconsistencies between the two ways of administering (e.g. the web does RBAC, PS doesn't).

    I'll be giving what Carolyn posted a shot.

    Monday, May 07, 2012 8:16 AM
  • I'm afraid I seem to be unable to do it as well. In my case... specifying CredSSP authentication gets me the good old

    [chdevocs04.nxodev.intra] Connecting to remote server failed with the following error message : The WinRM client cannot
     process the request. The authentication mechanism requested by the client is not supported by the server or unencrypte
    d traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration
     or specify one of the authentication mechanisms supported by the server.  To use Kerberos, specify the computer name a
    s the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To
    use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name and
    password. Possible authentication mechanisms reported by server:     Negotiate For more information, see the about_Remo
    te_Troubleshooting Help topic.

    Also, it seems that the winrm setup on the server remains non persistent... after every boot, calling "winrm quickconfig" asks me to enable the WinRM service. And CredSSP also won't be turned on again after an FE reboot.

    And, I can't help but notice that it shouldn't be that difficult. Especially seeing that the local management shell doesn't do RBAC, remote powershell management should work out of the box for ALL commandlets, not just some.

    @edit: I still have the problem of the FE loosing the config, but I managed to get it working using invoke-command. However, that's not exactly what I need... I need to be able to specify a connection uri (that in term automatically loads the required commandlets and works properly when calling import-session on the newly created session (unlike the approach with invoke-command... you cannot import that session). So the question becomes:

    How do I get the following command to work:

    New-PSSession -ConnectionUri https://chdevocs04.nxodev.intra/ocspowershell/ -Credential $UserCredential -Authentication CredSSP

    And how do I get the FE to persistently have CredSSP enabled and winrm enabled?

    • Edited by Stephan Steiner Monday, May 07, 2012 11:19 AM adding new insights and questions
    Monday, May 07, 2012 9:58 AM
  • Confirm that WinRM is configured including firewall rules by running Winrm QuickConfig from an elevated prompt on the FE server.

    If that doesn't work, what response are you getting to the Invoke command?

    Friday, June 15, 2012 1:50 PM
  • And how do I get the FE to persistently have CredSSP enabled and winrm enabled?

    I have the same problem.  Did you solve it?
    Friday, July 06, 2012 6:05 PM
  • Any update on this? Anyone get *-CsCommonAreaPhone commandlets working via remote PS or any other off-server method?
    • Edited by James Frost Monday, February 18, 2013 3:31 AM
    Monday, February 18, 2013 3:30 AM
  • This might be the reason why control panel does not have option to create common area phones.

    Petri

    Monday, June 10, 2013 7:59 AM
  • We actually found a workaround to this. 

    We had issues with the new-cscommonareaphone when using PS-Remoting. The issue it turned out was with the creation of the AD contact in the specific OU, and incorrect permissions within AD. As one of the posters mentioned above, this is because PS-Remoting doesn't appear to use the user's credentials correctly when creating the AD contact.

    In our case, the workaround was to create a dummy AD contact manually using the AD Users and Computers snap-in. This AD object then had to be permissioned such that the Everyone group had Write access to it. Once this happened, the service desk could use the new-cscommonareaphone command and PS-Remoting to effectively overwrite the properties on the object and assign all the normal policies.

    Some extra work for every device... but better then giving them Full access to the Lync servers which was the only alternative.

    Regards, James.


    James Frost

    Monday, June 10, 2013 8:47 AM
  • What about giving full access to your Lync servers to the OU where your Common area Phones locate?

    As Stephan's PSS URL:
    "https://chdevocs04.nxodev.intra/ocspowershell"

    he needs to give credentials to "chdevocs04$" for the OU where their Common area phone contacts locate. Then he can create contacts remotely.

    This is all about RBAC (Role Based Access Control) - same case with Exchange also. All changes are done by the servers credentials, not user's own credentials. Personally I don't like this so much, because after this AD's security logs are pretty much useless because you cannot see from there who modified the object.


    Petri

    Monday, June 10, 2013 10:11 AM
  • I know this is an old thread, but the solution is

    Grant-CsOuPermission -ObjectType "device" -ou [OU]

    That grants permission to create Common Area Phones in the specified OU.

    Friday, February 28, 2014 6:30 PM
  • Thanks Pat that works perfectly.
    • Proposed as answer by dduuhh2 Monday, May 26, 2014 11:13 PM
    Monday, May 26, 2014 11:13 PM