BLOG ³¡¸¨®æ

Windows Server - Configuring DFSR to a Static Port

Configuring DFS servers to listen over specific network ports. This is usually to satisfy firewall rules – more on this later. A port in TCP/IP is simply an endpoint to communication between computers. Some are reserved, some are well-known, and the rest are simply available to any application to use. Today I will explain the network communication done through all facets of DFSR operation and administration. Even if you don’t care about firewalls and ports, this should shed some light on DFSR networking in general, and may save you skull sweat someday.

DFSR and RPC

Plenty of Windows components support hard-coding to exclusive ports, and at a glance, DFSR is no exception. By running the DFSRDIAG STATICRPC command against the DFSR servers you force them to listen on whatever port you like for file replication:

Many Windows RPC applications use the Endpoint Mapper (EPM) component for these types of client-server operations. It’s not a requirement though; an RPC application is free to declare its own port and only listen on that one, with a client that is hard-coded to contact that port only. This range of ports is 1025-5000 in Windows Server 2003 and older, and 49152-65535 in Vista and later. DFSR uses EPM.

Update 3/3/2011 (nice catch Walter)

As you have probably found, we later noticed a bug in DFSR on Win2008 and Win2008 R2 DCs (only - not member servers) where the service would always send-receive on port 5722. This article was done before that and doesn't reflect it. Read more on this here:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;832017

http://blogs.technet.com/b/askds/archive/2010/05/14/friday-mail-sack-it-s-about-to-get-real-edition.aspx

All of the below is accurate for non-DCs

By setting the port, you are telling EPM to always respond with the same port instead of one within the dynamic range. So when DFSR contacted the other server, it would only need to use two ports:

So with a Netmon 3.3 capture, it will look something like this when the DFSR service starts up:

1. The local computer opens a dynamic client port and connects to EPM on the remote computer, asking for connectivity to DFSR.

2. That remote computer responds with a port that the local computer can connect to for DFSR communication. Because I have statically assigned port 55555, the remote computer will always respond with this port.

3. The local computer then opens a new client port and binds to that RPC port on the remote server, where the DFSR service is actually listening. At this point two DFSR servers can replicate files between each other.

The Rest of the Story

If it’s that easy, why the blog post? Because there’s much more DFSR than just the RPC replication port. To start, your DFSR servers need to be able to contact DC’s. To do that, they need name resolution. And they will need to use Kerberos. And the management tools will need DRS API connectivity to the DC’s. There will also need to be SMB connectivity to create replicated folders and communicate with the Service Control Manager to manipulate DFSR. And all of the above also need the dynamic client ports available outbound through the firewall to allow that communication. So now that’s:

• EPM port 135 (inbound on remote DFSR servers and DC’s)
• DFSR port X (inbound on remote DFSR servers)
• SMB port 445 (inbound on remote DFSR servers)
• DNS port 53 (inbound on remote DNS servers)
• LDAP port 389 (inbound on remote DC’s)
• Kerberos port 88 (inbound on remote DC’s)
• Ports 1025-5000 or 49152-65535 (outbound, Win2003 and Win2008 respectively – and inbound on remote DC’s).

Let’s see this in action. Here I gathered a Netmon 3.3 capture of configuring a new replication group:

• Server-01 – IP 10.10.0.101 – DC/DNS
• Server-02 – IP 10.10.0.102 – DFSR
• Server-03 – IP 10.10.0.103 – DFSR
• Server-04 – IP 10.10.0.104 – Computer running the DFSMGMT.MSC snap-in

1. First the snap-in gets name resolution for the DC from my management computer (local port 51562 to remote port 53):

2. Then it contacts the DC – the EPM is bound (local port 49199 to remote port 135) and a dynamic port is negotiated so that the client knows which port on which to talk to the DC (port 49156).

3. Having connected to the DC through RPC to DRS (a management API), it then returns information about the domain and other things needed by the snap-in.

4. The snap-in then performs an LDAP query to the DC to locate the DFSR-GlobalSettings container in that domain o that it can read in any new Replication Groups (local port 49201 to remote port 389).

5. The snap-performs LDAP and DNS queries to get the names of the computers being selected for replication:

6. The DFSR service must be verified (is it installed? Is it running?) This requires a Kerberos CIFS (SMB) request to the DC as well as an SMB connection to the DFSR servers – this is actually a ‘named pipe’ operation over remote port 445, where RPC uses SMB as a transport:

7. The Replicated Folders are created (or verified to exist) on the DFSR servers – I called mine ‘testrf’. This uses SMB again from the snap-in computer to the DFSR server, over remote port 445:

8. The snap-in will write all the configuration data through LDAP over remote port 389 against the DC. This creates all the AD objects and attributes, creates the topology, writes to each DFSR computer object, etc. There are quite a few frames here so I will just highlight a bit of it:

9. If you wait for AD replication to complete and the DFSR servers to poll for changes, you will see the DFSR servers request configuration info through LDAP, and then start working normally on their static RPC port 55555 – just like I showed at the beginning of this post above.

DCOM and WMI

All of the things I’ve discussed are guaranteed needs in order to use DFSR. For the most part you don’t have to have too many remote ports open on the DFSR server itself. However, if you want to use tools like DFSRDIAG.EXE and WMIC.EXE remotely against a DFSR server, or have a remote DFSR server generate ‘Diagnostic Health Reports’, there is more to do.

DFSR utilizes Windows Management Instrumentation as its ‘quasi-API’. When tools like DFS Management are run to generate health reports, or DFSRDIAG POLLAD is targeted against a remote server, you are actually using DCOM and WMI to tell the targeted server to perform actions on your behalf.

There is no mechanism to control which RPC DCOM/WMI will listen on as there is for DFSR and other services. At service startup DCOM/WMI will pick the next available dynamic RPC port. This means in theory that you would have to have open the entire range of dynamic ports for the target OS, 1025-5000 (Win2003) or 49152-65535 (Win2008)

For example, here I am running DFSRDIAG POLLAD /MEM:2008-02 to force that server to poll its DC for configuration changes. Note the listening port that I am talking to on the DFSR server (hint – it’s not 55555):

And in my final example, here I am running the DFS Management snap-in and requesting a diagnostic health report. Note again how we use DCOM/WMI/RPC and do not connect directly to the DFSR service; again this requires that we have all those inbound dynamic ports open on the DFSR server:

Wrap Up

So is it worth it to try and use a static replication port? Maybe. If you don’t plan on directly administering a DFSR server and just need it talking to its DC, its DNS server, and its replication partners, can definitely keep the number of ports used quite low. But if you ever want to communicate directly with it as an administrator, you will need quite a few holes punched through your firewall.

Source URL: http://blogs.technet.com/b/askds/archive/2009/07/16/configuring-dfsr-to-a-static-port-the-rest-of-the-story.aspx
Relate Post : Windows Server - Tuning replication performance in DFSR Windows Server 2012 - 變更 Remote Desktop Service Port NETSH 指令修改IP address Windows 2012 - DC server not sync (SYSVOL & NETLOGON) Windows 2008 / 2012 - KMS Server setup Windows Server 2012 - DNS Backup and Recovery Windows Server 2008 - Metadata Cleanup Using NTDSUTIL Windows Server 2012 - Configuring Active Directory Recycle Bin Windows Server - Create Trusted Remote Desktop Services (RDP) SSL Certificate Windows Server 2012 - Hyper-V Failover Clustering
Comments :
No Comments

Post your comment:

Post your comment by Guest :

Verify Code :