[OpenAFS] Openafs-Client and Windows

[Jason Garman]

For what it's worth...

I'm using the W2k AFS client with a bunch of Terminal Services boxes.  
I have a login.bat file that copies the afsdcell.ini and afsdsbmt.ini 
files from a centralized location to the users' Windows directory in 
their profile (right now we're not doing roaming profiles).  Then I use 
a series of 'net use' commands to map the appropriate drives for the 
user, with the /persistent:no flag.

It looks something like this:

copy %SystemRoot%\afsdcell.ini "%USERPROFILE%\WINDOWS"
copy %SystemRoot%\afsdsbmt.ini "%USERPROFILE%\WINDOWS"
reg import "\\pdc\netlogon\wake.reg"

\\pdc\netlogon\wakedist\program\wake\wake.exe
net use u: \\%COMPUTERNAME%-afs\users\%USERNAME% /persistent:no
net use x: \\%COMPUTERNAME%-afs\root /persistent:no
net use y: \\%COMPUTERNAME%-afs\users /persistent:no
net use z: \\%COMPUTERNAME%-afs\cell /persistent:no

The users don't have any access to the AFS token management system tray 
utility so I don't worry too much about that (I don't know off hand if 
the users can create mounts in there that'll affect other users...)

On Monday, Mar 3, 2003, at 15:35 US/Eastern, James Peterson wrote:

> "User A logs in and maps some drives and works under afs. User A logs 
> off.
> User B logs in and gets the drivemappings of user A. He has no access 
> to the
> files, but why he must get the drives mapping. "
>
> It is a design feature of Windows that it attempt to map the previous 
> state.
>
> It is a good idea to place the user table in "user" related area, 
> either in
> the registry or in the Application data area.  It is also a good 
> design to
> keep these tables out of the Windows/system area, because this is 
> frequently
> "write" protected for the user's own good.
>
> "The client stores some Inforamtion about the drivemapping k: in the
> Registry: [HKEY_CURRENT_USER\Network\K]
> "RemotePath"=3D"\\\\W2KTSRV2-AFS\\auto1"
>
> Actually windows does that as a process of logoff.  It is not a 
> function of
> the AFS client.  The only way to prevent that is to dismount the AFS 
> drives
> through a hook, prior to logoff.  This is especially important to 
> Terminal
> Server and security issues.
>
> "The client says the service is running but it doesn't work. OK."
>
> AFS client Terminal Server support needs to get a hook into the logout
> process in order to clean up the last users drive mapping.  The AFS 
> client
> also needs to have multiple locations of .ini files (as you stated).  I
> didn't have the energy to get the Terminal Server issues worked out;
> however, I would love to support our mapping out these issues.  There 
> was
> quite a response to the topic of roaming profiles and I have been 
> collecting
> various methods of use.  I would recommend you 'bone up' on past 
> responses
> and then we could specify a general solution that works for most of the
> community.
>
> Of course Open AFS is a volunteer effort and you don't have to take 
> any of
> my suggestions.
>
> James
> "Integrity is the Base of Excellence"
>
>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info