Computer Browser not able to fetch domain

I have 7 win 2003 servers for an application for three environments dev, quality and production and two domains d1 and d2. The application uses computer browser service to get a list of domains. Now in dev and staging I am getting two domains d1 and d2 but in production I get only d2. Now d2 is the domain where the servers are registered and there is a trust relationship between d1 and d2. Using "My Network Places" I can see both the domains and access any computer and resources available. d2 is the parent domain and any host in d1 get d1.d2.com as their DNS suffix. I have used browstat status in all the servers and get "There are 2 domains in domain d2 on transport \Device\NetBT_Tcpip_...."  in development and quality but in production  I get "There are 1 domains in domain d2 on transport \Device\NetBT_Tcpip_....". All servers have two NICs installed, have Netbios settings set to default and all of them are in same subnet and have same DNS servers configured ... both primary and secondary. But strangely the dev and quality servers always pick up the one another or themselves as master browser and the same happens for 5 production servers, I have never seen a production server picking up any quality or dev server as master browser and the same is true for quality and dev. Please help me....I
ArnabAcharjeeAsked:
Who is Participating?
 
ChiefITCommented:
By nature, packets for Netbios shares/SMB shares/CIFS shares (or whatever you want to call them), are held on the broadcast domain. This means a router will not route those broadcasted packets. It's much like DHCP broadcasts, ( you get that locally unless you relay DHCP ))

If you impliment WINS or an LMHOST record between the two site domain master browsers, then you should know some ISPs block netbios traffic over these ports because of security: Many hackers seek these file shares because they are easily seen.

Port 137 (WINS and Netbios port)
Port 138 (netbios datagram port)
Port 139 (netbios datagram port)
Port 445 SMB
These are the ports netbios/wins uses known as common information file sharing (CIFS shares), (as well as Linux Server Message Block meaning SMB)

For that reason, some have found firewalls that allow VPN and the Netbios services have been redirected to a different port.

SMB over SSh is an example:
http://www.axllent.org/docs/networking/samba_over_ssh

This type of redirection for SMB works for Windows as well, because both windows and Linux have common file sharing structures to be compatible with each other.

So, think of SMB for linux and CIFS for windows as the same entity.

Many firewall manufacturers, Like Sonic Wall, redirect file sharing ports to a more secure port to use file sharing over a VPN...

For now, try to map network drives using the fully qualified domain name.. Example:

\\server.domain.name\share
0
 
ChiefITCommented:
Netbios is confined to the Broadcast domain, unless you have help with WINS or IPhelper that allows broadcasted traffic through your VPN tunnel, or over the NAT router.

I assume D1 and D2 are on two separate broadcast domains.

If so, you might look at what it takes to get netbios broadcasts from one site to the other. It appears you already have that one way, but not both.

An alternative is to use WINS. In that case, you might read this article to get netbios from one broadcast domain to the other using a WINS/WAN configuration. WINS allows Netbios to be routed.
http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/net/chptr3.mspx?mfr=true

Who Knows, you may already have WINS, but have a problem with the master browser records of the one domain.
0
 
ArnabAcharjeeAuthor Commented:
I am not able to understand what I need to do here. If you want me to run any command and post the output, I can do that.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
ChiefITCommented:
First off, let's determine the topology of the network.

D1 is one domain and D2 is another. This probably means they are not on the same broadcast domain. Do you understand the term, "Broadcast domain"?
0
 
ArnabAcharjeeAuthor Commented:
No i do not. but the FQDN for servers residing in the d1 domain is severrname.d1.d2.com and FQDN for servers in d2 domain is servername.d2.com...please let me know if this info helps
0
 
ArnabAcharjeeAuthor Commented:
I have gone through some documents regarding broadcast domain and able to understand what it means..Please let me know what info I may provide you to troubleshoot this issue.
0
 
ArnabAcharjeeAuthor Commented:
ChiefIT, This issue is urgent...please respond
0
 
kevinhsiehCommented:
Install WINS on one of your servers and configure all servers and PCs to use the WINS server. You can assign the WINS server using DHCP for DHCP clients, and you will need to manually configure WINS for machines not using DHCP.
0
 
ArnabAcharjeeAuthor Commented:
Kevin,

The WINS servers are already active and all the servers have 1 NIC configured to use that. As the issue has been identified to be happening only in one network segment (I am guessing as all the servers are being hosted from a data center and I do not have physical access), it may have to deal something with BROADCAST DOMAIN as ChiefIT was also guessing. Please remember that the quality and development servers with exact same configuration like production are working fine and they have same subnet, same DNS servers, same WINS servers and being hosted from the same domain. I have also found that running BROWSTAT STATUS returns 2 domains in quality and development but returns only 1 domain in production..And if I run BROWSTAT GM 1 D1 in production, it is saying "Unable to get domain: Access Denied." but returns master browser name in quality and dev, running BROWSTAT GM 1 D2(all servers are being hosted from this domain) returns master browser name in all environments...please let me know if these info helps in isolating the issue..
0
 
ChiefITCommented:
The concept of a broadcast domain, is simply where your broadcasts go. They are held behind a NAT router, VLAN, or will not go through a VPN connection.

An example of a broadcast message is DHCP. When a client logs on, it sends out a DHCP broadcast to find a server that will provide it with a DHCP address. That broadcast is held to the broadcast domain.

Netbios is the same way, without WINS enabled. Since you have WINS, it appears your multihomed servers are causing problems with what nic your Netbios broadcasts are sent out on. This means you have to DISABLE, netbios on any NIC you don't want broadcasting Netbios information on. THEN, you have to make sure WINS has a record of that NIC. You see, Netbios traditionally binds to one nic, and that nic is usually the first one in the bind order.

What I would like you to read up on is the master browser service. This is how the browser service works and will help you to track down the issue on that one domain. It is important you understand the concept of where your broadcast domain stops. Broadcasts stay within it's OWN subnet, and will not go across a router, or VLAN, or VPN tunnel. This is very important to understand to fix this issue.

Please read the following threads: The first one is a Microsoft article on the domain master browser service:
http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/net/chptr3.mspx?mfr=true

The second issue, is much like your issue, and will help you understand netbios broadcasts and the broadcast domain:
http://www.experts-exchange.com/Networking/Windows_Networking/Internet_Protocols/Net_BIOS_and_NetBEUI/Q_24988326.html
0
 
kevinhsiehCommented:
Is this a problem where the machines can't connect to each other? Or is it just that they don't display when browsing the network?
0
 
ArnabAcharjeeAuthor Commented:
Thanks a lot ChiefIT for helping in isolating the root cause. In the mean time I have found that the production affected servers are on a different network segment and quality/devs are on different network segment (VLAN) and they have different gateways which are nothing but VLAN routers. Now if the broadcast packets need to reach other segment , they need help from either LMHOSTS or WINS. I have assumed the issue to be with WINS servers and enabled LMHOST lookup and entered the domain controller's and the other domain's master browser's entry in the LMHOSTS file but still the issue persists. Another observation is that the working servers(quality/Dev) have the same WINS servers configured like in production and if are able to route the packets why not production servers? It is giving me some reason to believe that the gateway may have some firewall rule which is blocking the broadcast packets...Please let me know your thoughts on this...Is there anyway(may be some command) I can check if a broadcast packet is able to reach other segment or track the packet?
0
 
ArnabAcharjeeAuthor Commented:
Kevin,

The machines can see each other and I am able to access them using my network places.As we have thousands of servers in the data center, I use search computer and it returns any computer I search. When I go to My Network Places, I see two domains and then I can access the computers also, but browstat status returns only 1 domain in production segment whereas  the same returns 2 domains in quality/dev and running browstat gm 1 d1 returns  "Unable to get master: Access is denied" in production whereas the same command immediately returns the master browser name of d1 domain in quality/dev..
0
 
PberSolutions ArchitectCommented:
This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.