[13] in winnt
winnt: what do we mean by support and for whom
daemon@ATHENA.MIT.EDU (Rob Smyser)
Wed Jun 4 17:26:58 1997
Date: Wed, 4 Jun 1997 17:25:01 -0400
To: winnt@MIT.EDU
From: Rob Smyser <smyser@MIT.EDU>
Folks,
As part of defining who gets how much support when, I thought we needed
to list who our customers are and what do we think they need from us. One
pass is to figure out the major user groups we deal with. If you have time
or interest, I'd like your reactions comments, changes to the scheme I lay
out briefly below. We often talk about distinctions between Full Support,
Partial Support and No Support, but we don't often talk about for whom.
This is an effort to get closer to that...
- - - - - - - -
When we think about "supporting NT at MIT", the natural questions are,
- which parts of NT? (since it's so complex an operating environment), and
- for which customers? (since MIT's user community is so diverse).
Whatever we answer to the above helps create the set of deliverables for
support.
To help create a big picture of the supportable community and what features
they may need, I've made the following list of categories, roughly in order
of complexity. Each of the four sections gives a name to the group, some
summary of what they tend to do, and a list of the technologies they tend
to use.
1.) Individual users (students, faculty, staff)
These users don't do networked resource sharing other than by sending
email attachments to each other. Their use of MITnet is confined to email,
web-browing and printing. Administrative users might use telnet or dialup
to reach MITVMA or VMC. Some users will want to do the same work at home
as on campus. These folks will need support for these topics:
- getting a direct ethernet connection on campus
- installing eudora
- printing to athena/networked printers
- connecting from off-campus via tether
- secure telnet access to unix or mitvm*
- backing up work with adsm
2.) Small Workgroups (small dept offices, research groups, some admin offices)
This group is a like a collection of individuals, except that many will
want to share files from one PC to another for work. The file-sharing can
be on a protocol not normally routed across MITnet (i.e., Netware or
NetBeui). These folks will need support for these topics:
- all of the ones in Individual Users, and
- client for networks (possibly over NetBeui only, if asked to do so)
- passwds on each shared resource
3.) Dept Workgroups (mit business units, large dept offices)
This group is like the Small Workgroup, but there is more than one
building involved. This group has been able to use Appletalk to accomplish
multi-building file-sharing in the past, and will expect to be able to do
something similar in NT.
- all of the features of Small Workgroups, and
- client for networks over tcpip
- passwds on a user level, arbitrated by a domain controller.
4.) Academic Labs (architecture, planning, civil eng, meche, etc.)
Groups like this tend to use a mix of PC, Mac and Athena workstations in
heterogeneous lab settings. Students access central "Class" filesystems as
well. These groups tend to have cluster managers (who act like IT
Partners, but have less formal support from IS) and may run Domain
Controllers NT Servers. They tend to want:
- all of the features of Dept Workgroups above, plus
- AFS on NT, with authenticated access to the athena cell
- kerberized NT login
Now, there are some subclasses of the Small Workgroups and Dept. Workgroups
models:
1.) ad-hoc file sharing, with passwds on each resources, vs. centrally
administered NT domains.
2.) users need administrative applications that don't run on NT yet, vs.
users who don't have that problem.
Our support of groups with a central server requires us to have a strategy,
even if still under development, for dealing with domains. Things to think
about include recommended naming conventions for the domains and
workgroups, running WINS servers in each domain vs centrally across the
network, etc.
When users require administrative apps that don't run under NT, we need to
either allow the dept to remain on windows 3.11 with full support until
they do, or develop a method for dealing with those few applications until
they do work. Alternative methods include buying fixes (as CAO is
spending $6K June 1 to get the 32-bit middleware layer that will stop
SumMIT from crashing under NT as it does with the 16-bit laye) or even dual
booting into Win31to run those incompatible programs (which is a no-brainer
in NT and which some more advanced customers are known to be doing).
The idea of this whole note is to develop a classification of users,
support for whom we can develop in phases. Looking ahead, we ought to be
able to support the Individual Users on July 1 with minor rewrites of the
win95 support materials. We will need to develop material for the
Workgroups at both levels -- that will take more work during the summer.
The last class has needs that basically can't be supported now. Their
unique needs are research topics now, and await further work and NT 5.0 at
least.
As I said, I'd like your reactions to the customer breakdown. It will
guide how we build a list of what support to provide for whom and by when.
But we are by no means committing ourselves to fully supporting all these
people in all these ways by the July 1 date.
Looking forward to your feedback.
Rob
--------
Rob Smyser
I/S Computing Help Desk, MIT, 11-226, 617.253.1358
smyser@mit.edu
