Choosing a Windows Server Migration Option
General Considerations and Recommendations
Introduction
In migrating a Windows server platform, these are some
of the general considerations and recommendations based on
various factors as determined by the circumstances and
needs of your DLC or office. The system administrator may
use these considerations as part of a loose decision tree
to help you guide your decision towards the best
migration/deployment option for your DLC. Remember, the
options are win.mit.edu, or WIN, an independent Domain, or
an independent Workgroup.
First, examine known deciding factors to see
if there is a hard reason to sway your decision one way or
another. If one of the factors defined there
holds true for your environment, your decision essentially
will be limited or already determined.
Second, consider the following factors and
associated recommendations for each case. If the
known deciding factors do not apply in your case and have
not indicated an option, these may help you make a more
informed decision. One or more of these factors may be
significant so much as to affect your selection, or add up
to an affinity towards one solution or another.
Size of
Your Environment
The size of your environment in number of machines or
users may be a significant factor in which
migration/deployment option (and associated paths) are
best.
- Number of machines.
- If you have a large number of machines (more than 50), you should consider automated or well-managed migration/deployment path, potentially using automated or semi-automated methods such as Remote Installation Services (RIS), RIPrep, or drive imaging to ease the burden of migrating/deploying all of your machines.
- You should give serious consideration to joining
WIN for ease of migration/deployment for the
following reasons:
- Existing machines running supported Windows
operating systems, OS, simply can be joined to
WIN without complicated migration paths.
- For deploying new machines or installing from
scratch, WIN offers flexible RIS deployment
options.
- RIPrep imaging and drive-imaging methods can
work with WIN, provided images are implemented
properly. These methods are more complicated than
simply joining existing machines or performing new
installations via RIS).
- If you are considering an independent Domain,
you might want to watch out for the following
limitation.
- If you would like to use RIS, this service is
limited to WIN on MITnet and you may not be able
to deploy a RIS server for your Domain.
- If you have a small number of machines
(10 - 50), you should seriously consider
WIN for ease of management and administration
without having to deploy a separate
Domain, domain controllers (DCs),
DNS servers, and necessary hardware.
All of the deployment benefits listed
above are valid for your use.
- If you have a very small number of machines (less
than 10), and you cannot join WIN for a specific
reason, you should seriously consider deploying
stand-alone Windows machines in a Windows workgroup to
avoid having to deploy a separate Domain and
associated hardware, software and services for a very
small number of machines.
- Number of users.
- If you have a large number of users (more than
50), you should consider carefully both joining WIN
and deploying an independent Domain.
- If you have a lot of user groups, finely-crafted
or highly granular ACLs and permissions on shares,
files, folders, and other Domain resources, then you
will need to migrate these carefully to your new
environment.
- Since WIN uses existing MIT Kerberos
principals (MIT user accounts) as its user base,
independent user identities and associated
permissions (even if the usernames are matched to
their MIT Kerberos equivalents) will need to be
migrated. There is currently no automated
mechanism for doing this.
- If your usernames in your existing
Domain do not match their MIT Kerberos
counterparts, then the migration process may be
more confusing.
- If your user groups and ACLs/permissions are not
too complicated, you should give serious
consideration to joining WIN to take advantage of
benefits like existing MIT user accounts and
groups/lists, permissions based on these, and
ACLs.
- If you have a large user base with (already or
preferably) roaming profiles (e.g. users) or
multiple user machines (student clusters, public
areas, training environments), you should give
joining WIN serious consideration for its ability to
store user profiles in roaming profiles accessible
widely across campus and on all machines throughout
the Domain.
- If you have a small number of users
(10 - 50), you should seriously consider
joining WIN, once again, for ease
of management and administration
without having to deploy a separate
domain, DCs, DNS servers, and necessary
hardware. All of the deployment
benefits listed above are valid for
your use.
- If you have a very small number of users (less
than 10) and a similarly small number of machines for
these users, and you cannot join WIN for a
specific reason, you should seriously consider
deploying stand-alone machines in a Workgroup to avoid
having to deploy a separate Domain and associated
hardware, software, and services for a very small
number of machines.
[Back to top]
Complexity
of Your Environment
Your existing environment of mission-critical
and/or line-of-business applications in
use, the diversity of the operating systems
you use and characteristics of any existing
Domain may factor significantly
in your decision. See also the item further
below about Software Deployment for relevant
information.
- Application servers/services,
especially if mission-critical.
If you currently run or plan to deploy
mission-critical application servers
and services in the near future, it is
important to check with the vendor for
system requirements. System
requirements to watch out for include:
- OS requirements.
- Network services this application server/service depends on or requires (e.g. DHCP, particular DNS configurations, etc.).
- Impact on Active Directory schema in a Domain
where this application server/service is to be
deployed.
- Support conditions, and restrictions, particularly
on Domain configurations, if any, from the
vendor.
- Line-of-business applications.
Similar to application servers/services,
line-of-business applications and their
compatibility are important in making
your decision. Before you move forward,
you may want to check with the vendors
of line-of-business applications you
use for system requirements. System
requirements to watch out for include
the same factors as for application servers/services:
- OS requirements.
- Network services this application server/service depends on or requires (e.g. DHCP, particular DNS configurations, etc.).
- Impact on Active Directory schema in a Domain
where this application server/service is to be
deployed.
- Support conditions, and restrictions, particularly
on Domain configurations, if any, from the
vendor.
- MIT supported applications.
Currently, there are no known major incompatibilities
between MIT supported software applications (some of
which are site-licensed and centrally-distributed) in
WIN. The same is potentially true for a "plain
vanilla" independent Domain, but each Domain is
different and there may be configuration differences
that may arise in individual cases.
- Third-party applications. You
should consult with the vendor for details of any and
all third-party applications for compatibility
requirements. There are a number of pilot migrations and
ongoing deployments which have successfully deployed
various academic and administrative applications in WIN,
and you may consult IS&T
Software Release Team for more information about
specifics.
- Diversity of operating systems.
Chances are that Windows and its flavors are not the
only operating systems you run in your environment, and
these may factor in your decision.
- If your non-Windows machines are generally used as
clients accessing Domain or machine resources on
Windows Servers, you will find most supported
non-Windows operating systems, including Mac OS
and flavors of Unix and Linux, can access resources on
machines in WIN using built-in or third-party software
tools.
- If your non-Windows machines are generally used as
servers which your Windows clients (among clients
running other operating systems), it is likely that
they will be able to do so even when joined to WIN. If
custom software clients (e.g. database drivers, custom
GUIs, etc.) are required to access your non-Windows
servers, you should check with the vendor for
compatibility requirements, paying close attention to
the factors suggested for mission-critical application
servers/services and line-of-business applications
above.
- If your non-Windows machines are clients or
servers integrated into your existing Windows NT4
Domain, you should consult with the vendor for
compatibility requirements for a Windows Domain in
order to find out if they can similarly be integrated
into WIN. Currently, only machines running supported Windows operating
systems are permitted in WIN and while it may be
possible technically, integrating other operating
systems may be demanding work or conflict with
administrative/privacy/security policies. In such
cases, if the integration is critical to your work,
you may have to deploy an independent Domain to
maintain features or investigate alternatives.
- Existing Domain characteristics. If
you have an existing Windows NT4 Domain and thinking
about migration, certain characteristics of your Windows
NT4 Domain which you may want to preserve may be a
significant consideration.
- Domain structure. If your
existing Windows NT4 domain is a complicated
implementation, for instance, a combination of Windows
NT4 domains with accounts and resources distributed
among them, etc., you will not be able to
replicate the same structure using Domains in WIN
when you join machines. You may, however, be able to
achieve similar organizational patterns for your
groups of machines using organizational units called
containers (which can also be nested to a
limited extent) that are available in WIN. In order
to have complicated multiple Domains or deeply-nested
organizational units, you may choose to deploy an
independent Domain.
- Trust relationships. If you have
trust relationships to other existing Windows NT4
Domains at MIT or elsewhere, you may not transfer them
to WIN. However, if DLCs or offices at MIT with whom
you have trust relationships also join WIN, you will
be able to realize the same benefits, such as
administrative or user access to each other's
resources, appropriate and fine-grained permissions
(on a per-user or per-list basis) using WIN features.
If you must explicitly maintain a trust relationship
with a Domain outside MIT, then you will need to
deploy an independent Domain and coordinate with the
other Domain all trust relationships.
[Back to
top]
Collaboration with
Other MIT DLCs
If you frequently collaborate with other MIT DLCs such
as academic departments with common student bases or
projects, or administrative departments working on the
same financial data sources, you may benefit greatly from
joining WIN unless one of the known deciding factors
indicate otherwise. Naturally, you will need to
coordinate and consult with DLCs with whom you work
closely to investigate parallels and to see whether
adopting the same solution indeed serves each office
better.
- Users and line-of-business needs.
By joining WIN, your users can benefit from using the
same, central, MIT user database and identities for
setting permissions and ACLs for access to your DLC
resources in WIN. Additionally, your users will benefit
from single sign-on with access to multiple systems for
which they are authorized.
- System administrators and local IT
resources/needs. By joining WIN, you may be
able to pool IT resources across DLCs or offices working
together, aggregating the availability of your systems
and IT resources maintaining them through appropriate
configuration of administrative privileges and
collaboration.
Collaboration with non-MIT entities (people,
groups, or organizations)
If you frequently collaborate with non-MIT entities
(such as outside academic institutions, businesses, the
Federal Government or local governments, etc.), you may
have technical and more importantly administrative
policies and requirements on the work you perform and the
configuration of your IT systems. You should check
agreements, contracts, and other legal documents you have
with these entities to determine any specific technical
requirements or policies you may be subject to and compare
with the available options.
[Back to
top]
DLC Type or Affiliation
(Academic vs. Administrative)
Depending on your main line of business (e.g. academic
department, research laboratory/group/center,
administrative department or office), you may realize
different benefits from joining WIN.
- Academic departments especially may
benefit from joining WIN to serve their large student
populations which are typically mobile, prefer roaming
access and settings to multiple computer systems,
including departmental and public clusters. In cases of
special purpose deployments such as high-performance or
task-specific computing clusters, labs, and studios, WIN
might help with its built-in self-maintenance and rapid
deployment/rebuild features.
- Research
laboratories/groups/centers especially may
benefit from joining WIN to serve their continuing IT
administration needs. With most research environments,
especially smaller ones relying on in-house IT resources
(often students with a high turnover rate), WIN may help
ease admin burdens by abstracting Domain management and
maintenance tasks from the local IT administrators,
leaving them to focus on the more immediate tasks at
hand such as maintaining access permissions and software
deployment.
- Administrative departments or
offices may benefit from joining WIN to help
ease administrative burdens on the rapid deployment of
multiple machines with the same configuration
(applications, settings, etc.) and through single
sign-on to Kerberos on which a number of MIT business
applications rely.
[Back to
top]
Geographic/Network
Layout/Locations
If your DLC has multiple locations (such as satellite
offices or remote training facilities) on campus, these
may factor in in your decision.
- If your DLC has single geographic or network
location, neither option necessarily provides a
significant benefit on this factor alone, and you should
consider the other factors listed here.
- If your DLC has multiple geographic locations where
your machines reside, you may benefit from joining WIN;
roaming user profiles and access to your servers in WIN
as well as to lockers on MIT's distributed file system,
DFS, may help share your resources across different
locations.
- If one or more of your locations reside on a network
segment without a supported network
configuration, you may not be able to take advantage
of WIN or join machines in that location to WIN at this
time.
[Back to top]
Remote Access Needs
If your users are dependent on remote (i.e. from
non-MITnet ISPs, e.g. from home via broadband, through
Tether, or on the road while traveling) access for
mission-critical work or day-to-day operations, these may
factor in your decision.
- If you have client machines that are portables
(notebooks/laptops), you can join them to WIN and access
Domain resources, including DFS, and work easily on
MITnet and over well-connected links such as Tether or
most broadband providers. However, different ISPs have
different blocking policies on their connections and
these may interfere with your access. The same is
generally true of independent Domains.
- Since portables are not always connected to the
Internet or a network with access to the Internet and
MITnet, disconnected operation is important and certain
WIN defaults (such as user profiles being stored on DFS)
may require pre-configuration steps to enhance it. The
same is true for independent Domains, but perhaps to a
lesser extent depending on user profile accessibility
and options.
- If the majority of your client machines are
portables and you do not need them to access Domain
resources remotely very often, you may keep them outside
of WIN or an independent Domain and have them access
Domain resources manually or through scripted
applications on demand.
[Back to
top]
User Behavior and
Training
Your typical user behavior and the user training
resources you have may factor in your decision, as
well. By user behavior, we mean the ways your users
operate your machines; e.g. do they place a lot of items
on their Windows Desktop and My Documents folders? Do they
customize their own machines heavily?
- Roaming profiles.By default,
roaming profiles are stored in the user's existing
DFS home directory. There is an option on a
per-user basis for a local profile per machine
or the roaming profile on a specified share of an
accessible server. However, without this option, you may
need to train your users to save MIT-owned,
mission-critical, or business documents in your server
shares such that the local administrators can access
them in an emergency. Currently, privacy policies and rules of use strictly prohibit access to other
user's DFS spaces (unless they choose to change
permissions themselves) by anyone else. If on-demand
local IT/system administrator access to documents
located in a user's Windows profile is a
mission-critical need, or you cannot train your users to
save such documents in a share where your system
administrators have access, you may want to consider an
independent Domain as an option.
- Administrative lockdown of
machines. As in a typical Workgroup or Domain,
administrative lockdown of machines is available in the
WIN environment to prevent users from changing systems
beyond norms set by system administrators For different
aspects of this please refer to the Administrative
lockdown item under the System Administration section
and the Privacy, Sensitivity and Auditing section
further below.
[Back to top]
User Account Management
User account management, especially the urgency
thereof, may be a consideration in your selection.
- User account management turnaround.
In WIN, Domain-wide user accounts are the same as
existing MIT user accounts. As such, user account
management tasks such as user creation and deletion are
handled by the User Accounts
office. In most cases, there is, at most, a 24-hour
turnaround in user account service, but if you have
needs for 24x7 user account management, it may not be
possible to deliver that using our current
infrastructure and service levels. Workarounds,
however, exist, such as in the next three items
below.
- Temporary or guest user accounts.
If you join WIN and need to create a temporary or guest
account for a visiting user, contractor or temp to
access your machines and resources, you will need to
sponsor a standard MIT guest account also through User Accounts.
There is usually up to a 24-hour turnaround time, but
often less, and alternatives such as using local user
accounts may be applicable. If this is a frequent need
and cannot be met by existing services, you may want to
consider using local user accounts or deploying an
independent Domain if the resource to be accessed is
indeed Domain-wide.
- Local user accounts. As with
typical Windows machines and Domains, local
user accounts can be created on client and server
machines in WIN on a per machine basis. A
Domain-wide user for which no corresponding Kerberos
principal exists is not impossible, but currently very
limited for operational reasons, and if done, only to
address very specific needs.
- Using groups for instantaneous
turnaround/lockout. Whether you choose to join
WIN or deploy an independent Domain or a workgroup, it
is highly recommended that you assign your users
appropriately to user groups or lists and set
permissions to your resources using these groups. Then,
if you have an urgent need to remove a user's access to
your resources, you may do so by simply removing them
from some or all of the appropriate groups of which they
are a member. This is easier in WIN, since WIN uses
existing Athena lists for permissions and ACLs; they are
potentially already in use by you for group emailing
purposes.
- Single sign-on. Single sign-on to
MIT Kerberos-compatible services and applications such
as email through Eudora, Kerberized print queues, SAP
and other business applications, among others, means
there is only one user account and password to worry
about if you join WIN. Contrast this with having to
maintain your own user accounts and passwords separately
in an independent Domain or workgroup.
[Back to top]
Typical
Uses
If your primary need or reason for using a Windows NT4
Domain appears among the most popular needs among owners
of Windows Server platforms, these may factor in your
decision, pointing towards WIN. Most popular needs
are:
- Centralized user authentication. If
centralized user authentication is one of the primary
needs driving your deployment, joining WIN satisfies the
same need and in fact further enhances it. You receive
benefits of integration into the existing MIT user
accounts database and single sign-on using MIT's own
Kerberos implementation.
- Roaming profiles. If roaming
profiles for your Windows users is a primary need, you
will replicate that benefit by joining
WIN. Additionally, each user's profile is stored in DFS,
making files accessible to them from any other
machine that is a member of WIN.
- File sharing. If file sharing is a
primary need, you will replicate the benefit by joining
WIN. Additionally, you will be able to set permissions
on your file shares (among other objects) using existing
MIT user accounts and Athena lists, including for MIT
users and groups outside your DLC who may need access to
your resources.
- Printing. If printer (queue)
sharing is a primary need, you will replicate the same
benefit by joining WIN. Additionally, you will be able
to set permissions in the same manner as file shares, as
explained in the previous item, and continue using
Kerberized print queues (now with single sign-on
benefits, without needing to re-authenticate) or SAP
print queues.
[Back to
top]
System Administration/Machine
Management and Local IT Resources
System administration and machine management features
available per option may be an important factor in your
decision.
- Group Policy management. Group
Policy, a centralized and highly-granular mechanism for
managing objects (machines, users, and user
environments) in a Windows Domain is available in both
WIN and an independent Domain and greatly simplifies
machine configuration tasks for system
administrators. If you join WIN, additional options on
top of the standard Windows Group Policy settings,
called WIN extensions, are available for setting
additional features, such as default administrator
passwords on your machines, pushing down (and if
desired, overrideable) critical security patches and
Service Packs, and deploying software on your
machines.
- Software deployment. In addition to
traditional software deployment methods, Group Policy
and scripts can be used to deploy applications available
in the new Microsoft Installer (MSI) format centrally,
without having to visit each machine. MSI installers can
rebuild and repair themselves in case of damaged or
missing files or registry settings.
- MSI packages are not necessarily available for
each application or software package for Windows
available, even though major vendors are slowly
adapting this technology. Others have MSI packages,
but are not designed for unattended deployment. These
cannot realize all of the benefits of centralized MSI
deployment through Group Policy, a problem common to
both WIN and independent Domains. However, IS&T is
working hard to develop a full set of compatible MSI
installers for all MIT distributed software packages,
and has resources to help DLCs or offices who would
like to develop MSI versions of packages they have
licensed and own for deployment. Collaboration with
pilot DLCs and offices have already begun to yield a
base set of common applications as well as third party
packages that are available as MSIs.
- More traditional deployment mechanisms that are
manual (visiting each machine to install applications)
or drive imaging, then joining machines to a Domain
are both available in WIN and have successfully been
implemented.
- More aggressive deployment mechanisms and
applications, such as Microsoft Systems Management
Server, or enterprise drive imaging/deployment
packages may or may not be fully compatible with WIN
and may require you to deploy an independent Domain to
use them. You should check with the vendor for
specific info, and refer to the recommendation
guidelines under the Complexity of Your Environment
item above.
- Rapid rebuilding and
self-maintenance. If you need drop-replacement
of failed hardware or of the software image on a client
machine, rapid rebuilding of machines to specs, or
periodic self-maintenance tasks, you should seriously
consider joining WIN. Beyond standard features provided
by Windows Group Policy settings, WIN extensions,
scripting, and self-maintenance features allow you to
reinstall rapidly or quickly deploy machines, especially
if most or all of your critical applications are
available in MSI format.
- Administrative lockdown. If you
desire systems with administrative lockdown preventing
users from heavily customizing or tampering with them,
this is possible using various GP features in a typical
Domain, as well as WIN. Examples include machines in
public areas, multi-user workstations and training
machines. If you are interested in additional
functionality, such as logout scripts, self-maintenance
features to undo user changes, and user or group
permissions based on existing MIT user accounts and
lists, you should give WIN serious consideration.
- Support & service availability.
If 24x7 aggressive support and service availability from
IT resources for your Windows Servers and domain
environment is a mission-critical need, this may factor
in your decision.
- If you WIN, IS&T guarantees the 24x7 availability of
WIN, its DCs and associated Domain services and
resources such as user authentication via Kerberos and
DFS access. Beyond infrastructure network services on
IS&T supported networks, local IT resources are
responsible for the maintenance, security, and support
of their machines using available interfaces and
Domain features, and may specify local service and
support policies for their users.
- If you deploy an independent Domain, IS&T guarantees
the continued availability of DNS records pointing to
your DCs. Beyond infrastructure network services on
IS&T supported networks, local IT resources are
responsible for the operation, maintenance, security,
and support of your independent Domain, DCs and
associated Domain resources, as well as member
machines and user resources.
- If your local IT resources are limited (such as in
a high-turnover office or a smaller group), you may
want to give WIN serious consideration for its lighter
maintenance (no DC or Domain maintenance) burden and
better availability.
[Back to
top]
Privacy, Sensitivity and
Auditing of Your Data
IS&T maintains the same rules of use and privacy policies
in WIN as it does for other central computing
systems. Each machine in WIN has additional auditing
and central logging, which records any and all access so
violations can be tracked down and appropriately answered.
- If your main line of business involves handling
sensitive business or research data, you may be subject
to additional government or contractual obligations
beyond MIT policies. If you are concerned with the
implications of joining WIN for this reason, you are
encouraged to consult IS&T to
further discuss available safeguards and policies and
clarify details.
[Back to top]
|
