Pending File Rename Registry Key Causes Lync/SQL Install to Halt

I’ve run into this one a few times, so I figured I’d share my experience.  During the “Prepare First Standard Edition Wizard” the installer says “The server must be restarted before installation can continue”.   I’ve also seen this same error when doing SQL installs, such as the backend database.

After a reboot, the installation still halts with the same error.  To correct the behavior we have to hop into our registry editor and navigate to: HKLM>System>ControlSet001>Control>Session Manager

Under the “PendingFileRename” entry you will see text like what is in the box below.

This tells the system that the file in question is pending a rename and causes the SQL install to fail because it checks this entry before proceeding.  If you delete the contents in the “Value data” box and restart the installer (not the machine), the issue will be resolved temporarily and will allow you to continue with the installation.

Posted in Uncategorized | Tagged , , | 2 Comments

Adding More than 10 Distribution Lists to the Lync Contact List

Just like in OCS with Lync you can add distribution lists to your contact list.  However, there is a default limitation on how many groups you can add to your list.  In Lync and OCS that limit is 10, which at a recent deployment wasn’t quite enough for all the teams that certain users may need to have on their contact list.

The client used these lists for a number of business functions and would like the limitation to be removed.  To start off let’s look at my contact list with 10 distribution lists already added to it.

Now I’ll search for a new distribution list and try to add it to my contact list.

As you can see I get the error “The Contact list already contains the maximum number of distribution groups” when trying to add the eleventh list.  To change this behavior we need to modify the client policy in the Lync Management Shell.  In this case I’ve chosen to allow the maximum number of distribution lists to be added (64).  If you have multiple policies in Lync you will need to modify each one by specifying the identity.  Since I only have the one client policy, I can change just that one with the command:

Set-CsClientPolicy -Identity Global -MaximumDGsAllowedInContactList 64

After signing out and back in I can now add additional distribution lists to my contact list.

Posted in Uncategorized | Tagged , , , | 4 Comments

How to Customize the Meeting Entry Page for Lync

With Lync 2010 we now have a single client for Lync Client and the Online Meeting (formerly called Live Meeting) functionality which makes everything a little simpler.  If you have the Lync Client you get your meeting functionality and the Outlook integration for scheduling online meetings all from the one client.

Even better than the single install for our own clients is the capability to customize the meeting entry page that is sent as part of the Online Meeting invite.  This makes it easier for external contacts that don’t already have the Lync client or attendee to join the meeting (if the Reach client doesn’t provide the functionality they need for the meeting).

There are two options with this customization:

1.       Provide a link to the Lync Attendee client download

2.       Provide the option to join the meeting from a legacy client

To customize the page we need to use the Lync Server Management Shell (LSMS).

We’ll start by enabling the Lync Attendee client download.  To do this we need to run the following command from LSMS:

Set-CsWebServiceConfiguration -ShowDownloadCommunicatorAttendeeLink $true

After running the command we can open our meeting page and see the change:

It may also make sense to enable users to join from their Communicator clients (with limited functionality).  To do that we run the following command from the LSMS:

Set-CsWebServiceConfiguration -ShowJoinUsingLegacyClientLink $true

After the command completes we can once again open our meeting and see the change:

The lack of these options was definitely felt in OCS 2007 R2, just another way Lync is making the user experience even better!

Posted in Uncategorized | Tagged , , , | 8 Comments

Deploying XMPP for Lync

 After deploying our edge server and enabling federation in this article the next logical step may be to enable communication with other IM platforms such as Google Chat via the XMPP gateway.  At the time of Lync RTM there was no updated XMPP server, so in this article we will utilize the OCS 2007 R2 version available from Microsoft here.

To start off with, this is what our environment will look like:

Since we will be adding another server, I have updated the hostname and IP address table below

Server Name Role IP Address
LyncDC.lyncguy.local Domain Controller/DNS/CA
LyncFE.lyncguy.local Lync Standard Edition Front End
Lyncedge.lyncguy.local Lync Edge server – not domain joined (internal NIC) Lync XMPP Server – not domain joined

For this scenario we will be using a single NIC on our XMPP server, with the NIC placed in the same DMZ network our edge server’s external interface is on.  This will allow the edge and XMPP servers to communicate directly and to be protected by the corporate firewall.

No internal DNS changes are required to make this work, but since the XMPP server will be behind NAT and sharing the same network segment as the XMPP gateway we will update its host file so it can resolve the address of the XMPP gateway to the DMZ IP address and not the public IP.

To do that we will add an entry for the on the edges host file pointing to its DMZ IP address (

Now we need to log into our XMPP server, set up the IP address and modify the hostname.  First we’ll assign our IP Address:

Now we modify our hostname

And modify the primary DNS suffix

To allow the XMPP server to reach our access edge I have added an entry for pointing to the DMZ IP address of the access edge

These entries allow the XMPP gateway and the edge server to communicate directly, not sending the traffic back and forth through the firewall since they are on the same network.

I will not cover the XMPP Gateway install or configuration; there is a great article here that covers everything you need to know including external DNS and firewalls (although those are covered below as well).

Once you have completed the steps in the article above you are ready to configure your Lync environment for XMPP.  To do that we start on the Front End server by opening the Lync Server Control Panel, going to “External Access” and then clicking on “Federated Domains”

Click New>Allowed Domain and add in the information for and your XMPP server

Now click “Commit” to save your changes.  The changes will automatically be pushed to your edge server, but you can also check the Event Viewer under the Lync Server section to verify you see the following event

Next you need to open NAT port 5269 inbound from the public IP to your private IP

Rule Public IP Private IP Allowed Protocol – Port
XMPP Access XX.102.182.166 TCP – 5269

Last but not least you need to create public DNS records.  The first record will be an A record

Record Type Public Name Public IP Port
A XX.102.182.166  

Then we will create an SRV Record

Record Type Public Name Name Port
SRV 5269


And now you should be able to chat with your google chat contacts via Lync.  XMPP can also be used to communicate with other IM services, see the documentation for more detail.

Posted in Uncategorized | Tagged , , , , , , | 62 Comments

Deploying an Edge Server with Lync

For this article and the next I am going to add an Edge server and an XMPP gateway to an existing Lync environment.  All articles moving forward will be built on the RTM bits of Lync, but to build the Front End server for this environment I followed the original article here, the only difference is the name of the server and the domain.  The lab has the following servers and IPs:

Server Name Role IP Address
LyncDC.lyncguy.local Domain Controller/DNS/CA
LyncFE.lyncguy.local Lync Standard Edition Front End
Lyncedge.lyncguy.local Lync Edge server – not domain joined (internal NIC)

The active directory domain name for this lab is LyncGuy.local, with the public sip domain  I prefer to do these labs with different name spaces for AD and the public domain because that is the most common scenario I’ve run into in the real world.  To make this work you have to have an internal copy of the public zone and an external copy; this is commonly referred to as “split brain DNS”.

To start with I have to create a copy of my public zone on my internal DNS server so internal clients can reach the Lync server directly.  To accomplish this I’ve created the following records in DNS:

Record Type DNS Entry IP Address

We also need to create an SRV record for client automatic sign-in.  The new record will be for “” and will point to on port 5061.

***Note – you can utilize another name here such as the Front End servers name, however the domain must match the sip domain.  You also must have a SAN entry on the front end certificate to match this entry***

Now that our DNS zone is in order we can plan for our edge server.  In this example I will be using 1 internal IP, 3 DMZ IPs and 3 Public IPs.  Instead of placing the public IPs directly on the edge servers public NIC, I will NAT the public IPs to the private IPs with my lab ASA.  I’ve also matched the last octet of the address to make it easier to manage at a glance.

Public Name Public IP DMZ IP XX.102.182.163 XX.102.182.164 XX.102.182.165

Here is what the design looks like:

To start we need to add an edge to our topology, on the front end server (lyncfe) open “Lync Server Topology Builder”. Then we need to expand our topology, right click “Edge Pools” and choose “New Edge Pool”

Click “Next” on the “Define Edge Pool” page

Enter the FQDN you will be using for your edge and select “Single Computer Pool”

Next we have a screen offering 3 options:

  • “Use a Single FQDN & IP Address” – this option will not be selected because we have plenty of public IPs to use.  If you only have 1 IP this is a good option – however this will force you to use ports other than 443 which aren’t always open outbound from corporate networks and may cause usability issues on networks you cannot control.
  • “Enable Federation (port 5061) – this option will configure the edge server to listen on port 5061 of the access edge IP for inbound federation traffic from other Lync and OCS environments
  • “The external IP address of this edge pool is translated by NAT” – this option tells Lync the IP addresses on the outside interface of the edge are not the actual public IP addresses.  Putting the edge behind another firewall can give an extra layer of security and help prevent the server from being compromised.

For this scenario we have selected “Enable Federation (port 5061)” and “The external IP address of this edge pools is translated by NAT”

Next we define our public names for the edge roles, notice all roles use port 443.  I would highly recommend using this method if possible.

Now we set the IP address for the internal network of our edge server.  In this scenario I have placed the internal NIC on the same subnet as the domain controller and front end server.  Because of limited resources in my lab I have configured the environment this way, whenever possible I recommend placing this NIC in another DMZ that has a higher security level than the DMZ for the outside interfaces.

At this point we specify the DMZ IP addresses of our edge server

In the next box we will enter the Public IP address of the A/V edge services (  In OCS 2007 R2 we had to make sure the edge server could resolve the public name to the public IP, however, this box allows that requirement to be removed and we can just enter the IP here.

Next we select our next hop server (the front end server)

Next we click “Finish” and the wizard completes, we can now see our newly defined edge server in the Topology.

Now we can publish our topology.

Before we move on to working on the edge server we need to open the Lync Server Control Panel and configure our External User Access policies.

Under External Access Policy>Global Policy: Modify the existing policy to allow remote user access, federation and public IM connectivity (all of these are optional).  Click “Commit” when you have selected the options that are right for your environment

Now under Access Edge Configuration>Global Policy: Modify the existing policy to Enable Federation, remote user access and anonymous access to meetings.  I’ve also enabled dynamic domain discovery.  This allows our Lync users to automatically add Lync/OCS users from other environments without requiring administrative configuration.  This option may not be right for all environments, if it isn’t right for your environment you’ll want to use the “Federated Domains” tab to define the allowed domains and uncheck this option.  Next click “Commit”

Now that our environment is ready, we need to export the topologies configuration to a file which we we’ll import during the Edge install.  On the front end server open “Lync Server Management Shell” and run the command:

Export-csconfiguration –filename c:\

The file “” will now be on the C drive of your front end server.  This file will need to be copied to the edge server.

Now that the topology has been updated we need to log into our edge server and configure it.

First we need to make sure that all the IP Addresses get assigned to the appropriate NIC.

On the internal NIC we will use only an IP Address and subnet mask, we cannot put a default gateway on this interface.

Next, on the external NIC we will fill in an IP address, subnet mask, default gateway and DNS, do not click “OK” yet

We also need to bind our other 2 IP addresses to the external NIC, to do this click the “Advanced” button and then click “Add” under “IP Addresses” and add each IP address

At this point we’ll want to add a route back to any internal networks the internal NIC.  For this example I will be adding a route back to an internal network of, this could be another client or server subnet that the edge server will need to know how to route to.  The edge’s internal interface must be able to route to all internal networks via a gateway on the same network as its internal NIC, so if you have multiple networks you will have to add them all.  To do this we will use the route add command from a command prompt (Run As Administrator):

Route add –p mask

The “-p” portion of this command makes the route persistent, “” is the next hop router to reach the other internal networks.

Next we need to configure hostname of our edge server.  When we configure this value we must also add a primary DNS suffix.  This is different than adding the computer to the domain, but it does tell the computer it’s full name (i.e. LyncEdge.lyncguy.local).

Once you have updated the name and primary DNS suffix and you click “OK” you will be prompted to reboot the edge server.

While the edge server is rebooting we can add a DNS entry on the domain controller so all internal resources know how to reach the server by its “FQDN” – it’s not actually an FQDN because it isn’t domain joined, but the rest of the systems will need to be able to route to it like it is.

Once the edge has rebooted we will need to add the feature “Microsoft .NET Framework 3.5”, to do this open Server Manager, go to Features, click “Add Features” and choose “Microsoft .NET Framework 3.5”.

You can click “next” through all other screens and then click “Install”.  Once the install completes we can move on to starting the Lync install.  First we need to copy the file created above to the C drive of the edge server.

Now we can run the CD, we will immediately be prompted to install the “Microsoft Visual C++ 2008 Redistributable”, click OK here:

The install window for Lync will pop up when the C++ install completes

Click “Install” and then accept the terms and click “OK”

Now we are back in the familiar Lync Server Deployment Wizard

Click on “Install or Update Lync Server System”

Under Step 1 we click “Run”

Select the file from the C drive and click “Next”.  This will allow the edge server to gather its settings from the export file.

A number of pre-requisites are installed at this point.  When this completes click “Finish”

Now click “Run” under Step 2

Click “Next” and a number of pre-requisites are installed

Once the install completes we can open up the Services snap-in and see the Lync Services are now present

Before we can move on to Step 3 (Requesting Certificates), we need to make it possible for the edge server to resolve names of the internal servers it will talk to.  This will include the CA because we will need to request the certificate for the internal interface from the internal CA.  Also, we will need to trust the internal CA so we will need to export its certificate and install it on the edge server.

To allow the edge server to resolve some internal names but not all we have a few options, a DNS server in the DMZ is one, but for this article we will be editing the host file.  The reason I’ve chosen not to utilize the internal DNS servers is to limit the number of servers the edge server can look up in case it is compromised.

The host file is located at “C:\windows\system32\drivers\etc”, the best method of editing this file is to run Notepad as administrator and then open this file (You’ll have to switch to “All Files” in the file type selection box)

For this scenario I will add entries for the CA and the Front End server:

Now that we can resolve the CA, we’ll use the web enrollment page to download the Root CA chain.

Open IE and go to https://lyncdc.lyncguy.local/certsrv, you may have to authenticate, if you do use your domain account.  Click on “Download a CA Certificate, Certificate Chain, or CRL”

Click on “Download CA Certificate”

Save the file to the desktop or another location on the edge server.

Open the certificates snap-in for the local computer, expand “Trusted Root Certificate Authorites”, right click “Certificates” and choose “Import”

Browse to the file you download in the last step and click “Open”

This will import the certificate into the trusted store for the local computer.

Now we move on to Step 3 in the Deployment Wizard, requesting and installing certificates

Highlight “Edge Internal” and click “Request” – this will allow us to request the certificate for our internal communications between the edge server and the front end.

I won’t cover every step in this wizard; you should be using all defaults here other than information specific to your environment.  I will however strongly suggest you do not add any SANs to this certificate.  One other thing of note, you will want to do this certificate request online, specifying your internal CA as show below

You will also have to provide domain credentials to request the certificate

Once the request is completed the wizard will automatically take you to the next wizard to assign the certificate.  Again, this is a next-next-finish scenario.

Because this is a lab scenario and I will not be requesting public certificates I will just re-run this wizard select “External Edge Certificate” for the second certificate.  If you are using public certificates you will want to choose “Prepare Request now but send later (offline request)” for your request.

***One important difference between OCS 2007 R2 and Lync is the edge roles can now all share one certificate with a subject (CN) of only the access edge, you no longer need to re-generate the certificate for each role, utilizing that roles FQDN as the subject name.  For information on how that worked in OCS 2007 R2 please see this article***

The new certificate will have the following fields automatically, unless you are configuring multiple sip domains there is no need to modify this or add additional SANs.

Subject (Common Name)

Now we can run Step 4 to start the services and our edge server should be up and running.

Once this process is complete the NATs and access lists must be created on the firewall to allow the appropriate traffic in and out.  I have only covered the inbound rules in the table below, please see the edge server documentation or the Lync Server Planning Tool for more detail.

Rule 1 Public IP Private IP Allowed Protocol – Port
Access Edge (client access) XX.102.182.163 TCP – 443
Access Edge (federation) XX.102.182.163 TCP – 5061
Web Conferencing Edge XX.102.182.164 TCP – 443
A/V Edge XX.102.182.165 TCP – 443
A/V Edge XX.102.182.165 UDP – 3478
A/V Edge XX.102.182.165 TCP – 50,000 through 59,999
A/V Edge XX.102.182.165 UDP – 50,000 through 59,999

After the firewall changes are made we need to create the A records for each of our services on the public DNS server

Record Type Name IP Address
A XX.102.182.163
A XX.102.182.164
A XX.102.182.165

You will also need to create an SRV record for auto sign-in on the domain and federation. For automatic sign-in you can create an SRV record for pointing to your access edge server ( on port 443.  For federation you will need to createn an SRV record for pointing to your access edge server on port 5061.

Now we can test the server using and get ready to deploy reverse proxy.  For that I’m going to point you to Randy Wintle’s article on the subject.

For the next article I will go through configuring XMPP for Lync using the OCS 2007 R2 XMPP gateway.


Posted in Uncategorized | Tagged , , , , | 431 Comments

Exchange 2010 SP1 and Cisco Unity Voicemail Issue

Today I was contacted by a client who installed Exchange 2010 Service Pack 1 (SP1) and after the reboot voicemail no longer worked for users who were homed on the Cisco Call Manager and using Exchange for Voicemail.  The customer was seeing the event ID 2021 with the following information in the application log on the Exchange server:

The Unified Messaging server rejected an incoming call with the ID “1b70bb00-cd011f77-98-604a8c0@”. Reason: “Invalid Route header: mismatched character: expected: ‘”‘, found: ‘EOF'”

The issue is described very well in this article (but no fix or link to a fix):

The problem is the Unity system is including a common in the Alerting Name (i.e Peters,Kevin).

To correct this behavior we modified the following fields for the Cisco user and removed the comma:

Alerting Name

ASCII Alerting Name

Display Name

ASCII Display Name

There is also an option to upgrade to build “7.1.5bsu2” or newer to correct the issue. However, there are many things to consider when upgrading versions of your Call Manager so I would suggest working with Cisco TAC to verify this upgrade is the right approach to resolve the issue while leaving your environment intact.

Posted in Uncategorized | Tagged , , , | Leave a comment

Welcome to Lync!

It’s official; the new name of OCS is Lync!   With the name change comes a number of new features including revamped management interfaces (Topology Builder, Deployment Wizard and CSCP) and a Management Shell with tons of great new scripting capabilities.

With all of these new features available, and a new way to deploy I thought it would be fitting to cover deploying a topology.   To start things off easy we’ll jump into a single box Standard Edition pool.  Over the next few articles I will add layers to this deployment until it resembles what you may want to use in your environment.

Keep in mind the RC is for lab use only; it is not a good idea to install this into your production domain.  Also, please read the reference documents here:

Now let’s start with a link to the download:

For this install you’ll need a DC/DNS/CA server (I named mine lyncdc.ocsguy.local), we’ll bypass that portion of the install to keep the article to a reasonable length.

Once you have your Lync Server on the domain we need to install all the pre-requisites:

Here’s a quick ServerManagerCMD script to make that happen, to use this open a Command Prompt (Run As Administrator) and paste the information below.  For formatting purposes copy this into notepad and make sure when wordwrap is unchecked it is all on one line.

****Begin Copy Below This Line****

servermanagercmd -i NET-Framework Web-WebServer Web-Common-Http Web-Static-Content Web-Default-Doc Web-Dir-Browsing Web-Http-Errors Web-Http-Redirect Web-Asp-Net Web-ISAPI-Ext Web-ISAPI-Filter Web-Http-Logging Web-Log-Libraries Web-Http-Tracing Web-Security Web-Windows-Auth Web-Client-Auth Web-Performance Web-Stat-Compression Web-Mgmt-Tools Web-Mgmt-Console Web-Scripting-Tools telnet-client rsat-adds

****End Copy Above This Line ****

Now that we have the roles and features necessary we reboot to complete the installation and start the install.

Go to your DVD Drive>Setup>AMD64>  and run Setup.exe

Click “OK” to install the vcredist package.

Next you will see the LyncServer 2010 Install screen (sometimes this is hidden behind your explorer window); click Install

After accepting the license agreement the install will begin.

Now we will see the “Deployment Wizard”, we’ll skip over the “Prepare Active Directory” section for the article (but you should do it if you are following along at home) and go right to install of the “Topology Builder”

And onto “Prepare First Standard Edition Server”, this preps our new lyncserver to house the Central Management Store (CMS).

This will take a couple of minutes, so now is a good time to get up and grab some coffee or stretch…

Now our server is ready to host the CMS and we can start out with the Topology Builder.

With Lync Microsoft has built a fantastic deployment configuration utility in the Topology Builder that allows you to create your entire topology all at once, and then it stores this topology in the CMS where each server can access it.  After the topology is published, you run the “Deployment Wizard” on each server and its rolls are automatically installed.  I must say I really like this utility!

So we open “Lync Server Topology Builder” and choose “New Topology”

We are prompted to select a name and a location to save the Topology Builder XML file to (tbxml).  Each time we open the topology builder we will be presented with this same option, after publishing the topology the first time we will choose “Download Topology”.  The great part of this is you can make a copy of this file every time you are logging in to make a change, in the event of an issue just grab the previous file and re-publish it.

Now we are creating our topology, we start by defining our SIP domain.  In this case I will be using for the SIP domain, ocsguy.local is the internal domain name and will not be needed.

Now we define our first site

And now we are finished, notice the check box is selected to take us right into the “New Front End Wizard”:

On to the Front End configuration:

Make sure to check “Standard Edition”

We select our features, bypassing CAC and the collocated Mediation server for now. 

And bypass the other roles for now


Now we need to create a file share named “Share” on the Front End server


Now we can see our topology in place and are ready to publish it


Once our topology is published, we need to go back into the Deployment Wizard and let the wizard configure our new standard edition server.

We choose “Install Local Configuration Store” first and select “Retrieve directly from Central Management Store” for the replica selection

Now on to step 2, this is almost identical to Step 1, with one exception.  You will be prompted to reboot the server and re-start the installation during this step:

Once you have restarted after the prompt you come right back into the deployment and run Step 2 again:

Now we request our certificate, this is a pretty standard process, I haven’t included every screenshot but the important ones are below

We now start the services (step 4)

Before we can enable our first user, we have to add the “Administrator” account to some roles in AD, from ADUC right click the administrative user, go to properties and open the “Member of” tab.  Add the Administrator account to the groups shown below.

Next, log off and back on to the Front End server to let the permissions take effect.

Now we can go out to our Communications Server Control Panel (CSCP). 

If you haven’t installed SilverLight already you’ll see a prompt to do so now


Now we enable a test account:

Since we haven’t deployed Exchange yet we can’t base the SIP address on the email address so I chose SAMAccountName, make sure to choose your public SIP Domain (in this case and not your internal domain.

Now we log into DNS and create A records:     

And the SRV record:


And last but not least, we get to sign in (if the computer you are testing from isn’t joined to the domain you will need to import the root certificate).

After enabling a few more users you can begon testing and learning all of the great new features of Lync.  Check back soon as I will be going over the next step in the process, adding external connectivity.

Posted in Uncategorized | Tagged , , , , , | 70 Comments

OCS Reverse Proxy from Forefront TMG on a UAG Server – Getting Some Bang For Your Buck

As you may have guessed by the title, I get paid by the acronym….

With the release of Microsoft’s Forefront Unified Access Gateway (UAG) many companies have found a very useful product to securely publish applications such as OWA, Direct Access and SharePoint (among many, many others) from one place.  UAG also includes a TMG server built into it, which you can utilize as a reverse proxy for OCS or other applications you don’t want to require authentication for.  Microsoft even has a great support article detailing what is and isn’t supported here.  The article very clearly states you can utilize the TMG on your UAG server to publish OCS (although it doesn’t specify which roles); however making it all work is not as intuitive as one might hope.  With that in mind, I’d like to share what I learned while working on a recent deployment to help others who want to utilize their UAG for other purposes.

For starters let’s talk about the network; here is what my lab looks like for this scenario:

As you see in the diagram I have placed one NIC of the UAG into the DMZ network, and the other on the LAN.  I recommend having another firewall between the UAG’s “inside” interface and the LAN whenever possible but I didn’t have enough resources in my lab to make this work.

For this scenario I will be publishing OWA/ActiveSync with the UAG, and the OCS Webfarm FQDN (Address book, etc…) with the TMG.

For OWA I will be using the public IP of, with my lab firewall NAT’ing that IP to the DMZ IP of

For the OCS Webfarm I will be using the public IP of, with my lab firewall NAT’ing that IP to the DMZ IP of

Here’s the way we will be separating the IP addresses:



If you’ve ever installed UAG you have most likely noticed it utilizes IIS, and bind’s all the IPs ( on the boxes external NIC to IIS (sort of taking them hostage for UAG’s sole use).  Although this is perfectly fine if you plan to use the box only as a UAG server, it doesn’t work so well if you want to utilize the TMG role as well.  What we need to do is add bindings for only IP addresses we intend to allow UAG to control (and

Let’s get started.

First we can examine how the IPs are bound on each port by opening a command prompt and running the following command:

Netstat –ano

The output of this command will be pretty long, if you’d prefer you can send the output to a text file by adding “>c:\ports.txt” to the end of the command:

Then you can open the file and see bound to port 443 for PID #4, if you open task manager and go to process, you can see the PIDs for each process, 4 is the system:

Now on to unbinding the, open a command prompt (run as administrator if required) and type the following commands:



add iplisten ipaddress=

The above command reminds the binding for all IP address on the host.

Now, we need to rebind all IP addresses we want UAG to listen on, for example, the command below will allow the UAG to use :

add iplisten ipaddress=

Once that is completed we can re-run our “netstat –ano” command to verify is no longer bound to 80/443, instead we should see only the IPs we specified in the “add iplisten ipaddress=” commands.  You’re output should look like below, notice 443 is no longer bound on

At this point we have freed the hostages so to speak, and we can now use the TMG and UAG on the same server with different IP address allocated to each.  On to configuring your reverse proxy for OCS, for that I’d recommend checking out Randy Wintle’s  excellent article on the subject over at the UC Made Easy site here.  It’s a great article that I’ve used for reference a number of times and send many other folks to, so I won’t re-invent the wheel.

As a side note, although this article is specifically about the UAG and TMG, it can be directly related to OCS implementation which is why I’ve chosen to publish it here.  I hope this article helps someone out there and as always welcome any feedback.


Posted in Uncategorized | Tagged , , , , , , | 13 Comments

Citrix NetScaler VPX and OCS 2007 R2 – Certificates

In the past few months it’s been a bit quiet on the posting front.  The major reason being Wave 14 (CS2010) is taking up a lot of my time and there isn’t a lot we’re allowed to show from our labs yet.  As the end of the year approaches, the public beta’s and/or release candidates hit the net, and the RTM comes out you can expect a lot more information from all of the UC bloggers, but for now we’ll stick with OCS 2007 R2.

My current lab is an OCS 2007 R2 environment with 2 Front End servers and a Citrix NetScaler virtual appliance (VPX) running as a load balancer.  I’m prepping the environment to simulate a migration from R2 to Wave 14 utilizing the document here (this is an RTM version, but it gives you the jist).  But as is usually the case, I found a gotcha on the certificate setup on the VPX, and thought it was worth sharing.  This particular gotcha even had the citrix support folks scratching their head.

To start off with, I have the following relevant servers in the environment:

KPDC1.msucguy.local – DC, DNS, CA

KPOC1.msucguy.local – OCS Front End

KPOC2.msucguy.local – OCS Front END

Ocpool.msucguy.local –

The VIP for the OCS servers is and resides on the load balancer.

After deploying the front end servers I was ready to setup the load balancer.  I started by exporting the root CA Cert from the trusted certificate authority as a .cer file and uploading it to the VPX.  Next, I exported the certificate I planned to use for the OCS VIP and Front Servers and followed the procedure here to convert it.  My pfx file was named “FrontEnd_Cert.pfx”, this is what the output of the commands looked like.

I uploaded the certificate to the VPX,(notice no “key filename”).

I then linked the cert to the CA cert I had imported earlier and tried to configure it for the OCS Virtual Server:

I received the error “Binding CerKeys:Certificate is not a server certificate”

After playing around this one for a while, and tapping a few friends with more experience with Citrix appliances (including a Citrix support engineer for this platform) I still couldn’t find a way to get the certificate to work.

At this point I started from the beginning with a brand new certificate request on KPOC1, this time using the offline request method so I could download the .cer file from the CA during the request.



I opened up the CA Web Enrollment webpage, generated the new cert and downloaded the .CER file


Next I processed the offline request in the OCS Certificate wizard and copied the .cer file downloaded in the last step to my workstation running the OPENSSL tool.  I also went into the Certificate snap-in and exported the .PFX version of the certificate from my Front End server and copied it to the other OCS Front End servers to be assigned, and my workstation to be converted.

Now, using the command line I first converted the .pfx file to a .pem, and then converted the .pem file to a .der.   

Once the conversions were completed I uploaded the .cer and the .der files to the VPX, making sure to choose the certificate format type of “der”.

Once the upload was complete I was able to assign the certificate to my OCS Virtual Servers and start load balancing.



There may be an easier way of doing this out there, but this is what worked for me.  If you happen to know a better way please feel free to email me via the contact page or post a comment. 

Hope this helps!


Posted in Uncategorized | Tagged , , , , , , | Leave a comment