Thanks Chris. -t On Feb 14, 2008, at 8:41 AM, Harper, Chris wrote: > Listserves were ADFUTURE and EMAILFUTURE, just a small correction > there. But yes will be a good platform for this discussion. > > Christopher M. Harper > MANAGER OF INFORMATION TECHNOLOGY > University Relations / Michigan State University > 401 Olds Hall, East Lansing, MI 48824-1047 > Email: [log in to unmask] / Direct: 517.355.9980 > Web: http://ur.msu.edu / Cell: 517.290.5496 > > > -- > > From: MSU Network Administrators Group [mailto:[log in to unmask]] > On Behalf Of Troy Murray > Sent: Wednesday, February 13, 2008 8:36 PM > To: [log in to unmask] > Subject: Re: [MSUNAG] MSU Exchange Thoughts on Central Active > Directory and no more "Islands" > > A good thread to start the list setup for that discussion, I think > it was by using "adfuture" and or "mailfuture" in the subject and > body to the list serve address. > > -- > Troy Murray > Sent from my iPhone > > On Feb 13, 2008, at 7:25 PM, Esther Reed <[log in to unmask]> wrote: > I left today’s IT Exchange a bit early so perhaps my following > comments have been discussed: > (This is a bit long to provide background to those who did not > attend.) > > When I left, the discussion about options for MSU Email was > revolving around MS Exchange and a central AD. The idea of a single > sign-on using just the centrally authenticated and maintained > account was included in this. Tom Davis asked, “If we built it, > would you come?” I must add that some of the discussion seemed (to > me) to wander from a central email system to an entirely central > computing system -- no more “islands”. > > The responses, that I heard, discussed the pros and cons from IT and > business viewpoints: What is reasonable or convenient to create and > maintain? I heard no one mention a major component: the needs of > individual colleges, units, departments and programs. Aren’t > computing systems supposed to serve and mesh with a unit’s workflow > (as much as possible given their budget)? > > MSU has over 240 graduate programs -- most have different needs, > priorities and workflows. Add to that undergraduate programs, > research grants, centers, extension services and satellite > operations. It is easy to see that many pieces of MSU have vastly > different needs and workflows that will not fit a standard business > model. > > The problems with a central Exchange and AD are (1) one-size-fits- > all configuration, (2) inability to nimbly change, and (3) long > response times. These are NOT criticisms; these are the nature of > the beast. > > (1) One-size-fits-all: A central system can not match its AD to > the workflow of every unit on campus. It just can’t. A “best fit” > middle-of-the-road configuration will have to be used. Units, who > do not quite match, will have to adjust their workflows to fit. A > unit with its own child domain will have more flexibility, but some > limitations will have to exist to ensure that all domains play > nicely together. > > (2) Nimble changes: How long does it take for a single unit to > upgrade its servers -- once the chairman or dean gives their > blessing ;^) ? How long for a central system? How long have we > just been *discussing* changing MSU email? Again, no criticism -- > thorough preparation is critical. It just takes a long time to > change a behemoth. > > (3) Response times: If my Dean wants an account created or a > global Exchange group changed right now, I can do that in minutes. > How long will it take for a central system to respond to this > request? 4 hours? 24 hours? 1 week? > > I do agree that a centrally maintained system will be attractive to > some units, such as (a) units who have no IT person; (b) units who > want their IT person to do something other than Exchange or AD; (c) > units whose IT person is not interested in doing Exchange or AD; (d) > units whose workflow will be minimally impacted; or (e) units who > want a central feature such as a globally shared calendar (BTW, not > everyone wants this.). > > However, I believe that many units need a specialized configuration, > nimble changes, quick response times and an IT person who intimately > knows their workflow. These units will continue to maintain their > separate “islands” as long as they can afford to do so. These units > pay for this because it makes sense for how they need to do business > -- it strengthens whatever service or course they provide. To tell > them “too bad” and force them to a central system will weaken them > -- compared to competing programs or services -- and, in turn, > weaken MSU. > > It would be far better to have central *policies* of what is needed > (security, encryption, disaster protection, email services, etc.). > Then each unit would be allowed to choose how to comply -- either > join the central system or make sure that their “island” follows the > rules. > > I believe that MSU will continue to need both: a central system and > “islands”. > > What are your thoughts or opinions? > > ~ Esther > > Esther V. V. Reed > IT Systems Administrator > MSU Graduate School > -- Troy Murray Developer Michigan State University Biomedical Research and Informatics Center (BRIC) 100 Conrad Hall East Lansing, MI 48824 Phone: 517-432-4248 Fax: 517-353-9420 E-mail: [log in to unmask] Calendar HTML - http://www.icalx.com/html/troymurray72/month.php?cal=BRIC+Work iCalendar - http://www.icalx.com/public/troymurray72/BRIC%20Work.ics