깡민쓰~IT Story

So you’ve got some DNS Zones on your Domain Controllers and you’re building a test lab or another domain that you want to copy these to. Easy right – not so easy if they are AD integrated zones. This means the files for these zones are not stored in C:\Windows\System32\dns an normal, they are actually stored and replicated to all DCs inside AD.

I had a requirement to move an integrated forward lookup zone from one domain to another so I’m sharing what I did below.

Logon to your DC with the integrated zone and fireup our friend Powershell.

Get-DNSServerZone

You’ll see your zones listed out.

You’ll see here which zones are integrated and which are not.

The ZoneName column is key for the next bit, make a note of the ZoneName you want to export.

Export-DNSServerZone -Name <ZoneName from the above> -Filename <Yourzone.dns>

There’s no confirmation for this command, but this will export the zone to a file that can be resuable.

Open up C:\Windows\System32\dns in explorer.

You’ll see here you DNS zone file. Take a copy of this and place it somewhere.

Log in to your new DNS server where the zone will be imported.

Open up C:\Windows\System32\dns in explorer and copy the file you just exported into this folder.

Now open the DNZ Management Console.

Right click “Forward Lookup Zones” and select “New Zone”, Select “Next” to get started.

Select the zone type and remember to untick the “Store the zone in Active Directory” option.

I know, I know, we want it to be in AD; don’t worry. It will still be once we are done.

Select “Next”.

Populate the Zone Name and select “Next”.

Select “Use the existing file” and enter the name of the file you copied into “C:\Windows\System32\dns”, select “Next”.

Select “Next” on the dynamic update options. Note: The secure option will be available once we convert this zone to an AD integrated zone.

The zone should now appear fully populated in the DNS console. Now time to convert this zone back to an AD integrated zone.

Right click the zone and select “Properties”.

Select “Change” on the right of “Type”.

You might recognise this screen, Select “Store the zone in Active Directory” and click “OK”. Confirm you want to move the zone to AD.

You now have the option to change the dynamic updates to this zone, select as per your preference.

This wraps up the zone import, the whole process could be easily scripted with Powershell. Happy to take a crack at it if anyone is interested.

Now that I have outlined the building blocks of a Lync infrastructure, there are three more topics to understand if we want to have a working infrastructure:

• Firewall rules required to allow communications for Lync clients, Lync servers and for the aforementioned non-Lync servers with additional services we need
• DNS settings to make Lync services available both on the internal network and from the Internet
• Structure of the certificates. Lync is secure by design and digital certificates are mandatory for every Lync 2013 infrastructure

Firewall Rules Required for Lync Server 2013

A deep dive about firewall rules for Lync Server 2013 should include TechNet article Port Requirements http://technet.microsoft.com/en-us/library/gg398798.aspx and the Lync 2013 Protocol Workloads poster http://www.microsoft.com/en-us/download/details.aspx?id=39968 (i.e. to check the requirements for the different scenarios). However to make the topic easier to understand, I have tried to create an explanation based on some assumption.

• The first assumption I will make here is that your network has a segregated DMZ to make services available to the Internet in a secure manner. A couple of the possible solutions for such a deployment are
• Using two firewalls. Note: usually the technology used for the firewalls is not important. However if a SIP trunk is required in our scenario, it is important to have a SIP Application-level gateway (ALG).
• A three-legged firewall that will create a logical demilitarized zone

There is no difference in the result, from the functionality point of view, going for the first option or the second one. A single firewall would imply a single point of failure and higher security risk, because a single Internet-connected device will be exposed both on the DMZ and on the internal network. Having two different firewalls, a front (FW2) and a back firewall (FW1), as shown in figure 6.7, is more secure, especially if we are going to use two different platforms or solutions for security. In the aforementioned scenario, an exploitable security vulnerability on a single technology will not affect the second firewall

A layout including only firewalls and networks that will have an impact on our Lync deployment

Figure 6.7 layout including only firewalls and networks that will have an impact on our Lync deployment

• The second assumption will be that we will not deploy High Availability or load balancing systems (including Enterprise Edition pools of Lync Front Ends). Although you may require them in a real-world design, they add a configuration overhead that will not help understanding the fundamentals of Lync Server 2013 network traffic requirements
• The third assumption is that we will use NAT every time that a public IP is required. Exposing directly a server to the Internet usually is not the best security solution available
• Fourth assumption is that the Edge Server will use three addresses on the “external” network interface card to expose services to the Internet. The addresses are the ones we have already seen:

Edge_IPs

• Last assumption: no integration or connection with Office Communications Server 2007 deployments or clients is required

We will have to grant the following types of network traffic:

6.1 From servers in the DMZ to servers in the internal network

6.2 From servers in the DMZ to the external network

6.3 From the external network to servers in the DMZ

6.4 From servers in internal network to servers in DMZ

6.5 Network traffic related to Lync clients in the internal network

Note: the point 6.5 of the list is interesting only if you have firewalls (or end-point firewalls) separating the networks containing the Lync clients and the Lync servers.

6.1 Network Traffic from servers in The DMZ to Servers in the Internal Network

On the Back-End firewall, FW1,for traffic starting from the reverse proxy, the following ports will be required

On the Back-End firewall, FW1, for traffic starting from the Edge Server, the following ports will be required

6.2 Network Traffic from Servers in the DMZ to the External Network

On the Front firewall, FW2, from the Edge Server, the following ports will be required. It is helpful to remind you the fourth assumption: we have three different IPs on the external network interface of the Lync Edge Server: Access, Webconf and AV. The firewall rules for network traffic from the external network to the Edge will have to point to one of the three IPs, as explained in the following table.

6.3 Network Traffic from the External Network to Servers in the DMZ

On the Front firewall, FW2, traffic from the external network to the reverse proxy, the following ports will be required

On the Front-End firewall, FW2, traffic from the external network to the Edge Server, the following ports will be required

6.4 Network Traffic from Servers in the Internal Network to Servers in the DMZ

On the Back-End firewall, FW1, for traffic starting from the internal network, the following ports will be required

6.5 Network Traffic Related to Lync Clients in the Internal Network

The following rules are required on any end-point firewall and on any internal firewall that controls traffic coming from the Lync clients on the internal network.

Notes Related to the Firewall Rules Required for Lync Server 2013

Lync Server 2013 Edge Server requires DNS resolution and http access to revocation lists of certificates. Depending from your network design, the aforementioned services could be on the Internet or could be available using services on the internal network (like a proxy). The following rule is to be adapted to your network layout

Centralized Logging Service (a new feature in Lync Server 2013) requires additional ports on the back-end firewall (for more details see the TechNet article Using the Centralized Logging Service http://technet.microsoft.com/en-us/library/jj688101.aspx

Disclaimer: please consider the answer as an approximation that could miss some detail. I will try to make a more complete answer in a future post.

Ports required in Lync 2013 (must be reachable from your administrative workstation):
— Ports LDAP (TCP 389) and msft-gc (TCP 3268) on a global catalog/domain controller are always required

-For the Lync Server Control Panel (process is AdminUIHost.exe): HTTPS and TCP 49336 on the Lync server you are going to manage

-For the Lync Server Management Shell (process is powershell.exe): TCP 49336 on the Lync server you are going to manage

-For the Topology Builder to download Lync topology (process is Microsoft.Rtc.Management.TopologyBuilder.exe): TCP 49336 on the Lync server hosting the CMS database

-For the Topology Builder to publish Lync topology (process is Microsoft.Rtc.Management.TopologyBuilder.exe): in addition to the aforementioned ports, Microsoft Directory Services TCP/UDP 445 to a Domain Controller and to the Lync server hosting the CMS database

https://www.absoluteuc.org/part-2-draft-chapter-6-dns-certificate-firewall-requirements-lync-server-2013

http://www.cusoon.fr/sbc-and-sba-guide-ports/