The problem of port exhaustion usually doesn’t affect DC’s to the same extent as it affects clients and application servers.
The reason is that a Domain Controller is the lord of its own small kingdom, it will usually have a local copy (RW or RO) of the partitions it needs to consult for servicing incoming user requests for information (LDAP queries) or authentication (Kerberos).
The crux of this is that RWDC’s seldom have to make outbound connections to other DC’s regarding LDAP or Kerberos requests.
I.e. Port Exhaustion only applies to outbound connections and since authentication requests are inbound connections a RWDC can usually continue authenticating users even if it can’t make any new outbound connections.
For RODC’s we have some additional requirements.
Under normal circumstances, when an RODC receives an authentication request from a user that doesn’t have her or his password cached on the RODC then the RODC must make a network connection to it’s upstream RWDC replication partner (usually referred to as ‘chaining’ the authentication).
If the RODC is suffering from a port exhaustion condition at the point in time when it needs to contact the RWDC, the authentication attempt will fail (the same will apply if the network is down of course).
The tcpip.sys, afd.sys and tdx.sys binaries that shipped with Windows Server 2008 have been updated several times to address a compatibility issue with TDI. The latest public build of tcpip.sys as of today is available in KB968991 while KB961775 contains the afd.sys/tdx.sys updates. SP2 does not contain either update, as both were released psot-SP2.
Port Exhaustion and You (or, why the Netstat tool is your friend)
New AFD connections fail when software that uses TDI drivers is installed on a Windows Server 2008 or Windows Vista SP1 system that is running on a computer that has multiple processors
File copying from down-level systems to Windows Vista or Windows Server 2008 is significantly slower if Intel I/OAT is enabled
Appendix A: RODC Technical Reference Topics