Magic Pseudo Domains
- How to over-complicate a simple network
Premble
At home I am the network admin. I have no choice really, no-one else is going to do it, so over the years network admin has become something of a second hobby to my programming. If i wasn't a perfectionist, life would be much simpler, as I could simply make things work (however convoluted the method may be) and leave it at that, but unfortunately I have a tendency to want to make things as easy to use and as consistent as possible, so things tend to drag on a bit.
Anyway, the problem I faced at home was this, my family have two PCs, one upstairs, and one downstairs. They thus have to deal with the annoyance that all their documents, settings, etc are stored in two different places. There are multiple avenues with which to proceed with, all of whihch however could be grouped under one of two main methods, centralisation or replication.
Replication is the more wasteful storage-wise of the two, but with that comes built-in distributed backups of their data, which isn't such a bad thing. The actual synchronisation however is the trick, as there is still the issue of merging conflicts should the users be logged on in two places at once.
Centralisation is the other option. I considered either storing their profiles on one of the machines (in essence making it a file server), as well as moving the profiles to the machines where they were most commonly used (though it would necessitate both PCs being on and would complicate things no end). Another option is to set up roaming Windows profiles. This requires a domain to be set up and the machines added to it. The problem here is that many of XP's new features have issues when joining a domain, including but not limited to:
- FUS
- Welcome
- Offline files
Of these only one or two really mattered, the loss of the welcome screen coming in a close second to the loss of fast user switching.
I found a solution to the fast-user switching and welcome screen problems after noticing FrontMotion's FMLogin software. The minor downsides to this software are it's dependence on Flash, it's unfixed bugs (another reason I prefer open source software), and its imperfect integration with the windows shell. Those aside, its a nice piece of work, and free for non-commercial use. Still, it's not quite what I'm after, so I'll probably write my own welcome screen replacement at some point.
Oh yeah, just for reference, the special trick required to enable fast user switching when you're on a domain is to simply set the registry value HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AllowMultipleTSSessions = 1. Thats it, it's effective immediately (look at task manager's new "users" tab for proof of that). Re-enabling the welcome screen can be achieved by setting the value HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\LogonType = 1 as well. That value is only used by the default login process so it can switch between the NT-style login (0) and the welcome screen (1) login types. Why Microsoft went to all the effort to have part of the logon system customisable but then couldn't finish the job with all their resources is beyond me. Though be warned, Windows, in it's infinite wisdom, will try and change it back to the normal values whenever it can. The only place I've noticed this explicitly is when default login process is activated.
At this point a domain-based setup seems like the best bet, but I've worked with domain setups before, and I didn't like roaming profiles one bit, roaming profiles do not handle simultaneous logons well at all.
Implementation
So I decided that I'd create my own little hybrid setup, having non-roaming domain profiles can come later after I make my welcome screen replacement, and until then I'll just set up local profiles all using centralised file storage, (incidentally, this method should also work with XP home and it's crippled lack of features e.g. not being allowed to join a domain.)
Which should all work in theory...as always though, in practice it doesn't. Right off the bat I made things hard for myself by using Samba on Debian Sarge as my file server. It works well now that I have got quotas, POSIX ACLs, and extended attributes setup correctly, but it still causes problems as the ACLs are not the same, though Samba does a stellar job of translating between the two.
The first step of migrating the user profiles to the server is to decide on a profile structure, as you now have to bear in mind that multiple OSes will be potentially using this profile. I decided to Set up four folders in the UNIX profile; ".Win9x", ".WinNT", ".WinShared" (for the files that the profiles share, such as the start menu, etc), and finally documents (aka. the my documents folder.)
The next step is to decide what you want to do with the all users profile. You can leave in on the workstation as it currently is (providing a workstation set of common applications) or you can move it to the server with the rest of the profiles.
I chose to move it, as I was attempting to get the default welcome screen to display the user pictures from a central location. I promptly discovered that the welcome screen will only read the pictures from a single location, the files being %ALLUSERSPROFILE%\Application Data\Microsoft\User Pictures\%USERNAME%.bmp for each user on the screen. However, it will not access them from a network path, even if said path has read access for the guest account. The stupid thing is though, if you log on the off again, the welcome screen will show the pictures! Thus, even whilst not using a domain setup, I have still been thwarted by the shoddy implementation of the welcome screen. Yet another reason to make a better one then.
Niggles
Moving and merging the allusers profile on the whole went fine, bar a slight hiccup with the antivirus software. The software (like I suppose many others) assumes certain things about the all users profile, namely that any user can write to it, as well as control the ACLs of the files within it. This I was unhappy about, as it meant I had to relax quite a few folder's worth of permissions (i.e. give the nobody user rwx access) so that the software would install. All I can do is put it down to good practice for the next badly-witten piece of software I need, I suppose.
I'm sure they had a good reason. There must be one, but I can't think of it. Microsoft, in their infinite wisdom, blocked Windows XP from allowing you to customise folders (e.g. changing the icon for it) on a network filesystem, even if you map a drive. They state explicitly in the knowledgebase that you cannot do it. Strangely enough, once again, I found that you can, if you do it manually.
The file "desktop.ini" is the key here, as it is a rather important one of Window's bodge mechanisims. All sorts of information can go into this file, very little of which is officially documented, though I have found out quite a bit in my experiments. Changing a folder's icon simply requires:
...and then all you need to do is set the folder's system attribute and Bob's your uncle.
Another thing I discovered was the aliasing that can be performed on folder names using the desktop.ini file. Unfortunately this is not extendable, as it only performs rewriting for 5 or so system folders. This is how XP presents you with both "otheruser's Documents" or "My Documents", depending on who is looking at the folders. I'm tempted to hack around with shell32.dll's string table to try and add more in, but I fear it will not work due to code constraints. I'm still hopeful though.
