Home / Services And Resources / Server Services

Windows Server Platforms: Choosing a Windows Server

 

Migration Option

General Considerations and Recommendations

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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
 
Related Links

Windows Server Platforms