[139] in Kakapo Windows Team
Re: Migration from NT4 to W2k Domain
daemon@ATHENA.MIT.EDU (Wael Hishmeh)
Thu Oct 16 19:44:25 2003
Message-Id: <5.0.2.1.2.20031016192238.019838f0@hesiod>
Date: Thu, 16 Oct 2003 19:44:14 -0400
To: "Fred Baars" <fbaars@MIT.EDU>
From: Wael Hishmeh <wael@MIT.EDU>
Cc: kakapo@MIT.EDU, goguen@MIT.EDU, ditr-collocation@MIT.EDU
In-Reply-To: <00e201c39421$e2ab88f0$dc019812@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Fred,
Thank you for taking the time to work this through.
I'mm cc'ing the kakapo team here for the request to take it's course
through the channel fielding domain requests.
Once we hear from kakapo we can schedule a meeting to work through the
details and then I can work out a migration plan.
The profile page has not been released yet. I'll let you know when it's ready.
Thank you,
Wael
At 04:12 PM 10/16/2003 -0400, Fred Baars wrote:
>Hi Wael and Paul,
>
>Thanks for the recap of all the things we talked about. After our meeting
>and reading up some more about the pro's and cons of going into the
>Win.mit.edu domain or creating a separate domain I have come to a decision
>to go both ways and run a mixed environment.
>Especially because of support purposes, as the Helpdesk will provide first
>tier support, I want to follow the following scenario:
>
>The servers will be going to a separate domain, preferably
>helpdesk.ms.mit.edu.
>The Helpdesk domain takes a special place not just for administration of our
>own existing domain but especially because we provide support to clients in
>very specific ways within the domain setup that we have. To limit the amount
>of changes that will need to take place to get to a new domain and because
>we do want to get experience in different configurations (for support
>purposes and our own expansion of knowledge), we will go this mixed route.
>Three of the callcenter machines and one machine at my desk that is used
>as a Console are located in the Win.mit.edu domain already.
>
>This will leave the domain administration with us as far as accounts,
>policies, permissions, profiles and file and print sharing are concerned and
>it will give us some hands-on experience with a separate domain setup.
>There will be no need to change and/or set up new accounts, copying
>profiles, new setting of permissions and policies that are already in place
>right now.
>Due to our specific domain setup and because we want to keep a mixed
>environment we do not want to move away from that right now.
>
>One other thing to take in consideration for me was the special setup
>that we have for the domain as far as housecalls procedures are concerned.
>One of the servers is dedicated to backup clients data for clients machines
>that we work on. This server has specific file and folder permissions as
>well as the three machines in Housecalls that are used for slaving clients
>harddisks.
>
>These machines as well as the servers and Callcenter machines are used every
>day for the Helpdesk as support tools and they are critical for our work for
>all support purposes, not just Winathena.
>The added extra features like Kerberos login and AFS client will change the
>setup of these machines and as Winathena will be a relatively small portion
>of the overall support we provide at this time we will only use a limited
>number of Callcenter machines with these extra features.
>
>As most support issues/questions will most likely come from users with
>Winathena machines rather then the serverside there are the
>four machines in the Win.mit.edu domain as mentioned earlier and they are
>going to stay there. As we go other machines may be added.
>We use VNC to connect to machines in the callcenter which have
>respectively NT4 Workstation, WME, WXP and W98 as their OS. We VNC into
>these machines to "see" what the clients see when we are troubleshooting
>their problems. We are going to use one of the Winathena machines within
>the Win.mit.edu domain the same way.
>
>Note: These older Os's are going to be around for a while for support
>(eventhough not officially anymore, users are still out there with these
>OS's and we still provide "best effort" support). These machines are also
>part of the old domain right now.
>
>The other two Winathena Callcenter machines can be accessed directly and be
>used as usual for taking regular calls and also to get hands-on experience
>for ourselves on machines that are part of the Win.mit.edu domain. This way
>we can also support clients with troubleshooting their Winathena problems
>and we can remain running tests for pushing out software updates, MS
>updates, etc. that can give feedback to you and other container admins.
>
>I will add the personal machines for support staff to Helpdesk container in
>the Win.mit.edu domain at the specific users request as well.
>
>As you can tell there are a lot of specific setups tied into the domain and
>Callcenter that have taken a lot of time to crystalize over the years and
>things are running smooth at this time. We want to minimize the impact that
>moving to a W2K domain is going to have on our daily business of
>supporting our clients as well as our own working environment.
>
>As mentioned, the ghosting part will remain the same, either in a separate
>or Win.mit.edu's domain.
>
>Can you provide me with the script to "route" the roaming profiles so we can
>test this on the Callcenter machines that are already in the Win.mit.edu
>domain ?
>We will need to let our users know where their profile will go and how to
>change this if they are working on the Winathena machines in the callcenter.
>
>Let me know what migration plan you can offer and what information you need
>from me to create this.
>I will make a separate request for our own DNS zone through the webpages.
>
>
>Regards,
>
>
> > Hi Fred,
> >
> > Thank you for allocating time to meet today.
> >
> > We discussed four issues which prompted you to inquire about specific
> > functionality in an independent domain vs. the central win.mit domain.
> > 1) Ghosting machines and the SID.
> > 2) Desire to store roaming profiles elsewhere than AFS (on standalone or
> > member server).
> > 3) Client authentication to stand alone or member servers, for file access
> > and such.
> > 4) Migration path and plan.
> >
> > Naturally, the final decision to operate an independent domain if you wish
> > will be up to you as the customer.
> > But as we discussed, the burden might not be worth it if the functionality
> > you seek could be achieved through the central Windows domain.
> > This would be especially true if the same obstacles such as extra steps in
> > ghosted machines joining the domain would have to be performed in either
> > domain.
> >
> > The conclusions we arrived at during our meeting were verified Paul. I
>will
> > list them here:
> > 1) Ghosted machines will have to "rejoin" the domain in order to acquire
> > new and unique SIDs. After a machine is ghosted, it's unique host name and
> > network parameters entered, and it's instance deleted from AD, the machine
> > will have to join the domain to acquire the SID.
> > This would be true in an independent domain as well.
> >
> > 2) The development team has a web interface which allows users to point to
> > where they want their roaming profiles stored. This interface though is
>not
> > public yet as of today. Please note that this allows the users, and not
>the
> > system admin, to change the profile settings, through their Kerberos
> > principle.
> > Sys Admins can control roaming profiles without user consent in a standard
> > windows domain.
> >
> > 3) Client authentication to a stand alone server can be achieved through
> > local accounts. If the server is a member of win.mit then you can take
> > advantage of moira group ACL'ing.
> >
> > 4) We discussed possible upgrade paths and scenarios during our meeting.
> > Once you decide on a direction, we'll work on developing a detailed
>upgrade
> > and migration plan.
> >
> > We also talked about roaming user environment on Mac OS10 and
> > interpretability with AD.
> > I chatted with Al Willis and we agreed that it would be best if you put
> > your Mac Sys Admin directly in touch with AL.
> >
> > We are also willing to help you set up If you feel that you need an
> > independent domain for support training purposes.
> > We still owe you a delivery date on the profile web page.
> > Please let me know if you develop other questions between now and a time
> > when Paul and I can visit with you.
> >
> > Thank you,
> >
> > Wael
> >
> >
