[OpenAFS] Mapping drives on Windows

[Cameron, Frank]

>> You can use NET USE to map your drives.
>>    Set Start AFS Client when computer starts
>>    place in your logon script:  net use T:
\\yourComputerName-afs\yourPath
>
>How do you do this if the logon script is shared among many machines?
>(Is there a reason \\localhost-afs\yourPath could not be made to work,
>for example?)
>
>I am curious how one is supposed to carry out a large-scale AFS
>deployment to Windows machines.  Is there a reason for tying the AFS
>configuration to the machine name?  At first glance, it seems like
>needless variation among the clients.

In a login script you can:
    net use Z: \\%COMPUTERNAME%-AFS\all
but, this doesn't work for 9x machines that don't set the COMPUTERNAME
environment variable.  For 9x machines (or NT) you could use a small
little program to read the computer name from the registry and make it
useable.

Another drawback is if you have machines with long NetBIOS names, the end
of the name will be truncated so '-AFS' can be appended.  Also, special
characters that are valid in NetBIOS naming but invalid DNS naming are
converted (eg '_' becomes '-').  In both cases just using the machine's
name will fail.

I would love to be able to just use \\localhost-afs\... or something
similar.  However, it is not as simple as just modifying the code to use
'localhost' instead of the NetBIOS name when generating the new AFS name
because, the name that is generated must be unique on the NetBIOS network.

I had three W2K Terminal Servers with long names like THISCITY-CITRIX1,
THISCITY-CITRIX2, and THISCITY-CITRIX3.  Because the names were so long
they were being truncated and because the only difference in the names was
the last chracter, the truncated names were identical.  So, the first
machine up would register the name and the other two would fail to start
the service (with an obscure reference to smb.c line XXX).  After
installing a newer client release with a more descriptive error message
(failed to register NetBIOS name) I renamed them just CITRIX1, 2, and 3 to
get things working.

-frank

P.S.  When we deployed to our machines I wrote a little program to run
post-install that replaced the ini files and registry keys with custom
default settings for the cell and drive mappings automatically and setup
our unattended install to run it after the install proper and before the
reboot.  A nice side-effect of this is I can run that program on a machine
with a hosed up config and (often) get it working again.  However, we still
had to (and must continue to do so when a machine gets a new user) modify
the
user's 'personal' drive mapping in the client config.