Archive for July, 2008

Some hints in setting up a Windows 2003 Server

I’m a technology person, software engineer actually, for a small business. We ran Windows NT up until recently. The need to upgrade was based more on our old hardware. In any case, I thought I would share my experience in hopes of helping others in a similar situation.

The goal was to run Windows 2003 Server on our LAN to offer file sharing, printer sharing, and authentication (for logging in from any PC) for a small number of PCs in our office. Our LAN is behind a DSL router and a LinkSys router (see image below). The LinkSys router provides NAT, so all PCs connected to it share one IP address.

We also used Windows 2003’s DHCP and DNS and will explain why. Note that this server was not used to provide email (Exchange) or any web services. VPN access was provided, on a separate server, and that will be discussed.

I experimented with installing Windows 2003 Server several times. So I became familar with many options, although I did not try every thing possible. At first it didn’t seem very easy to set things up. But after I was successful, I think the installation is actually easier than the documentation and wizards indicate.

I started with the goal of moving our NT Domain to an Active Directory based domain. There was a new server for the new domain, so the old domain was kept running. Users were moved, one by one, to the new domain – after the new domain was setup.

Domain Controller

The first thing to note is that the Manage Your Server tool is quite useful. After installing Windows 2003 (and the service packs), you are greeted with a Manage Your Server application when you log in. Up to this point, Windows 2003 is running, but no services (called “roles”) have been installed. I installed everything from this tool. In some cases I would uninstall (remove a role) and then reinstall to try again. The tools also indicates when prerequiste services are needed and offers to install them.

NOTE: Manage Your Server provides an option to setup a server in typical fasion. I didn’t try this. It may work well, in which case the following description may be rendered less useful. I had a pretty good idea of what we needed and wanted to install just the required components.

The DNS Server should be the first thing installed. When trying to install some other services (like Active Directory) a notification that DNS is required appears. DNS is used to identify PCs on your LAN. With Windows NT, WINS performed some of this function (note there is a WINS server in Windows 2003, but DNS is really required). For a small organization DNS can be setup to provide name resolution for internal resources. For external resources (ex. microsoft.com) DNS defers to the ISP’s DNS. After installing DNS, the only thing really needed is to setup: the forwarders. These tell DNS where your ISP’s DNS servers are so that all external lookups can be performed there (see image).

Next, DHCP was installed. It is recommended to use Windows 2003’s DHCP instead of the router’s DHCP. I turned off the LinkSys router’s DHCP.

The install is pretty straight forward. But I couldn’t get client PCs to pickup some of the typical settings, such as default gateway (from the router) and WINS server. That is when I realized these are provided by the DHCP server. These items needed to be added to DHCP’s Server Options (see image).

After that, the clients worked. The network for each client was configured to work by obtaiining their address and DNS from DHCP.

Now when a client started up, it uses the Windows 2003 Server’s DHCP to get an IP address, default gateway (from the router), and IP address of our DNS server. NOTE: The server we are setting up requires a static IP address on the local LAN and that address is used for DNS and WINS servers.

Now Active Directory was installed then file sharing and print sharing. Some of those items require DNS, which was already installed. I also installed WINS in the end.

At this point I copied files over from the old domain server to the new, set up sharing and security on each user’s folder, and created new users in Active Directory. Then I changed the domain on each PC to the new domain.

VPN and RRAS

Finally, we wanted VPN access to our LAN. This is where most of the problems arose. At first, I didn’t want to dedicate an entire server to VPN, referred to as RRAS. So I installed it on the domain controller along with a second NIC, which is required. It never did work. The network requirements of a domain controller conflict with that of RRAS, and that is as technical as I will get.

Intead an old PC (866MHz) was used for the RRAS server. The second network card was installed in it. From that point on, the RRAS installation gets you close. The Manage You Server tools installed RRAS. But there were a couple of trickty things.

Basically, think of the RRAS server as another member of the internal LAN. It is a member of the domain, and must join the domain.

Also, how are the two network cards configured? The internal LAN connection needs a static IP on the internal LAN. Setup the network settings as you wou BUT, leave the default gateway blank. It turns out that only one default gateway can be allowed on a PC. The default gateway settiing from the external NIC will be used. The external connection needs to be setup with an external IP address (see network diagram above). The default gateway and DNS should be configured with the ISP’s values.

Now, external PCs can “dial” into the LAN. When conneted, via VPN, the client can only access resources on the remote LAN. They can not access the Internet. There is a workaround but it opens a potential security vulnerability. In the properties for the VPN connection, one can disable the “use default gateway” option. This is described elsewhere.

Initially, we could not access any resources on the remote LAN after the VPN connection was established. It turns out that the IP subnet for our internal LAN was often the same as remote users’ subnets. In other words, the remote LAN was using IP addresses like 192.168.1.x and so were remote users. RRAS requires different subnets. Since most home-based routers use 192.168.1.x as the default subnet, we decided to change the subnet used in the office. That meant changing the DHCP configuration only.

Winding down

All in all, the entire process of setting Windows 2003 Server with LAN capabilities for a small office is rather easy. The Manage Your Server tools does almost all the work and seems to provide good default settings. Hopefully the hints provided here make things easier for you, particularly in regards to VPN setup.

Other Useful Links:

How to setup a VPN Server

Advertisements

July 3, 2008 at 11:16 am Leave a comment


RSS Twitter Timeline

  • An error has occurred; the feed is probably down. Try again later.
July 2008
S M T W T F S
« May   Aug »
 12345
6789101112
13141516171819
20212223242526
2728293031