Independent Windows Workgroup
Introduction
IS&T provides the centrally-managed win.mit.edu,
or WIN, Domain and accommodates, in our
centrally maintained DNS services, the
DLC or office who may need to deploy an
independent Domain. See the general considerations
and recommendations for Choosing
a Windows Server Migration Option for
more information.
General
Description
Independent Windows workgroups (or Workgroups
for short, since they are, by definition
"independent") are collections
of machines configured to advertise themselves
as belonging loosely to a "group of
machines" with a common name. There
is no central management of objects (user
accounts, machines, printers, etc.) and
each machine maintains its own local database
of users, printers, and other resources.
Access control and sharing of resources
like files or printers is handled in a
peer-to-peer fashion and there are no "controlling"
or "master" machines like domain
controllers or central file servers.
Most installations of Windows client operating
systems, unless specified otherwise at
installation time, are configured by default
to identify themselves as member of a workgroup
called "WORKGROUP". A Workgroup
is not associated with a Domain (including
WIN). Typically, it is an option for DLC
that cannot join WIN and cannot deploy
an independent Domain for lack of resources
or other reasons. Since it does not scale
well in large machine numbers, it is a
limited option and potentially for only
small groups.
Windows workgroups do not require extensive
configuration on part of the customer or
IS&T. The process involves essentially agreeing
on a common workgroup name, and configuring
each machine to identify themselves as
part of that workgroup which itself is
usually a one-step process. Since workgroup-naming
is not a centrally provided or controlled
service, there may be workgroup name overlaps/collisions.
These overlaps/collisions, however, will
not impact normal operation of machines
since network access and the functionality
of the individual machines are not affected
by their participation in a Windows workgroup.
At worst, customers with choices of overlapping
Windows workgroup names will need to negotiate
among themselves to help avoid them. This
may only be necessary if users rely on
browsing other machines in the same Windows
workgroup from an interface like the Network
Neighborhood that will display available
workgroup resources.
[Back
to top]
Prominent Features,
Benefits, and Disadvantages
Compared to a Domain (WIN, independent
or even an NT Domain), Windows workgroups
do not offer much in the way of benefits,
because they forego the central management
features inherent in a Domain. However,
there are certain advantages that can be
realized on a case-by-case basis, mostly
all in very small-scale deployments such
as up to at most 10 - 15 machines:
- Ability to manage a small number of
machines individually when joining a
domain requires an extensive learning
curve for local IT resources and/or the
deployment and operation of additional
local services, as in the case with independent
Windows Active Directory domains on MITnet.
- Ability to run application servers,
services, or workstation software on
one-off or very small number of dedicated
machines that would require extensive
Active Directory schema changes or other
modifications to the domain if in an
Active Directory domain.
- Ability to comply with third party
vendors' support policies for their software
and hardware products, if these policies
have stipulations that limit support
if machines participate in a Windows
Active Directory domain environment.
- Ability to migrate to/deploy a current
Windows operating system and move away
from Windows NT even when joining/migrating
to/deploying a Windows Active Directory
domain is not an option.
Some of the more significant disadvantages
are:
- Lack of many of the benefits offered
by WIN, including
- Seamless integration into existing
MIT infrastructure and to other central
IS&T services such as Kerberos authentication,
Moira, etc.
- Lack of single sign-on benefits
and the need to separately maintain
local user accounts and passwords.
- Reduced ease of sharing data and
access control across DLCs and offices
also participating in WIN.
- Lack of built-in self-maintenance
features manageable via Group Policy.
- Additional burden of management tasks
on a per-machine basis, including
- Running, securing and maintaining
individual machines.
- Running, securing and maintaining
local user accounts, file and printer
shares, access controls on individual
machines.
- Active Directory and domain object
(users, machines, printers) management
in a Windows server environment.
- Securing machines, including the
timely distribution of critical security
patches and service packs.
[Back
to top]
Design
Choices (Requirements and Limitations)
Specific to MIT and Workgroups on MITnet
Because of the limited, peer-to-peer nature
of Windows workgroups, there are no special
requirements or limitations for Windows
workgroup deployments beyond those for
stand-alone machines running Windows. As
a reminder, in order to guard against interfering
with or affecting the performance of services
for all other customers, DLCs or offices
should especially pay attention to the
following:
- For DLCs in areas with supported
network configurations, the DLC deploying
a Workgroup must refrain from deploying
network services that will interfere
with existing, centrally provided network
services. These include
- DHCP services (also initiated by
other Windows services, such as Internet
Connection Sharing (ICS), additionally
not allowed on MITnet)
- For DLCs in areas without supported network
configurations, such as those with private subnets,
locally controlled IP ranges, DNS subdomains, on other
ISPs, etc., more rules may or may not apply and you are
encouraged to consult with your local network
administrators to determine the best course of
action.
[Back
to top]
Sample Migration to
Workgroup Plan
Background:
- Department Z has three NT4 servers
in a domain configuration consisting
of PDC, BDC and file / application server.
Client machines consist of 12 laptops
and five desktop workstations. Desktop
stations are being reduced further in
favor of laptops.
- Server applications are BDM and BSImport.
- Local applications are MIT standard
applications, MS Office, Crystal Ball,
Power Sim, and Delphi.
- The department also uses Meeting Maker
which is hosted on a UNIX server housed
in E40. It is used for meetings as well
as scheduling common resources such as
meeting rooms and projectors. They plan
for Oracle Calendar Desktop software.
- They have Palm OS PDAs and seek to
start synchronizing them with their workstations.
User Accounts:
- Kerberos principals.
- Visitor accounts occasionally required.
Printing:
LPR direct to printers over TCP/IP
with no print servers. Printers are not
Athenized.
Remote access and security:
Users connect from home, have
local copies of database files, occasionally
transmit sensitive data unencrypted over
the network, and are interested in a VPN.
Design recommendations:
The customer could execute all
current operations in a Workgroup based
on W2K or W2K3 servers.
Such an environment would be more reliable
and secure than their current environment.
It eliminates the operational burdens of
a full-fledged Domain, and avoids risks
associated with joining WIN. Joining WIN
in the future would be a step closer, simpler
and not constrained by time.
Factors considered in this recommendation
are:
- Small size of the organization
- Existing challenges to laptop use in
a domain
- Significance of laptops to the operations
of the customer
- High learning curve vs. criticality
of moving off NT4 in a timely manner.
Migration plan:
Workstations:
Are currently W2K or XP and need no upgrades.
- Create and verify local accounts on
client machines and synchronize each
with the Domain accounts. (for the period
between removing client machines from
the Domain and demoting the DCs to standalone
servers, DLC needs to manage two accounts
per user).
- Break machine Domain association.
- Test client access to shares and applications
on file server
Creating independent replica file / applications
server with W2K(3) operating system:
- Demote BDC to member server (using
U-Promote)
- Upgrade old BDC to W2K(3)
- Replicate shares and applications from
file / applications server to standalone
server (old BDC)
- Remove old BDC server from the Domain
and leave it a standalone server
- Verify / create / clean accounts and
shares locally on this server (old BDC).
- Disconnect the original file and applications
server form the network and use its network
parameters for the old BDC.
- Test client access to resources and
operations of the new file server.
If all goes well, keep the new environment.
Otherwise, revert to original file server,
troubleshoot problems with new server,
and test again until it works.
The domain at this point will be left with
a PDC and file / applications server that
are not relevant to operations. Once the
customer is satisfied with the new operations
the PDC can be demoted and the OS upgraded
to W2K(3) and used for other purposes.
The original file server can be upgraded
without worrying about loss of data or
operations and used for redundancy if the
customer wishes.
[Back
to top]
|
