Enables you to create a new external access policy. External access policies determine whether or not your users can: 1) communicate with users who have SIP accounts with a federated organization; 2) communicate with users who have SIP accounts with a public instant messaging provider such as Windows Live; and, 3) access Microsoft Communications Server 2010 over the Internet, without having to log on to your internal network.
Syntax
New-CsExternalAccessPolicy -Identity <XdsIdentity> [-Confirm [<SwitchParameter>]] [-Description <String>] [-EnableFederationAccess <$true | $false>] [-EnableOutsideAccess <$true | $false>] [-EnablePublicCloudAccess <$true | $false>] [-EnablePublicCloudAudioVideoAccess <$true | $false>] [-Force <SwitchParameter>] [-InMemory <SwitchParameter>] [-WhatIf [<SwitchParameter>]] |
Parameters
Parameter | Required | Type | Description |
---|---|---|---|
Identity |
Required |
XdsIdentity |
Indicates the unique Identity assigned to the policy when it is created. New external access policies can be created at the site or per-user scope. To create a new site policy, use the prefix "site:" and the name of the site as your Identity. For example, use this syntax to create a new policy for the Redmond site: -Identity site:Redmond. To create a new per-user policy, use an Identity similar to this: -Identity SalesAccessPolicy. Note that you cannot create a new global policy; if you want to make changes to the global policy, use the Set-CsExternalAccessPolicy cmdlet instead. Likewise, you cannot create a new site or per-user policy if a policy with that Identity already exists. If you need to make changes to an existing policy, use Set-CsExternalAccessPolicy. |
EnableFederationAccess |
Optional |
Boolean |
Indicates whether the user is allowed to communicate with people who have SIP accounts with a federated organization. The default value is False. |
EnablePublicCloudAccess |
Optional |
Boolean |
Indicates whether the user is allowed to communicate with people who have SIP accounts with a public Internet connectivity provider such as Yahoo!, AOL, or Windows Live. The default value is False. |
Description |
Optional |
String |
Enables administrators to provide explanatory test to accompany the policy. For example, the Description might include information about the users the policy should be assigned to. |
EnablePublicCloudAudioVideoAccess |
Optional |
Boolean |
Indicates whether the user is allowed to conduct audio/video conversations with people who have SIP accounts with a public Internet connectivity provider such as Yahoo!, AOL, or Windows Live. |
EnableOutsideAccess |
Optional |
Boolean |
Indicates whether the user is allowed to connect to Communications Server 2010 over the Internet, without logging on to the organization’s internal network. The default value is False. |
InMemory |
Optional |
Switch Parameter |
Creates an object reference without actually committing the object as a permanent change. If you assign the output of this cmdlet called with this parameter to a variable, you can make changes to the properties of the object reference and then commit those changes by calling this cmdlet’s matching Set- cmdlet. |
Force |
Optional |
Switch Parameter |
Suppresses the display of any non-fatal error message that might arise when running the command. |
WhatIf |
Optional |
Switch Parameter |
Describes what would happen if you executed the command without actually executing the command. |
Confirm |
Optional |
Switch Parameter |
Prompts you for confirmation before executing the command. |
Detailed Description
When you install Communications Server 2010 your users are only allowed to exchange instant messages and presence information among themselves: by default, they can only communicate with other people who have SIP accounts in your Active Directory. In addition, users are not allowed to access Communications Server 2010 over the Internet; instead, they must be logged on to your internal network before they will be able to log on to Communications Server 2010.
That might be sufficient to meet your communication needs. If it doesn’t meet your needs you can use external access policies to extend the ability of your users to communicate and collaborate. External access policies can grant (or revoke) the ability of your users to do any or all of the following:
Communicate with people who have SIP accounts with a federated organization. Note that enabling federation alone will not provide users with this capability. Instead, you must enable federation and then assign users an external access policy that gives them the right to communicate with federated users.
Communicate with people who have SIP accounts with a public instant messaging service such as AOL or Yahoo!.
Access Communications Server 2010 over the Internet, without having to first log on to your internal network. This enables your users to use Microsoft Communicator "14" and log on to Communications Server 2010 from an Internet café or other remote location.
When you install Communications Server 2010 a global external access policy is automatically created for you. (Because this is a global policy, that also means that all of your users, by default, have their external access capabilities managed by this policy.) In addition to the global policy, you can also create custom external access policies at either the site or the per-user scope. If you create an external access policy at the site scope, that policy will automatically be assigned to the site upon creation. If you create an external access policy at the per-user scope, that policy will be created but will not be assigned to any users. To assign the policy to a user or group of users, use the Grant-CsExternalAccessPolicy cmdlet.
When creating new external access policies (a task you can perform using New-CsExternalAccessPolicy) keep two things in mind. First, policy identities must be unique; if you already have a policy with the Identity RedmondAccessPolicy then any command that tries to create a new policy with that same Identity will fail. Related to this is the fact that, while you can have many policies configured at the per-user scope, you are limited to just one global policy as well as one site policy per site. (That is, you cannot have two policies with the Identity site:Redmond.) If you want to replace a site policy with a new policy then you must first delete the existing policy and then create a new policy for that site. (Alternatively, you could simply use Set-CsExternalAccessPolicy to modify the existing site policy.) You can also use Set-CsExternalAccessPolicy to modify the global policy; however, you cannot delete the global policy, and you cannot create a new policy at the global scope.
Return Types
Creates new instances of the Microsoft.Rtc.Management.WriteableConfig.Policy.ExternalAccess.ExternalAccessPolicy object.
Examples
-------------------------- Example 1 ------------------------
Copy Code | |
---|---|
New-CsExternalAccessPolicy -Identity site:Redmond -EnableFederationAccess $True -EnableOutsideAccess $True |
The command shown in Example 1 creates a new external access policy that has the Identity site:Redmond; upon creation, this policy will automatically be assigned to the Redmond site. Note that this new policy sets both the EnableFederationAccess and the EnableOutsideAccess properties to True ($True).
-------------------------- Example 2 ------------------------
Copy Code | |
---|---|
$x = New-CsExternalAccessPolicy -Identity RedmondAccessPolicy -InMemory $x.EnableFederationAccess = $True $x.EnablePublicCloudAccess = $True $x.EnableOutsideAccess = $True Set-CsExternalAccessPolicy -Instance $x |
Example 2 demonstrates the use of the -InMemory parameter; this parameter enables you to create an in-memory-only instance of an external access policy. After it has been created, you can modify the in-memory-only instance, then use the Set-CsExternalAccessPolicy cmdlet to transform the virtual policy into a real external access policy.
To do all this, the first command in the example calls New-CsExternalAccessPolicy, and the -InMemory parameter, to create a virtual policy with the Identity RedmondAccessPolicy; this virtual policy is stored in a variable named $x. The next three commands are used to modify the properties of the virtual policy: the EnableFederationAccess, EnablePublicCloudAccess, and the EnableOutsideAccess properties are all set to True. Finally, the last command uses Set-CsExternalAccessPolicy to create an actual external access policy with the Identity RedmondAccessPolicy. If you do not call Set-CsExternalAccessPolicy then the virtual policy will disappear as soon as you terminate your Windows PowerShell session or delete the variable $x. Should that happen, then an external access policy with the Identity RedmondAccessPolicy will never be created.