Workgroup & Domain... Peaceful Coexistence

[Guest]

We have a workgroup that meets the modest networking needs of our 3-person
company; it works and is dependable. We share three printers/fax among three
work areas and each work area has two computers. This work group accesses
the Internet through a router with a fixed IP on business-class service from
our cable ISP provider.

We have installed a domain with three servers (AD, SQLSvr2K, WebServer)
where we are experimenting and exploring ways to increase the level of our
technical skills and ways to serve our clients (we do non-IT consulting, but
our clients are impressed when we can show some sophistication in our service
delivery). This developmental domain resides behind a second router with its
own fixed IP. We'd like to share the workgroup printers with the development
domain server. There is also a scanner in this development environment
(domain) and we'd like to drop files from the scanner into a shared workgroup
folder.

- Is there an accepted topology for these two networks to collaborate and
share resources?
- The domain server (Server 2003 Ent Edition) has two network ports, so we
could make a direct connection to a workgroup switch, but we're not sure what
that means for network stability, security, or performance.
- For now, we really don't want to join everyone to the domain since we are
experimenting with capabilities that may require us to uninstall/reinstall a
server operating system or otherwise adversely affect server performance.

Thanks for any insights you can offer or any suggestions for research leads.
We're like that TV ad, "We're a small business; we don't have IT guys."
Thanks for bringing things down to our level.

 

[Phillip Windell]

I appologize in advance if I ramble a bit. I'm not sure enough of what you
are actually doing and why,...but I'm trying to give you things to think
about in the following post. Maybe I can help more once I know more.

delivery). This developmental domain resides behind a second router with its
own fixed IP.

Define "router" in your context. Now-a-days, unfortunately, what many
people call a "router" is really an "internet-sharing-nat-device" and not a
real router. NAT devices should never be inside a LAN or between two
LANs,..they belong only at the edge. If you are using a real LAN Router then
there is no such thing as "behind" or "in front of" so I have no way to know
what you really mean. You should not be running two subnets (networks) with
such a small system. There is no benefit. Run one single network with a
single address range.

We'd like to share the workgroup printers with the development
domain server. There is also a scanner in this development environment
(domain) and we'd like to drop files from the scanner into a shared workgroup
folder.

These are the kind of things Domains are designed for. Ditch the workgroup.
Join all the machines to the Domain. If the "test" Domain isn't sutable,
then build the "real" one and don't waste your time trying to make a "test"
Domain function with a Workgroup which is a big hassle when all you have to
do is create the real Domain and forget it.

- Is there an accepted topology for these two networks to collaborate and
share resources?

Domains have no relationship to Topology. You are comparing "apples and
oranges". Topology has to do with connectivity and you must have
connectivity in the first place whether you have a Domain or not,...on the
other hand if you have a Domain you would already have to have connectivity
in the first place. So you don't have "two networks",...you only have one
network that has both a Domain and a Workgroup living on it.

- The domain server (Server 2003 Ent Edition) has two network ports, so we
could make a direct connection to a workgroup switch, but we're not sure what
that means for network stability, security, or performance.

There is no such thing technically as a "workgroup switch",...switches have
nothing to do with "workgroups". Switches are just switches and topology is
just topology,...if you ran all Linux machines instead of Windows you
wouldn't even have a Workgroup or a Domain,..so think that through,...
understanding the terminology and what relates to what is really
important,..I'm not just trying to be "picky" with you.

More,...Never put two NICs in a Domain Controller unless you really
understand exactly what you are doing because there are a lot of things just
itching to bit you in the rear.

272294 - Active Directory Communication Fails on Multihomed Domain
Controllers
http://support.microsoft.com/default.aspx?scid=kb;en-us;272294

191611 - Symptoms of Multihomed Browsers
http://support.microsoft.com/default.aspx?scid=kb;EN-US;191611

- For now, we really don't want to join everyone to the domain since we are
experimenting with capabilities that may require us to uninstall/reinstall a
server operating system or otherwise adversely affect server performance.

You should join them anyway. It only takes a few seconds plus a reboot to
join them,..the same to unjoin them,..the same to re-join them. It ain't
worth worrying about, so just join them.

You can still log into the machine with the local account (third line is
machine name) and they will continue behave just as they did in the
workgroup. You don't have to use the Domain User Account for anything if you
don't want to, until the domain is permanent. But that leaves you with the
same hassels of the workgroup that you had to start with. I think you are
searching for a "middle ground" that just simply doesn't exist. You are
either using a Worlgroup model or a Domain model, you can't use both.

 

[Guest]

Thanks for the response.... I think you have correctly described how we are
trying to find a middle path. Here's a little more clarity about our efforts.

- We have one cable service (obviously) and a switch inside the cable modem.
From this switch, are two "routers" (Linksys BEFSX41's). Having two NAT
devices with firewalls active, we now lease 2 fixed IP addresses, each router
has its own, unique IP address, and we effectively operate two independent
local networks.

- Why do that? Well, on one side we are operating our normal business ops
in a workgroup in one LAN, and in the other side we have installed three
servers... our test environment...
- Server 2003 Ent Ed (the DC)
- Server 2003 Std (running SharePoint Portal Server, SQL2000 and
potentially Exchange Server)
- Server 2003 Web Ed
Our goal is to build an extranet capability with which we can impress
clients with team sites and other web-enabled capabilities. There is a steep
learning curve in this for us and we are cautious not to interrupt current
work with some SNAFU created in our test environment.

- True, we could just "join the domain," by switching machines to the
appropriate router and changing the computer ID. If the domain became
problematic because of our learning efforts, we could log-on to the local
machine or kick back to a workgroup.

- Even if we do that, having two networks and two IP's enables us to
replicate the experience the extranet client will have when coming to us from
the Internet. That's an advantage in our test environment. We could keep a
single machine on the second router to accomplish this test activity.

Before we give up on our "middle path," we have contemplated using the
second NIC (on our entry level server, Intel S875WP1-E board) to the DMZ side
of the router that terminates the LAN with the workgroup. I think this could
instigate the multihomed browser issue you pointed out. We tried it
previously and could view two networks from within the domain. It took a
very long time to open a shared folder in a workgroup computer from a domain
machine. However, the DC was able to serve as a printer server for machines
in the domain and print to a network printer and the workgrouped machines
could print to the same printer without being in the domain.

Thanks for your insights.

Best regards,

John

 

[Phillip Windell]

- We have one cable service (obviously) and a switch inside the cable modem.
From this switch, are two "routers" (Linksys BEFSX41's). Having two NAT
devices with firewalls active, we now lease 2 fixed IP addresses, each router
has its own, unique IP address, and we effectively operate two independent
local networks.

Ok, I think I'm seeing what you have:
1. Single Internet connection with two Public IP#s
2. Two Lynksys NAT Devices on the same Internet connection with each using
one of your Public IP#s

- Even if we do that, having two networks and two IP's enables us to
replicate the experience the extranet client will have when coming to us from
the Internet. That's an advantage in our test environment.

Yes. I can see that as being a good test environment.

of the router that terminates the LAN with the workgroup. I think this could
instigate the multihomed browser issue you pointed out. We tried it
previously and could view two networks from within the domain. It took a
very long time to open a shared folder in a workgroup computer from a domain
machine. However, the DC was able to serve as a printer server for machines
in the domain and print to a network printer and the workgrouped machines
could print to the same printer without being in the domain.

To be honest with you,...just buy another printer and forget it. It isn't
worth all the "head stands" and "cart-wheels" just for the sake of a
printer. You have two networks separated by two NAT Devices and for the
"lab" you are trying to create that is perfectly fine, but creating a
routable link directly between the two networks that bypasses the NAT
Devices really blows your "model".

If the DC is the machine with the Printer that is shared, then yes you can
duel-home it if you are careful to follow what the article I posted says
about making the proper Nic the "first-priority Nic" and the printer would
work. But because the DC now has a direct path to the other network that
doesn't require going through the NAT Devices you "lab" is no longer going
to always behave the way you intended. It just is not worth it for the sake
of a dumb printer.

Put the best printer on you production network and buy some cheap $50 inkjet
printer for the Lab network and be done with it.

 

[Guest]

Thanks, again, Phillip.

You provided an excellent lead concerning the multihomed browser issue. We
may try connecting a couple of DMZ-side (local) ports of the routers for
normal operations; then disconnect this link when actually running the site
in a test mode. Pretty soon, I suspect, we'll get over the hand-wringing and
just join the domain as you originally suggested. There are a couple of
issues other than print sharing. Our office scanner is on a domain machine
and we need to move files into shared folders on computers currently in the
workgroup.

Appreciate that you shed some light into our peculiar circumstances. Best
regards for the New Year, John