Thursday, November 06, 2003
msdfs
Starting to create the msdfs root on our samba domain controller. I just occoured to me the we can put the msdfs tree into production without having samba controlling the domain.
the plan is to push out the same profile and home dir path for all users:
\\msdfs-server\msdfs\home\%username%\profile
\\msdfs-server\msdfs\home\%username%
and on the server itself, the /msdfs/home directory is filled with symoblic links:
Noticing some interesting things.
1) Even if you stop samba on the msdfs server, the drive maps still work for the user. Even when the drive mapping is labled "aa46 on msdfs-server\msdfs\home" . Windows seems to know the real location of the data.
2) The msdfs share, likewise, doesn't seem to need the "profile acls = true" paramerter set, as long as the server hosting the actual profile has it.
...and right now I changed the "home" folder to another name, then back again, and I can't get into it from a windows session which has persisted through the name change, even though I can map to the subdirectories. So msdfs seems to cache a lot of info on the client side.
Some more research shows that clients cache the connections for a while (90 minutes or so) so changes made to the dfs tree can cause problems for a while.
Starting to create the msdfs root on our samba domain controller. I just occoured to me the we can put the msdfs tree into production without having samba controlling the domain.
the plan is to push out the same profile and home dir path for all users:
\\msdfs-server\msdfs\home\%username%\profile
\\msdfs-server\msdfs\home\%username%
and on the server itself, the /msdfs/home directory is filled with symoblic links:
lrwxrwx--- 1 root root 36 Nov 6 13:05 aa46 -> msdfs:homeserver.foouniversity.edu\home\aa46
Noticing some interesting things.
1) Even if you stop samba on the msdfs server, the drive maps still work for the user. Even when the drive mapping is labled "aa46 on msdfs-server\msdfs\home" . Windows seems to know the real location of the data.
2) The msdfs share, likewise, doesn't seem to need the "profile acls = true" paramerter set, as long as the server hosting the actual profile has it.
...and right now I changed the "home" folder to another name, then back again, and I can't get into it from a windows session which has persisted through the name change, even though I can map to the subdirectories. So msdfs seems to cache a lot of info on the client side.
Some more research shows that clients cache the connections for a while (90 minutes or so) so changes made to the dfs tree can cause problems for a while.
