June 3, 1999

Note: This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Barbara: Hello, and welcome to the Microsoft Support WebCast. We would like to thank all of you for joining us. Our topic today will be Microsoft® Windows® 98, Microsoft® Windows® 95, and Microsoft® Windows NT® Dial-up, Authentication, and Browsing using TCP/IP, IPX/SPX, and NetBEUI. Our presenter today will be Sherwood Lawrence. I'm Barbara Lamkin and I'll be your host for today's session.

We will start the session with Sherwood's presentation, and follow that up with a Q&A when the presentation is done. During the live session, you should see a Submit Question link to the right of the presentation box. This option will enable you to e-mail us your question, and I will ask it on your behalf. This alias is available for question submission only during the live session.

I'd like to take a moment now to introduce Sherwood. Sherwood Lawrence is a support professional working in the Windows NT Support group. Before coming to Microsoft, he worked in the industry as a programmer, database administrator, and systems administrator. He has an extensive background in investigating performance issues in both databases and operating systems. He's a Microsoft Certified Systems Engineer. Thanks so much for joining us, Sherwood.

Sherwood: Thank you, and thank you for the introduction. What we're going to cover today is how to get Windows 95, Windows 98, and Windows NT to dial up, authenticate, and browse networks, using each of our three protocols that we support: TCP/IP, NWLink, and NetBEUI. We'll also be showing you the configurations for our Microsoft® Remote Access Service (RAS) server, as well as our Microsoft® Routing and Remote Access Service (RRAS) server.

So let's go ahead and move on to slide 2, which is our objectives slide. This will cover what we're going to talk about today. The first thing that we're going to talk about is a review of some of our networking objectives. What is it that we're trying to achieve, and why do we actually implement these types of things in our environment?

We'll also talk about a review of dial-up components. What components will we be looking at? Specifically, client and server components. We'll also cover a software and hardware checklist. These are things that you should check to make sure that you have before really getting into and implementing dial-up networking.

We'll also discuss configuration of clients and servers. We'll do both a general treatment and a protocol-specific treatment. We'll look at common error messages that you might see in a dial-up networking environment, and discuss some of the articles and references that you can use to help you troubleshoot, as well as set up, these environments.

Finally, we'll take the questions during the question and answer period.

Let's move on now to slide 3, where we'll cover our networking objectives. The first thing, our most common goal, is to be able to get RAS validation. That just means that the client is able to actually connect to the server successfully. Our second objective, really, is NT domain log on. So we're distinguishing the difference between RAS validation and NT domain log on. NT domain log on is what allows you to run logon scripts, for instance.

We also want to be able to get access to network resources, as well as browse network resources. It is possible that when you're setting this up, that one or more of these will work, while others will not. For instance, you might be able to connect to a RAS server, but you might not be able to get logged on, and we'll talk about some of those issues.

To successfully achieve all of these objectives, we need to look at both the client configuration and the server configuration.

Let's move on to our next slide, which is our review of dial-up components. Here I just wanted to give you sort of a little visual representation of what the components are in your network. Typically, you have a dial-up client. This could be Windows 95, Windows 98, or Windows NT, and for the purposes of this presentation, when we refer to NT we mean both NT Workstation and NT Server.

We also have the WAN link. This could be an ISDN line or a normal 56 Kbps modem, or even a 28.8 Kbps modem. But for our purposes, we'll just be talking about dial-up connections in general.

We'll also look at dial-up servers, and this could be one of two servers on our site. It could be our RAS server, which you can install by default in Windows NT 4.0. Or the Routing and Remote Access Service server, which is a free download on the Microsoft Web site. Once you have the server configured and the client configured, we then hope to have access to the internal network resources in terms of browsing and getting access to file shares and printers, and anything else that might be on your network.

Our next slide shows us our software and hardware checklist. These are some things that you'll want to make sure that you have before actually trying to implement this.

First and foremost, very important, is check the Hardware Compatibility List (HCL) for your dial-up devices. Make sure that your modems are on the hardware device specifically. You can find the Hardware Compatibility List on our Web site at http://www.microsoft.com/hwtest/hcl/.

On the RAS client side, you'll want to make sure that, depending on your client, you have the appropriate and updated software. For instance, with Windows 95, you'll want to have DUN 1.3. If you want more information on this particular install or download, you can go to Q191494 — that's one of our Knowledge Base articles — for that.

For Windows 98, you'll want to install the DUN update, which is also identified in Q189771, also a Knowledge Base article.

If you're using Windows NT as a RAS client, you'll want to make sure that you have the latest service pack. For purposes of testing for this presentation, I made sure that we had SP5 on our boxes.

On the RAS server side, again, the latest software will mean that for both RAS or RRAS, or Routing and Remote Access Service, you want to install SP5. For more information on SP5, you can find the Readme.txt file once you've installed that.

Our next slide is just an overview of some of the things that we're going to be talking about. We're going to discuss configuration of clients and servers in general. And that means that this configuration would apply regardless of the protocol that you're using. Whether you're using NetBEUI, NWLink, or TCP/IP, the configuration of both the clients and servers will be the same, and that's what we're going to cover here.

Our next slide is just an introduction, saying we're going to be talking about the client side, Windows 95, 98, and NT.

Now we should be on slide 8. This is discussing the Windows 95 configuration. Key concepts here. The first concept that we want to talk about is hardware profiles. For a Windows 95 configuration, you'll want to make sure that you've either created a no-network hardware profile, or verify that no network cards have an IP address on the same network you're trying to dial in to.

What we mean by that is that whenever you dial in to a network, your RAS server or RRAS server is going to give you an IP address, or it's going to try to give you some sort of information about the network that you're on. Make sure that you have a no-network hardware profile, so that there's no conflict of any sort when you dial in.

If the client normally uses DHCP to get an IP address, run winipcfg and choose Release All if dialing in to the same network as the DHCP server. Now, that is a little bit specific in terms of protocol, but in general, we want to make sure that we don't have network cards on our client.

In terms of our network configuration, verify that Client for Microsoft Networks is installed and selected under Primary Network Logon. Hit the ESC key at the first logon screen when booting clients, to prevent network log on or a Windows-validated session. Typically what can happen is, if you don't hit the ESC key when your Windows 95 client first comes up, you'll get a Windows log on. As soon as you have a Windows log on, you'll no longer be able to get validated by an NT domain.

Our next slide talks about the Identification tab of the computer. In order to get to the Configuration and Identification tabs, you need to right-click Network Neighborhood, go to Properties, and then you'll be able to configure these options.

Under Identification, you'll want the computer name to be unique, and you'll want to make sure that the workgroup name is the same as the domain name.

Additional Windows 95 configuration, if you look at the next slide, is that for Client for Microsoft Networks, you want to make sure that you've selected Log on to Windows NT domain, and you'll want the Windows NT domain name to be the same as the domain name that you're logging into.

On slide 11, this is something that you won't necessarily have to check all the time, but it is a troubleshooting place that you can go. Under the Dial-up Adapter itself, when you right-click it and go to Properties, you'll want to make sure that the protocol that you want to dial in with is selected. You may find occasionally that the protocol you want to dial in with doesn't show up, even though you have it installed. In this case, you will need to re-add that protocol, even if it already exists, so that the bindings get regenerated for the Dial-up Networking Adapter.

Our next slide shows our Windows 98 configuration, and as we go through this presentation, what you'll find is that a lot of the client-side configurations and server-side configurations are the same from protocol to protocol. So in this case, you can see in Windows 98 configuration, we still need to be concerned about hardware profiles. Make sure you have a no-network profile. And for Primary Network Logon you'll choose Client for Microsoft Networks.

Our next slide shows us that, under the Identification tab, you'll still want to have a unique computer name, and you'll still want to identify the domain name in the Workgroup area.

Our next slide, "Windows 98 Configuration," shows us that for Client for Microsoft Networks, you'll still want to select Log on to Windows NT domain, and put in the domain name under Windows NT domain.

On slide 15, again, Windows 98 configuration. You won't always have to go to this, because usually it's taken care of for you. But you'll always, if you're having trouble, want to make sure that your bindings are correct. Make sure that the protocol that you want to dial up with is also bound to your dial-up adapter.

Next is our Windows NT configuration, and this is a little bit more complicated than Windows 95 and Windows 98. When a Windows NT client first attempts to dial in to a network, a couple of things are going to happen. The first thing that is going to happen after you dial up is that it's going to want to check to see if you have a machine account. What we're assuming, in this next couple of slides, is that your NT machine does not have a machine account in the domain. So we're going to start from base, as if you had just installed the NT Workstation or NT Server.

Again, the first thing that we're going to want to make sure of is that our hardware profiles are set up so that we don't have a NIC or a network card on our machine. For identification of this machine, we'll want to make sure that the NT client is in its own workgroup, unless it already has an account in the domain. Sometimes that's true and sometimes it's not, but again, for our purposes here, we're going to assume that this NT Server is brand-new, or this NT Workstation is brand-new, and does not have a machine account.

Under the Services tab, we'll want to make sure that Remote Access Service is installed, and that it's available under the Services tab. To configure the Remote Access Service, you select Remote Access Service and hit Properties. Once you do that, you'll see a graphic like the one in the top right-hand corner of slide 18. Here we have, in this particular case, a modem, Courier V.Everything, and in order to configure Windows NT to dial up, we're going to choose the Configure button at the bottom part of the screen.

When you select the Configure button, you'll see a selection for what you want to do for that particular port, or that particular device, and for Windows NT, we're going to choose Dial out only.

On slide 19, we again see Remote Access Setup, and instead of choosing the Configure button, we're going to choose the Network button. Under the Network button, you'll see that you have the option of choosing which protocol you want to dial out with. You can choose either NetBEUI, TCP/IP, or IPX. It just depends on what protocol you're using in your environment.

On slide 20 we show you that, under your Windows NT configuration, you'll also need to have the protocol installed that you want to use for your dial-up networking adapter.

Our next slide, again, shows us the Bindings tab, and where to go to make sure that the protocol that you want to use is also bound. Now, notice that the difference here is that we didn't go to the Dial-up Adapters tab to make sure that the protocols were bound. We actually went to the Bindings tab for all services, looked under Remote Access Server Service, and made sure that the protocols were bound there.

Once the RAS components have been configured, we'll want to configure dial-up networking on the Windows NT workstation or server. When you first run dial-up networking, it's initially going to start a Telephony Dialing Wizard, and that's just going to give you options, like if you have to dial 9 to get to an outside line, or what your area code is.

Once that's occurred, you'll want to go to the Properties of the Dial-up Networking connection, and then to the Basic tab, type the name of the connection and the phone number you want to dial. Under the Server tab, choose the protocols that you want to use, and you can leave everything else as the default.

Our next slide shows us basically the procedure steps that you're going to take once you have set up the previous slide. One, you'll dial the connection, enter the name and password, as well as the domain that you want to authenticate with. Once authenticated, go to Network Properties, Identification, Change, and Join the domain. You'll only need to join the domain once.

After you've done this, you'll reboot the NT client. Notice that we have now gone from a workgroup to an NT domain environment.

Our next slide gives us just a sequence of steps that we're going to implement. After the reboot, you'll hit CTRL+ALT+DEL like normal to log on. Make sure to select the option which says Log on using Dial-up Networking. And that's important, because if you don't select that, it won't know how you're going to try to get to the domain. So make sure that you've selected Log on using Dial-up Networking.

Once you've done this, this will pop up the dial-up networking connection box, so you can dial whichever dial-up networking connection you want with any protocol that you want. These dial-up networking connections can have already been created, or you can create them during this logon session. Once connected, you'll be logged on and authenticated, as if you were connected on the network LAN.

So that's a little bit about the configuration of clients. Now let's go to the configuration of servers, and we should be on slide 25. This is just a bulleted list of what we'll be covering. We'll be covering RAS and Routing and Remote Access Service configuration.

On slide 26, we have the RAS server configuration for normal RAS. If you went to Remote Access Setup and chose Properties, you'd want to make sure that you had at least one RAS-capable device for people dialing in. On our particular slide here, not only do I have a modem, but I have two virtual private network connections as well.

Here we'll choose Configure under Remote Access Setup, Properties. And make sure that you have selected Receive calls only or Dial out and Receive calls.

Our next slide shows us the network properties for a RAS server. You'll simply hit the Network button, and under the Network button you'll see an image which gives you Server Settings. Remember that, before, all we had were dial-out protocols. Now that we're on the server side, we want to select which protocols the server will actually allow or accept. You can select any of the protocols here that you want, and later on we'll show you how to actually configure each of these protocols for dial-up.

Our next slide shows us the Routing and Remote Access Service configuration. Again, just choosing Configure, we'll be able to select what we want our RAS server to do. We can select Dial out and receive calls as a demand dial router, or Receive calls as a RAS server. You'll want to have one of those selected, at least, so that people can dial in to the particular server.

Our next slide shows us what happens when you hit the Network button. Again, this allows you to select which protocol you're going to accept for incoming connections: NetBEUI, TCP/IP, or IPX.

And that ends our general configuration options for RAS clients and RAS servers. Our next slide shows us a table of what we're going to cover in the next few slides. It's the configuration of clients and servers, but this time we're going to be protocol-specific. We're going to start off with NetBEUI, then we'll follow with IPX/SPX, and then we'll end with TCP/IP. For each of these protocols we'll show you the protocol-specific configurations for both clients and servers.

Let's go ahead and move on to our next slide. Here, the title slide for NetBEUI shows us that we're going to be heading into the NetBEUI protocol and configuration for clients and servers.

Slide 32 shows you a scenario which I set up and tested, which shows you Windows 95, 98, or NT client, dialing up to both RAS and RRAS servers where I have configured NetBEUI only. I had also, on my network, a PDC, so in these cases, the RAS and RRAS servers were not the PDC, we actually had a PDC on our internal network that had resources that could be accessed.

Let's go ahead and take a look at NetBEUI Windows 95, 98, and NT configurations. Slide 33 shows you what we're going to be covering in the next couple of slides.

Moving on to slide 34, we show you the NetBEUI specific configurations for Windows 95. All you have to do in order to make this work, is go to the Properties of the connectoid, then go to Server Types. Under the Advanced Options, you'll want to choose Log on to network, under Allowed network protocols, select NetBEUI. And that's all you'll have to do on the client side.

Our next slide shows you the NetBEUI configuration for Windows 98. It's actually the exact same as Windows 95. Not a lot of differences here. Just make sure that you've selected Log on to network, and make sure that you've selected NetBEUI as your allowed network protocol.

For Windows NT, on slide 36, once it starts up, and you use CTRL+ALT+DEL to log on like normal, once you've entered your user name, password, and domain for authentication, and selected Log on using Dial-Up Networking, you'll get the option to choose a dial-up networking connection. Just make sure that you've selected a connection that has NetBEUI installed. This particular slide just shows you what a phonebook entry would look like.

Our next slide, slide 37, shows you what an actual phonebook entry that just has NetBEUI selected looks like. So just make sure that you have NetBEUI selected under Dial-up Server Type, under the Server tab. And then once you've connected, you should be able to log on like normal.

Slide 38 shows us that we're going to break from talking about clients and start talking about servers, both RAS and Routing and Remote Access Service servers.

Moving on to slide 39, we have NetBEUI configuration for a RAS server. And under the Properties of the RAS server we'll choose Network Configuration. You may recall this particular image where we were choosing whether we would have NetBEUI or TCP/IP or IPX. Once you've actually selected NetBEUI as an allowed protocol for remote clients, choose the Configure button.

Once you choose the Configure button, you'll see that the only options for NetBEUI are to allow the NetBEUI client to access Entire network or This computer only. Naturally, if you have domain controllers that are on the network, you'll want to make sure that you've chosen Entire network so the RAS client will be authenticated.

Our next slide shows the NetBEUI configuration for Routing and Remote Access Service server. Again, this is fairly simple. You just go to the Server Settings for NetBEUI, choose the Configure button. You'll see that, again, the only options are Entire network or This computer only. Fairly simple. Not very complex.

Our next slide, slide 41, introduces NWLink as our client and server protocol. We then move on to our next slide, which shows us, again, a scenario that we've set up and tested here with Windows 95, 98, and NT running IPX only. We have a RAS and RRAS server where we're running NWLink only, and then we have a PDC on the internal network.

Let's take a look at the Windows 95 configuration, 98 configuration, and NT configuration. Slide 43 is just going to give us a client side here, and then we'll move on from there to slide 44.

NWLink for Windows 95: how do you configure it? It's actually fairly simple. Under the Properties of the connectoid, Server Types, we're going to choose Log on to network, and make sure that we have IPX/SPX selected.

Our next slide shows us NWLink for Windows 98, which again, is just making sure that, under the Properties of the connectoid, we've selected Log on to network, as well as making sure that we've selected IPX/SPX Compatible under Allowed network protocols.

For Windows NT, again, when our machine boots up, we'll hit CTRL+ALT+DEL like normal to log on, enter our user name and password, as well as for authentication. Make sure to choose the check box that says Log on using Dial-up Networking, then choose a phonebook entry that has IPX selected for its protocol.

Slide 47 shows you a phonebook entry where you have IPX/SPX compatible selected under the Server tab. Once you've dialed up with this particular phonebook entry, you'll be logged on like normal on to your network.

Slide 48 shows us that we're now going to be talking about NWLink in terms of the configuration of the servers. This is going to be a little bit more complex. We'll have a little bit more to talk about here in terms of both the RAS server and the Routing and Remote Access Service server.

Let's go ahead and move on to slide 49, where we'll talk about the configuration of NWLink for a RAS server. A couple of key points here that we need to address. The first thing that we need to address is that the RAS server must have a unique Internal Network Number. For more information on this particular item, you can look up Knowledge Base article Q198518.

The RAS server cannot be a PDC, although other servers will be okay. You can have an NT stand-alone server that's a member of the domain, or not. You can have a back-up domain controller within a domain as well. But we don't want the RAS server to be a PDC when we're using NWLink only.

During installation of NWLink and RAS, you'll be given a window, an option, which says, "Do you want to enable type 20 packets for NetBIOS Broadcast Propagation?" If you're going to have RAS clients who are dialing in with NWLink only, you'll definitely want to enable type 20 packets.

If you've only got NT clients that are dialing in, then nothing else needs to be done. However, if you have clients that are using 95 or 98, then, on the RAS server, you'll also need to edit the registry per Knowledge Base article Q173607. Basically, what that registry parameter does is tell the RAS server to make sure that any client packets are broadcast onto the LAN, and any LAN packets are broadcast onto the WAN or the RAS clients themselves.

The registry setting that you'll set for that is under the NetBIOS routing parameter, and that setting will be 7. I would caution you, though, that if you're going to do this, make sure that you're only doing this on very small networks. That's because you will be copying, basically, all of the LAN broadcast traffic onto the WAN, and a lot of WAN connections have a lot smaller bandwidth than LANs, so that you can run into some problems there.

So I would say on small networks, this registry parameter can work well for you. On large networks, you will probably want to use NetBEUI or TCP/IP in conjunction with NWLink, and not set the registry parameter for moving broadcasts onto the WAN. So just keep that in mind as you're setting up this particular configuration.

Our next slide shows us the RAS Server IPX Configuration button under Network Configuration for RAS. Just to let you know that you can leave the default that you see when you bring up the Configure button. You can allow clients to access Entire network, Allocate network numbers automatically, and Assign same network number to all IPX clients. Those are the defaults when this is installed, and that seems to work very well for us in our environment.

Our next slide talks a little bit about configurations for NWLink on a Routing and Remote Access Service server. A couple of key things. You must have a unique Internal Network Number per this Knowledge Base article, Q198518. And the RRAS server also cannot be a PDC, although other servers are okay. Other than that, there are no additional configuration parameters that you need to be concerned with.

Our next slide shows us the IPX configuration. Again, if you look at the slide here, you'll see that we can allow remote access IPX clients to access the Entire network, Allocate network numbers automatically, and Assign same network number to all IPX clients. So here we see that the RAS components themselves are not very different between RAS and Routing and Remote Access Service.

Our next slide does show us one key difference. You may recall that in the RAS server configuration of IPX, we needed to edit the registry to broadcast packets out onto our WAN. Well, on the Routing and Remote Access Service, we use the Routing and Remote Access Admin to help us in this particular configuration.

So if you open the Routing and Remote Access Admin, you'll see an IPX Routing section. Under the IPX Routing section, you'll also see an area called NetBIOS Broadcast. When you see the NetBIOS Broadcast, you'll have Interfaces, which are your default interfaces. Namely, any network cards you may have, your internal network address, as well as an area for dial-in clients.

If you right-click the Dial-In Clients, and Configure Dial-In Clients, you will see a graphic or a window like the one on the right-hand side of this slide. In this slide, you can see some of the selections that we have. In order to allow 95, 98, and NT to dial up to our RAS server, you want to select, under NetBIOS (type 20) Broadcast Packet Handling, Accept Broadcast. And in terms of delivering broadcast, you'll want to choose Only When Interface Is Up.

Again, I would caution you that you can set these selections only for small networks. If you do have a large or congested network, you'll want to use NetBEUI or TCP/IP instead of implementing this particular strategy.

Okay, good, that brings us to our last and final protocol, the TCP/IP protocol, which is on slide 54. We're on configuration for clients and servers. Our next slide shows us another example of configurations that we've done internally. This is Windows 95, 98, and NT, dialing in with TCP/IP only, connecting to RAS and RRAS servers, with TCP/IP only, and then authenticating against a domain or with a PDC on the internal network.

Slide 56 shows us what we're going to cover in this particular area. We have TCP/IP for 95, 98, and NT, and I also threw in just a little bit of information on NetBIOS name resolution, since that can be very important for us.

Slide 57 shows us the TCP/IP configuration for Windows 95. Instead of just selecting the box for TCP/IP, like we did for NetBEUI and IPX/SPX, when we select TCP/IP we have this additional box called TCP/IP Settings. Now, in truth, you can just leave the defaults for TCP/IP Settings. But I wanted to go ahead and show you what those defaults were.

Our defaults for that particular protocol are Server assigned IP address, Server assigned name server addresses, Use IP header compression, and Use default gateway on remote network. These are what we would leave, and these are the defaults that you can use.

Our next slide shows us basically the exact same thing, but with Windows 98. You'll see that the defaults are the same, and if you select TCP/IP, you can just leave the defaults as they are.

On slide 59, again, we just sort of give you the sequence of events here for log on. You would use CTRL+ALT+DEL like normal, put in the user name, password, and domain, make sure to choose the check box which says Log on using Dial-up Networking, and then choose the phonebook entry, which you knew to be configured with TCP/IP.

Slide 60 shows us what a phonebook entry would look like once it has TCP/IP selected, and you'll notice that even with TCP/IP settings here, they are the defaults, just like with Windows 95 and Windows 98. We still have Server assigned IP address, we still have Server assigned name server addresses, and you have selected Use IP header compression and Use default gateway on remote network.

So the default settings for 95, 98, and NT Workstation and NT Server, are all the same. And they can work just as with the defaults.

On slide 61, just a last little clarification. If the RAS server is able to authenticate your RAS session, your domain log on will proceed as if you are connected via a local LAN connection.

That brings us to slide 62, where I wanted to discuss NetBIOS name resolution for just a little bit. For 95 and 98 clients, when you're using WINS on your network, you're going to want to make sure that, under the Dial-Up Adapter, Properties, WINS Configuration tab, which you've clicked Use DHCP for WINS Resolution. Occasionally you'll find that Disable WINS Resolution is selected, and if that is selected, you will not be able to use WINS in your environment. So do make sure that Use DHCP for WINS Resolution is selected for your Windows 95 and 98 clients.

If you're using Windows 95 and 98 clients, and you're not using WINS, that's okay. You can use Lmhosts files for logging on and getting authenticated by your domain.

I show you here just two entries which you can use to get to your PDC. Notice that the first entry is the entry for the PDC. It has a #PRE and a #DOM entry. That's important. The second entry is a domain entry for the domain name itself, and that's the 1B entry. I've also seen, occasionally, just depending on the strategy you want to take, you could take the second line, copy it, and change the capital B to a capital C. So you'd have both a 1B entry and a 1C entry, all pointing to the primary domain controller.

Do make sure that the Lmhosts file is pointing to the first bound IP on the network card of the primary domain controller, because NetBIOS only binds to the first IP of the network interface. That's very key. If you're pointing to an IP that is third or fourth bound on a network card, you still may not be able to get authenticated, because NetBIOS isn't bound to that IP address.

Our next slide moves us from discussion of clients to discussion of servers. We'll talk a little bit about the RAS server configuration, as well as the Routing and Remote Access Service server configuration.

Slide 65 shows us a few bullets about TCP/IP and the RAS server. First, you want to allow clients to access the entire network. You'll want to configure either a RAS pool or use DHCP. If you're using a RAS pool, the easiest thing to do is make sure that the RAS pool of addresses is on the same network as your LAN card. Your pool must be in the range of the first bound IP address on any NIC on the server.

And again, this is the recommended way to do this. You can put RAS pools on networks that are their own network, but then that requires some route table additions in order to make that work. So it can be pretty problematic. Again, the recommendation for the RAS pool, if you're going to use that, is to make sure that it's on the same network as your network cards.

You also want to install a WINS server, or point to a WINS server, or let DHCP assign the WINS server to the client. Unless you are relying on the clients to have preconfigured Lmhosts files.

Slide 66 shows us our Windows configuration for Server Settings. We see TCP/IP. If you choose Configure, you'll have the option of choosing some of the things that we talked about on the previous slide. Namely, do we want clients to access the entire network, and our choice of whether we want to use the static address pool, or use DHPC to assign remote IP addresses.

Our next slide discusses TCP/IP with our Routing and Remote Access Service server. Again, most of this is the same as with RAS. We want to allow clients to access the entire network. Configure either a RAS or RRAS static pool, or use DHCP. If you're going to use a Routing and Remote Access static pool, again, the easiest thing to do is make sure that the pool of addresses is on the same network as your LAN card.

Also, make sure to use the correct mask for the range of IPs you are creating for your dial-up clients. The pool must be in the range of the first bound IP address on any NIC on the server.

What I mean here when I say, "use the correct mask," is that you're not actually defining — in the RRAS static pool — you're not actually defining a subnet mask. All you're doing is creating a mask, or an IP mask, which indicates a range of IPs that you're going to give out. So it's a little bit different from RAS, in that with RAS you could just pick 12 IPs that you wanted in the pool. Well, with RRAS, you're going to give out IPs on masked boundaries. So you'll give out 4 addresses, or 8 addresses, or 16 addresses, or 32 addresses, just depending on what mask you're using. So that's pretty important.

You'll also either want to install a WINS server, point to a WINS server, or let DHCP assign a WINS server to the clients. Unless, of course, you are relying on the clients to have a preconfigured Lmhosts file.

With NT, in terms of NetBIOS name resolution, when NT is your client, NT will either get the WINS information from the dial-up networking connection — you don't have to actually configure it to do that like you do with Windows 95 and Windows 98 — or it will use an Lmhosts file. So with NT, the reason that I didn't mention that in terms of NetBIOS name resolution, is that you don't really have a way to disable that unless you go and alter or change the bindings, and I wouldn't recommend that you do that. I would just go ahead and leave the defaults.

Let's move now to slide 68, which just shows you the TCP/IP RRAS server configuration. Just like with RAS, you have TCP/IP, which you can select, when you choose Configure. Here you can allow the clients to access the entire network. Or use DHCP or the static address pool.

On slide 69, what we're showing you here are some common error messages, which you can see in the course of doing dial-up networking. And if you're getting into more complex environments, again, you might see some of these.

Error 629, probably one of the most common errors is, "You have been disconnected from the computer you dialed. Double-click the connection to try again." This can be created by a number of different misconfigurations. What I would recommend if you see that error, or actually any of the errors that I'm going to review here, is to make sure that you've gone back and looked at both the general configuration of the clients, the specific-protocol configuration of the clients, the general configuration for the servers, and the protocol-specific configuration of the servers. You should not see any of these errors if you are following the configurations that you've seen here.

Error 633, "The port is in use or not configured for Remote Access Dial-Out." That one is pretty straightforward. That means that on your client, you haven't configured it to dial out on that particular interface. So that one is pretty easily resolved.

Error 720, "No PPP control protocols configured." We most often see this one if you have a RAS or RRAS server, and, for instance, you've selected Use DHCP to assign client's IP addresses, but you've forgotten to install a DHCP server. So then the RAS or RRAS tries to go get IP addresses, but it can't find any. It can't bind any, and therefore, when the client dials up, it's not going to be able to get an IP address. That's usually when we see that one.

These other errors — "You have been disconnected from the computer you dialed. Double-click the connection to try again." It's a fairly generic error. There could be a lot of reasons for that. You'll just, again, want to look at the general and protocol-specific configurations for that.

"Dial-up Networking cannot negotiate a compatible set of network protocols that you specified in the Server Type settings." This one, again, usually has to do with some sort of a configuration error. You want to make sure to check that out.

And then finally, another pretty common error that we see: "No domain server was available to validate your password. You may not be able to gain access to some network resources." Probably, again, one of the more common errors. Misconfiguration of any of the things that we've talked about can result in that. So if protocols connect but they can't browse to the PDC for some reason — there could be a ton of different reasons why you would see that. So I would say, again, just review that information that we've discussed, and if you have further troubles, give us a call.

Slide 70 shows you a pretty good list — it's not an all-inclusive list or an exhaustive list, but it's a pretty good list — to start from if you are having dial-up networking trouble. This particular presentation is going to be out in KB format, so you'll have a Knowledge Base article for that. Creating hardware profiles, the Readme release notes for Windows 95 and 98, how to configure Windows 95 to dial in to a RAS and RRAS server. Again, that's another article that's out there. How to create hardware profiles for laptop computers, setting the workgroup name the same as the domain name.

So if you want more information about why this is necessary, these articles may be able to go into the kind of depth that you need. Requirements for browsing across dial-up networking, name resolution for WINS/Lmhosts. That's a very good article, very thorough. NET USE attempt across domain fails without name resolution. That article will give you a description of why name resolution is important to domain authentication. Some recommended practices for WINS. You don't want to install WINS on your network so that your clients can dial up, but then configure WINS wrong in some way, and have that end up messing you up worse. So you might want to follow that "Recommended Practices."

There's an article on the internal IPX network number. That's a good description of why we actually need that, and how to configure it. Workstation using Lmhosts fails to log on if domain controller is unavailable. Another place where you might look for troubleshooting purposes. And another fairly good one is, "Erratic Domain Logon From Windows 95 Dial-Up Networking." Not only will that give you a place to start, but it will also point you to some other articles.

So that brings us to the end of the presentation. I do want to point out that there are more complex dial-up networking configurations or setups. What we did here, in this particular presentation, is just show you how clients could dial up with NetBEUI only, IPX/SPX only, or TCP/IP only. And all of these configurations were tested, so you can be assured that they work.

More complex scenarios, where you're dialing in with multiple protocols, maybe are best suited for another type of presentation like this, that may come in the future.

I'll leave it at that. I hope that was useful. And I'll try to entertain any questions that I can.

Barbara: Great. Thank you so much, Sherwood. We'll now move into the Q&A portion of the WebCast. Once again, you can submit your questions via e-mail only during this live session, using the Submit Question link. And that appears on your Web page, below the presenter's picture. So be sure and click that, to send the e-mail to us right away.

It looks like we have only one question at this time. Sherwood, a couple of times you mentioned the term "connectoid." Can you explain that a little bit more? What is a connectoid?

Sherwood: Yes. The connectoid in Windows 95 and Windows 98 is simply the icon which you use to start a dial-up networking connection. So if you double-click My Computer and then double-click Dial-up Networking, you'll come to a location where you can create new dial-up networking sessions. So in Windows 95 or in Windows 98, you could actually have a directory there that has 10, 12, 15 different little icons, all representing different dial-up networking connections.

NT Workstation and NT Server don't implement connectoids in the same way that Windows 95 and Windows 98 do. What Windows NT does is put all of those entries into one place called the Phonebook. So you won't actually see connectoids in NT like you will in Windows 95 and Windows 98. So hopefully, that better fleshes that out and is more understandable.

Barbara: Excellent. Thank you so much, Sherwood. We have a second question coming up now. Why did you say the workgroup name must match the domain name? Doesn't the dial-up networking properties contain the domain information?

Sherwood: Well, the reason that you want the workgroup name to match the domain name has to do with how browsing works. I can't really get into a tremendously deep discussion of how browsing works, but what I can say is that the reason that you want the workgroup name to be the same as the domain name is because of the way that browsing works. When you actually try to perform a domain log on, domain log ons do participate in the browsing process, so that they can find a domain controller to log on to.

So there's this whole process of, I want to log on to a domain controller. How do I find a domain controller? Well, I better go look for a domain controller. So if your Windows 95 and 98 machines are in a workgroup that is the same as the domain name, when they go out to look for a domain authentication or a domain log on, they're already in that workgroup, so they send it to that 1B entry. So when you're in the workgroup, you'll send out a domain authentication to the 1B entry, and so normal domain controllers that are in that domain can respond, and say, "Oh, I can handle that domain logon request."

If your 95 or 98 machine is in a workgroup that is different than your domain, you can end up having trouble. Because the 1Bs that you're sending out for domain authentication are getting sent to a workgroup that those other domains don't even know about.

For a better treatment of that, you might be able to find Knowledge Base articles or some other references. But that's just sort of my streamlined version of why that has to be.

Barbara: Great. Thank you, Sherwood. And a third question has come in. I use Windows 98 dial-up networking to dial into a corporate network, specifically the MS Corp. net. I am able to get authenticated okay, but name resolution to an IP address often takes quite a long while to establish. Specifically, I have trouble connecting to my mail server, which is an Exchange server. I always have to retry the connection at least once, and I suspect this may be because the host lookup takes too long. Should I put the mail server into a hosts file? Where does that go for Windows 98, and is the format the standard format that NT uses?

Sherwood: That's quite a question. Let me see if I can break that question down into a couple of mini-responses.

If you're using Exchange as your mail server, then you're — I don't know for sure, but I would suggest that you're probably using Outlook as your client. Outlook, when it's trying to find the mail server, is going to be doing host name resolution first. You are absolutely correct in that case. So a host file can help you.

If you're doing host name resolution first, you're going to look for a host file. If you don't have a host file, you'll go to a DNS server. If the DNS server is having trouble resolving the MX record, then you could, of course, have timeout issues. I don't know if that's exactly what you're encountering. A host file could definitely help you, because then you would immediately have the IP address that you want to connect to.

It sounds like that is just a name resolution problem, because it sounds like you've got domain authentication and things like that going. So yes, I would say that the host file is probably what you want to go with. The host file is in the Windows directory, and you just put the host file in there.

Make sure that if you create the host file with Notepad, that you don't leave it with the .txt extension, because it won't work for you. You just want it to be Host, period.

Barbara: All right. There are no more questions in the e-mail queue, so I would like to let you know also that the PowerPoint images may have been small, depending on your monitor resolution, or difficult to see. If that was the case, you can go to the Support Web site, where you found the description, the abstract, of this presentation, and download the PowerPoint slides. If you don't have PowerPoint, you can also download the PowerPoint viewer from the Microsoft Web site.

We have answered all the questions that were submitted. I want to thank everyone for participating in today's Support WebCast, and I do hope this information was useful to you. We hope you'll join us again in the near future. Thank you and good-bye.