Sign in
 
HomeOnline20132010Interop ProgramsLibraryForumsGalleryLync Blogs
TechCenter >
> 
> 
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

Proposed Answer 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

  • Tuesday, April 10, 2012 4:34 PM
     
     
    Sign In to Vote
    0

    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?

     

All Replies

  • Thursday, April 12, 2012 3:32 AM
    Moderator
     
     
    Sign In to Vote
    0

    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 6:23 AM
     
     
    Sign In to Vote
    0

    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).

     
  • Friday, April 20, 2012 12:03 AM
     
     Proposed Answer
    Sign In to Vote
    1

    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.

     
  • Thursday, April 26, 2012 2:39 PM
     
     Proposed Answer
    Sign In to Vote
    0

    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

     
  • Friday, April 27, 2012 2:17 PM
     
     
    Sign In to Vote
    0

    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 ?

     
  • Monday, May 07, 2012 8:16 AM
     
     
    Sign In to Vote
    0

    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 9:58 AM
     
     
    Sign In to Vote
    0

    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
    •  
     
  • Friday, June 15, 2012 1:50 PM
     
     
    Sign In to Vote
    0

    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, July 06, 2012 6:05 PM
     
     
    Sign In to Vote
    0

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

    I have the same problem.  Did you solve it?
     
  • Monday, February 18, 2013 3:30 AM
     
     
    Sign In to Vote
    0
    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
    •