Interesting Question.
Historically, prior to the advent of fully switched networks, the main consideration to breaking a network into subnets had to do with limiting the number of nodes in a single collision domain. That is, if you had too many nodes, your network performance would reach a peak and eventually would collapse under heavy load due to excessive collisions. The exact number of nodes that could be deployed depended on lots of factors, but generally speaking you could not regularly load the collision domain much beyond 50% of the total bandwidth available and still have the network be stable all the time. 50 nodes on the network was a lot nodes in those days. With heavy use users, you might have topped out at 20 or 30 nodes before needing to start subnetting things.
Of course, with fully switched full-duplex subnets, collisions are not a concern anymore and assuming typical desktop type users, you can typically deploy hundreds of nodes in a single subnet without any issues at all. Having lots of broadcast traffic, as other answers have alluded to, might be a concern depending on what protocols/applications you are running on the network. However, understand that subnetting a network does not necessarily help you with your broadcast traffic concerns. Many of the protocols use broadcasting for a reason - that is, when all the nodes on network actually need to see such traffic to implement the application level feature(s) desired. Simply subnetting the network doesn't actually buy you anything if the broadcasted packet is also going to need to forwarded over to the other subnet and broadcasted out again. In fact, that actually adds extra traffic (and latency) to both subnets if you think this through.
Generally speaking, today, the main reasons for subnetting networks has much more to do with organizational, administrative and security boundary considerations than anything else.
The original question asks for measurable metrics that trigger subnetting considerations. I am not sure there are any in terms of specific numbers. This is going to depend dramatically on the 'applications' involved and I don't think there is really any trigger points that would generally apply.
Relative to rules of thumbs in planning out subnets:
- Consider subnets for each different organizational departments/divisions, especially as they get to be non-trivial (50+ nodes!?) in size.
- Consider subnets for groups of nodes/users using a common application set that is distinct from other users or node types (Developers, VoIP Devices, manufacturing floor)
- Consider subnets for groups of users that have differing security requirements (securing the accounting department, Securing Wifi)
- Consider subnets from a virus outbreak, security breach and damage containment perspective. How many nodes get exposed/breached - what is an acceptable exposure level for your organization? This consideration assumes restrictive routing (firewall) rules between subnets.
With all that said, adding subnets adds some level of administrative overhead and potentially causes problems relative to running out of node addresses in one subnet and having too many left in another pool, etc. The routing and firewall setups and placement of common servers in the network and such get more involved, that kind of thing. Certainly, each subnet should have a reason for existing that outweighs the overhead of maintaining the more sophisticated logical topology.
re: "How can we allow our partner to login to our AD, but prevent them from accessing any other servers except for the ones on the site?"
I'd strongly encourage you to create an AD forest expressly for the JV resources. Create one-way intransitive forest trusts with the JV members' existing AD infrastructures. Using selective DNS forwarding, maintain the DNS for the JV in a secure AD integrated DNS zone hosted by JV servers. This keeps the partner at "arms length" from your own servers. Both partners should be explicitly placing shared data / applications / servers into the shared area. Using your existing AD for the "shared area" may save you a little money on licensing, but it's not worth the added risk and complexity.
re: "How can we set this up so that each partner's respective IT departments can manage the local workstations without any admin privileges on our AD?" and "Currently, we are working from the network diagram below. Using VLANs we can prevent each JV partner from traversing the others' VPN link and still allow access to the shared resources, but this setup does not allow each joint venture partner to manage their own workstations and users."
I'm not sure I understand. I see what you're saying re: isolating network traffic from the JV members, but I'm not following the rest. Are the JV members going to have user and computer accounts in their own AD forests, or in the JV forest? That's unclear to me. I'd have the JV members maintain their user and computer accounts in their own AD forests, and grant access to JV shared resources though membership in groups in the JV AD forest.
Ohh! I think I'm getting it. At this "site" there will be some client computers that are shared by the users from both JV members working together! Am I right?
You could handle those "shared" computers a number of different ways.
I'd probably join the computers to the JV AD domain, but you might not. The ownership of the client computers would probably dictate how I'd handle that. If the client computers remains with each JV member then I think I'd join them to the owning JV member's AD domain.
With client computers joined to the JV AD domain user accounts from either JV member domain (as well as the JV AD domain itself) could be used to logon to the client computers (since there would be trust relationships in place from the JV AD forest to the members' AD forests).
Be aware that it would be helpful to have read-only domain controllers from each members' AD forest in place at the "shared site". If the client computers ared joined to the JV AD forest computer group policy will come from the JV AD forest. User group policy would come from the members' AD forests, though, so having a local DC would be helpful. If the client computers are joined to the members' AD forests then, obviously, having a local DC from each members' forest would be nice.
Delegation of control in the JV AD forest can be used to give the JV members' IT staff any abilities they need in the JV AD forest itself. Group policy "Restricted Groups" could be used to grant JV members' IT staff administrative rights over "their" client computers that are joined to the JV AD domain. (Client computers that remain in the members' AD forests are a moot point.)
re: "Setting up a 2-way trust between the JV partners and allowing each partner to manage their own users and machines. What are the pluses and minuses to this? How far does this trust extend?" and "Creating a new domain and setting up 1-way trusts from each of the original domains. What are the pluses and minuses to this?"
A Windows "trust relationship" does not grant access to anything, per se. Look at this statement: "Domain A trusts domain B."
Now, replace the word "trusts" with the phrase "is permitted to name in permissions users, groups, and computers from": "Domain A is permitted to name in permissions users, groups, and computers from domain B."
A "trust" doesn't grant access, it permits you the ability to grant access. If you have a dedicated JV AD forest you'll want it to have external intransitive 1-way trusts with the JV members' AD forests so that users and groups from the JV members' forest can be named in permissions or joined to groups in the JV AD forest. This would allow the user and computer accounts for each JV member to be managed in that member's own AD forest. By using groups that are located in the JV AD forest to control permissions to JV resources the JV could effectively manage permission to access JV resources.
You wouldn't want a 2-way trust in any circmstance, from my understanding of your situation. Am I correct in thinking that it is not mutually desirable for either JV member to name the users, groups, or computers from the other member in permissions? It sounds like there aren't going to be shared resources hosted on servers owned by both JV members, so mutual trust isn't necessary. Having said that, again, a 2-way trust only permits the capbility of granting access and does not actually grant any access.
I have some experience with a similar project a few years ago between a local hosptical association and several groups of doctors. In their case, they created a dedicated AD forest for the JV, but didn't create trust relationships to the existing JV members' infrastructures. We ended up with duplicate credentials in both the JV members' local AD and the JV AD. That was the biggest "wart" that I saw in their network, and something I'd avoid in the future.
I see that you're in construction. I have a Customer who does contact engineering and project management for large-scale constructions projects and often has employees located in field offices (aka "trailers") on Customer sites for years at a time. I have yet to have a situation where the Customer or another contractor on the project go to the level of detail that you're looking for, but the situation I outlined above would be how I'd pursue it if it did happen. The expense of a few Windows Server licenses and computers to host domain controllers for the JV AD (and members' on-site read-only DCs) isn't much amortized over 4 years, and creates a very solid foundation upon which to conduct shared operations.
Best Answer
Please don't take offense to this but I strongly suggest you bring in a local area IT consulting firm that specializes in systems and network administration. I also came from a programming background many moons ago and learned many hard lessons on the do's and don'ts of managing a networked server environment. I (thankfully) had alot of mentors and help over the years, because without it, who knows what kind of smoldering wreckage would be left behind.
Moving right along now to your original question: I see two mistakes, one being Linux: don't get me wrong, I love Linux and use it in all kinds of various roles, but as a sole server in a small company that (again, no offense) doesn't have a full-time sysadmin is asking for trouble. Finding competent Linux administrators (and it's even harder to find ones that follow best practices) is not easy. Down the road, if you leave or you hire a new person to take over your duties, who's going to look after it?
Assuming you're under 75 end-users, I would strongly recommend Microsoft Small Business Server 2011 Standard on solid tier-1 hardware (like Dell, HP, IBM) with a 3-year on-site/4-hour replacement warranty. Have at least a RAID 1 mirrored array for the data (and another for the system if you can afford it). Get at least 8GB of RAM, 12GB is better. Invest in an offline/off-site backup: you can start with a couple of external drives or a tape drive, but something you can take off-site with you every night.
I'm also not sold on your suggestion for a custom "all-in-one" database: there are so many better, more viable software options out there, that unless you have some very specific niche requirements that only a custom solution can provide, you'd be much better off using a well-supported 3rd-party offering. You have to resist the "I can write something" programmer urges and think about supporting this solution long-term.
And finally, I think you and your employer need to decide what you role is going to be at this company. It sounds like you're new there and while you're right, they likely do need to upgrade their systems, you don't want to bite off more than you can chew and fail to provide whatever it was that you were hired there to do.
EDIT
There's a lot of opinions floating around right now, so I'm going to take a step back and hopefully provide some platform-agnostic advice that will be of use to you regardless of what you end up going with:
Do a complete inventory of all systems and devices; check warranty status of hardware (if it's a Dell, IBM, etc. you should be able use the service tag to get a warranty check; if it's a white box server, they may still have some sort of identifier, but you'll have to call to find out what the status is most likely).
Do a complete inventory of data: Don't trust that they have no data on their C: drives; they probably do, actually they probably have PST files all over the place of old mail. Find out what's critical, what's being backed up, what's not being backed up, how it's being backed up and whether anything is taken off-site or not. FIX THIS FIRST. RIGHT NOW. If they have no backup setup, go buy an external USB drive at a Big Box store for now and use NTBackup (it's likely on that server already) and do a full backup and take it off-site with you. If they have backup in place, go do a test restore (see below).
Check patch levels on all systems (get #2 sorted out first!): not just Windows Updates, but Java and all Adobe products especially and update accordingly (might want to do #4 first so you know what machines are higher-priority than others. i.e. that workstation for the part-time staff member could stand a botched update much more than the accountant who cuts the pay checks).
Talk to your users: find out what's working well, what's not working, get a feel for everyone's level of change tolerance, their comfort level with IT (you may be recruiting a helper to get things in order), and any wish lists they may have. Understand their business processes; as a sysadmin, your priority should be ensuring that the systems the business depends on to function are working in good order and to do that, you need to know how everyone uses those systems.
After #1, you should have an idea of how the network's setup. Look for any old hubs that can be replaced; you'll want at least 10/100 everywhere, switch-wise. Check the firewall/router (make sure there is one), check for any open wi-fi access points, etc.
If you do go the Linux route, stick with a distro that's well-supported by the community (Ubuntu would be a good choice) and set it up on whatever hardware you can afford (as you know, a LAMP box could be an off-lease P4 workstation for now) and as isolated from the currently-working system as possible. As a learning exercise (and could pay huge dividends in a disaster recovery scenario), try to get the core applications that are running on the current server working on another Windows box first -- use your full backup you did in #2 to do a test restore; have fun with that :)
As for your test setup, you can opt to buy something beefy with lots of RAM and then you can virtualize (ESXi is free, so is XenServer, so is VirtualBox) but if the current server is Windows 2003 or older, you can likely get that FoxPro application working on an off-lease Windows XP workstation for cheap.
Now pat yourself on the back; you now have good backups; you also did a test restore and now have a better understanding of how everything works together. You also likely have a (long) priority TODO list that'll keep you busy for the foreseeable future.
Oh and when that's all done, you now have a test environment you can start building your Utopian "dream" system... or maybe take a vacation :)