|
14Browsing on a Microsoft NetworkBrowsing a computer network is a lot like shopping in a large department store. Before you know what you can buy, you must find out what’s available. Browsing a network is a process of just taking a look around to see what can be used. That’s where the Microsoft browsing service comes in. With the new interface to NT, seeing what network resources are available has become a much more logical process. As with Windows 95, the primary network window for users to see what’s available is the Network Neighborhood icon, which you always can find on the desktop if network services are enabled. Because Windows NT and Windows 95 have excellent graphical interfaces to view the items available on the network, there is little need for users to resort to the text-based browsing methods that other network are still mired in. This chapter covers the principles and specifics of setting up browsing services on a Microsoft network. Examining the Principles of BrowsingBrowsing a Microsoft Windows Network is like any other network element. It consists of a server side and a client side. In order for browsing to be successful, both sides must be correctly structured. Not to fear. Very little, if any extra effort is needed to ensure that browsing on a Microsoft Windows Network will succeed. Looking At the Terms of BrowsingIn order for you to understand the intricacies of browsing, you first must understand the terms involved. I have found that once people know the meaning of the words you are using, they generally have an easier time following your instructions. If you are an experienced network person, feel free to skip ahead to the next section. The following terms are used when discussing browsing on a Microsoft network:
Understanding Workgroups Versus DomainsMany people become confused when talking about workgroups and domains. Both are very similar in nature. The difference is in security. Domains have a central security figure in the form of the primary domain controller (PDC), which always is going to be an NT Server. Workgroups, on the other hand, are simply a collection of computers on a network grouped together in name only. This action of grouping computers by a classification name (whether that name reflects a workgroup or a domain name) helps greatly when browsing the available network resources. Try to imagine a large department store where the products for sale are not grouped together in a logical fashion. It would take hours to find the things you needed to buy. The same is true for networks that have no logical structure. Workgroups and domains, for browsing purposes, are the same except for the level of security involved. Workgroup machines (Windows for Workgroups 3.11 or Windows 95) do not consult any higher authority when permitting a user to log onto them. Even though WFWG or Windows 95 prompts a user for a name and password when logging on, this information is not cross referenced against any central database. WFWG and Windows 95 store the user name and password locally. After a local logon name and password are defined, that information combination is kept and used only by the local machine to validate and permit that user to log on again in the future. Consider this. A new user named Ben Franklin is logging onto a Windows 95 workstation for the first time. This workstation is set up as a workgroup machine only. Ben logs on when prompted to do so and enters a password of LIGHTNING. Windows 95 saves this information to the local drive in the form of a *.PWL file found in the default Windows directory (traditionally, C:\WINDOWS). If anyone wants to log onto this Windows 95 workstation in the future as Ben Franklin, he must enter the correct password that first was established. In this scenario, just logging onto the Windows 95 workstation has done nothing as far as network validation goes. Old Ben has simply been given authorization to log onto the Windows 95 workstation in question. If Ben goes to another workgroup-based workstation, he can enter anything he wants for a user name and password. Workgroup machines do not share user names and passwords. All user names and passwords are for local use only. Domains, however, are a lot different. If a WFWG or Windows 95 workstation is set to log onto a domain, all logons are validated by a central security machine called a primary domain controller (PDC). The action of a user logging onto a domain also establishes network authorization. Only NT Servers and NT Workstations have centralized security for resource management, however. WFWG and Windows 95 workstations simply do not have the capability to reference a domain controller in order to find out whether a network user has authorization to use one of their resources. WFWG and Win95 workstations can use either workgroup or domain level authorization for user logins but have no ability to reference an NT PDC in order to find out if a network user have authorization to use their resources even if they are set as domain participants. The PDC of this small network is BOSS, and there are three workstations: Alpha, Beta, and Gamma. Alpha and Gamma are Windows 95 workstations, and Beta is an NT Workstation. All workstations are set to log onto the domain OFFICE. All user names and passwords therefore are validated by BOSS before anyone logging on is granted network permission. The user Ben Franklin wants to log onto the network but is not a valid user of the domain OFFICE. This means that he is not in the user database that BOSS maintains. Ben is trying to log on from Alpha, one of the Windows 95 workstations. Ben is prompted for his name and password. He does not get validated with the user name Ben Franklin and a password LIGHTNING, so he clicks Cancel from the logon dialog box and proceeds to enter Windows 95 without network validation. At this point, Ben still can access resources on the other Windows 95 workstation of this small network because Windows 95 and WFWG workstations have very little resource protection. Ben cannot access resources on the NT Server and NT Workstation, however, because access to all resources on these computers is controlled by the PDC; because Ben is not validated by the PDC in this scenario, he is out of luck. Of course, resources on Windows 95 and WFWG workstations can have access limitation placed on them in the form of passwords and allowed user lists. When resources on workgroup machines are secured by password protection or they have a permitted user list defined for them, the protection is only for the local resource. Workgroup machines do not have network-wide authority. Browsing without proper network validation can produce mixed results because a user still might be able to see and use network resources of WFWG and Windows 95 workstations (unless resources on these machines are protected locally) and see but not have access to NT-based resources. Despite all of Windows 95’s enhancements to networking, it is still very basic in the realm of security and internetworking cooperation. Logging on as a Workgroup Member but Accessing the DomainEven if a user logs onto a workstation that is set to only provide workgroup-level validation, he still can access domain resources if he has a valid domain name and password. If Ben Franklin had been a valid user to the PDC but the Windows 95 workstation he had been logging onto was set up as a workgroup machine, he still would be granted access to domain resources when he attempted to access or view them. NT machines demand validation of a workgroup user by a PDC using the current logon name and password from the workgroup machine. If the workgroup machine provides a valid user name and password (determined by the PDC), the user is granted permission to use a domain resource. This permission, however, is determined only at the point when the user attempts to access domain-controlled network resources. As stated earlier, just logging onto a workgroup machine does not provide network authorization at that point. Using Trust RelationshipsFor a long time, trust relationships confused me. I understood only part of the principle involved when dealing with trusts. It sounds simple enough on the surface: Two domains can enter a relationship in which one trusts the other (and maybe vice versa) to properly validate network users and allow access to network resources. It’s basically an If you say the user is OK, then he’s OK by me situation. Chapter 18, Understanding the Registry covers establishing trust relationships in greater depth. Even if two domains have a two-way trust relationship, that does not by default mean that users of one domain have access to browse and use resources on the opposite domain. When I first began working with NT, I thought all I had to do to easily give users of one domain access to resources in another domain was to set up a trust between the two domains in question. Setting up a trust is only the first half of granting domain user rights to browse and access foreign domain resources. After a trust is established correctly, the second part of setting up users in one domain as valid users of another is to modify the user group of one domain to be part of the user group of the other. This, in essence, makes the users of one domain able to access the resources of another domain without having to go through the hassle of ensuring that parallel and identical user accounts exist on both domains for every user needing access to both domain resources. Adding a user group from one domain to the user group of another domain is covered in greater detail in Chapter 18. Examining the Pitfalls of Trust RelationshipsWhen one domain trusts another domain, the PDCs of both domains talk to each other when a user from one domain attempts to access secured resources (resources on an NT Server or NT Workstation) on the other domain. The two domains, Office and Home, are in a two-way trust relationship and the user groups of both domains have been adjusted correctly. Therefore, the two domain controllers BOSS and WORKER tell each other about their own user’s access levels when users from one domain try to access resources on the other. When Karen Simpson from the Home domain wants to access the resources on Beta (an NT Workstation system that follows the security settings of the Office PDC), the Office PDC, BOSS, asks the Home PDC, WORKER, what sort of access Karen Simpson has. WORKER informs BOSS, and BOSS grants or denies access accordingly. If Karen is on the Home network and, for some reason, the Home PDC, WORKER, goes down, she cannot access secured resources in the Office domain because her own PDC cannot tell the Office PDC about her security rights. This scenario plays heavily in remote access situations in which one domain trusts another one but the two PDCs cannot communicate correctly. You might find that when attempting to access secured resources on a remote network, you are getting Cannot Find Logon Server error messages. This is due to the remote PDC not being able to locate the local PDC to gather user information. Suppose that the two domains are not physically connected but the trust relationship has been established by connecting the two PDCs directly with the Remote Access Server (RAS) features built into Windows NT. After the trust is established and the RAS connection is broken, the trust still is active. Now, if Karen Simpson uses the network-dialer feature of her Windows 95 workstation to get a RAS network connection to the Office domain PDC, she cannot access any secured Office domain resources because the Office PDC still wants to talk to the Home network PDC, WORKER, to get security rights information. The network-dialer feature of Windows 95 cannot route network data back to the Home PDC. Just think of Windows 95 dialup network connections as one-way only connections. The Windows 95 workstation can see the remote network but the remote network cannot allow the Home PDC WORKER to talk to the Office PDC BOSS. This means that the Office PDC requests for information from the Home PDC go unanswered and therefore Karen Simpson is not granted any access to secured Office resources. The workaround for this situation is to simply not have a trust relationship between the two domains and to make certain that each domain has an identical user account for all users needing access to both domains. That forces the remote network to grant or deny access to remote resources based only on the security rights it finds for the user in question in its own user database. This solution is a little more work for the network Administrator, but it ensures that users are granted access to resources when they need them. Using the Network NeighborhoodTo open the interface for browsing the resources a network has to offer, you double-click the Network Neighborhood icon on the Windows NT desktop. This has become the standard user interface for browsing network resources for both Windows 95 and Windows NT. And it’s a good thing, too. Until this interface was developed, users had to use the File Manager to browse network resources or the command-line utility NET.EXE to browse. Figure 14.1 shows the Network Neighborhood window. The Network Neighborhood (browse client interface)
Other computers in the domain in which the current machine is a member are shown when Network Neighborhood is started. If the Network Neighborhood is started and you do not see all the members of your domain and you are certain that they are present on the network, many things could be occurring to prevent them from being displayed. Being present in the browse list (the display of systems on the network in the Network Neighborhood) and actually being on the network as a valid network member are two separate items. This chapter covers issues that deal with browsing network systems and resources. Seeing Other Domains in the Network NeighborhoodThe first entry in the browse list enables you to view the entire network, as shown in Figure 14.2. Keep in mind that a Windows NT Server can act as a gateway machine between many different network platforms. NT can talk to Novell networks, Unix networks, and IBM mainframes. The proper term for the internal NT network platform is the Microsoft Windows Network. The next step after viewing the entire network is viewing other network platforms for which NT may be acting as a gateway. If no other network platforms are being gatewayed by an NT server, the only network platform listed is the Microsoft Windows Network. Viewing your connections on the entire network.
Double-clicking the Entire Network entry in the Network Neighborhood enables you to browse all domains accessible to the current machine. Note that it is possible to see network systems and resources without actually having access to use them. You can use a resource directly through the Network Neighborhood or by mapping a resource to a local drive letter or device name (such as LPT1, in the case of printer resources). When mapped to a local drive letter or device name, the resource becomes transparent to applications and services running on an NT Server. The main role of an NT Server is not to use resources but rather to give workstations access to them. Using Master Browsers and Backup BrowsersOn every network domain, a Master Browser exists. This is a system on the network responsible for keeping a list of all members of the network. This centralization of the domain member list helps increase network performance. Individual systems on the network don’t have to continually broadcast their presence in order for the other machines on the network to see them. The Master Browser of a domain most likely is the PDC. If the PDC goes down, however, there are provisions for allowing other machines in the domain to take over the role of Master Browser. These machines are called backup browsers and typically run concurrent to the Master Browser, maintaining the same member list of the domain, ready to take charge if promoted by the Master Browser or if certain network conditions arise that warrant a new Master Browser election. Holding ElectionsWhen an NT Server is brought online, an election is held. An election is a network process to find out which machine on the network is best suited to be the Master Browser. Typically, a PDC always must be the Master Browser for its domain. If a domain PDC is down, however, other machines can take over the roll of Master Browser. When an NT Server is brought up, it sends out a network-wide notification indicating that a new election should be held. Every NT Server brought up on a network forces a new election unless that server’s configuration is set so that it should never be a master or backup browser itself. The notification message NT Servers use is called an election datagram. Election datagrams are broadcast network wide. The term election is a little misleading because the servers on the network don’t actually "vote" on who should be the Master Browser. These datagrams force every viable browser candidate to sum up its potential as a Master Browser and to report its result to the server that initiated the election. The server with the highest potential is elected as the Master Browser. Included with the election datagram is information on the initiator’s election version and election criteria. Receiving browser candidates compare their election version and criteria to the information sent to them by the new Master Browser candidate. If the new Master Browser candidate’s election version is higher than any other potential browser’s election version, the new candidate wins the election and becomes the new Master Browser. The server with the newest network software therefore always is the Master Browser for a domain. If the new candidate’s election version is the same as the current Master Browser’s election version, election criteria is summed up and the candidate with the higher criteria total wins. When a new server is brought online in a network, a Master Browser already is running. An election is normally a process to see whether any newly started servers have the muscle to bump off the current king and take his place. Elections also are used to find a new king when the current king steps aside gracefully (is shut down properly) or does not respond to a browse client’s request for a browse list (meaning that the current Master Browser was taken down hard via a crash or a power outage). Browse clients talk to any available browser to gather a browse list. Clients typically talk to a backup browser to eliminate the burden of the Master Browser. If a browse client cannot find a backup browser, it polls the Master Browser for a list of available backup browsers. If it cannot find the Master Browser, the client issues a domain-wide request for an election. Looking At the Election ProcedureWhen a new server is brought up or the current Master Browser cannot be found in a domain, an election takes place in the following manner:
After a browser becomes the tentative winner of the election, all browsers enter a mode known as running election. During this period, the tentative winner reinitiates the election to ensure that it is the real winner. After a system loses an election, it does not broadcast any more cycles that may be left. A system also demotes itself to the status of backup browser if it loses an election. If no other browser on the network responds to the election request with better criteria, the tentative winner becomes the actual winner and the election is over. Strange situations can occur during elections. The network might have a break in the communication lines and be functionally severed in half, for example. Each half might remain functional, but each half would have determined a Master Browser for itself. What if the two halves were rejoined? There would be two Master Browsers for a single domain. In this scenario, when a Master Browser receives a server announcement from another machine claiming to be a Master Browser for the current domain, it immediately demotes itself to the role of backup browser, sends out an election datagram, and starts a legitimate election. Examining Election CriteriaIf two potential Master Browsers have to duke it out by comparing capabilities, the elements listed in Table 14.1 are examined. These are hexadecimal values that are masked to obtain the end value. Table 14.1. Election criteria.
As you can see, most of the election criteria tries to ensure that the Master Browser generally goes in this order:
Other factors, such as running a WINS client and being set as a preferred Master Browser, play minor roles if two machines are tied in the primary elements. The MaintainServerList setting is a WFWG setting found in the SYSTEM.INI file in the [network] section. If this setting is set to True or Yes, the WFWG workstation maintains its own list of available servers on the network and is therefore a potential Master Browser. Setting this setting to No or False prevents a WFWG workstation from becoming a Master Browser. If this setting is not present, the value is Auto, which means that the WFWG machine still maintains a browse list but is not treated preferentially if an election is held. In networks in which there is a mix of NT machines and WFWG workstations, it is best to not allow WFWG workstations to be browsers. As mentioned earlier, WFWG machines do not have the same level of network security as NT machines. A situation could arise in which an election is held and a WFWG machine becomes a Master Browser, but it doesn’t have the correct access privileges to correctly communicate with all members of the network. Remember that a WFWG machine has no network access at all if it does not have the correct login name and password. If a Master Browser goes down and a WFWG is placed in charge of the network browse list, the WFWG machine could have an incomplete list of available servers. NT machines also have the MaintainServerList, which is found in the Registry in the section HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters This Registry key is a REG_SZ type value and can be set to TrueTRUE or FalseFALSE. The effect is the same as on a WFWG workstation. A Master Browser election can be totally biased if a Registry key called IsDomainMasterBrowser is added to the section HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters This is a REG_SZ type key and can have a value of TrueTRUE or FalseFALSE. Setting this key to TrueTRUE ensures that the machine in question always is the Master Browser of a domain if no other servers are configured similarly. Communicating Between Network Servers and the Browse MasterWhen a non-browser candidate server is brought up on a network, it sends out another type of datagram called a server announcement. This datagram is directed to the current Master Browser of the domain. After the Master Browser receives this datagram, the server name is added to the browse list. All Microsoft networking systems (WFWG, Windows 95, NT, and LAN Manager 2.x) send server announcements when they go online. It is at this initial stage that potential browsers are informed by the Master Browser whether they are backup browsers. The Master Browser also sends a list of backup browsers to any standard servers just joining the network as well at this point. Servers continue to announce themselves to the Master Browser when they first start at a rate of about once every minute. As they continue to operate, that announcement time gradually increases until it becomes once every 12 minutes. If the Master Browser does not hear from a server within three announcement periods, it removes the unresponsive server from the browse list. If a new Master Browser has just gone online, it can force all servers on the network to reregister with it. This is done via a request announcement datagram—a network-wide broadcast to which all servers within the domain must respond. Servers are set to respond to this query with a server announcement datagram at a random time within 30 seconds. If a new Master Browser of a large network received responses all at once after just coming up, it might get swamped with responses. The randomizing of the response time by network servers helps keeps network traffic from becoming too heavy for the Master Browser to handle. Using Backup BrowsersAs already mentioned, the Master Browser is in charge of indicating which remaining potential browsers should be considered backup browsers. The general rule of thumb is one backup browser for every 32 workstations on the network, with at least one backup browser regardless of how few workstations are on the network. Potential browsers are tagged as backup browsers by the Master Browser when they come online. Thereafter, they contact the Master Browser once every 15 minutes to retrieve an updated browse list. If a backup browser is unable to locate the Master Browser, it immediately initiates an election. Backup browsers are the first to field browse-list requests by browse clients.requested to do so. go directly to the Master Browser for a domain. If a browse client cannot locate the Master Browser, it attempts to find one of the backup browsers. Spanning SubnetsDomains can span subnets, meaning that some of the servers on a domain can be separated by routers. The thing to keep in mind about routers is that they do not forward general network broadcasts. This means that networks that rely exclusively on the NetBEUI protocol do not work very well when routers are involved. Keep in mind that the NetBEUI protocol relies almost exclusively on network broadcasts to communicate. This is a simple method of network communication on non-subnetted domains. The TCP/IP protocol can be routed across routers, however. Remote access connections also are considered to be routed connections and, therefore, the same restrictions apply. It always is best to have a second protocol enabled on a Microsoft Windows Network other than NetBEUI. The logical choice currently is TCP/IP. For each section of a domain that resides on a separate network segment, a Master Browser and a set of backup browsers exist. The PDC of the entire domain serves as an entity known as a domain Master Browser. A domain Master Browser is a browser that merges browse lists from all domain network segments into a single list and then redistributes that complete list back to the local segment Master Browser for it to use. In order for subnetted browsing to function correctly, each segment of the domain must have an NT Server on it. Only NT Server can correctly route browsing datagrams over routers. The following procedure is used during subnetted domain browser communication:
If a network segment becomes severed from the rest of the network, the Master Browser for that segment continues to operate, but the browse list entries from the rest of the network segments eventually are cleared. The local Master Browser continues to try to reach the domain Master Browser every 15 minutes. Using Multiple Domains in the Browse ListA browse list can contain other domains as well as servers from the current domain. In order for a Master Browser to have information about other domains, domain announcement datagrams are used. These datagrams are broadcast by the Master Browser of a domain. The broadcast datagrams contain information about the Master Browser of the broadcasting domain and are received by foreign domains, which then add the domain name to their own browse list. The datagrams also contain information about the name of the Master Browser for the domain in question and what type of Windows NT the Master Browser of the domain is running (server or workstation). If the Master Browser of the domain is an NT Server, the datagram also contains information indicated if the Master Browser is a PDC. Master Browsers make domain announcement datagram broadcasts once every minute for five minutes and then once every 15 minutes thereafter. A domain Master Browser queries any available WINS server for information on registered domain NetBIOS addresses to supplement its domain list obtained by domain announcement datagrams. WINS servers help out greatly when dealing with subnetted domains. Using Browse ClientsNow that you have some basic understanding of how the server side of browsing works, take a short look at what happens from the client side. Remember that the primary browsing client interface for both Windows 95 and NT 4.0 is the Network Neighborhood on the desktop. When a client first requests a browse list from the network, it must retrieve a list of available backup browsers from the Master Browser. Clients do this by means of the query browsers servers datagram directed to the Master Browser of the domain. The Master Browser responds with a list of available backup browsers for the client from which to choose. All backup browsers should have an up-to-date copy of the Master Browser’s browse list (at least a copy no older than 15 minutes). The client chooses up to three backup browsers to query for future needs. The client then randomly chooses a backup browser to use for browse-list requests. Each time the client needs a browse list, it randomly chooses one of the three backup browsers on which it has information. This approach to browsing the network spreads out the load placed on all browsers. The Master Browser’s primary role is to make sure that all backup browsers have up-to-date information. If a client cannot contact one of the backup browsers it has information on, it tries another one. If it fails to contact any of the three backup browsers it knows about, it queries the Master Browser for a new list of backup browsers. If it cannot contact the Master Browser for the domain after three attempts, it issues a force election datagram, which begins the election process for all potential browsers. Using the Browse ListMany situations can occur that cause the information displayed in the browse list to be incorrect. Keep in mind that it can take some time before a crashed server is removed from the browse list. At their longer intervals, for example, servers announce themselves to the Master Browser once every 12 minutes. Three non-contact cycles must occur before the Master Browser removes a server from the list. That means a Master Browser might not remove a server from display for 36 minutes. To make matters worse, backup browsers retrieve a new browse list once every 15 minutes. So, if things are timed badly, it might take 51 minutes before a server is removed from the browse list. The same principle can work in reverse. Simply because a server is not visible on the browse list does not mean that the server is not present on the network. A Microsoft Windows Network is sometimes flighty when it comes to correctly showing who is online. It is particularly bad with RAS connections and dealing with workgroups without NT PDC. If you want to test whether a server is on the network, but you do not see the server in the browse list, you always can use the NET.EXE program from within a command shell to try to manually locate it. Looking for a Server on the NetworkIf the browse list does not show a server that you are certain is up and running, you can use NET.EXE to view and/or connect to resources on that server. NET.EXE most easily is used from within a command shell. NET.EXE is an application in both NT 4.0 and Windows 95. To view resources on a non-visible server, you use the following command line: NET VIEW \\ServerName If the name of the server in question contains a space, you must enclose the double backslash name string in quotation marks. To actually connect to resources on a server that is not visible in the Network Neighborhood, you use the following command line: NET USE x: \\ServerName\ServerResource Again, if the ServerName or ServerResource contains any spaces, you must enclose the final string in quotation marks. x: specifies the local drive letter to which you want to link the network resource. NET.EXE supports a wide range of network commands that are useful when troubleshooting browse problems. Hiding Resources from the Browse ListAlthough there is no way to keep a server that is a member of a domain from being displayed in the browse list, there is a way of hiding shared resources while still making them available for use. When assigning a share name to a resource, you can append a dollar sign ($) to the end of the share name to keep the resource from being displayed in the browse list. The $ is an actual part of the share name. When resource share names are appended with a $, the only way to link to them from a remote network site is to know the name of the resource and to use the NET.EXE command from within a command shell to perform the mapping. An example of using a hidden resource follows: NET USE S: \\controller\backdoor$ BACKDOORbackdoor$ can be a share name for the root directory of drive C on the server CONTROLLERcontroller. Use hidden resource names if you need to have a publicly available resource but you don’t want the majority of network users to know about it. Manually Adding Domains to the Browse ListYou can double-click the Network icon in the Control Panel to alter the browse service of an NT Server to manually include foreign domains for browsing purposes. Figure 14.3 shows the Add Domain element of Control Panel. To add a foreign domain to the browse list, follow these steps:
Adding a foreign domain to the browse list
The added domains are available immediately for browsing (assuming that they are accessible to the current domain) by clients. Normally, it takes several minutes before a newly connected domain is visible to the current domain browsers. Adding the domain names in this manner ensures that browse clients do not have to wait before the foreign domains have correctly announced themselves. Browsing with LAN ManagerLAN Manager 2.x is another, older, Microsoft network environment. It behaves very similarly to Windows NT, but there are some small differences you might have to work around in order to get an NT Server to correctly interact with a LAN Manager 2.x system. The first problem that arises is the fact that LAN Manager and NT use slightly different announcement formats for certain network activities. You can tell NT to issue LAN Manager compatible announcements to LAN Manager clients by doing the following:
You must restart the server in order for the changes to take effect. Some special provisions must be made in order for NT browsers to see LAN Manager servers as well. Follow the same steps you used to manually add domains to the browse list. You can add up to four LAN Manager domains in this manner. SummaryIn this chapter we looked at the principles involved with browsing on a Microsoft Windows Network. We have seen how both the server side and client side of browsing works. You should now be familiar with the principles of elections and their purposes within a network environment. Knowing all of this should allow you to more easily troubleshoot and problems you may be experiencing if browsing services on your network are not functioning as they should.
|
