Advice: 2003 Server with XP Clients

I am setting up a network with a 2003 server and 8 XP client machines for an office and decided to do it as a workgroup instead of a domain because it is only a stand alone server.

For simplicity, and because security is not that much of an issue in this very small office, I have setup a power user account with the same name and password for all clients in the workgroup (but not on the server and not administrative rights).

My question is i should only have to share the folder(s) and drive(s) they need on the server to each client and eliminate the "everyone" acct and make sure only the single designated acct i gave them has access to these mapped areas of the server right?

Any other precaution i should take? I will also migrate this from wired to wireless in about 9 months at which time security will get tighter (for obvious reasons).

This is my first setup and I want to make sure I dont miss anything.

Thanks for any help

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

keatron

Breadfan wrote:

I am setting up a network with a 2003 server and 8 XP client machines for an office and decided to do it as a workgroup instead of a domain because it is only a stand alone server.

For simplicity, and because security is not that much of an issue in this very small office, I have setup a power user account with the same name and password for all clients in the workgroup (but not on the server and not administrative rights).

I probably would've have went ahead with a domain environment.

Breadfan wrote:

My question is i should only have to share the folder(s) and drive(s) they need on the server to each client and eliminate the "everyone" acct and make sure only the single designated acct i gave them has access to these mapped areas of the server right?

This again is another reason I would've created a domain.

Breadfan wrote:

Any other precaution i should take? I will also migrate this from wired to wireless in about 9 months at which time security will get tighter (for obvious reasons).

You said that security is not a concern but it will get tighter in 9 months. This is indeed another reason you should've maybe started with a domain. You said you went with a workgroup for simplicity, but from a technical and administrative perspective, a domain would've been more simple. Also what about future growth? If your client adds 3 more users, then you're over the recommended number of clients for efficient operation in a workgroup environment (10). What kinds of applications do they use and what type of company is this?

Breadfan

well the client stations will be more like "dummy terminals" in that they are only accessing info from the server (like picture files and small word files). It's a Dentist office and they will only be retrieving xray files periodically from the server in each room.

The stations will not have internet access and wont be used for any other purpose that I know of. That is why I decided to go with workgroup versus domain. Only 2 computers will be used for other puposes and that is the 2 front desk computers.

shadown7

I would scratch the workgroup idea and go with a domain. You should always plan for the future.

TeKniques

Agreed a Domain is the way to go. Even if they are only accessing files from the server, plus you will be ready for expansion if the time ever calls. Workgroups are just a bad idea nowadays, I know because I had to work in one that had multiple sites using workgroups for network access and it was hell trying to get mapped drives to work, Unix compatability, etc.

Breadfan

rerun the network setup wizard on server 2003 and all of the clients? and then make up my own domain name?

I have never done that part before; only workgroups.

TeKniques

Breadfan wrote:

rerun the network setup wizard on server 2003 and all of the clients? and then make up my own domain name?

I have never done that part before; only workgroups.

HERE are some instructions to get you started.

Joining the clients to the domain is simple. Just go to the MyComputer properties -> Computer Name tab (Windows XP Pro) -> Change button.

Good luck!

eurotrash

here's a couple other links, for the server part and the workstation part.

sprkymrk

Pay special attention to DNS. Don't use the ISP DNS for clients, nothing will work right. Unless MS has changed it, if you allow the DCPromo process to install DNS on the server it will also get screwed up (it will think it is the king of all root servers), so set it up first. Find yourself some documentation on creating an AD domain from technet, pay attention to DNS (its the backbone of AD), and go from there.

Judd

sprkymrk wrote:

Pay special attention to DNS. Don't use the ISP DNS for clients, nothing will work right. Unless MS has changed it, if you allow the DCPromo process to install DNS on the server it will also get screwed up (it will think it is the king of all root servers), so set it up first.

I disagree on the DCPromo/DNS comment, I think for this environment and his experience that the DCPromo would be acceptable. When he creates the DHCP scope, he just needs to remember that the DC is the DNS server for the clients. He mentioned that, as for now, no workstations would have internet access; therefore using the ISP’s DNS is irrelevant.

sprkymrk

Judd wrote:

I disagree on the DCPromo/DNS comment, I think for this environment and his experience that the DCPromo would be acceptable. When he creates the DHCP scope, he just needs to remember that the DC is the DNS server for the clients. He mentioned that, as for now, no workstations would have internet access; therefore using the ISP’s DNS is irrelevant.

You're right, I forgot that for now he doesn't have Internet access. If he ever DOES open it up to Internet access, though, and he installed DNS during the DCPromo process, he will run into problems that will be tough to sort out. Unless, as I mentioned, MS has fixed that problem in W2K3.

Judd

sprkymrk wrote:

Unless, as I mentioned, MS has fixed that problem in W2K3.

I cannot comment on the W2K process, but I've had no real problems with implementing a DC using the standard DCPromo options of W2K3. You must remember to have the server connected to the internet during the DCPromo and it will not configure itself as the root name server and will instead build its list of root hints.

The best approach is to set up a forwarder using both his ISP primary and secondary DNS servers, this will eliminate each authoritative name server from sending replies back to the DC during the query process and sucking up this bandwidth. Forwarders and the key!

RussS

Some good stuff here Breadfan. Nothing much more I can add to what Keatron has alreay said except that if you want to be able to control your network/users you will only be able to do that efficiently on a domain.

sprkymrk

Judd wrote:

I cannot comment on the W2K process, but I've had no real problems with implementing a DC using the standard DCPromo options of W2K3. You must remember to have the server connected to the internet during the DCPromo and it will not configure itself as the root name server and will instead build its list of root hints.

That's good information Judd, thanks. I usually don't bring a machine online until it's fully configured and patched, but I suppose it would be simple to do everything except run DCPromo, then connect it, then run DCPromo to avoid the root server problem.

With that in mind, it still puts him in the same place of having possible DNS problems (with authenticating, Group Policy, etc.) if he uses DCpromo to install DNS. As you mentioned, he won't have problems if he never connects to the Internet. However, if he intends to do so in the future, AFTER he runs DCPromo, he will have to delete his existing root hints, load the originals, and run a few commands to fix it. Since he is not currently connected to the Internet, DCPromo will configure itself as a root DNS server.

Judd wrote:

The best approach is to set up a forwarder using both his ISP primary and secondary DNS servers, this will eliminate each authoritative name server from sending replies back to the DC during the query process and sucking up this bandwidth. Forwarders and the key!

Forwarders are pretty standard procedure in a small environment like the one in this case. However, he can't set up forwarders until he gets an ISP. The use of forwarders does not necessarily reduce bandwidth use. The use of caching DNS queries is used for that purpose, is it not?
Larger environments will make use of a split DNS structure - public and private.

Again, good info Judd, thank you.

Breadfan

after all was said and done, he decided to have someone come in and redo everything. i only had 5 hours to this one evening as a favor and he never gave me a chance to rectify the situation. Add to the fact he had his software vendor people in their screwing around with the server settings for a week and now it's messed up.

I dont really feel as though I was given a fair shake at it, and this was my first attempt at setting up a live network. It was a learning experience.

I am still running cable and creating patch cables (speaking of does anybody know a good website on horizontal wiring)? It's pretty straight forward I know but want to make sure I have everything right. I have the wall plates and will be running it under crawl space and never actually done that before but this should be good preparation for net+ and real world work

Thanks again for all of your help and advice

Judd

sprkymrk wrote:

Forwarders are pretty standard procedure in a small environment like the one in this case. However, he can't set up forwarders until he gets an ISP.

Very true.

sprkymrk wrote:

The use of forwarders does not necessarily reduce bandwidth use. The use of caching DNS queries is used for that purpose, is it not?

Yes, but you may have misread what I said.

Judd wrote:

The best approach is to set up a forwarder using both his ISP primary and secondary DNS servers, this will eliminate each authoritative name server from sending replies back to the DC during the query process and sucking up this bandwidth.

Using forwarders helps to eliminate the query/reply process of DNS without forwarders. If he didn't set up forwarders, DNS would look to its cache, if not there it would send a query to the next authoritative server, get a response with the next authoritative server, send that same reply to that server, etc. etc, until the IP is resolved and the address sent to the client, this does suck up LAN bandwidth. Setting up forwarders lets the ISP's servers handle this query/reply process utilizing their bandwidth. The DNS cache is used in both situations, but for non-routine queries, the DNS cache wouldn't be much help.

sprkymrk

sprkymrk wrote:

The use of forwarders does not necessarily reduce bandwidth use. The use of caching DNS queries is used for that purpose, is it not?

Judd wrote:

Yes, but you may have misread what I said.

Using forwarders helps to eliminate the query/reply process of DNS without forwarders. {Snipped for brevity - sprkymrk} Setting up forwarders lets the ISP's servers handle this query/reply process utilizing their bandwidth. The DNS cache is used in both situations, but for non-routine queries, the DNS cache wouldn't be much help.

10-4 Judd. Good clarification.

kalebksp

Why were you all recommending that someone with no previous experience setting up AD do it for the first time in a production environment? No offense to breadfan, but I seriously doubt that he was quite ready for that task, and at the very least should have tried it in a lab before hand.

sprkymrk

kalebksp wrote:

Why were you all recommending that someone with no previous experience setting up AD do it for the first time in a production environment? No offense to breadfan, but I seriously doubt that he was quite ready for that task, and at the very least should have tried it in a lab before hand.

If you'll notice, we didn't realize his experience level until his third post...
But thanks for the helpful input.

kalebksp

sprkymrk wrote:

If you'll notice, we didn't realize his experience level until his third post...
But thanks for the helpful input.

I know it may be a very abstract idea, but, you can look at the little bar that people list their certifications on, or you can ask them.

On a side note, I've always felt that a little "emoticon" of a hand with the middle finger raised would be quite appropriate. It would definitely express my feelings.

sprkymrk

kalebksp wrote:

On a side note, I've always felt that a little "emoticon" of a hand with the middle finger raised would be quite appropriate. It would definitely express my feelings.

Didn't mean to trip your trigger kalebksp. Please accept my apology.
sprkymrk

keatron

kalebksp wrote:

Why were you all recommending that someone with no previous experience setting up AD do it for the first time in a production environment? No offense to breadfan, but I seriously doubt that he was quite ready for that task, and at the very least should have tried it in a lab before hand.

First off, you don't push a solution off on a client based on your experience level or what you can and can't do. His question was basically what is the best solution and we answered that. I partner with several other firms for various things (like huge power management and redundancy installs). I would hope that he explained to the client up front that he didn't have any experience doing this (sounds like he did). Basically the work was a little beyond his skill level. And it's nothing to be ashamed of. Those of you who haven't been there eventually will. The only mistakes I see that you made were not readily identifying what the clients needs were (he needed a domain from the beginning) and then not stepping up to say something to the effect of "your needs surpass my areas of expertise, but I would like to bring an expert in that area in" or something like that. Remember, one of the most important parts of business is building relationships.

Breadfan, the main thing is to not let this kill your confidence and drive. Go home set up a lab, master the things we pointed out here, and just be prepared to do a better job the next time. Good luck.

Keatron

kalebksp

I agree with you keatron. I've setup various AD configurations in my own lab, but I wouldn't setup a domain for a business. Some people may not realise the amount of planning that goes into effective domain implementation and when a bunch of more experienced people are telling them what to do there is a good chance they'll follow the advice. I would hope that breadfan wouldn't be ashamed of not knowing how to setup a domain with no prior experience, it's not exactly something you learn to do over a weekend. My comment had nothing to do with breadfan. There is nothing wrong with the suggestion that a domain would be a better way to go, because it is. I just find it irresponsible to tell someone that may not even know that it is out of their current skill range to do it.

Trailerisf

Breadfan, forget all the negativity.

* Set up your sever in an Active Directory environment.
* Disable guest users and create a password for the admin account
* Create shared drives on your server ( I would reconmend a completely different partition from your O/S - its standard)
* Google search setting up an active directory -- its not too bad for a few users
You can map people's individual computers to the shared drive by right clicking the start button - then select explore - tools - map network drive
Pick an un used letter and map it to the location on the server ie: //server/home (as long as you have a folder on the "server" shared as home) You will also want to make sure you have the SHARE and NTFS permissions set properly for the folders.

I would also reconmend that you create a group called domain users. That way when you share folders, you can just add the group name rather than each individual user.

This is just a basic push in the right direction. Google search will do wonders for you.

Trailerisf

kalebksp wrote:

I agree with you keatron. I've setup various AD configurations in my own lab, but I wouldn't setup a domain for a business. Some people may not realise the amount of planning that goes into effective domain implementation and when a bunch of more experienced people are telling them what to do there is a good chance they'll follow the advice. I would hope that breadfan wouldn't be ashamed of not knowing how to setup a domain with no prior experience, it's not exactly something you learn to do over a weekend. My comment had nothing to do with breadfan. There is nothing wrong with the suggestion that a domain would be a better way to go, because it is. I just find it irresponsible to tell someone that may not even know that it is out of their current skill range to do it.

He will have less issues setting up a domain than he will trying to troubleshoot file/print sharing problems in a Workgroup. For a few users, its not all that hard.