[OpenAFS] Openafs-Client and Windows
Jason Garman
jgarman@wedgie.org
Tue, 4 Mar 2003 22:36:17 -0500
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