We have a separate AD domain setup within our DMZ. We have a one-way trust (DMZ trusts internal domain), so that we can use internal user accounts inside the DMZ domain. This has always worked well. About a month ago, we had some issues with our internal PDC. We had to move the roles off of it, then rebuilt it, and all is good. However, within our DMZ domain, it now takes several minutes to log in to a member server when using an internal user account. There is no delay when using an account within the DMZ domain. When getting this long delay (up to 4-5 minutes sometimes), we also get Event 1053 in the logs (Windows cannot determine the user or computer name(There are no more endpoints available from the endpoint mapper. ) Group Policy processing aborted). I have checked DNS, which appears to be working(our internal zone is replicating to the DMZ DC). I have tried re-creating the trust, which also did not help. Does anyone have any idea of what I should try next? The odd thing is, our DMZ has 3 sites which correspond to our 3 internal sites, and this problem is not occurring at all at the other 2 sites. It is only happening at the site where we had to rebuild our DC.

Hello,please post an unedited ipconfig /all from the problem DC and a machine where you try to logonfrom. Did you check that all internal DCs are replicating correct with repadmin /showrepl and chekc the DCs with dcdiag /v and netdiag for problems?Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights.

Sorry about the delay. Repadmin, dcdiag, and netdiag do not show any errors or failures. For some reason, during netdiag, the 'trust relationship test' is skipped. I tried running it with the /test:trust flag, but it still skipped it. Do you know why this would be? To me, this would be one of the more useful tests to run. Here is the IP config from the DMZ domain controller: Windows IP Configuration Host Name . . . . . . . . . . . . : dmz-dc Primary Dns Suffix . . . . . . . : domain.dmz Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : domain.dmz Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter Physical Address. . . . . . . . . : 00-50-56-84-7F-07 DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.27.151 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.27.1 DNS Servers . . . . . . . . . . . : 192.168.27.151 192.168.29.151 Here is the ipconfig for the member server: Windows IP Configuration Host Name . . . . . . . . . . . . : dmz-member Primary Dns Suffix . . . . . . . : domain.dmz Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : domain.dmz Ethernet adapter dmz: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter Physical Address. . . . . . . . . : 00-50-56-BD-7C-75 DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.27.119 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.27.1 DNS Servers . . . . . . . . . . . : 192.168.27.151 I did change the server names and domain names, but the rest of the information is correct.

I figured this out. For those curious, the randomly used RPC ports were being blocked by our firewall. The guy who had set this up in the past had modified a limited range that we would allow through the firewall to allow RPC calls to work. When rebuilding the server, these defaulted back to using a range that fell outside of the range we specified in the firewall. I set them back to our appropriate range using this MC article: http://support.microsoft.com/kb/154596