Topic Last Modified: 2011-04-05

The previous topic, Define Edge Server Input File, defined the building blocks for the input file required to merge the legacy topology using the Lync Server Management Shell. This topic dives deeper into the layout and purpose of the input.xml file. This topic explains the various parameters you need to set when authoring the Edge Server input.xml file.

The input.xml file, which can be created using any text editor, should look something like this:

So what does all that mean? Well, to begin with, your XML file should start with the following XML declaration: <?xml version="1.0" encoding="utf-8"?>

After the XML declaration you should then insert the <TopologyInput> element, like so:

This element is very important: if <TopologyInput> is not present then schema validation will not take place. In turn, that could cause Merge-CsLegacyTopology to try and merge a poorly-formed XML file. Because this is an XML file, it is important that this be a well-formed XML file. As a result, you also need to add a closing tag for the <TopologyInput> element: </TopologyInput>

That means that your XML file should now look like this:

With the basic file structure in place, you are now ready to identify the Edge Server components deployed in Office Communications Server. That is something you do inside the <EdgeClusters> element. With that in mind, your next step is to add opening and closing tags for the <EdgeClusters> element to the XML file:

Inside the <EdgeClusters> element you then add as many as five child elements:

• <EdgeCluster>   The <EdgeCluster> element is where you define the different Edge Server roles in your existing Office Communications Server topology. There are three roles you need to concern yourself with:
  
  
  • Lync Access Edge Server   Previously known as the Access Proxy server, the Access Edge Server is responsible for handling all SIP traffic that crosses your organization’s firewall. If your topology includes an Access Edge Server, you need to add this attribute to the <EdgeCluster> element: AP="true"
    
    
  • Web Conferencing Edge Server   The web Conferencing Edge Server (also known as the Data Proxy server) relays traffic between the A/V Conferencing Server and external clients. If your topology includes a web Conferencing Edge Server, you need to add this attribute to the <EdgeCluster> element: DP="true"
    
    
  • A/V Edge Server   The A/V Edge Server (also known as the Media Relay server) provides a single connection point that enables incoming and outgoing media traffic to help firewalls and network address translation (NAT) devices. If your topology includes an A/V Edge Server then you need to add this attribute to the <EdgeCluster> element: MR="true"
    
    Next, specify the version of Office Communications Server running in your legacy domain. For Office Communications Server 2007 R2, use this attribute and attribute value: Version="OCS2007R2"
    
    Finally, if you have enabled federation in Office Communications Server you should add FederationEnabled attribute to the <EdgeCluster> element: FederationEnabled="true"
    
    A completed <EdgeCluster> element will look something like this:
    
    

    	Copy Code
    <EdgeCluster AP="true" MR="true" DP="true" Version="OCS2007R2">

• <LoadBalancer>   The <LoadBalancer> element contains the fully qualified domain names (FQDNS) for both your internal Edge Server load balancer and your external Edge Server load balancers. Note that for external load balancers, you must specify all your load balancers, including the Access Edge (AP), web Conferencing (DP), and A/V Edge (MR) load balancers. A complete <LoadBalancer> tag should look something like this:
  
  

  	Copy Code
  <LoadBalancer InternalFqdn="edgeint.fqdn " ExternalDPFqdn="ExternalDP.Fqdn" />

  If you do not use Edge Server load balancers then this element can be omitted.
  
  
• <Machine>   The <Machine> element contains the (FQDN) of your Edge Server (note that this should be the server’s internal name). For example: <Machine InternalFqdn="node1.fqdn " />
  
  
• <Ports>   Use the <Ports> element to indicate the ports used by your Edge Servers. An APPort indicates an Access Edge Server, a DPPort indicates a web Conferencing Edge Server, and an MRPort indicates a Media Relay Server. Be sure and distinguish between internal ports and external ports. The following example defines the ports InternalAPPort, InternalDPPort, and ExternalDPPort:
  
  

  	Copy Code
  <Ports InternalAPPort="5061" InternalDPPort="8057" ExternalDPPort="443"/>

• <DirectorOrEdgeNextHop>   The <DirectorOrEdgeNextHop> element contains the FQDN of your Edge Server’s next hop server: <DirectorOrEdgeNextHop Fqdn="director.fqdn.com " /> If the next hop server is a Director, you must add the attribute IsDirector="true":
  
  

  	Copy Code
  <DirectorOrEdgeNextHop Fqdn=" director.fqdn.com " IsDirector="true" />

  If the IsDirector attribute is not set to "True," Lync Server 2010 will not be able to use the Office Communications Server 2007 R2 Director for federation.
  
  Upon completion, the element should look similar to the following:
  
  

  Copy Code

  <EdgeClusters> <EdgeCluster AP="true" MR="true" DP="true" Version="OCS2007R2"> <LoadBalancer InternalFqdn="edgeint.fqdn" ExternalDPFqdn="ExternalDP.Fqdn /> <Machines> <Machine InternalFqdn = "node1.fqdn"/> <Machine InternalFqdn = "anothernode1.fqdn"/> </Machines> <Ports InternalAPPort="5061" InternalDPPort="8057" ExternalDPPort="443"/> <DirectorOrEdgeNextHop Fqdn="director.fqdn.com " /> </EdgeCluster> </EdgeClusters>

All that’s left now is to add the <RegistrarClusterPort> element; this is the section of the XML file where you define the port and the transport type for your Registrar cluster. A completed <RegistrarClusterPort> element, one that defines port 5065 and transport type MTLS, will look like the following:

The following conditions apply to the EnableAutoDiscoveryOfPorts parameter:

• EnableAutoDiscoveryOfPorts is a required parameter but Port is an optional parameter.
  
  
• If EnableAutoDiscoveryOfPorts is true and Port is provided, then the value of Port is ignored.
  
  
• If EnableAutoDiscoveryOfPorts is false and Port is provided, then value of Port is used.
  
  
• If EnableAutoDiscoveryOfPorts is false and Port is not provided, an error is logged as this is an unsupported configuration.
  
  

So finally, that gives us an XML file that can be used with the Merge-CsLegacyTopology cmdlet: