[OpenAFS] Roaming Windows Profiles

[Rodney M Dyer]

At 05:01 PM 2/5/2003 -0500, you wrote:

>My observations follow.  Do they agree with your experiences?
>
>         The profile needs system:anyuser l access (for windows to "see" the
>                 profile exists prior to getting tokens)

This can be worked around.  I describe how in previous mail to infoafs.

>         AD won't let you redirect folders with arbitrary variables
>                 (so, it's possible to redirect all users' profiles to
>                 /afs/cell/home/user/WinProfile, but cells that have
>                 /afs/cell/home/u/user/WinProfile must set each profile
>                 location for each user separately--or create another
>                 separate set of mount points).

Our "N:" drive is globally mounted by a group policy startup script when 
the workstations boot.  In our logon process we "subst" the "U:" drive to 
the user's home directory on "N:".  In the group policy for folder 
redirection we refer all redirections via the "U:" drive.  That solved the 
problem.

>         It's necessary to ensure that My Documents, etc does NOT roam, but
>                 is redirected into AFS... otherwise login/logout times
>                 increase substancially over the same setup without AFS.

Yep, that's what we did.


>         Certain files, like MS office docs, shouldn't be opened directly
>                 out of AFS due to assumptions about byte-range locking
>                 which AFS doesn't support... so access to non-roaming
>                 space is still required.

You don't need to be worried about this unless you are sharing the 
documents with someone else through the AFS file system.  For all personal 
documents in the users home directory byte-range locking and sharing 
doesn't matter at all.  We did however have some troubles that seem to be 
resolved now related to Outlook PST (mailbox) files becoming corrupted in 
AFS.  This was due to a sparse file problem I believe.  The following 
registry information seems to solve the problem...

; Minimizes having to repair .pst file

[HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\PST]
"PSTNullFreeOnClose"=dword:00000001


In the case where you need to share documents and databases between users 
we've setup a Microsoft dfs tree off of our active directory domain that is 
just for that purpose.  Since our AD trusts our MIT kdc tgt's there is no 
authentication required to use the share other than logon.


>Others I'm forgetting?

AFS on windows can be somewhat unstable over time, or during the use of 
large files, or using many many files.  We have watchdog processes that 
occur on the hour, and during logon that make sure the afs service stays 
running and the AFS "N:" drive stays linked.  Strangely sometimes just 
loosing network connectivity for short intervals can cause the AFS service 
to lock-up under windows.  We've done all we can to keep the afs service 
stable.  For something that derives from the UNIX world, I don't understand 
why the afs service is not as stable as a rock.


>Cheers,
>Stephen
>--
>Stephen Joyce
>Systems Administrator                                            P A N I C
>Physics & Astronomy Department                         Physics & Astronomy
>University of North Carolina at Chapel Hill         Network Infrastructure
>voice: (919) 962-7214                                        and Computing
>fax: (919) 962-0480                               http://www.panic.unc.edu