Orpheus Department Support - Requirements
Revision 1What are the motivations for implementing this project?
Orpheus Department Support - Requirements
Author(s)
Revision Notes
1 – Initial draft of the requirements.
Last Updated:
June 12,
2001
Revision #
1
2 – Revised draft
2
3 – Another revisiosn
3
June 12, 2001
1 of 9
Orpheus Department Support - Requirements
Revision What are the motivations for implementing this project?
1. Project Overview
Orpheus for Clusters was successfully deployed for the Fall Semester, Year 2000 to all Computing
Services clusters. We are determining the needs of the department administrators on campus, to see how
Orpheus can help them to maintain their cluster software and machines.
The goal of the Departmental Orpheus project is to deploy a supportable, scalable, secure Windows 2000
based Operating System environment that provides the departments with an easier method of managing
groups of systems in order to reduce the Total Cost of Ownership (TCO) for the departments. The current
Andrew UNIX distribution is being used as a guideline for features that will be attempted under Orpheus
(e.g. Operating System Installation, Operating System patches, Application installation and upgrades,
distributed control to departments, distributed file access, and consistent user preferences on multiple
machines).
June 12, 2001
2 of 9
Orpheus Department Support - Requirements
Revision What are the motivations for implementing this project?
What are the motivations for implementing this project?
1.1.1
What user need will be satisfied by this project? What other services or projects will be enabled
by the completion of this project? What resource savings will be realized? What strategic
initiatives will be served by this project? In essence, why are we doing this?


Interviews with Departmental administrators indicated that they would like to see the
following Orpheus services:

Automated Operating System and Patch (Service Packs) Installs via the network
– Remote Installation Service (RIS) installation.

Automated Installations of Common Applications – Microsoft Software Installer
(MSI) distribution via Group Policy Objects (GPO).

Distributed Departmental Control of Users, Groups and Computers Organizational Unit (OU) management.

A single unified login (account integration) granting authentication access to both
Andrew and Active Directory Windows Resources.

Integrated file access to the UNIX AFS directories (OpenAFS).

Consistent User Preferences on multiple machines (Roaming Profiles).
Additional departmental system service requirements may include:

Andrew.AD authentication for Microsoft Applications (e.g. IIS, SQLServer,
etc.). This may also potentially affect Non-Microsoft products designed for
Windows 2000/XP.

Centralized Fileserver Space accessible via Windows 2000.

Options for Desktop Backups to a Centralized Location.

Centralized Security Tools.
It is envisioned that the adoption of Orpheus by the departments will allow the departments
to share the benefits of one central Active Directory (AD) and remove the necessity for
each and every department to support its’ own Windows Domain leading to a reduced
administrative cost and better access to information through implied transitive trust
relationships. It will tightly integrate the current domain and Andrew user accounts. The
Orpheus project may also attempt to allow the flexibility for departments to run their own
domain within the Andrew.ad.cmu.edu forest (at potentially a reduced service capability
vice the OU approach).
1.2 What is the goal of this project?
1.2.1
What, specifically, will be the end-result of this project? Software? A service? Technical
infrastructure? Describe the results briefly.
June 12, 2001
3 of 9
Orpheus Department Support - Requirements

Revision What is the anticipated audience of the resulting service?
A supportable, scalable, secure Windows 2000 based computing environment that gives
the departments easy access to the above listed services.
2. User Requirements
2.1 What is the anticipated audience of the resulting service?
2.1.1
What is the profile of a typical user? Are the novice or expert users or the entire range? Are they
a specific type of user (business administrators, departmental computing support personnel,
programmers, system administrators, etc.)?

Typical users will be departmental administrators supporting both “lab” environments
and departmental desktop machines (staff and faculty). Most administrators will have
previous skills supporting Windows Operating Systems. Some administrators may only
do the job as a secondary assignment to other job functions. It is possible that some
departments will only have student support.

Given the wide range of skills and manpower that the departments are likely to have with
Windows 2000, the departmental Orpheus deployment will need to be flexible enough to
accommodate various integration models (e.g. Domain vice OU support).
2.2 What are the specific tasks that users will use this service to accomplish?
2.2.1
What, specifically, will the user be able to do with this service? For example, update machine
and data outlet registration, add machines and outlet, query other users (for whom they have
authorization) machines and outlets, etc. What types of information will they be able to view
only as opposed to edit? This is more high-level than the specific interface or feature
requirements below.

Easier management of Departmental Computing Environments is the primary goal.
Specific features include:

Automated Operating System and Patch (Service Packs) Installs via the network.

Automated Installs of Common Applications (MSI distribution via GPO).

Distributed Departmental Control of Users, Groups and Computers (OU
management).

A single unified login (account integration) granting authentication access to both
Andrew and Active Directory Windows Resources.

Integrated file access to the UNIX AFS directories (OpenAFS).

Consistent User Preferences on multiple machines (Roaming Profiles).
2.3 What are the specific interface or feature requirements?
June 12, 2001
4 of 9
Orpheus Department Support - Requirements
2.3.1
Revision Are there restrictions on what users, or types of users, can
Are there interface requirements, such as multi-platform support, a web interface, or some other
requirement that affects how the service or software is presented? Are there features that the
software or service must contain?

All systems participating in the deployment of Project Orpheus (Andrew Windows 2000)
must be capable of running the Windows 2000 operating system. The ability to perform
an RIS installation via PXE boot is strongly recommended.

In order to take advantage of the network features of the Operating System, the systems
will be required to have a reliable, fast (10mb/s) Ethernet connection. It is not envisioned
that Orpheus will support wireless, DSL or machines connected via modems.
2.4 Are there restrictions on what users, or types of users, can do?
2.4.1
Are there tasks that some users will have access to and others will not? Is there data that some
users will have access to and others will not?

Organizational Units (OU) will be delegated control and will have the ability to create
objects (Users, Groups, Computers, Printers, GPO’s, OU’s, etc.). Specific guidelines for
OU delegation are being drafted in another document. It is envisioned that these
guidelines will include sections on: OS upgrades, Patch updates, Security, Naming
Conventions, Object Creation and other items.
3. Technical Requirements
3.1 Are there any standards that need to be adhered to?
3.1.1
Are there technical standards that the software or service must adhere to? Are there standards
with which it should not interfere with or not preclude even if it doesn’t employ those standards?

In all cases, services should utilize operating system native utilities.

Specific guidelines for OU delegation are being drafted in another document. It is
envisioned that these guidelines will include sections on: OS upgrades, Patch updates,
Security, Naming Conventions, Object Creation and other items.

Specific guidelines for externally controlled domains within the Andrew.ad.cmu.edu
forest are being drafted in another document. It is envisioned that these guidelines will
include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object
Creation and other items.
3.2 Is there a dependence on a third party?
3.2.1
Is the development reliant on a third party for development of a product or implementation of
features in an existing product? Are there aspects of the project that should not be reliant on third
parties?
June 12, 2001
5 of 9
Orpheus Department Support - Requirements
Revision
Are there any other technical constraints?

Orpheus is heavily dependent upon Microsoft in the release of OS upgrades, Service
Packs, Hot Fixes and bug support.

Orpheus also presumes that vendors will migrate to the Microsoft recommended
application deployment method (MSI’s).
3.3 Are there any other technical constraints?
3.3.1
Are there other technical constraints on the software or service such as network bandwidth
restrictions, integration with or at least non-interference with other software or services?

Orpheus machines will be required to have to have a reliable, fast (10mb/s) Ethernet
connection to support distributed logins and software installations over the network. It is
not envisioned that Orpheus will support wireless, DSL or machines connected via
modems.

Due to the security implications of AD replication in the Andrew Forest, security of
Domain Controllers (DC’s) may severely limit the ability to distribute control of DC’s.
3.4 Are there any maintenance considerations?
3.4.1
How will configuration be maintained or updates applied? Who will be responsible for them?

Specific tasks will be divided between Systems and User Services. User Services
consultants will maintain most services while the Systems Group will maintain server –
side issues.

The Systems Group will provide some support for developing MSI’s for required
applications until a point in time when vendors have adopted this standard for delivery.
User Services will provide product testing for the MSI’s.

Service Packs (SP’s) and Hot Fixes will need to be applied in a timely manner.

Operating Systems Upgrades (Windows XP) will need to be considered and applied
where appropriate.

Application Vendors will be asked to deliver applications in MSI format in order to
prevent an ongoing maintenance issue with the development of application MSI’s.
June 12, 2001
6 of 9
Orpheus Department Support - Requirements
Revision
What are the support expectations?
4. Deployment Requirements
4.1 What are the support expectations?
4.1.1
What will be supported? Will there be aspects of the software or service for which we won’t
provide support? Will documentation, training, be needed? Will special Help Center support be
needed (e.g., create accounts or administrate authorization)? Will the software be available in
computing clusters? Will DSP support the software or service?

Primary support will be provided through the Technical Services group’s consultants
(formerly DWS). This will include providing documentation, consulting with
departmental administrators, and may include training.

DSP may become clients of this service.

Application Support will be limited to applications that are covered under the Service
Level Agreements (SLA’s).

Machines will be expected to be in a clean state (no additional applications after a clean
load).

On-Line Documentation will be provided for common procedures.

On-Site Training of departmental users will be offered where appropriate.
4.2 What are the policy issues?
4.2.1
Will any existing policies/guidelines be applicable to the resulting software or service or will
changes in existing policies/guidelines need to be considered? Will new policies/guidelines need
to be developed? Will these policies pertain to access to the service, potential abuse-related
issues, etc.? Are there aspects of the software or service that will be banned or the use of which
will be discouraged?

Software, which will make any modifications to the AD schema, will not be allowed
unless Computing Services approves the changes.

Specific guidelines for OU delegation are being drafted in another document. It is
envisioned that these guidelines will include sections on: OS upgrades, Patch updates,
Security, Naming Conventions, Object Creation and other items.

Specific guidelines for externally controlled domains within the Andrew.ad.cmu.edu
forest are being drafted in another document. It is envisioned that these guidelines will
include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object
Creation and other items.
4.3 Are there current services that must be continued or phased-out?
June 12, 2001
7 of 9
Orpheus Department Support - Requirements
4.3.1
Revision Does the software or service have a finite lifespan?
Is there other software or another service that this project will replace? If so, are there aspects of
the older software or service that must be continued? Are there aspects that must be phased out
before this project is deployed? Does a migration path need to be defined for moving from an old
version to a new one?

There are no known phase-out dependencies for this project.

Departmental Orpheus is a new ambitious project that intends to bring a secure,
scalability, distributed computing environment to the Windows platform on Campus, and
hence is not replacing any existing project.

Although Orpheus isn’t dependent upon other project phase-outs, it is envisioned that
implementing Orpheus will assist the Computing Services in replacing and/or
augmenting other campus technologies (e.g. Netware Servers, WINS, AppleTalk, a
unified printing solution, etc.)
4.4 Does the software or service have a finite lifespan?
4.4.1
Is this software or service a temporary solution? What are the conditions or dates which, once
met, will require or facilitate the phasing out of this software or service?

Departmental Orpheus is not intended to be a temporary solution, but the start of an effort
for distributed Windows support.
4.5 Are there timing issues for deployment?
4.5.1
Are there issues with when the software or service is deployed? Must it be during a weekend or
over a break? Is there a deadline before which the software or service must be deployed? Must
the software or service be deployed in conjunction with another project? After another project?
Before another project?

We hope to be able to provide a set of specified core services (from Orpheus meeting
minutes) to departments by mid-August of 2001.
5. Costs
5.1 Are there restrictions on Computing Services’ hardware/software costs?
5.1.1
If hardware or software will need to be purchased for this system or service, are there restrictions
on the overall cost?

There are potentially training costs for Systems Group and User Services Consultants.
5.2 Are there constraints on users’ hardware/software costs?
5.2.1
If hardware or software will need to be purchased by the user, are the restrictions on how much
this hardware or software should cost per user?
June 12, 2001
8 of 9
Orpheus Department Support - Requirements
Revision Are there constraints on users’ hardware/software costs?

All systems participating in the deployment of Project Orpheus (Andrew Windows 2000)
must be capable of running the Windows 2000 operating system. The ability to perform
an RIS installation via PXE boot is strongly recommended.

One of the potential solution to the issue about DC security, would require Computing
Services to buy/host DC’s in a secure operational area (e.g. within Cyert Hall). A rough
estimate of cost is $9K/Domain. No estimate on the expected number of domains is
known at this time.
June 12, 2001
9 of 9