Domain controllers required ports: Use PowerShell to check if they are listening

An Active Directory domain controller needs to listen on specific ports to service different client requests. For example, when a client computer needs to authenticate, it connects to a server which hosts KDC service and which is listening on the Port 88. Similarly, network ports TCP 139 and UDP 138 are required by the SYSVOL replication service that takes place between all domain controllers. At a minimum, they must listen on these required ports:

UDP Port 88 is required for authentication purposes. UDP Port 88 is used by clients and domain controllers to authenticate with each other.

Both UDP and TCP Port 135 are required for communication between domain controllers and clients to domain controllers.

TCP Port 139 and UDP 138 network ports are used by the SYSVOL replication service to replicate contents of SYSVOL folder.

TCP Port 3268 and 3269 are required for Global Catalog communication from clients to domain controllers. Global catalog servers help in finding an object in the Active Directory quickly.

Both DNS TCP and UDP 53 network ports are used by clients and domain controllers for name resolution purposes.

Check the network port status on a domain controller

If you wish to check the network port status on a specific domain controller, you can run a simple NetStat command that will list all the network ports that a domain controller is listening on. To check the port status on a particular domain controller and to save the output to a text file, execute this command:

Netstat –an –b | find /I “’Listening” > C:\Temp\DCPorts.txt

When you execute the command, it checks all the ports that are listening on a domain controller and then saves the output to C:\Temp\DCPorts.TXT file. You can navigate through the file to ensure the domain controller is listening on the required network ports. However, it becomes difficult if you need to check network ports status on each domain controller. It might take a considerable amount of time if you use the above method to check the status of each port on each domain controller. This is where this article comes in handy. Here we provide a PowerShell script that connects to each domain controller and then collects the network port status.

Requirements for running the PowerShell script

Make sure you run the script from a Windows Server 2012 R2 member server or domain controller, and ensure to create a Temp folder on the C:\ drive as script generates a report by name “DCPortReport.CSV” under the C:\Temp folder. Apart from meeting the above requirements, there are a few other requirements that you need to meet:

First, download PortQry from Microsoft. The script uses the tool to collect the port status from the target domain controller.

The script checks common domain controller ports such as UDP-389, TCP-389, UDP-135, TCP-135, UDP-88, TCP-88, UDP-445, and TCP-445. The status for each port is provided in the report generated by the script.

Once the script has been executed successfully, a report file named DCPortReport.CSV file will be created under “C:\Temp” folder. The report includes the port status for each domain controller as shown in the report below:

As you can see in the report, the script connected to each domain controller, ran thePortQry tool, and then collected the port status for each domain controller. As is indicated in the “Final Status” column of the report, DC3.TechGenix.com and DC4.TechGenix.com domain controllers are not listening on one or more ports. All you need to do is just check the output and make sure nothing on the operating system is preventing a domain controller from listening on the required network ports.

You may find this PowerShell script handy in case you wish to check the domain controllers port status in an Active Directory forest. While you can check the port status on a single domain controller by using the NetStat command as explained above, using the script will save you a lot of time. You can include the PowerShell script in your Active Directory Health Procedure and have the script run every month to ensure the domain controllers are listening on the required ports.

Post Views: 20,968

Featured Links

Read Next

Nirmal Sharma

Nirmal Sharma is a MCSEx3, MCITP and was awarded the Microsoft MVP award in Directory Services and Windows Networking. He specializes in Microsoft Azure, Office 365, Directory Services, Failover Clusters, Hyper-V, PowerShell Scripting and System Center products. Nirmal has been involved with Microsoft Technologies since 1994. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to PowerShell-based Dynamic Packs for www.ITDynamicPacks.Net solutions.

3 Comments

- no need to use portqry, use system.Net.Sockets instead
- why the test for netogon? in fact that test means you need admin access on the DC's, which you wouldn't need for just testing ports. Worse, every Windows box will have netlogon service; so the test adds a security requirement for no benefit
- don't create a file on disk as you go, create a PS Object and just output it to the pipeline
- you can dynamically get the DC list, or better still write an advanced function that either determines them, or takes a list
- way too many unneeded variables, often assigned and then just used once on next line
- The variable 'ReachOrNot' is assigned but never used
- The variable 'PortUDP139Status' is assigned but never used.
- The variable 'PortTCP139Status' is assigned but never used.
- The variable 'STR' is assigned but never used
- refactor the code using functions, you have the same code over and over testing each port
- $CurProfNowForAll has no definition?

Featured Freeware

Recommended

Follow Us

Domain controllers required ports: Use PowerShell to check if they are listening

TECHGENIX

TechGenix reaches millions of IT Professionals every month, and has set the standard for providing free technical content through its growing family of websites, empowering them with the answers and tools that are needed to set up, configure, maintain and enhance their networks.