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?

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

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

• Proposed as answer by Carolyn Blanding Thursday, April 26, 2012 12:27 PM
• Unproposed as answer by Carolyn Blanding Thursday, April 26, 2012 12:27 PM

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

• Proposed as answer by Carolyn Blanding Thursday, April 26, 2012 12:27 PM
• Unproposed as answer by Carolyn Blanding Thursday, April 26, 2012 12:27 PM

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

• Proposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 12:27 PM
• Unproposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 12:27 PM

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

• Proposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 12:27 PM
• Unproposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 12:27 PM

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

• Proposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 12:27 PM
• Unproposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 12:27 PM

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.

• Proposed as answer by Sharon.ShenMicrosoft contingent staff, Moderator Wednesday, April 25, 2012 6:10 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.

• Proposed as answer by Sharon.ShenMicrosoft contingent staff, Moderator Wednesday, April 25, 2012 6:10 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.

• Proposed as answer by Sharon.ShenMicrosoft contingent staff, Moderator Wednesday, April 25, 2012 6:10 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

• Proposed as answer by Carolyn Blanding Thursday, April 26, 2012 2:39 PM

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

• Proposed as answer by Carolyn Blanding Thursday, April 26, 2012 2:39 PM

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

• Proposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 2:39 PM

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

• Proposed as answer by Carolyn BlandingMicrosoft employee Thursday, April 26, 2012 2:39 PM

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

• Proposed as answer by Carolyn BlandingMicrosoft employee 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 ?

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.

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

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

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

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?

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

I have the same problem.  Did you solve it?

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

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

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

This might be the reason why control panel does not have option to create common area phones.

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.

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.

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.

Thanks Pat that works perfectly.

• Proposed as answer by dduuhh2 Monday, May 26, 2014 11:13 PM

Thanks Pat that works perfectly.

• Proposed as answer by dduuhh2 Monday, May 26, 2014 11:13 PM

Thanks Pat that works perfectly.

• Proposed as answer by dduuhh2 Monday, May 26, 2014 11:13 PM

We're still having problems - I can run New-CsCommonAreaPhone with my account in Lync Management Shell on my desktop PC, even if it's only in CsServerAdministrator, but a colleague cannot even if logged in directly to a Front End Server, though his account is in CsAdminstrator, CsUserAdministrator, CsServerAdministrator and RTCUniversalUserAdmins.

I checked the AD permissions on an OU where we're putting the CAP objects, and RTCUniversalUserAdmins has several direct Special permissions on child Contact objects for that container - I had run Grant-CsOuPermission on all those OUs when my account was in Domain Admins (it is no longer in that group). I've also checked to make sure that my account was not a member (direct or indirect) of any other group that had permissions on the Common Area Phone OUs.

The only possible difference that I can see is that my account is in an AD group that has local admin privileges on the SQL Servers and my colleague's is not, but I'd really rather not have to make every help desk staffer who should be able to create Common Area Phones a local admin on the SQL Servers - is there anything else I could be missing?

MandieD, does your colleagues get any error messages? If you get the "access denied" add credentials to your Front End server. The CAP objects are created by the Front End server credentials.