[34] in Kakapo Windows Team
Re: WIN deliverables
daemon@ATHENA.MIT.EDU (Kerem B Limon)
Thu Jul 17 12:29:37 2003
Message-Id: <5.2.0.9.2.20030717122011.090b0d60@hesiod>
Date: Thu, 17 Jul 2003 12:29:26 -0400
To: "Thomas L. Thornton" <tomt@mit.edu>
From: Kerem B Limon <kerem.limon@MIT.EDU>
Cc: kakapo@mit.edu
In-Reply-To: <200307171523.h6HFN95D002473@the-rim.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Tom,
Can we get access to the "test MSIs that work on XP" in the interim?
Specifically, IS internally, the Delivery Team, and Arch/DUSP have asked
for them to test Windows XP machines in the domain, Arch and DUSP
sepcifically just to see if their existing MSIs will install on their
machines. I think all involved realize that these are not the final
product, but are willing to work with whatever's available.
I have some related questions:
o There was, at some point in the near past, a manual method of installing
some prior version of OpenAFS after joining a Windows XP Pro machine and
getting some semblance of what it may be like having a Windows XP machine
in win.mit.edu. Has that changed? Is it still possible or not? If yes, what
are the caveats, and if no, what is the impediment--e.g. OpenAFS version
incompatibility, etc.?
o When I spoke to Paul on Tuesday about the OpenAFS deployment testing, I
asked whether the fact that you are doing deployment testing indicates that
you have come to a stop in hacking/changing/tweaking/fixing (whichever's
appropriate) OpenAFS code to make it work in the domain, and have moved on
to getting it to actually deploy properly. He indicated that was the case
and the deployment issue had hit an undocumented Microsoft bug, which has
been escalated to PSS. My question then is, can we get that version of the
code and possibly instructions on how to manually install/configure it on a
joined machine (bypassing the GP deployment) to create the desired end
result? Am I making an incorrect distinction between OpenAFS code changes
and work needed to get its MSI package to deploy in the domain?
o So, with these two, in effect, I am asking the question of whether it is
possible to have a Windows XP Pro machine in win.mit.edu,
manually/automatically/or through some combination of those configured,
until the deployment issues are resolved and you can officially say that we
can do it. This is very important, because it determines what we can tell
Arch/DUSP as well as internal IS customers who have been asking for it.
I am also glad to discuss the details in person in an hour.
Thanks!
Kerem
At 03/07/17 11:23 Thursday, Thomas L. Thornton wrote:
>I am reminded that you should get a quick review of where we stand on
>win.mit.edu deliverables. In the past couple weeks we have been
>mostly striving to complete an OpenAFS.msi that is deployable by Group
>Policy. While we have a couple test MSIs that work on XP when
>hand-installed, testing the Friday version shows the ability to deploy
>it through Group Policy uncovers a Microsoft bug, documented by PSS.
>We may have their workaround, in hotfix form, Any Time Now. Paul
>thinks that once we verify that this bug is overcome, he will have a
>GP-deployable MSI within days.
>
>Note that Paul and I are out Monday-Thursday next week.
>
>The Pismere.msi was also ready on Friday. It has been separated from
>the AFS installer and contains new locker utilities and a few other
>features. Testing here goes on, so far without any problems. It will
>be ready for test container admins to deploy when we are happy with
>OpenAFS by GP.
>
>New Member Server security and settings documentation is posted at
>http://mit.edu/pismere/support/for-cont-admins/security-info. The two
>documents are accurate and pretty useful, but Kevin Weston, the
>just-graduated student working on them, expects to expand them over
>the summer.
>
>Subcontainer documentation is posted and available at
>http://mit.edu/pismere/support/for-cont-admins/subcont/acldraft.txt .
>
>Please send any comments.
>
>-Tom