[OpenAFS] AFS in a Windows business environment

[Cameron, Frank]

After migrating 95% of the users at our main site (roughly 50% of total
users nationwide) here is a short list of the issues we've had with trying
to use the AFS client in a Windows business environment.  We are using IBM
AFS on the (Sun) servers and on most of the Windows clients; there are a few
OpenAFS 1.0.4 clients on machines that had trouble with the IBM client.

1> Lack of byte-range locking
This largely raises its head for us regarding Outlook PST files.  Many of
our users are heavily dependent on using PST's and most store them in their
network folders so they get backed up.  Unfortunately, when stored in AFS
space the files are corrupted.  So now, we are forced to continue to
maintain the legacy file areas for the sake of Outlook files.

2> Client Issues
	a> Dial-up Access
	When not connected to the network (either because of a problem or
because the laptop has gone home for the night) the service fails to start
(I don't have a test machine handy to get what line of smb.c it fails at).
On NT4, the service can successfully start after connecting to the network
(usually via RAS) if the user is a local administrator (giving a user local
admin rights is strictly prohibited by our security policy).  On W2K
however, the service cannot be started even after establishing a RAS
connection.  The service fails to start because it 'cannot reset LAN
adapters' (which when seen in other contexts has been a NetBIOS
configuration problem).  So, from NT it is possible, though inconvenient, to
access AFS over a dial-up link; but, from 2K, it is not possible to access
AFS over a dial-up link.  I have some thoughts for a small NT wrapper
service that would wait for an active network connection and then start the
AFS service proper.
	b> Managing ACLs and Groups
	Things missing:
		A recurse subfolders option when setting ACLs
		A user/group list (ideally displaying both user name and
full name) when setting ACLs
		A GUI interface to create/manage personal groups
	c> Drive Mappings
	The current drive mapping scheme works but, it is difficult to
manage consistently across many desktops.  Particularly, since AFS is
accessed through a NetBIOS name that is unique to each workstation, it is
difficult to reliably use login scripts to enforce standard drive mappings
that follow users from machine to machine.  Ideally, AFS would be accessed
through the same NetBIOS name from all machines (\\AFS perhaps?).  This way
a single login script command can easily (and most importantly reliably) be
used in scripts; this also has the happy benefit that UNC-lovers can go to
any machine and happily run \\afs\cell\users\me\mystuff\.
	d> Disconnection
	Sometimes when the network link is disturbed the AFS daemon will
consume 100% of system processor time (this could have relevance to 'a'
above).
	e> Password Change
	Ideally, AFS cells would be listed just as NT domains and NDS trees
are listed in the standard Windows password change dialog box.
	f> Token Renewal
	Ideally, it would be possible to renew tokens when unlocking the
workstation.

I have this feeling that I'm leaving out something big; but, that's all that
comes to mind right now.  If I had to order the above by importance I would
say: 1, 2a, 2d, 2b, 2e, 2f, 2c.

That said, overall AFS is great and head-to-head (except primarily for the
file lock issues) is a better place to store files than on an NT file
server.  The comparison to NetWare is stickier; but, again AFS wins overall
(primarily for the server independence).

-frank