Real networking over "simple file sharing"

Hi, I have a question about networking. I guess I'm pretty good at normal networking (Internet Connection Sharing, file sharing, router, switches, hubs, hell, I even made my own CAT6 cables for a completely gigabit-compliant network).

But there's one area that I'm a complete n0ob. At my work, there's like 100 computers in the building and everybody "logs in" to some sort of server (i've never seen it) that is on some sort of domain. For instance, when you log in, you have to type <domain>\<user name> and then your password. They give you your user name and a temporary password, and they make you change it to whatever you like by logging in your first time.

Well, I want to do something like this for my home network, since I have like 8 different computers, as well as a stand-alone "server" computer with a large RAID array of drives (1.2TB). I try to enforce that everyone saves stuff on the server b/c it backs up automatically, yet people are reluctant to do so b/c they have personal files that they do not wish to share. So the point is a common "shared folder" is not sufficient.

At my work, they also get around this by having public folders AND private folders, where only your user name can access.

I'm wondering if anyone can tell me what OS is necessary for this (not XP pro?), and how to get a "domain" so that people can log into the server in the way I stated above. Also, if anyone knows of a good tutorial page, I'd be very thankful since every single page seems to be about "home office networking" not REAL networking.

Thanks!

Here's a quick* "Windows Networking 101" to try to answer some of your questions...

In short, you will require a domain for this to work as you want.
Computers in a workgroup are just a collection of independent, standalone clients with their own very personal view of "the world", and they do NOT trust any outside accounts (user or computer).

Because of this, you can have "John Smith" as a user on computer A and another "John Smith" on computer B - these are entirely different user accounts and can have different passwords, details, files, etc.

In order to have a degree of trust between the machines, you need a single authority that all of them trust - a domain (or "Active Directory").
With at least one domain controller, the machines can now join this concept of a unified view of the world and you can have user accounts which are trusted by all of them (the permissions for these accounts are defined at the domain or machin level).

Now, you can only have one "John Smith" as a domain user account, to ensure uniqueness, and every machine that is in the domain should be able to authenticate this user logging on - so long as the domain controller can be contacted.

Technical limitation to note here - Windows XP Professional is required to join a domain.

A machine that is a member of a domain can use local users or domain users to authenicate - in either case on a successful logon a user profile is created with specific exclusive access control rights given to this user account, so here are your private files per-user.
All flavours of Windows from 2000 upwards have these "My Documents", "My Pictures", etc you will have seen - these are stored within your user profile to keep them accessible only by you (unless you start playing with "My Shared Documents".

Private or shared folders on a file server work the same way, but specifically with domain user accounts - you can automate some of this stuff with redirected folders, roaming profiles, etc. but at the basic level the share simply has a list of domain user accounts that are permitted different levels of access to the folder.

So, as long your "server" is actually a member of the Windows Server family (Windows 2000 Server or Windows 2003 Server) then it could become a domain controller - however the client machines need to be able to join a domain also.

A domain is not just about file sharing, however, it is a very complex and powerful thing and there are courses and books dedicated to only portions of how to configure, use, extend, modify and integrate with them - so this is not a small subject.

To be honest, your problem is best solved with a method of password-protecting the files themselves, as I'm not sure if XP Home can disble "simple file sharing" (never actually played with the Home versions on networks as I only ever see corporate installs).
"Simple file sharing" basically defaults to using the Guest account on remote machines, so all the clients authenticate as the same (anonymous) user and there is no concept of individual permissions.


What you could do is share out specific folders on the server with a $ appended to the end of the name, so they are not visible when browsing the server - then have each client machine use a persistent mapping to their own shares.
It is common to have H: (for "Home") mapped to a location where users store their personal files, and a different letter (or set of letters) for common/shared folders.

So on the server your folder structure might look like:
D:\Public
D:\Funnies
D:\Users\Mary
D:\Users\Bob
D:\Users\Janet

Your shares might be set up thus, with Guest access allowed for all:
Public = D:\Public
Funnies = D:\Funnies
MarySecretShare$ = D:\Users\Mary
BobPrivateFiles$ = D:\Users\Bob
JanetsStuff$ = D:\Users\Janet

Anyone browsing to the server will only see Public and Funnies.
Mary should be logged onto a client then have H: mapped (with "reconnect at logon") to MarySecretShare$.
Similary, Bob and Janet log on and have H: persistently mapped to their unique sharenames.

This is not a secure solution of course, just a way to obscure the files that people want to be private - but it's a no-cost way you could help them a little bit immediately.


Going into a domain environment for such a tiny network might be a sledgehammer to crack a walnut, there are most likely other ways to use 3rd party apps for authentication-based file sharing.
I know that NAS boxes are becoming popular in the US, and I think some may have file synchronisation & user-based authentication built in - but I've not paid much attention to them.

(By user-based authentication I mean the user would be prompted to provide a name and password when they attempt to access a resource, rather than have it occur seamlessly with Windows authentication.)


* Okay maybe I lied about "quick", but this is the tip of a very large iceberg - even large companies don't utilise the full potential of domains
I don't know if this helped or just made things more confusing!

You can run a windows domain on everythiing ( just about ) from windows NT server upwards :)

Pauls covered a lot in his post - but as he said, it really is a huge subject.

You should be able to get hold of a 120 day evaluation version of Server 2003 , to at least have a try with building a domain , and adding users to it.

Wow! Lots to read, but I read every word :D

I think I will try the eval version of Win Server 2003 and see how I like the whole domain aspect. I know it's a big deal to run a real network, but I'm mostly wanting to do it out of curiosity b/c it
s the logical next step of skill development for me. I'm glad you guys took the time to write those posts. My only question at this point is, is this the same kind of "domain" as an Internet domain (.com, .org, .co.uk, etc.)? Does this mean that I'd have to purchase a website in addition to the server OS?

Thanks a ton!

In short no - generally an Active Directory domain name will be domain.local.

Quote:

---

Originally Posted by latrosicarius

My only question at this point is, is this the same kind of "domain" as an Internet domain (.com, .org, .co.uk, etc.)? Does this mean that I'd have to purchase a website in addition to the server OS?

---

No, a Windows "domain" is not associated with an internet domain name, you don't need to buy an internet domain name.
Though if you intended to ever host your own website and have a large internal network, this is where planning the Windows domain structure would be an important step BEFORE deploying the first domain controller (DC).

One reason being, say I register the internet domain "mydomain.com" and set up a domain controller using this same name, but on my private internal network.

Now say I have a website hosted elsewhere, accessible via http://www.mydomain.com or http://mydomain.com - these would have to resolve to public IP addresses for the outside world to see this website.

Part of Windows domain functionality is provided by the fact that every domain controller will actually have a slightly different view of what "mydomain.com" is, in terms of DNS - and they CANNOT point to the public IP address of the website.
This would mean that members of the domain would be unable to visit the website via http://mydomain.com, as they would end up talking to a DC which would simply reply with "huh?".

In your case not a big issue, but this is just to highlight the difference in the namespaces and why you shouldn't jump in and start building DCs for companies without careful planning (though MANY people do).
Not much good if your employees can't even acces the company website when the customers can.

Recommendation is not use a domain which could exist on the Internet, and typical practice is to prepend "corp." in front of the domain name for Windows' use.
e.g. the public internet domain would be "mydomain.com" and the Windows domain would be "corp.mydomain.com"

Also, don't use "single-label domains" such as "home", and don't use other companies' internet domain names.

Small Business Server defaults to a ".local" domain, but this would never be potentially connectable with the Internet to join public namespaces.

while you can name your domain with an externally reachable domain name , its generally considered not to be a good idea. As splash said , most people tend to use a .local extenstion for the active directory root domain.

You'll find out that as you build your domain , that coreect local DNS resolution is key to your active directory functioning - the fist thing my networking tutor put on the board in large letters was ( NO DNS = NO AD )


nb. if you are using wondws NT , then DNS doesn't matter as NT domains do not use DNS in the same way, they'd rather use WINS , but I dont want to over complicate the issue :)

Quote:

---

Small Business Server defaults to a ".local" domain, but this would never be potentially connectable with the Internet to join public namespaces.

---

which imo is a good thing , it does mean a few more steps ( and another DNS zone somwhere ) but its more flexible

the only case where it is a pain is when you are setting LCS SRV records in DNS :)

For what your going to use it for, would it not be better to use an ftp server or just do it with normal passworded file share?

Paul,

Quote:

---

Here's a quick* "Windows Networking 101" to try to answer some of your questions...

---

Excellent post - If you don't mind I think I'll pinch it for work, save me spending hours trying to explain it to the newbies we get every year. It can't be intern time again can it :rolleyes: :rolleyes:

Awesome, thanks so much for posting, everyone.

Just for clarification, if I want to eventually use my server for an FTP server (I don't need to do a whois--typint the IP address is fine), I should not use .local? It should be something like "ftp.xxx.xx.xx.xx" for the FTP, and something like "net.xxx.xx.xx.xx" for the local network?

(however, when I'm on the inside, I can use "ftp.localhost" & "net.localhost"?)

I appreciate your respnses, sorry for asking more info, but I'm kind of a noob when it comes to DNS stuff. Thanks!

Quote:

---

Originally Posted by latrosicarius

...if I want to eventually use my server for an FTP server (I don't need to do a whois--typint the IP address is fine), I should not use .local? It should be something like "ftp.xxx.xx.xx.xx" for the FTP, and something like "net.xxx.xx.xx.xx" for the local network?

(however, when I'm on the inside, I can use "ftp.localhost" & "net.localhost"?)

---

Right, not sure what you mean by "net.localhost", but in essence if you intend to have your server accessible from the Internet using the public IP address (which would NAT to your private server IP) then you don't need to be concerned about names or DNS at all.


The label "localhost" traditionally translates to 127.0.0.1 which is the loopback address - effectively a machine's way of saying "me" when referring to itself on the network.

The problems you run into with DNS are with internal clients, if you called your Windows domain microsoft.com for example then you could encounter problems reaching the Microsoft website because your clients would get referred to your domain controllers for the name "microsoft.com".

I have seen this problem occur with a few companies who didn't plan their AD correctly and then ask how they can get their clients to use http://mycompany.com and have it work - all to avoid typing "www." at the start.

There is nothing to stop you using the domain name blahblahblah.zzz.wooooobong.wibble if you really felt so inclined.
It would never be reachable by this name on the Internet, but it should be fine for a Windows domain.
Hell of a thing to type in when joining your domain, however.


One thing to bear in mind is that another way to authenticate against AD is to use a "Universal Principal Name", or UPN.

This is your username, followed by an @, followed by your AD DNS name.
e.g.
Domain name = wowzers.lookatme.com
NetBIOS domain name = WOWZERS
User name = BobTheMighty

Traditional logon would be WOWZERS\BobTheMighty
UPN logon would be BobTheMighty@wowzers.lookatme.com

The reason? People tend to remember email addresses more easily than domain/user combinations.


Similarly, your machine names would register in local DNS as machinename.domainname - so for a machine called HAL2000 you might have the name HAL2000.blahblahblah.zzz.wooooobong.wibble as far as your internal clients are concerned.
Then you can just use the command "ftp HAL2000.blahblahblah.zzz.wooooobong.wibble" from a client and it will resolve to that server's private IP address correctly and connect to the FTP server service.

Oh thanks, I see what you mean--localhost would only work from the server itself, not the clients in the network. What I meant by "net.xxx.x.x.xx" was a variation of what you said of "corp.domain.com", except that I am not a corperation so I just changed it up a bit.

So my thinking would be that the active directory would be "net.xxx.x.x.xx", and later when I set up the FPT site, it will be "ftp.xxx.x.x.xx". I'm not sure if this is "best practices" or not though.

Also, the xxx.x.x.xx would be the server's internal IP and due to the dynamic nature of a non-commercial ISP, the only way to access the ftp or network from outside the LAN would be to type in the current router IP address, which would port forward all incomming connections to the server's internal IP.

^ lol, I think I have it right... just thinking out loud.

Thanks again

Follow up:

Just letting you guys know that I DL'ed the 180-day trial of Win Server 2003 from microsoft.com and installed it. Setting up the server was a snap and I ended up using a domain name of:

Code:

---

homenet.local

---

So, logging in on a client PC (like I am right now), I use the following for logging onto the Active Directory:

Code:

---

homenet\<user name>

---

Just saying thanks for your help, but I do have a few more questions:

1.) It's slower to log on than normal. I know it's because it has to talk over the LAN, but it's even slower than at work, and I have a fully Gigabit (1-Gbps) network, whereas at work we only have Megabit (1-Mbps). It's not slow for accessing files, only for logging on.

2.) I can't seem to be an administrator on my client PC with the user name that I log into the server with. I know this is possible b/c I am an administrator on my work client. Furthermore, at work, the HelpDesk has the ability to remotely grant me administrative privelages on my client PC (without physically comming to my PC). I'm wondering how to do this... maybe not remotely, but at least make me an admin on my own client.

Thanks!

Quote:

---

Originally Posted by latrosicarius

1.) It's slower to log on than normal. I know it's because it has to talk over the LAN, but it's even slower than at work, and I have a fully Gigabit (1-Gbps) network, whereas at work we only have Megabit (1-Mbps). It's not slow for accessing files, only for logging on.

---

Okay, the thing with slow logons is you have to know where the delay occurs.
What I mean is the logon process from entering your credentials to having your desktop up has some key points in it - you need to describe a) where the delay occurs and b) how long it is.

1. You initially enter your credentials and the window greys out the input boxes
2. The logon window vanishes and the first status window appears
3. "Applying your user settings" (or similar, I forget the exact text) appears
4. Any logon scripts from group policies are executed
5. Any post-logon scripts on the local machine are executed
6. Your desktop is up and you are logged in

You might want to look into "userenv logging" to check the logon process and where delays are coming up, with any errors.

I would start by checking your client DNS points only to your DC, and your DNS service on the DC is forwarding DNS queries to your router/ISP - it sounds like your clients may be trying to locate their DC for authentication by first checking the Internet.

Quote:

---

Originally Posted by latrosicarius

2.) I can't seem to be an administrator on my client PC with the user name that I log into the server with. I know this is possible b/c I am an administrator on my work client. Furthermore, at work, the HelpDesk has the ability to remotely grant me administrative privelages on my client PC (without physically comming to my PC). I'm wondering how to do this... maybe not remotely, but at least make me an admin on my own client.

---

I strongly recommend against having a regular user account being an administrator of local machines, this is one of the reasons viruses and worms are so prevalent and why Windows is perceived as insecure.
You should not need admin rights for day-to-day activity - if certain apps require it then launch them with a right-click and use "run as", then give the credentials of a local (not domain) admin user.

But basically, local groups (on the client machines) can have users or groups from the domain put into them - it sounds like your work's helpdesk have rights to modify the Administrators group on the client machines, and just add your domain user on the fly.
Bad practice.

Quote:

---

Originally Posted by Paul Adams

Okay, the thing with slow logons is you have to know where the delay occurs.
What I mean is the logon process from entering your credentials to having your desktop up has some key points in it - you need to describe a) where the delay occurs and b) how long it is.

1. You initially enter your credentials and the window greys out the input boxes
2. The logon window vanishes and the first status window appears
3. "Applying your user settings" (or similar, I forget the exact text) appears
4. Any logon scripts from group policies are executed
5. Any post-logon scripts on the local machine are executed
6. Your desktop is up and you are logged in

You might want to look into "userenv logging" to check the logon process and where delays are coming up, with any errors.

I would start by checking your client DNS points only to your DC, and your DNS service on the DC is forwarding DNS queries to your router/ISP - it sounds like your clients may be trying to locate their DC for authentication by first checking the Internet.

---

You, my friend, are a genius. That was exactly the problem (it was hanging on "Applying your user settings"). I assume, it was checking out on the Internet for a domain with my domain name, and when it could not find one, it would eventually come across the internal network domain.

Well, I went into START > CONTROL PANEL > NETWORK CONNECTIONS > right-click on LOCAL AREA CONNECTION > select PROPERTIES in the dropdown list.

Then select INTERNET PROTOCOL (TCP/IP) from the list > click PROPERTIES > ADVANCED > click on the DNS tab.

Then, in the "DNS server addresses, in order of use:" box, click ADD and type in my server's IP address, which I had already staticed, both on the server itself, and in the router. (If this helps anyone else, read down to the bottom of this post, where I'll show you how to make your server's IP address static (internally to the LAN, obviously--to get a static IP for your router itself, you need to upgrade your Internet service from your ISP to a commercial line).)

Anyway, now it logs in almost instantly! Thanks!

Quote:

---

Originally Posted by Paul Adams

I strongly recommend against having a regular user account being an administrator of local machines, this is one of the reasons viruses and worms are so prevalent and why Windows is perceived as insecure.
You should not need admin rights for day-to-day activity - if certain apps require it then launch them with a right-click and use "run as", then give the credentials of a local (not domain) admin user.

But basically, local groups (on the client machines) can have users or groups from the domain put into them - it sounds like your work's helpdesk have rights to modify the Administrators group on the client machines, and just add your domain user on the fly.
Bad practice.

---

Hmm, I see what you're talking about. If a virus gets control of a user account, it will only have restricted rights, but if it gets control of an Administrator account, it will have full privelages to muck up the whole system.

I actually already found out how to make my account an Administrator before I checked your post. What I did was, log into the server domain from the client PC like normal. Then go to START > CONTROL PANEL > USER ACCOUNTS.

Now, at this point, it was a shock b/c the normal User Accounts screen had been replaced with more of a properties-page dialog interface. Anyway, there was a list called "Users for this Computer", and inside it was listed the Administrator account, the ASPNET account that gets installed when you DL the .NET Framework, and the Guest account, but not my account.

So I clicked the ADD button. It prompted for the Administrator's password so I entered it (by the way, this WILL NOT work if you have previously left your Administrator account's password blank... if that is the case, you need to log out, get into your Administrator account, and change the password... then come back). Well, lo and behold, it was a snap to just add my user name and domain; next time I logged in to the domain as usual, I was happily supprised to find myself with all Administrative privelages...

*Happy*, that is, until I read your post. I've since returned myself to a restricted User account to be more safety-minded.

I just want to say THANK YOU to everyone who helped, especially to Paul!

----------

Now, as I mentioned above, this is just for those who want to know how to "static-ize" your server's IP address, both in the server itself, and in the router.

Doing it in the server is easy, just click START > CONTROL PANEL > NETWORK CONNECTIONS > right-click on LOCAL AREA CONNECTION > select PROPERTIES in the dropdown list.

Then select INTERNET PROTOCOL (TCP/IP) from the list > click PROPERTIES. There is an option to (1) "Obtain and IP address automatically", or (2) to "Use the following IP address". Well click on the second option and... put this window to the side....

Click START > RUN > type "cmd" and press ENTER. In the DOS box, type "ipconfig" and press ENTER. You will see three numbers listed: your current "IP address", as was assigned by the router, your "subnet mask", and your "default gateway", which is your router itself.

Just copy down those three numbers and bring back up the other window that you put off to the side just a second ago. You will notice, that it also has three boxes for you to input the three numbers you just wrote down. Do so, and press OK.

Now, we must go into the router. To do this, go to Internet Explorer or Firefox, and in the address bar, enter the "default gateway" number that you just wrote down (which will typically be "192.168.0.1"). It is the IP of your router. Your router configuration page will open in your browser.

This part gets tricky b/c every router company sets the configuration page up differently, and you will probably have to go to their respective websites and find what their default password is... otherwise, you won't be able to enter the configuration page.

You are looking for a feature called "DHCP". There should be a section that says "Add Static DHCP Client", and it will list the IP addresses and MAC addresses of all the computers currently attached to it (either directly or through switches, hubs, etc.).

The general process is to find your server in the list, enter it's IP address (that you previously wrote down, in case the router rebooted and tried to assign it a different IP by now). You will also need to enter it's MAC address and optionally name it "Server", etc. Just save your settings and there you go--both your server and router have assigned a static IP to your server. As, I said before, this does not mean that your router itself, is getting a static IP from your ISP, it just means that INTERNALLY, whithin the LAN, your server will always have the same IP.

Quote:

---

Originally Posted by latrosicarius

That was exactly the problem (it was hanging on "Applying your user settings"). I assume, it was checking out on the Internet for a domain with my domain name, and when it could not find one, it would eventually come across the internal network domain.

---

And not via DNS - the Internet DNS server replies, so the client knows it is "good" for name resolution, the backup DNS server entry only gets used in the event that the first one does not respond at all (or gives an error).

In theory you could add a HOSTS entry for the DC, but DNS is not used purely for looking up the DC but for dynamic registration and location of SRV records (which for sure your router and ISP DNS servers will not support).

With Windows NT, NetBIOS & WINS were used as main methods of name resolution and computer browsing - these are now being phased out.
From Windows 2000 onwards, DNS is the primary method of name resolution as it's what the rest of the Internet uses and doesn't rely on broadcasts - NetBIOS broadcasts are the fallback method to locate machines.

So in your case the DNS queries would be sent to locate any suitable domain controller for the domain, which would get "no such name" as the response every time - then the NetBIOS broadcasts would be sent and the client just shouts on the LAN to find any logon server capable of authenticating users, and this is how the client eventually succeeds - after a timeout.

I'm not really sure what the practical reasons are for having a secondary DNS server listed on the client. Would it be to actually have two servers set up to manage Active Directory, and if one fails, the other is a carbon-copy and will pick up the slack?

If so, is there any methodology to continuously update the secondary server, when you modify the Active Directory or permissions of the primary?

All domain controllers in an active directory run DNS . If you have a backup domain controller , then specifiying it as a secondary domain controller is a good thing :)

By the sounds of it you've got some reference materials with you , and if so , have a look at the chapter on replication ( essentially it will do it all for you ! )

Quote:

---

Originally Posted by latrosicarius

I'm not really sure what the practical reasons are for having a secondary DNS server listed on the client. Would it be to actually have two servers set up to manage Active Directory, and if one fails, the other is a carbon-copy and will pick up the slack?

If so, is there any methodology to continuously update the secondary server, when you modify the Active Directory or permissions of the primary?

---

Talking completely outside of AD, primary and secondary DNS servers have been a standard way of providing high availability of a key service for years - you do not want clients and servers being unable to communicate simply because one cannot find the other due to a single server being down.

The way it works is that the client tries name queries to its first DNS server, if it gets a reply then it knows the server is up and is happy - even if the response is "I can't find that name".
If the primary DNS server does not respond in a reasonable amount of time then the secondary DNS server is queried - if it responds then it becomes the preferred name server until either it becomes non-responsive itself or the client is rebooted.


Back to AD, DNS can run as the classic service using regular replication methods as with BIND servers on the Internet, or now "AD-integrated" so the information is actually passed around between the DCs as part of normal replication along with user accounts, servers, etc.
The AD-integrated model gets away from the "single master" problem, as every DC is a peer and can modify the zone data directly then inform the others.

Quote:

---

Originally Posted by Moby-Dick

All domain controllers in an active directory run DNS . If you have a backup domain controller , then specifiying it as a secondary domain controller is a good thing :)

By the sounds of it you've got some reference materials with you , and if so , have a look at the chapter on replication ( essentially it will do it all for you ! )

---

That sounds pretty logical. I don't have any real reference books or anything (I didn't have a clue about anything more than simple network sharing before this thread), but I will definitly look up Replication. It would be more for curiosity, since there's no way I could actually afford another server right now, since it's just for home use. Thanks for the info though--it really helps to know what terms to search for, like "replication" when I'm trying to make things work.

Quote:

---

Originally Posted by Paul Adams

Talking completely outside of AD, primary and secondary DNS servers have been a standard way of providing high availability of a key service for years - you do not want clients and servers being unable to communicate simply because one cannot find the other due to a single server being down.

The way it works is that the client tries name queries to its first DNS server, if it gets a reply then it knows the server is up and is happy - even if the response is "I can't find that name".
If the primary DNS server does not respond in a reasonable amount of time then the secondary DNS server is queried - if it responds then it becomes the preferred name server until either it becomes non-responsive itself or the client is rebooted.


Back to AD, DNS can run as the classic service using regular replication methods as with BIND servers on the Internet, or now "AD-integrated" so the information is actually passed around between the DCs as part of normal replication along with user accounts, servers, etc.
The AD-integrated model gets away from the "single master" problem, as every DC is a peer and can modify the zone data directly then inform the others.

---

From an infrastructure architect's point of view, what do you guys think would be the most logical way of designing a network? My thinking is you would have two machines that are identical ("replication", or whatever), whose only roles are DNS+AD.

Then there would be two more machines that each have a RAID controller card with lots of drives in a RAID-5 or 6 array, the only roles for them would be file sharing, but clients would only use one at a time, and the other would just Replicate the primary one. So if one goes down, the client's would still have access to their files.

And all this would probably have to be IN ADDITION to offline backup. I've never used tape backup, but I bet it's very slow :/ .... I'd almost prefer another array of hard drives that are powered down at all times, except when performing nightly backups.

Also, I'm told NTFS volumes currently have to be under 2TB or else you need a special OS. Therefore, if it was a real big business's network, you'd need multiple volumes. This gets into issues such as directory organization, public shares vs. inividual private user shares, etc. I wonder how you can split this up... if you just have each file sharing server acting as a client to the DNS+AD server, which routes all requests from workstations for files to the appropriate shared folder.

Depending on the number of volumes you have, you'd almost have to use tape backup versus hard drives :(
----
EDIT: wait! 172 gigs of tape backup for only $700 bucks?? I could get a 300GB hard drive for only $120 bucks... never mind tape backup lol... http://www.exabyte.com/
----

As far as the FTP, web, or streaming media roles, I'm not sure whether they should idealy get their own servers, or be grouped in with the file servers.

file server replication is a different kettle of fish - its possible , but not nessesarily in the way you are thinking of.

Active directory only replicates the directory itself , which contains all the user accounts , printers etc, ( and DNS if its AD integrated )

There is a way of replicating files around an active directory , its call DFS or ditributed filing system , but its not really designed for files that are to be changed by many people.

AD replication when you have slow network links can make things...interesting ( to give you an idea , our AD at work has a little over 500 domain controllers each connected via an ADSL speed link. )

it depends on the size of files you are dealing with , our mail file servers have much less than 2Tb storage , but we dont always deal with a huge ammount of data centrally.

tape backup is gewtting better , some of the new drives can back up a good ammount overnight.

in a large scale network , you'd probaby make use of a SAN ( Storage Area Network )

hope this gives you more food for thought :)

Hmm, okay thanks. I'm guessing you would rig up a SAN as a subdomain on your main domain? i.e.: if your AD+DNS server is on "homenet.local", your SAN file servers would be on something like "san.homenet.local"? I should look it up more--I still don't quite know the difference between SAN and NAS.

a SAN (storage area network ) is a complete network designed for just storage , its usually seperate from your conventional network.


two main flavours , FIBRE and iSCSI. Fibre uses optical fibre to connect the disk arrays to the servers , and iSCSI uses Gigabit ethernet.

The servers access the SAN resources as if they were a local disk. At the SAN management end of things , you can present a certian subset of your disk "pool" to a given server , so only that server sees those particular virtual discs.

a NAS is not quite the same , its just a disk share accessable over LAN ( at its most basic ) You'd map a drive to like like any other network resource.

SAN's dont use TCP/IP in the same way , so wouldn't be referenced with a DNS name.

That's very interesting, I'll check it out. I love this kind of IT theory stuff, thanks :-P

BTW, I'll add my network pics to the sticky thread soon. hehe

Moby's got the SAN/NAS thing down to pat as well as replication - one very common use of a SAN is to have clustered servers hooked up to them to access a common set of files (with exclusive access).
This provides high availability of the files, as if an active cluster node goes down or has a problem then the other one takes over the role in as much time as it takes to stop the service (if the first node is still alive) and start it up on the other node.

With volume mount points you can effectively extend storage over and over without a real restriction on space or drive letters.
Though I don't know how secure I would feel having THAT much storage in one place - in terms of "all your eggs in one basket" and also how the hell to back it up (in a reasonable amount of time too).

You are also pretty much spot-on in that DCs should be DCs and nada else - don't try to shoe-horn in SQL Server, Exchange, Live Communication Server, IIS, file sharing, printer serving, etc. onto them.

Personally I would separate and group servers based on their role and what types of clients needed to access them.
Public-facing web/FTP servers would go into a DMZ with a dirty side and a clean side.
Internal servers I would be tempted to put behind a firewall even from the client LAN, so I know the access to them can be controlled and monitored with an Intrusion Detection System (IDS).
If not firewalled, then at least VLAN'd to keep the broadcast chatter down.

AD & DNS go hand-in-hand so they are fine on the same box, DHCP I would either cluster or have in a 60/40 setup (one server handles 60% of the scope, the other 40% in case of failure of one).
For FTP & web (including WSUS) it makes sense to bundle together, load-balanced rather than clustered (check out NLBS) - possibly with an SMTP gateway if needed too.
File & printer sharing are commonly bundled together too - again with clustering to provide the uptime and allow maintenance on the fly.
SQL and Exchange most definitely want their own boxes, and again are commonly clustered as they are so commonly key services.

File replication (FRS) is typically used for servers in different sites connected by a WAN, so the clients can get a local copy of the files without having to drag them over a high-latency low-bandwidth connection.
FRS is the backbone of DFS and yes, it is not meant for frequently-changing files as you can't really devise an algorithm that doesn't end up being "last writer wins" for copies of a file in multiple locations available for editing.

One often-overlooked technology is the Volume Shadow Copy service - the ability to have versions of files effectively backed up for immediate reference at synchronisation points during the day.
Saves getting those backup tapes out when George from Accounts wants the Excel spreadsheet from last week that he just overwrote by mistake.


All this, and you are still at the tip of the Windows iceberg ;)

Wow, Paul... I knew I was just on the tip, but I didn't know how small the tip actually was :P

I really like the idea of Volume Shadow Copy... it might be an effective way to backup my files without interruption.

What's also a really cool idea (to me at least) is separating out the clients, the file+printer servers, & the servers dealing with external stuff (IIS, SQL, VPN(?), Exchange), all into separate "sub" LANs. This is the stuff I'm talkin' about! Sounds like an awesome way to tweak the network's performance by cutting down on cross chatter like you said. I assume, each sub LAN will idealy need it's own DNS server (and secondary backup) to point the clients out of the sub LAN and into main domain so they can find the AD server(s)?

In terms of Volume Mount Points, this seems like a good idea, especially if the network ever really needs to expand the space on it's public folder (possibly for a video content server). Then, the right way to backup would probably be to have the same number of drives being Shadow Copied to another file server as a backup.

Alas, too bad I don't have an infinite source of funding! I would totally set up a real Pro network for just like 2 clients LOL! The one thing I wouldn't use, though is Exchange--I MUCH prefer webmail (particularly Gmail) to any POP service with a client program (i.e: Outlook). Outlook is useful for its calendar, but Firefox has great extensions that take care of that. hehe.

Why do you guys know so much about this? Are you real IT guys, or do you just enjoy doing it for home use?

Quote:

---

Originally Posted by latrosicarius

I really like the idea of Volume Shadow Copy... it might be an effective way to backup my files without interruption.?

---

Two main functions of shadow copies are:
i. instant access to previous "snapshotted" versions of files
ii. ability to backup open files, for NTBackup or 3rd party backup tools

Quote:

---

Originally Posted by latrosicarius

Sounds like an awesome way to tweak the network's performance by cutting down on cross chatter like you said. I assume, each sub LAN will idealy need it's own DNS server (and secondary backup) to point the clients out of the sub LAN and into main domain so they can find the AD server(s)?

---

Performance is debatable, although if you get a saturated switch due to very busy servers connected to it then you can notice an improvement - typically I would recommend it for security more than anything, reducing the attack surface.

Quote:

---

Originally Posted by latrosicarius

Then, the right way to backup would probably be to have the same number of drives being Shadow Copied to another file server as a backup.

---

But the advantage of tapes is that you can have multiple backups, on a grandfather-father-son system - mirroring to a single set of disks gives only high availability rather than a proper backup.

Quote:

---

Originally Posted by latrosicarius

Why do you guys know so much about this? Are you real IT guys, or do you just enjoy doing it for home use?

---

Moby-Dick is a very talented guy, very knowledgable about a broad range of IT topics and has "real world" experience of applying that knowledge - so much better than theory.

Me, I just work for Microsoft ;)
Before I started here I worked as an IT Security Analyst in a bank.

:blush:

I just tinker about with PC's ;)

using exchange for POP mail is rather like using a Forumla 1 race car to drive down to the shops for a pint of milk :)

Exchange can run a web mail interface as good as , if not better than gmail , and also provides functionality for mobile devices ( push mail in a blackberryesque style ! )

We keep our core servers in their own vlan as we can run that as a gigabit network so that intra-server communications are pretty quick ( that core itself is split between a couple of buildings to give us a little bit of contingency ) Oddly enough our external facing servers are only for receiving mail. We colocate our web servers at a 3rd party site. each VLAN doesn't need its own DC / DNS node , just as long as there is a low ( routing ) cost , high speed route to one , its pretty happy most of the time :)

If you don't want to go to the expense of buyong a server 2003 license, and any client access licenses you may need, you can set up a Linux box as a SAMBA server, which will act likr a Windows Domain controller.

Its not something I have done myself (set up a domain controller) although I do use SAMBA on a mixed linux/windows network with shared and central filestores on the linux server, which may be sufficient for your needs..

To get everything you want, File Shareing and Printer Sharing & Spooling, and Scheduled Backups, and an Email Server (Exchange), a home web portal (SharePoint), and Shadow Copies, (great feature, I have 3 teenage daughters and it has recovered 'lost and damaged' homework in a trice without any drama or tears, DNS server, DHCP server (or use your router) and a lot more, that is EASY to set-up and configure, and has a good support community, will run happily on a machine with 1GB RAM, then you should definitely consider Windows Server 2003 Small Business Edition (SBS) as mentioned earlier in the thread. You get a full proper, secure, reliable, easily managed AD in a box with all the bits you will probably ever need. The extended version also adds SQL Server and ISA Server... but I have the Standard version, and am happy with it.

It is what I run at home, and it works pretty well, I have secure access to my email from anywhere via OWA (but I do use very strong passwords). I run a RAID 1 - Mirror just in case of HD failure.

It too is available as a 30/60 day trial (180 day is you have access to MSDN) and is actually a pretty good product from Microsoft....... Worth a look and a 'play' I suggest.

Quote:

---

Originally Posted by peterb

If you don't want to go to the expense of buyong a server 2003 license, and any client access licenses you may need, you can set up a Linux box as a SAMBA server, which will act likr a Windows Domain controller.

Its not something I have done myself (set up a domain controller) although I do use SAMBA on a mixed linux/windows network with shared and central filestores on the linux server, which may be sufficient for your needs..

---

Linux and samba are fine if you just want it to have a few SMB shares. Anything more and you're asking for disaster.
I used to have a linux zealot for a boss that did this setup in several places and it caused constant problems, all of which he blamed on microsoft :rolleyes:
The pillock didn't know his arse from his elbow and weas an embarrasment to the IT profession. I hope he dies in an electrical accident involving a toaster running embedded linux and a fork.

Paul, Moby, lol that's awesome. Keep up the good work!

Hey Peterb, Badass, that Linux idea is appealing for a low-cost solution for DNS, although it's probably not intended for the professional environment.

EtheAv8r, I'll definitly look into the Standard edition when my 180-day trial expires. Right now it's the Enterprise edition, but it's good to know that you can easily get by on less features.

One thing I want to warn you about is my bad experience with RAID-1. True, it's great in case one drive breaks, but if the drive's have lasted past the first few weeks without problems, they will probably last you another 5 years just fine.

However, built-in RAID controllers are VERY prone to screwing up, if the power goes out or something. this has happened to me and my friends over five times in the last three years, and I have since given up. Now, if I'm going to use RAID, it's RAID-0, 5, or 6 (on a HARDWARE add-in card) due to the performance and space increase over RAID-1, and I ALWAYS backup on a separate hard drive that can be turned OFF or unplugged.

I don't worry about my master drive, that I frequently RAID-0 b/c I can always reformat, but I save all my personal files in two places (slave & backup)