Event ID 1265 2

[lbrown13]

I have 2 servers in house. I have added two additional 2k servers at remote locations. All are win2k server
and I am getting the following error in the event viewer.
Also, I know that you are suppose to only put the ip of the server in the dns entry, does that include remote servers as well?

Larry


The attempt to establish a replication link with parameters

Partition: DC=lagrange,DC=pathwayscsb,DC=org
Source DSA DN: CN=NTDS Settings,CN=TROUPMH-SERVER,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lagrange,DC=pathwayscsb,DC=org
Source DSA Address: 8989ebc9-00c4-4aee-8036-d4aaed2b9ebb._msdcs.lagrange.pathwayscsb.org
Inter-site Transport (if any):

failed with the following status:

The RPC server is unavailable.

The record data is the status code. This operation will be retried.

 

[lbrown13]

I believe its going to a routing issue.

The in house servers are 10.1.0.0
One remote server is 192.168.5.250
The other remote server is 192.168.6.250

Do they need to communicate with each other?
Or do they just communicate with the main server?


Larry

 

[ITPangaeaArchitect]

small potential to be routing...since thatd break anything anyway

RPC server is unavailable 9 times out of 10 means you messed up your DNS config

you need to have quite a few ports open, or wide open, between the subnets (see 179442 for ports)

Read my FAQ and correct yoru DNS config:

http://tek-tips.com/faqs.cfm?fid=6083

that should correct it

delete any connection objects in dssites.msc and check replication topology..most should create immediately if all DCs are corrected; do this DC by DC (make sure to do it in the context of the DC using teh connect to domain controller for each DC this is done for...it speeds things up)

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[grimmy26]

ensure that you have ports 135 and 445 open. if not open them and see if that solves your issue

 

[lbrown13]

after more investigation...
I can ping from 6.250 to any of the 10.1.0
I can ping from 5.250 to any of the 10.1.0
I can ping from any 10.1.0 to 6.250 and 5.250
However, I can not ping from 6.250 to 5.250
or vice versa.

Larry

 

[grimmy26]

have you a route from the .5 network to the .6 network?

 

[ITPangaeaArchitect]

yep in your case sounds like it may be the routing....445 will have nothing to do with RPC though (its SMB)
135 is the endpoint mapper, and 1024-5000 are the dynamic response ports...these are required to be open...as is 88 udp, 53 tcp/udp, 389 tcp, etc. etc.

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[lbrown13]

I have tried putting static routes in on .5 and .6
and even on my main dc. I have tried putting them in the routers and on the servers.. still no luck

Thanks for the help!


Larry

 

[ITPangaeaArchitect]

what is the status of the subnet-to-subnet communciations at this point? Are the two subnets able to ping each other? If the subnet is built, and you feel properly, please ensure ICMP is open between them (this will be a required port anyway for group policy application to occur)

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[lbrown13]

I have made some changes to the outside network. I changed the 192.168.5.0 to 10.1.20.0 and the 192.168.6.0 to 10.1.30.0

This seem to improve one machine but not the other. I am not getting any errors except on the 10.1.30.0. I now get an error of 1265 about a dns lookup failure from 10.1.20.0. Also, it looks like that 10.1.20.0 isn't being replicated by the other servers. I had to manually populate the reverse lookups.
When running dcdiag on 10.1.20 I get

[MARIUS] DsBind() failed with error -2146893006,
The security context could not be established due to a failure in the requested quality of service (e.g. mutual authentication or delegation)..
[TROUPMH-SERVER] DsBind() failed with error -2146893006,
The security context could not be established due to a failure in the requested quality of service (e.g. mutual authentication or delegation)..

Also,
Starting test: FsmoCheck
Error: A GC returned by DsGetDcName() was not a GC in it's directory


I can ping ip addresses, it will reverse look up.
I can not however, ping the GUID of 10.1.20.0


Thanks for all the help!


Larry

 

[grimmy26]

Do you get any 5789 errors from NETLOGON source in the NT event log?

MCSE NT4, 2000, 2003

 

[lbrown13]

No, But I get a couple of 5790 and 5723 netlogon errors.

Thanks!


Larry

 

[ITPangaeaArchitect]

again

what is your DNS config

everything u have indicates a DNS issue or port closures

below is both templates I made for work that covers the dns config in the link i gave above and the port requirements. DNS being the problem is even supported stronger since you can't ping the GUID...which can be caused by netlogon service not starting...netlogon is responsible for creation/registration of all SRV records....and dhcp client service is responsible for creation/registration of host records..

so did you mess with the services at all since building the server? Is the firewall disabled?

also, look up 893066 and apply that or check the file versions in the article against yours...if yours are lower, download the patch and install...it is needed if you have the old version of 893066 on the box.

teh items outlined below are REQUIRED for win2000

DNS configuration (if you are running Windows 2000 and do not use this configuration, you may experience issues anywhere from replication to authentication of users, 2003 can also experience same issues):



**Note: I have included a custom method I use that I refer to as standardization. The standardization technique has the potential to decrease the frequency of “business down” issues that are caused by name resolution by approximately 80-90% (assuming long term downage here…examples are file replication, and user logons). The standardization method does take more time to initially set up/configure, but the downtime saved is easily worth the extra effort. To use the standardization method, you must take inventory of all DCs in your domain. Meaning, you will need the IP address, as well as the AD site they belong to. It is easiest to write this information down into a word or text document and then rearrange them in site order (this way you can go site by site instead of searching a list for site members). I would also make a mark by the PDCe so as to not confuse anything (example below). In the recommendations below, the standardization method will always be the method to follow the “-OR-“ (which follows the simple, acceptable method).

EX (servername – IP – sitename; PDC will be servername-PDC-IP-sitename)---

DOM1DC1 – PDC – 10.0.1.2 – Dallas

DOM1DC2 – 10.0.1.3 – Dallas

DOM1DC3 – 10.0.1.4 – Houston

DOM1DC4 – 10.0.1.5 – Houston



**this should make it substantially easier to go through the process without losing your place. It also has the additional benefit of creating DC documentation for later reference.



Standardization method PROS/CONS---

PROS:

-Has potential to decrease major issues caused by name resolution almost in their entirety (I have not seen any name resolution related problems whatsoever any of the times myself, or a customer I recommended the method to, performed this method). This method allows us to maintain DNS name resolution site by site because, for example, if a failure on the PDCe occurs, all members in the PDCe site, since they point to the same alternates in the same order, will fail back to the same DNS server, and begin registering there instead…if that replica DC fails, the same still goes…each time we have a failure all members of the site will fail to the same DNS server, thereby maintaining DNS name resolution almost indefinitely. I do not guarantee no failures at all, but it would substantially decrease the chances of them occurring at all.

CONS:

-Takes longer to configure

-If roles are transferred (specifically the PDC role), complete reconfiguration is required enterprise wide to reflect the new PDCe (this is a step that should be taken whether using standardization or simple method)





*****



Default advanced TCP/IP properties (settings should match these)---

DNS server address is listed

Append primary and connection specific DNS suffixes is marked (radio button)

Append the parent suffix of the primary DNS suffix is checked (checkbox)

Register this connections addresses in DNS is checked (checkbox)

Everything else should be blank

Ensure NetBIOS over TCP/IP is enabled and not set to default (mainly for Win2003)



Domain controllers---

PDCe faces itself and itself only for DNS, with defaults in advanced tcp/ip properties

Replica DCs in the enterprise (all sites) point to the PDCe for preferred DNS, and themselves as alternate, with defaults in advanced tcp/ip properties

-OR-

All replica DCs in site with the PDCe point to the PDCe for preferred, and all the same replica DCs in the same order beginning with the replica DCs in the site with the PDCe, and then out of site replicas (you choose alternate DNS order based on preference and site membership, there is no certain way you need to do this, although I would stick to site by site method…I normally base off of machine performance…such as a 3ghz processor w/ 4GB RAM would be listed before a 2ghz w/ 4GB RAM). Replica DCs in different sites than the PDCe should use the same methods, using the PDCe as preferred, and then the same order for alternates, beginning with replica DCs in the same site as first alternates, then moving to replica DCs in other sites.

EX (using server names and info from example above and adding on complexity):

DOM1DC1 – PDC – 10.0.1.2 – Dallas

DOM1DC2 – 10.0.1.3 – Dallas

DOM1DC5 – 10.0.1.6 - Dallas

DOM1DC3 – 10.0.1.4 – Houston

DOM1DC4 – 10.0.1.5 – Houston

DOM1DC6 – 10.0.1.7 - Houston





P: = preferred DNS A: = alternate DNS

DOM1DC1 – Dallas site - P: 10.0.1.2 & A: None

DOM1DC2 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7

DOM1DC5 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7

DOM1DC3 – Houston site – P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6

DOM1DC4 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6

DOM1DC6 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6





Domain members (servers and workstations) in site with PDCe:

Face PDCe as preferred DNS, and replica DCs as alternates in the same order specified on replica DCs in that site

EX:

DOM1DC1 – PDC – 10.0.1.2 – Dallas

DOM1DC2 – 10.0.1.3 – Dallas

DOM1DC5 – 10.0.1.6 - Dallas

DOM1DC3 – 10.0.1.4 – Houston

DOM1DC4 – 10.0.1.5 – Houston

DOM1DC6 – 10.0.1.7 - Houston



WORKSTATION1 – Dallas (PDCe) site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7





Domain members (servers and workstations) outside of PDCe site:

Choose a replica DC in that site to act like the PDCe’s DNS role for DCs (there is no special way to go about this…i.e.; if we choose DOM1DC3 to be preferred for all clients is fine, on the same note, so is choosing DOM1DC7 if we wanted). The top alternates will be replica DCs from the local site, then other sites replica DCs. The reason for not doing the same DNS config on clients outside of site of PDCe as we did on replica DCs in that remote site is to save time and bandwidth for DNS name resolution.

EX:

DOM1DC1 – PDC – 10.0.1.2 – Dallas

DOM1DC2 – 10.0.1.3 – Dallas

DOM1DC5 – 10.0.1.6 - Dallas

DOM1DC3 – 10.0.1.4 – Houston

DOM1DC4 – 10.0.1.5 – Houston

DOM1DC6 – 10.0.1.7 - Houston



WORKSTATION2 – Houston site – P: 10.0.1.4 & A: 10.0.1.5, 10.1.0.7, 10.0.1.2, 10.0.1.3, 10.0.1.6





Here is a listing of the port requirements for Active Directory domain, as well as optional ports:



Required ports:

1024-5000 TCP/UDP – RPC (dynamic response ports) / required for RPC to respond to communications

135 TCP – RPC (endpoint mapper) / required to open the endpoint mapper to the destination for RPC communications

389 TCP/UDP – LDAP / required to bind to a DC

3268 TCP – LDAP GC / required to bind to the GC function of a domain controller (extremely important for Exchange)

53 TCP/UDP – DNS / required for name resolution and Active Directory functionality as a whole

88 TCP/UDP – Kerberos / self explanatory

445 TCP – SMB / self explanatory

123 UDP – SNTP / required for time synchronization with a time source

ICMP / required for group policy detection, application, and MTU size detection, as well as other low level activities





Optional ports:

636 TCP – LDAP SSL / required to bind to a DC using LDAP over SSL

3269 TCP – LDAP GC SSL / required to bind to a GC using LDAP over SSL

137 UDP – NetBIOS name / self explanatory

138 UDP – NetBIOS Netlogon and Browsing / self explanatory

139 TCP – NetBIOS session / self explanatory

42 TCP – WINS replication / self explanatory

1723 TCP – PPTP / required if using PPTP VPN tunnel

IP PROTOCOL 47 (GRE) – VPN related/required for PPTP VPN tunnel as well



For more information, please see:

http://support.microsoft.com/support/kb/articles/q179/4/42.asp

For Exchange considerations:

http://support.microsoft.com/?kbid=259240

http://support.microsoft.com/default.aspx?scid=kb;en-us;280132

For SQL considerations:

http://support.microsoft.com/kb/q287932/

For SMS considerations:

http://support.microsoft.com/default.aspx?scid=kb;en-us;200898

http://support.microsoft.com/kb/q167128/

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[lbrown13]

Ok,
I the DNS server set to itself in the nic.
I put the PDC as the primary and all others
as alternatives. That fixed it!
Thanks alot for all the input guys!!

Brandon I will put you on my Christmas list!!


Larry