After several days of configuring and troubleshooting, finally got Lync integration with Cisco CUCM 8.6 working in a lab environment. This article walks through the steps taken and some of the problems encountered. Microsoft has a
document that provides step-by-step guidance on the integration available for download here which this article is based on. The steps in the document will not be repeated in this article, rather only the specific implementation in the lab and any deviations will be highlighted. The exact version of CUCM used in the lab is 8.6.2.22900-9 which is slightly newer than the 8.5.1.11900-211 version that the document is based on. Nonetheless all the steps in the document are still valid and can be used with some minor changes which are described in this article. Below shows the diagram for the lab setup:

The Cisco phones have extension 4xxx while the Lync clients have 9xxx. Lync 2010 server is running CU6 with colocated mediation server and media bypass enabled. CUCM users and Lync users should be able to call each other with 4 digit extensions. Below shows the 2 Cisco IP phones registered to CUCM:

CUCM Dial Plans typically consists of Directory Numbers, Route Patterns and Translation Patterns:

Directory Numbers (DN) are internal extensions assigned to phones lines, response groups, voicemail attendants etc.
Route Patterns (RP) are used to match numbers for routing to external PSTN gateways or SIP Trunks.
Translation Patterns (TP) are normalization rules used to manipulate dialed digits before routing a call.

When a user dials a number, the digits are send to CUCM which then uses the DN, TP and RP to perform a Digit Analysis process to determine whether to ring another user or send the call to a SIP Trunk or gateway. In Lync we call this Reverse Number Lookup (RNL). To control whether a user has permissions to ring another user or utilize a route to make PSTN or trunk calls, CUCM uses Partitions and Calling Search Spaces.

Partitions are collections of DNs, RPs and TPs that divide the Dial Plan into segments. For example, Partition Chicago contains directory numbers for users in Chicago and the Route Patterns and Translation Patterns for that locale. Any DN, RP or TP that is not assigned to a paritiion belongs into the Null Partition.

Calling Search Spaces (CSS) are an ordered list of Partitions grouped together and assigned to devices. Numbers in a partition are only reachable by devices that are assigned a CSS that contains that partition. Digit Analysis will only process DNs, TPs and RPs within the CSS assigned to the calling device. Therefore CSS controls what numbers a device can call. CSS can be assigned to phone lines, phone devices, gateways and trunks. Numbers not assigned to any Partition belong to the "Null Partition" and are reachable by all devices.

A simple illustration is as follows. If Bob wants to call Ann, then Bob's CSS must contain a Partition that Ann's Directory Number belongs to. Similarly, if Bob wants to make a IDD call through a gateway, Bob's CSS must contain a Partition than the Route Pattern for that gateway belongs to. In some sense, CSS's are like PSTN Usages in Lync.

Media Resource Groups (MRG) are logical groupings of media resources such as conference resources, transcoder resources, MOH servers and Media Termination Points. A Media Resource Group List (MRGL) is simply a prioritized grouping of MRGs. The most common use of MRGs and MRGLs is to restrict media resource usage on a  geographic basis. For example, an MRGL can be assigned  to a phone at a remote location that only allows it to access local conference bridge resources so that WAN bandwidth is conserved.

With the baisc CUCM concepts covered, we can proceed to configure the SIP Trunk. As per steps provided in the document, we need to do in the following order:
1. Create SIP Trunk Security Profile
2. Create SIP Profile
3. Create SIP Trunk
4. Create Route Pattern

1. Create SIP Trunk Security Profile
In the lab, we created the SIP Trunk Security Profile with no deviations. The screen capture is shown in the diagram below:

2. Create SIP Profile
Next, for the SIP Profile, we created as per documentation as well with no deviations as shown below:

3. Create SIP Trunk
Before creating the SIP Trunk, we need to define a few more items. The first is the Media Resource Group (MRG)which will then be added to a Media Resource Group List (MRGL). The MRG is defined under Media Resources->Media Resource Group and is shown below:

With the MRG defined we then add it into a MGRL created under Media Resources->Media Resource Group list as shown below:

Next item to define before creating the SIP Trunk would be the Calling Search Space (CSS) under Call Routing->Class of Control->Calling Search Space. Our CSS is defined as shown below:

The CSS shown above contains the Route Partition named "LyncPartition" which is defined in the Directory Number (Line[1]) of the Phone Configuration of the two Cisco IP Phones along with the CSS "Outbound to Lync":

The Route Partition "LyncPartition" contains the necessary translation pattern to translate the incoming number from Lync to CUCM extensions. Translation Patterns can be defined in Call Routing->Translation Pattern and our translation pattern translates E.164 number (without + sign) coming from Lync to a 4-digit CUCM extension:

In this lab, we are translating a 4-digit dialed number from Lync to E.164 for CUCM without the + sign. We will be using the Trunk Configuration to do it as shown later. Now we are ready to create the SIP Trunk. This is done under Device->Trunk and we have defined the SIP Trunk as shown below:

4. Create Route Pattern
We also need to create Route Patterns for CUCM users to call Lync users using 9XXX 4-digit extensions. This is defined in Call Routing->Route/Hunt->Route Pattern as shown below:

As per the MS documentation, these are the tasks to configure Lync Server to perform Direct SIP integration with CUCM:
1. Add CUCM to the Lync topology.
2. Configure the dial plan.
3. Add voice policy and route.
4. Add Trunk configuration.

1. Adding CUCM as a PSTN Gateway using Topology Builder
This is fairly straighforward process of using Topology Builder to a new PSTN Gateway using the IP address of CUCM with port 5060 over TCP:

Next we edit the properties of the Mediation Server and add the newly created gateway into the mediation pool:

We then published the topology and made sure there we no errors. 

2. Configuring the Dial Plan
We add a normalization rule to the relevent Dial Plan to catch CUCM 4-digit extensions starting with 4XXX. We will perform no translations:

3. Add voice policy and route
Now we edit the Global Voice Policy to add a new PSTN Usage as shown below:

The actual Route matches any dialed number starting with 4 and routes the call to the CUCM as shown below:

4. Add Trunk configuration.
Finaly we add a new Trunk Configuration in Lync. As per the MS documentation, we create a new Pool Trunk Configuration and select the CUCM PSTN Gateway with Encrpytion support set to Optional.

The documentation also specifies enabling Media Bypass and disabling Refer Support followed by running powershell cmdlets to set RTCPActiveCalls and RTCPCallsonHold to false and EnableSessionTime to True:

The remaining steps in the document of enabling Media Bypass in the Global Network Configuration and setting the MediaConfiguration to SupportEncryption are straightforward and are not repeated here. Simply follow the steps in the document.

We were getting call failures in the beginning and Lync Server's SIP Trace shows errors as below:

ms-diagnostics:
10404;source="LYNC2010.uclab.apac.local";reason="Gateway responded with 404 Not Found (User Not Found)";component="MediationServer";SipResponseCode="404";SipResponseText="Not Found";sip-reason="Q.850;cause=1";GatewayFqdn="10.222.202.152"
ms-diagnostics-public: 10404;reason="Gateway responded with 404 Not Found (User Not Found)";component="MediationServer";SipResponseCode="404";SipResponseText="Not Found";sip-reason="Q.850;cause=1"
Reason: Q.850;cause=1
ms-trunking-peer: 10.222.202.152
ms-endpoint-location-data: NetworkScope;ms-media-location-

Based on the ITU Recommendation Q.850, this error is due to "Unallocated (Unassigned) number". Later we found this to be due to the Device Pool that the CUCM Phones were in did not contain the correct CSS. Device Pools are defined under System->Device Pool. After selecting the correct CSS in the Device Pool, then all was fine and we are able to get calls to/from Lync and CUCM working:

As mentioned in the beginning, both CUCM users were able to call the Lync users using 4-digit extensions. It also happens that the CUCM users were signed in on phones capable of doing video. The Lync users were signed in on Polycom VVX600 phones running firmware 4.1.2.22625. The 9951 Cisco phones are capable of video when calling each other, but not with Lync due to the way Lync handles calls via the PSTN Gateway which only advertises audio capabilities in the SIP INVITE:

TL_INFO(TF_PROTOCOL) [0]0A10.1A24::02/13/2013-08:53:41.995.001d4d01 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(686))[4068699085]
<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_1099E63>], 10.250.27.54:5070<-10.250.27.67:63337
INVITE sip:4007@10.222.202.152:5070;user=phone;transport=tls;maddr=lync2010.uclab.apac.local SIP/2.0
FROM: "Brennon Kwok" <sip:Brennon.Kwok@uclab.apac.local>;tag=E1DEB21B-9B674EF4;epid=0004f2ae4b0d
TO: <sip:4007;phone-context=sgdialplan@uclab.apac.local;user=phone>
CSEQ: 1 INVITE
CALL-ID: 5b36d69dccfe4b1b3eae46c179ae4b0d
MAX-FORWARDS: 69
VIA: SIP/2.0/TLS 10.250.27.67:63337;branch=z9hG4bK85B5D519.F2C2544BA9E4FC96;branched=TRUE
VIA: SIP/2.0/TLS 10.250.27.13:35425;branch=z9hG4bK682046e83E0C5E49;ms-received-port=35425;ms-received-cid=540C500
RECORD-ROUTE: <sip:EEPool.uclab.apac.local:5061;transport=tls;ms-fe=LyncEE1.uclab.apac.local;opaque=state:T;lr>;tag=92BEAF9383A0D959E9B155C0472C72CB
ALLOW-EVENTS: conference,talk,hold
CONTACT: <sip:Brennon.Kwok@uclab.apac.local;opaque=user:epid:4WChQ84TxlyATEooiiwYcwAA;gruu>
CONTENT-LENGTH: 1485
SUPPORTED: replaces
SUPPORTED: ms-safe-transfer
SUPPORTED: ms-bypass
SUPPORTED: ms-dialog-route-set-update
SUPPORTED: timer
SUPPORTED: 100rel
SUPPORTED: gruu-10
USER-AGENT: PolycomVVX-VVX_600-UA/4.1.2.22625
CONTENT-TYPE: application/sdp
ACCEPT-LANGUAGE: en
ALLOW: INVITE, ACK, BYE, CANCEL,
OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
P-ASSERTED-IDENTITY: "Brennon Kwok"<sip:Brennon.Kwok@uclab.apac.local>,<tel:+6563899228;ext=9228>
ms-application-via: SIP;ms-urc-rs-from;ms-server=LyncEE1.uclab.apac.local;ms-pool=EEPool.uclab.apac.local;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57
ms-application-via: LYNCMON.uclab.apac.local_;ms-server=LyncEE1.uclab.apac.local;ms-pool=EEPool.uclab.apac.local;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
ms-routing-phase: from-uri-routing-done
ms-user-data: ms-publiccloud=TRUE;ms-federation=TRUE
v=0
o=- 1360745635 1360745635 IN
IP4 10.250.27.13
s=Polycom IP Phone
c=IN IP4 10.250.27.13
t=0 0
a=sendrecv
m=audio 2230 RTP/AVP 115 9 112 0 8 18 127
a=rtcp:2231
a=candidate:1 1 UDP 2130706431 10.250.27.13 2230 typ host
a=candidate:1 2 UDP 2130706430 10.250.27.13 2231 typ host
a=candidate:2 1 TCP-PASS 6619135 10.250.27.142 51773 typ relay raddr 10.250.27.13 rport 39949
a=candidate:2 2 TCP-PASS 6619134 10.250.27.142 51773 typ relay raddr 10.250.27.13 rport 39949
a=candidate:3 1 UDP 16777215 10.250.27.142 53415 typ relay raddr 10.250.27.13 rport 2730
a=candidate:3 2 UDP 16777214 10.250.27.142 52115 typ relay raddr 10.250.27.13 rport 2731
a=candidate:4 1 TCP-ACT 7012351 10.250.27.142 51773 typ relay raddr 10.250.27.13 rport 39949
a=candidate:4 2 TCP-ACT 7012350 10.250.27.142 51773 typ relay raddr 10.250.27.13 rport 39949
a=candidate:5 1 TCP-ACT 1684733951 10.250.27.13 39949 typ srflx raddr 10.250.27.13 rport 39949
a=candidate:5 2 TCP-ACT 1684733950 10.250.27.13 39949 typ srflx raddr 10.250.27.13 rport 39949
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:88sc2BjOStOMZ4A1VyLXlTiliS5xo/C6oKB6Ro1z|2^31|1:1
a=x-bypassid:68628bf5-5ec3-4b6a-a2c3-6ca33793a892
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=ice-pwd:LY9UIrMskLLh8sBCncz5PtUU
a=ice-ufrag:YoEu
------------EndOfIncoming
SipMessage

So it was not trivial to integrate Lync and CUCM even in a simple lab environment but the documentation provided by MS does help tremdously; many thanks to the authors. We hope this article is useful for those who want to test CUCM integration with Lync and many thanks also to my coleague HB Low for providing much assistance on CUCM.

After 2 days of testing and troubleshooting, I finally managed to get my Lync2010 server integrated with AsteriskNow 2.0 as a Direct SIP PBX. Many blogs have been written on this topic but majority were created sometime ago for older versions of Asterisk and used mainly the command line. This article provides guidance for integrating Lync2010 with the latest version of AsteriskNOW 2.0 as of Sep 2012 using the FreePBX GUI admin interface. I'll also provide some troubleshooting tips that I learned along the way.

Note that Asterisk is not offically supported by Microsoft as a Direct-SIP PBX and is not listed in their OIP page http://technet.microsoft.com/en-us/lync/gg131938.aspx. Nevertheless, 'not supported' does not always mean 'not working' and some
small-medium business may have done this in their environment using free Asterisk PBX as a gateway to the PSTN. This article serves primarily as a guide to get Lync-Asterisk integration in a lab for testing purposes only and not be used in a real-world deployment.

The high level overview of the steps involved are:

1. Install AsteriskNOW2.0 and create users
2. Install and Configure X-Lite and test call functionality in Asterisk
3. Create the Asterisk SIP Trunk
4. Create the Asterisk Inbound/Outbound Routes
5. Configure Additional Parameters
6. Configure the Dialplan, Voice Route, PSTN Usage and Voice Policy in Lync Server
7. Test calls between Polycom CX600 phone edition Lync and X-Lite client (Asterisk)

This whole process should take 3-4 hours assuming your Lync environment is already up and running. Ready? Lets begin.

Asterisk now provides a quickstart guide and download to enable you to install a full Asterisk PBX running on CentOS Linux. I used a Hyper-V virtual machine with 1.5GB RAM and got it up and running in under 30mins. The step-by-step guide is available here and I shall not repeat those steps in this article. Simply follow the guide up to the part where you are able to login to the Asterisk server and open a browser to access the FreePBX Admin page. You don't need to continue the rest of the guide which shows you how to setup the Digium phones. We will be using X-Lite as the softphone for Asterisk so as long as you can get to the page below (the FreePBX default username/password is admin/admin), you're done installing Asterisk:

The above page can be found under the top tab menu Reports->FreePBX System Status. You're now ready to create users for Asterisk so that X-Lite can register. In this guide I'm using 4-digit extensions starting with 3xxx for Asterisk and 9xxx for Lync. At the top tab menu, click on Applications and ensure Generic SIP Device is selected in the dropdown box, then click Submit. Then on the Add SIP Extenstion page, enter a suitable extension and display name similar to the picture below:

Scroll down and enter a secret for the user which will be used later when registering with X-Lite. Leave the other fields default and click Submit to create the user. Note that in a real production Asterisk environment you will need to popluate the other fields but in this guide we will just enter what's enough to get Lync integration working. Once the user is created it will appear in the top right of the Admin page. Click on the newly created user and scroll down to look for the 'Context' field. It should be automatically populated with "from-internal" and this is important to note when creating the SIP Trunk later.

Follow the above steps to create a 2nd user. Once done, we are ready to proceed to install and register X-Lite in the next step

Dowload and install X-Lite from http://www.counterpath.com/x-lite-download.html. I'm using an older version of X-Lite v3.0 so your X-Lite client may look different from the screenshots below. Go to the Menu and select SIP Account Settings... and create a new SIP account. Enter a Display Name for the Asterisk user created in Step 1 followed by the User name which should be the user Extension and the password field will be the secret entered earlier. The Domain field should be the IP address of the Asterisk server. Select the checkbox to
register with domain as shown below:

Next install X-Lite on a different PC and configure it to use the 2nd Asterisk user created in Step 1. Once that is done, test calling between these 2 users. It's important to verify this and make sure that Asterisk is working properly before attempting Lync integration. Once you have verified, proceed to Step 3.

On the top tab menu of FreePBX Admin page, click Connectivity->Trunks ,then click Add SIP Trunk. On the Add SIP Trunk page, enter a suitable Trunk Name and scroll down till you see Outgoing Settings section. Here's the critical section where you need to enter a couple of parameters in the PEER Details box to make the trunk work with Lync. These are shown in the screenshots below followed by a brief explanation of some of the key parameters

Next, ensure that in the Incoming Settings section, the USER context and USER details fields are left blank. Then click Submit Changes and Apply Config. Note that I have left the dialed number manipulation rules empty here because we will create them in the Inbound/Outbound Routes in the next step.

Let's create the Inbound route from Lync first. At the FreePBX Admin top menu bar, select Connectivity->Inbound Routes. In the Add Incoming Route page, give the route a description and leave the DID Number and CallerID Number fields blank to apply this route to all DID/CID numbers. Note that in a actual Asterisk deployment you would need to enter the correct values according to your route design. Then scroll down and choose Trunks in the Set Destination section and select the Lync Trunk created in Step 3 in the dropdown. Leave all other fields default. Then click Submit to create the inbound route:

To create the outbound route, click on Connectivity->Outbound Routes and in the Add Route page, give it a suitable name and in the Dial Patterns section, enter the fields similar to that shown in the picture below. The  first box enclosed in brackets ( )is what Aterisk will prepend to before sending the call to Lync and the fields in the square brackets [ ] enter the dialed digits that will used this route. Since we are using 4-digit extensions in Lync starting with 9XXX we will enter that. The full Lync TEL URI for user is in E.164 format so you will need to enter the front portion of the TEL URI including the plus (+) sign in the first bracketed field eg. +654444. When a Asterisk user dials 9000 for example, then the full number sent to Lync will be +6544449000. Then scroll down and in the Trunk Sequence section, select from the dropdown the Trunk created in Step 3. Then click Submit Changes to create the route.

There are 2 additional parameters required on Asterisk which unfortunately cannot be changed using the FreePBX Admin GUI. These parameters are required in order to for Asterisk to communicate with Lync using TCP. Many blogs recommend the use of WinSCP but I prefer to login directly onto the CentOS console and configure the parameters. First, open a console window in Hyper-V to the asterisk server and login as root. We will use the VI editor to edit the parameters file so run the command "vi /etc/asterisk/sip_custom.conf". this will open the file and you should see a blank file. Hit the "i" key to enter input mode and type in the two lines as shown below. Then type ":w" to save the file and then ":q" to quit VI editor. Next restart Asterisk by running the command "/etc/init.d/asterisk restart".

That's all that's needed on the Asterisk side. Next we will configure the Lync server. We will revisit the CentOS console later for troubleshooting

First, create a new PSTN gateway for Asterisk. In the Lync Topology Builder, select the PSTN Gateways node on the left and click New PSTN Gateway.... Enter the IP address of the Asterisk server and specify 5060 as the listening port and TCP for the Sip Transport Protocol. Then click OK to create the gateway.

Next associate the PSTN gateway with your Mediation Server. On the Topology Builder, expand Mediation Pools and select your mediation server then click Edit Properties. On the Mediation Server PSTN Gateway properties page, change the TCP listening port to 5060 and then select the PSTN gateway created earler and click Add to associate it. The gateway will appear in the lower box. Then click OK.

Next, edit your existing dialplan to create a new normalization rule for Asterisk extensions using the Lync Control Panel. This may or may not be necessary in your Lync environment depending on how you set up your dialplan. On my server, I created a new normalization rule for users dialing 3XXX which basically does nothing to change the dialstring. This is because in Asterisk my extensions are all 3XXX and E.164 format is not being used. So just create a new normalization rule for 4-digit numbers starting with 3 with a translation pattern of $1 which basically does nothing.

Next, use the Control Panel to edit your Voice Policy to add a new PSTN Usage. In my server I'm using the Global policy and I just add a new PSTN Usage called Asterisk:

In the New PSTN Usage Record page, under Associated Routes, click New and in the New Route page, give the route a name, then enter 3 in the starting digit box and click Add. In your environment, you would enter the starting digit(s) for your Asterisk extensions. then scroll down and under the Associated Gateways, clidk Add and select the PSTN Gateway created earlier in this step.

Finally click OK 3 times to return to the Control Panel and your Lync server is all set to communicate with Asterisk!

If you've followed this guide until this point, give yourself a pat on the back for being so patient and determined! We're now ready to test calls between the 2 systems. In my Lync, I have a Polycom CX600 registered with a Lync user extension 9228 and we should be able to make calls from this phone to the 2 Asterisk users created ealier by simply dialing 3000 or 3001. You should see the X-Lite client receive the popup incoming call alert and try out the sound quality between these two clients. Conversely, dialing the Lync user extension from X-Lite will cause the CX600 to ring and you can answer the call. 

Should things not go as smoothly as above, you may check the status of the SIP Peer in Asterisk. On the Asterisk console, login as root
and on the run the command "asterisk -r". At the Asterisk CLI prompt, run the command "sip show peers". You should see the Lync mediation server listed as a peer listening on port 5060 with an "OK" status.

If the status is not "OK", go back and check the configuration again to make sure the port numbers are correct and that none of the essential parameters in the earlier steps are left out. You may also use the Lync Logging Tool to check the SIP Trace and see what could be causing the issue. Last but not least, you might have opted to use 5068 for the TCP listening port on the Mediation Server and have created a rule to allow this port. If you suspect that firewall rule is incorrect and the port is not opened, temporarily disable the firewall on
Asterisk by running the command "service iptables stop".

That's all for this article and I hope it was a worthwhile effort to create it.

Below are references to blog sites which helped me to get the integration working. Many thanks to the authors:
http://memphistech.net/?p=245
http://savithomas.blogspot.com/2011/07/connecting-lync-server-2010-with.html
http://blog.metasplo.it/2011/11/integrating-lync-2010-and-asterisk.html

To recap, in Lync Server Edge Server deployments, an HTTPS reverse proxy in the perimeter network is required for external clients to access the Lync Server Web Services on the Director and the user's home pool. Some of the features that require external access through a reverse proxy include the following:

Enabling external users to download meeting content for your meetings.
Enabling external users to expand distribution groups.
Enabling remote users to download files from the Address Book service.
Accessing the Microsoft Lync Web App client.
Accessing the Dial-in Conferencing Settings webpage.
Accessing the Location Information service.
Enabling external devices to connect to Device
Update web service and obtain updates.

There's not much documentation on how to create and install the proper certficates on the Reverse Proxy so I'd like to share the steps that I took for setting up a Lync Reverse Proxy using Forefront Threat Management Gateway (TMG) 2010. The technet documentation at http://technet.microsoft.com/en-us/library/gg429704.aspx explains what the subject name and SAN's need to be for the certificate, but
does not actually tell you how to request and install the certificate in order to get it working. So here goes:

1. First and foremost, after installing TMG2010, if you are not using a public CA then you need to import the Root CA Certificate into the TMG Server's Trusted Root Certificate Authorities. This is because the TMG Server is not joined to the AD Domain since it sits in the perimeter network. To do this, navigate to http://<CAServerFQDN>/certsrv and click on Download a "CA Certificate, Certificate Chain or CRL" and then click on "Download CA
Certificate". Save the file with a .cer extension on the Reverse Proxy server then open it. Click on "Install Certificate" and follow the wizard, making sure you put the certificate into the "Trusted Root Certificate Authorities" Certificate Store.

2. Since there's no certificate wizard in TMG, you have to use Lync server to create the certificate on behalf of the Reverse Proxy. On the Lync Management Powershell, type the following:

> Request-CsCertificate -New -Type WebServicesExternal -PrivateKeyExportable $True -FriendlyName "RP Cert" -Organization "Polycom" -OU "APAC" -KeySize 2048 -City "SG" -State "SG" -Country "SG" -Output c:\rpcert.req

The parameters I used are for my environment so you have to substitute them with your own. Note we have to specify that the private key must be exportable. The advantage of using Lync is that it also generates the necessary SANs in the CSR for the certificate to work properly with all the Lync web services. You also need to make sure the External Web Services FQDN for the Lync Pool is defined as this
will be included in the SAN. If you have not yet defined this, open the Lync Topology builder and define it, then publish the topology before running this command.

3. Next, copy the rpcert.req to the CA and start the Certification Authority mmc from the adminstrative tools. Right-Click on the CA
server and choose "All Tasks" and then "Submit New Request". Choose the rpcert.req file and then select a location to save the cert, for eg. c:\rpcert.cer

4. With the rpcert.cer issued by the CA, you now need to copy this file back to the Lync server for import. Why not just import it into
the Reverse proxy server? Because the CSR was generated by Lync server which means the Private Key only resides there. By importing the certificate back into Lync, you can then export the entire certificate along with the Public and Private keys. On the Lync Management Shell, type the following:

> Import-CsCertificate -Path c:\rpcert.cer -PrivateKeyExportable %True

This will put the certificate into the Lync servers certificate store.

5. Now, start the Certificates MMC on the Lync server. To do this, run mmc from the Start menu and then click on File->Add Remove Snapin and choose Certificates and select the Local Computer Account. Expand Certificates->Personal->Certificates on the left navigation pane and you should see the newly imported cert, with the SN being the FQDN of the Reverse Proxy server. Right-Click on the certificate, select All Tasks and then Export. In the Export wizard, select "Yes, Export the Private Key" and you will be forced to export as a PKCS #12 .pfx file. Select "Include all certificates in the certification path if possible" and "Export all extended properties". Next you will be prompted to enter a password twice, and the complete the wizard by saving the file to a location you specify.

6. Finally, copy the newly exported .pfx file back to the Reverse Proxy server. Then start the Certificates MMC and choose the Computer Account. Expand Personal->Certificates and then Right-Click and choose All Tasks->Import. In the wizard, select the .pfx file and then enter the password in step 5. The certificate is now stored in the Reverse Proxy server's certificate store and ready for use.

As you configure TMG2010 to create the web publishing rule for Lync web services, follow the instructions given in the documentation and when creating a web listener, you can now select the imported certificate.

That's all for this post and hope this has been useful for you.