On the Edge Server, in the Deployment Wizard, next to Step 3: Request, Install, or Assign Certificates, click Run again.

Tip:
If you are deploying the Edge Server for the first time, you will see Run instead of Run Again.

On the Available Certificate Tasks page, click Create a new certificate request.

On the Certificate Request page, click External Edge Certificate.

On the Delayed or Immediate Request page, select the Prepare the request now, but send it later check box.

On the Certificate Request File page, type the full path and file name of the file to which the request is to be saved (for example, c:\cert_exernal_edge.cer).

On the Specify Alternate Certificate Template page, to use a template other than the default WebServer template, select the Use alternative certificate template for the selected certification authority check box.

On the Name and Security Settings page, do the following:

1. In Friendly name, type a display name for the certificate.

2. In Bit length, specify the bit length (typically, the default of 2048).

3. Verify that the Mark certificate private key as exportable check box is selected.

On the Organization Information page, type the name for the organization and the organizational unit (for example, a division or department).

On the Geographical Information page, specify the location information.

On the Subject Name/Subject Alternate Names page, the information to be automatically populated by the wizard is displayed. If additional subject alternative names are needed, you specify them in the next two steps.

On the SIP Domain Setting on Subject Alternate Names (SANs) page, select the domain check box to add a sip.<sipdomain> entry to the subject alternative names list.

On the Configure Additional Subject Alternate Names page, specify any additional subject alternative names that are required.

Tip:
If the XMPP proxy is installed, by default the domain name (such as contoso.com) is populated in the SAN entries. If you require more entries, add them in this step.

On the Request Summary page, review the certificate information to be used to generate the request.

After the commands finish running, you can View Log, or click Next to continue.

On the Certificate Request File page, you can view the generated certificate signing request (CSR) file by clicking View or exit the Certificate Wizard by clicking Finish.

Copy the request file and submit to your public certification authority.

After receiving, importing and assigning the public certificate, you must stop and restart the Edge Server services. You do this by typing in the Lync Server Management console:

	Copy Code
Stop-CsWindowsService

	Copy Code
Start-CsWindowsService

Open Lync Server Control Panel.

In the left navigation bar, click Federation and External Access and then click XMPP Federated Partners.

To create a new configuration, click New.

Define the following settings:

Primary domain    (Required). The primary domain is the base domain of the XMPP partner. For example, you would enter fabrikam.com for the XMPP partner domain name. This is a required entry.

Description   The description is for notes or other identifying information for this particular configuration. This entry is optional.

Additional domains   Additional domains are domains that are a part of your XMPP partner’s domain that should be included as part of the allowed XMPP communication. For example, if the primary domain is fabrikam.com, then you would list all other domains that are under fabrikam.com that you will communicate with by way of XMPP.

Partner type   The Partner type is a required setting. You must choose one of the following to describe and enforce what contacts can be added. You can select from:

• Federated   A Federated partner type represents a high level of trust between the Lync Server deployment and the XMPP partner.  This partner type is recommended for federating with XMPP servers within the same enterprise or where there is an established business relationship.  XMPP contacts in Federated partners can:

  1. Add Lync contacts and view their presence without express authorization from the Lync user.

  2. Send instant messages to Lync contacts whether or not the Lync user has added them into their contact list.

  3. See a Lync user’s status notes.

• Public verified   A Public verified partner is a public XMPP provider that is trusted to verify the identity of its users.  XMPP contacts in Public Verified networks can add Lync contacts and view their presence and send instant messages to them without express authorization from the Lync users.  XMPP contacts in public verified networks never see a Lync users’ status notes.  This setting is not recommended.

• Public unverified   A Public unverified partner is a public XMPP provider that is not trusted to verify the identity of its users.  XMPP users on Public Unverified networks cannot communicate with Lync users unless the Lync user has expressly authorized them by adding them to the contact list.  XMPP users on public unverified networks never see Lync users’ status notes.  This setting is recommended for any federation with public XMPP providers such as Google Talk.

Connection Type: Defines the various rules and dialback settings.

• TLS Negotiation   Defines the TLS negotiation rules. An XMPP service can require TLS, can make TLS optional, or you define that TLS is not supported. Choosing Optional leaves the requirement up to the XMPP service for a mandatory-to-negotiate decision. To view all possible settings and details for SASL, TLS and Dialback negotiation –including not valid and known error configurations - see Negotiation Settings for XMPP Federated Partners.

  • Required   The XMPP service requires TLS negotiation.

  • Optional   The XMPP service indicates that TLS is mandatory-to-negotiate.

  • Not Supported   The XMPP service does not support TLS.

• SASL negotiation   Defines the SASL negotiation rules. An XMPP service can require SASL, can make SASL optional, or you define that SASL is not supported. Choosing Optional leaves the requirement up to the partner XMPP service for a mandatory-to-negotiate decision.

  • Required   The XMPP service requires SASL negotiation.

  • Optional   The XMPP service indicates that SASL is mandatory-to-negotiate.

  • Not Supported   The XMPP service does not support SASL.

• Support server dialback negotiation The support server dialback negotiation process uses the domain name system (DNS) and an authoritative server to verify that the request came from a valid XMPP partner. To do this, the originating server creates a message of a specific type with a generated dialback key and looks up the receiving server in DNS. The originating server sends the key in an XML stream to the resulting DNS lookup, presumably the receiving server. On receipt of the key over the XML stream, the receiving server does not respond to the originating server, but sends the key to a known authoritative server. The authoritative server verifies that the key is either valid or not valid. If not valid, the receiving server does not respond to the originating server. If the key is valid, the receiving server informs the originating server that the identity and key is valid and the conversation can commence.

  There are two valid states for Dialback negotiation:

  • True   The XMPP server is configured to use Dialback negotiation if a request should be received from an originating server.

  • False   The XMPP server is not configured to use Dialback negotiation and if a request should be received from an originating server, it will be ignored.

Click Commit to save your changes to the site or user policy.

To configure DNS for XMPP federation, you add the following SRV record to your external DNS:_xmpp-server._tcp.<domain name> The SRV record will resolve to the Access Edge FQDN of the Edge server, with a port value of 5269.