Monday, November 10, 2003
netbios names and msdfs
exploring more mysteries of msdfs.
1) the fully qualified server UNC path always works, either through the dns name or c name:
given this link:
These will work:
\\msdfs-server.foouniversity.edu\msdfs\class\intro-233
\\samba.foouniversity.edu\msdfs\class\intro-233
...but, unqualified, only the dns name of the server will resolve
\\samba\msdfs\class\intro-233
entering this path
\\msdfs-server\msdfs\class\intro-233
get an error that the path can't be found.
At least gave the error until I rejoined the server to the domain using the c-name as it's netbios name. Or maybe its working on Win2K but not XP Pro. Or maybe it will work once the dfs cache times out on my XP pro client.
UPDATE: next morning.
The XP pro box started working the following morning, suggesting the msdfs clinet cache is making it difficult to troubleshoot this in a timely manner.
exploring more mysteries of msdfs.
1) the fully qualified server UNC path always works, either through the dns name or c name:
given this link:
intro-233 -> msdfs:classdata.foouniversity.edu\classes\fall03\intro-233
These will work:
\\msdfs-server.foouniversity.edu\msdfs\class\intro-233
\\samba.foouniversity.edu\msdfs\class\intro-233
...but, unqualified, only the dns name of the server will resolve
\\samba\msdfs\class\intro-233
entering this path
\\msdfs-server\msdfs\class\intro-233
get an error that the path can't be found.
At least gave the error until I rejoined the server to the domain using the c-name as it's netbios name. Or maybe its working on Win2K but not XP Pro. Or maybe it will work once the dfs cache times out on my XP pro client.
UPDATE: next morning.
The XP pro box started working the following morning, suggesting the msdfs clinet cache is making it difficult to troubleshoot this in a timely manner.
Friday, November 07, 2003
netbios aliases
I tried adding an alias to the test samba 3.0 server. After a few mintues, the server failed to authentice users to the domain. Looking in srvmgr.exe, I noticed that the alias name was in there. Looks like it screwed up the trust.
I tried adding an alias to the test samba 3.0 server. After a few mintues, the server failed to authentice users to the domain. Looking in srvmgr.exe, I noticed that the alias name was in there. Looks like it screwed up the trust.
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.
