Windows Phone 7

First off, apologies for the incredible dearth of posts for the past 3 months (Jesus!). I should have more on that soon. Suffice to say, I'm not dead.

Meantime, I wanted to just point out the Ars review of Windows Phone 7, which I'm presently in the midst of skimming. And I have to say, I'm impressed. It looks very promising and it's the most attractive, forward thinking thing I've seen come out of Redmond in, well, maybe since I started using computers, which would be about 12 years.

I'm intrigued by the largely text-based visual approach, and the incredibly spartan, almost institutional iconography. In a world of imagery overload there is something very appealing to me about this look, and I'd imagine it will appeal to the business set as well. It's classy but not cutesy the way iOS can be.

It's not often (ever?) I post something positive about a Microsoft product. And I don't know if it will be successful. But I have to admit, Windows Phone 7 looks, if nothing else, interesting.

Window for One

Like a lot of SysAdmins, I work in a cave. No windows except for the odd Dell system, of course. No natural light whatsoever. It can get depressing. So I was pretty intrigued when I saw this Winscape virtual window.

I've actually had this idea for some time. Get a large, bright screen and show video of the outdoors on it. Hang it on the wall and frame it with some trim so it looks like a window, and voila! Instant techno-window. But this rig adds one cool wrinkle: parallax. Parallax is the changing of said view out said window as your position relative to said window changes. Simply playing video of the beach on a screen will yield less realistic results as it will lack the parallax effect.

Parallax in the Winscape rig is achieved with a transmitter on the viewer that sends location to a sensor on or near the virtual window display. As the viewer moves relative to the screen, a computer tracks the movement and updates the display accordingly.

As someone who deals with a lot of art and museum installation, I can tell you that there is at least one big potential problem with this kind of setup. How do you deal with more than one viewer?

The Winscape system, while cool in concept, is clearly only suitable for the basement-living single crowd. Pity.

A Brief Foray Into Windows

I just had a rare occasion to use a Windows XP machine here in the lab. Oy, was it painful! All I wanted to do was take three simple screen shots — just three — for an instructional article I was writing for our community. It took a half an hour.

I started, of course, by logging in to a Windows box. That went fairly smoothly. Type my name and password, and, sure enough, I get in. So I open a new window by going to the Start menu and clicking "My Computer," although it's not my computer. It's anything but. Still, "My Computer" gets the new window open. I take my first screen shot by hitting the "Print Screen" key. Yes, Windows has a dedicated screen capture key called "Print Screen." Hit it and it sends the entire screen to the clipboard. Not to a file, mind you. To the clipboard. Next you'll need to open up some kind of image editor. I chose the venerable Photoshop CS3. Opened the app, created a new document, and hit control-v to paste my screen grab in. Good (if a bit of a pain in the ass) so far. Next I made some settings in my open window, and made another screen grab. And once more for good measure.

In Photoshop I decided that it would be best to save my files to my centrally-located network home account, so I hit the save button and navigated there, named the file, and... The Save dialog crashed. After waiting about five minutes I decided that the only thing to do was to force quit Photoshop, which I did, losing all my screen grabs and necessitating beginning the entire process anew.

Windows XP: Definitely Not My Computer (click image for larger view)

The next time around I saved each of my screen captures locally as I went, and that seemed to go okay. Next I just wanted to copy these documents to my network account so I could access them from my office Mac, but the copy failed, producing a meaningless error message. Looking through my files, however, it was clear what the problem was. Apparently, during the crash Photoshop had spewed about three thousand temp files all over my home account, and these needed to be deleted before Windows would copy anything over.

So, I began the process of deleting these three thousand or so files by selecting about six hundred of them and hitting the delete key. I kind of like that Windows' delete key actually deletes stuff. That's a nice touch. What I didn't like was that deleting 600 zero byte files was going to take four minutes. But what was I to do? I went ahead with the file deletion. Four minutes of sitting and watching that miserable, 8-bit trash deletion progress bar — you know, the one where the trash files fly through the air and dissipate in a big pink sparkle — is enough to turn just about anyone's brain to mush. Which is probably why, after it was all over I went ahead and switched to list view (though there seems to be no way to make this setting stick across windows) and selected the remaining 2400-or-so files, right-clicked and hit delete.

Eleven minutes?! Argh!

With some time to kill I decided to log in to an adjacent Mac. Once logged in the Windows brain-fog cleared and it dawned on me: I could just delete the files from the Mac! And it won't take eleven frickin' minutes!

And by golly, that's just what I did.

Eleven seconds later I was able to copy up my files from Windows to my network account and get on with my life.

When I think of how easy all that would have been on a Mac I'm appalled. Absolutely appalled. Windows is ugly, flimsy and crash-prone by comparison. And the user experience is dead-awful. It's no wonder I avoid it like the plague.

God help the Windows Admins! You have my pity.

Mac OS X Server 10.4.8 Breaks Windows Quotas

It's great to finally have something systems-related to post about amidst the endless bureaucracy that fills my days lately. Of course that means that — yup, you guessed it — something broke. But hey, that's what it's all about. Well, that and the fixing of said brokeness, of course.

So we recently discovered that our Windows clients were suddenly, and without explanation, able to greatly exceed their roaming profile quotas. In fact, looking at the roaming profile drive showed users with upwards of 25 GBs in their roaming profiles, which have quota limits of 50 MB. Not only that, but further testing revealed that Windows client machines wouldn't even complain if they went over quota. Any SMB connection to the roaming profile drive could exceed the quota limit without so much as a complaint from server or client. AFP worked. UNIX worked. But quotas were ignored over SMB. What the fuck?

For three days I've been trying to track this problem down, testing all sorts of quota scenarios and SMB configurations in between meetings and meetings and more meetings. Eventually, when I can't make headway on a problem, I start thinking it might just be a bug. So I started poking around in the Apple Discussions, and I found one and only one complaint of a similar nature: 10.4.8 Server with broken quotas on Windows. Had I recently done a system update that perhaps broke quotas?

So I started thinking about what in a system update could break such a thing. How do quotas work? There is no daemon. A colleague suggested that they were part of the kernel. Had I done anything that would have replaced the kernel in the last month or two?

The answer was yes. Over the winter break I had decided to update the server to version 10.4.8. Upon realizing this I began to strongly suspect that Mac OS X Server 10.4.8 contained a bug that broke quotas over SMB. Fortunately, as is often my practice, I'd made a clone of my 10.4.7 server to a portable firewire drive before upgrading. Testing my theory would be a simple matter of booting off the clone.

Sure enough, after booting from the clone, quotas began behaving properly on Windows clients again. Because I had the clone, reverting the 10.4.8 server back to 10.4.7 was a simple matter of cloning the contents of the firewire to the server's internal drive and rebooting. Voilà! Problem solved!

From now on I think I'll hold off on server updates unless I really, really need them. When it comes to servers, I think the old adage is best: If it ain't broke, don't fix it.

Three Platforms, One Server Part 12: AFP Network Home Accounts

I hit another minor but infuriating snag in my plan to unify the network, though this one was all Apple. It's another case of Apple making serious changes to the way you're supposed to set your server and clients and never really trumpeting much about it. Seems everything I used to do with my server and clients is done either slightly — or in some cases radically — differently in Tiger than it was in Panther. I must admit, I never checked the manuals on this, but something as simple setting up AFP networked home accounts has become a much more complex process in Tiger than it ever was in Panther, and it took me quite a while to figure out what I had to do to make it work like it did in the Panther glory days.

Now, to remind, we don't really use AFP networked home accounts for most users. Our users' home accounts live on an NFS server — a separate machine from our authentication server — which is auto-mounted on each client at boot. The only value the authentication server stores for most users' home accounts is where those home accounts can be found on the client machines, which in our case is /home. So I haven't had to worry too much about AFP network home accounts. Until last week.

There is one exception to the above standard. Certain Macromedia products do not function properly when the user's home account is located on our NFS server, for some reason. In particular, Flash is unable to read the publishing templates, effectively disabling HTML publishing from the app. This has been a long term problem and has affected every version of Flash since we moved to our NFS home account server almost three years ago. Our solution has been to create a special user — the FlashUser — whose home account lives in an AFP network home account. When people need to work with Flash, they are encouraged to use this FlashUser account so that they can use the publishing features. This is inconvenient, but it works and we're used to it, so we keep doing it until we find a better solution. Unfortunately, when I built my master authentication server (actually, when I rebuilt it) I forgot to add the FlashUser. The teacher of the Flash class eventually came to my office and asked about the account, and I told him it should just take a minute or two to get it set up. Boy was I wrong.

The FlashUser account was always a simple AFP network user account. The user's account information and actual home account data were both stored on the same server, the data shared via an AFP share point, and configured in Workgroup Manager's "Sharing" pane as an auto-mounted home folder. According to this article guest access must be enabled on the AFP share to auto-mount. Well, that's new in 10.4, and I had no idea. And beyond that, I think it sucks. Why should guest access be enabled on a home account share point? This didn't used to be the case, and it seems way less secure to me in that by doing this you open the entire AFP home account share to unauthenticated access. Bad. Why in the hell would they change this? Not only is it less secure, but it breaks with tradition in ways that could (and in my cases did) cause serious headaches for admins setting up AFP networks home accounts.

Fortunately, after many hours of trial and error, I discovered a way to accomplish the same thing without enabling guest access on the share. It is possible, but it's quite a pain. Nevertheless, it's what I did.

Guest access can be foregone if trusted directory binding is set up between the client and the computer (which still makes no sense to me. You either have to go totally insecure, or set up an insanely secure system. Seems like we could skip the trusted binding thing if you'd just let us set up the shares sans guest access like we used to do.) Trusted binding is a bit of a pain to set up in that, as far as I know at this point, the only way to set it up is to go to every machine, log in, and run the Directory Access application. Apple really, really, really needs to give us admins some command-line tools for controlling DA. The current set is paltry at best, though I do need to look and see if there is one for setting up client-server binding (there might be, in fact it might be called dsconfigladp though this tool can not be used for setting authentication sources, for some ungodly reason, and I have yet to try it for the purposes of directory binding). But before you set up your clients, you must be sure "Enable Directory Binding" on your server is checked in the Server Admin application. By default it's not. And, at least in my case, after enabling directory binding, I had to restart my server. Fun stuff. Also, I'm fairly certain this requires a properly functioning Kerberos setup on the server, so if you're just starting out, be sure to get Kerberos running right.

Directory Access: Enable Directory Binding
(click image for larger view)

Next you need to go to your client machines one by one and bind them to the server. If you've already joined your clients to a server for authentication, you can simply navigate to the server configuration in DA, click "Edit..." to edit it, and you'll be presented with a "Bind..." button that will walk you through the process. If you haven't yet joined a client you will be asked to set up trusted directory binding when you do. From there you need to enter the hostname of the client machine, the name of a directory administrator on your server, and that user's password. In my case, I needed to also reboot the client machine. Like I said, kind of a pain.

Directory Access: Configure LDAP
(click image for larger view)

Directory Access: Edit Server Config
(click image for larger view)

Directory Access: Hit "Bind..." to Set Up Trusted Directory Binding

(click image for larger view)

But that's it. You're done. (Well, 25 computers later, that is.) I now have my F lashUser set up again, and auto-mounting its home account in the usual way (none of that "Guest Access" shit), albeit with considerably more effort than it took in Panther. This is, in my opinion, just one more reason to hate Tiger, which I generally do, as long-term readers are well aware. It's another case in which Tiger has gotten harder and more complicated to use and set up, with no apparent advantage, or at least no immediate one.

I can only hope this is going somewhere good, because from my perspective the basic things I've come to rely on in both Mac OS X Server and Client (can you say "search by name?") have gotten harder to do in Tiger. Significantly harder. And that's too bad, 'cause that's just not what I'm looking for from Apple products. If I wanted something difficult to use, I'd switch to Linux. (I'd never switch to Windows.) And if Apple software continues along its current trajectory — the Tiger trend towards a more difficult OS — and Linux software continues along its current trend towards easier software, you may see more Linux switchers than ever. Apple's draw is ease-of-use. The more they move away from that idea in the implementation of their software, the less appealing they become, to me personally, as a computing platform, and the less distinguishable they become from their competitors.

But for now, I'm sticking by my favorite computer platform. Panther was an amazing OS — it truly "just worked". It's kind of sad that Tiger has been the OS that's made start considering, however peripherally, other options. Here's hoping they do better with Leopard.

BTW, here are a couple more links of interest regarding the topic of AFP newtork home accounts in Tiger. I don't have time to read them right now, but they may prove interesting at some point.

Creating a Home Directory for a Local User at a Server
Creating a Custom Home Directory
Automatically Mounting Share Points for Clients
Setting Up an Automountable AFP Share Point for Home Directories

A fellow SysAdmin and blogger, Nigel, from mind the explanatory gap (one of my systems faves) has some beefs with this article, and shares some of his own experiences which are quite contrary to what I've reported. Just to be clear, this article reflects my own experiences, and there's a bit more to my own scenario than I shared in the article, mainly because I didn't think the details were important. They may be, and I discuss it at greater length in my response to Nigel's comment. Thanks, Nigel, for keeping me on my toes on this one.

I'm not really sure what's going on here, but if I get to the bottom of it, I'll certainly report about it, either here or in a follow up post. But please read the comments for the full story, as there's really a lot missing in the article, and things start to get clearer in the comments.