SBS 2008 Shared & RedirectedFolders paths

By default Windows SBS 2008 has 2 shares setup - RedirectedFolders and UserShares, along with the various bits and bobs in the group policy to get it to work. Sadly they've placed the actual directories in the root of C:\. I don't like that. I'm fussy about file placement and it would be nice to move it to where we usually have the files (and have done since SBS 2000); D:\Data\..., which brings things into line with our standard setup that we tend to use at work.

Now you can just simply de-share the original directories, and move them to whereever you want. However this has the downside of causing issues (recreating the folders) if you create user accounts with the SBS 2008 console (since it also creates the various redirected folders for the user, and I know that several of our customers will be using this console).

Luckily there is provision to move these folders to another location. If you use the console you'll see that you can simply move it from drive to drive. However, if you delve into the registry you can see that 2 magic keys get created, which if you manually alter allows you to effectively place the directories where ever you like.

If you browse to
HLKM\SOFTWARE\Microsoft\SmallBusinessServer\Storage
You'll find that the following entries will either exist, or need to be created -
SharedRootPath SharedRootName FRRootPath FRShareName

*RootPath specifies the location for the user shared and redirected folders, where as the *ShareName specify the actual name of the shares themselves. Handy.

Xen, Vyatta, Happy New Year

New Years eve the extra bits of hardware I needed for my Xen box arrived (cheapo motherboard for VMX (Intel VT-x in my case) and power supply). As you can imagine with a house full of people, and corresponding day of pain afterwards, it wasn't the best time to be faffing with setting it all up. However, a few days later and it's all there and working like a dream.

I have to say that I'm pleasantly surprised and also taken back by a few things. I'm also a little disappointed about a few bits and bobs, but I'll get to that later.

Having tested Xen previously, and having got a book on it for quick reference, getting it set up was painless, quick and easy, once I'd upgraded my dom0 to Lenny to sort a few networking and Xen related issues. Whilst I maybe a glutton for punishment for running without a GUI, I actually found setting up both Linux and Windows virtual machines painless from the command line.

One thing I was worried about, was the performance of the Windows machines I'd setup - they were awful. I really do mean it. It was like being back in front of the AMD box that we were using for virtual machine testing at my old job 3 or 4 years ago. Turns out that Windows XP/2003 and the Xen ACPI implementation don't quite play nicely and it's a case of making Window use the "standard pc" "drivers". Once I'd done this it was a hell of a lot better.

Continuing on the subject I was also a little apprehensive of using LVM2 in my setup, as last time I'd used it I'd ended up with mangled data. Since it's now been quite a while since that happened (years now), the fact that it's very widely used, and on mention from Andy that he'd been using it at work for super secret projects, I went for it again. Happily there's been no problems and the disk performance of the domU's is excellent.

Xen has also given me my first real opportunity to use and play with Vyatta, a fully pre-packaged, commercially supported, open source alternative to Cisco, Juniper, etc. It's actually pretty sweet, it must be said. I like the JunOS-like interface for setting it up, and how the config needs to be saved and commited, and how it's all accessible from the command line or web-GUI (if you're that sort of person). If you're already using your own rolled Linux boxes as routers, then you might not beable to see the point behind Vyatta, and I must admit before trying it I was one of those people. However, it's simply that it's all there already, with support should you need it - which in the real world can sometimes be very useful (as I'm sure everyone knows, since people like Redhat, Canonical, IBM, etc. exist and thrive). As time goes on I hope to not only use it in testing, but also for creating a quarantined portion of my personal network here, and to connect the other "main house" network. Hopefully that'll work out nicely, and if I does I may well end up using Vyatta on my next externally hosted server (which may end up being setup in a xen-hosting style - let me know if you maybe interested!).

The only shame with the Vyatta system, is the price of the hardware appliances from the commercial company. In comparison with Cisco's offering they are cheaper, but when you're looking at the small end of the companies we support at work, it's sometimes hard to justify using anything more than a really cheap Draytek or "worse".

So on the whole things are going well with Xen. Right now I don't know if I'd suggest a Windows 2008 Hyper-V Core server or Xen at work, next time it comes up - I suspect that I'd suggest different solutions for different circumstances (i.e. Hyper-V core for a Windows network with non-virtual AD boxes, and Xen for a colocation setup), but I can't really explain why when you exclude the obvious (such as managability in each situation). Food for thought perhaps

Apparently I need to say Happy New Year also.

Recent Adobe products don't like...

...redirected App data directories, and causes a crash (Visual C++ Runtime error). Unfortunately after updating one or two of our customers at work it appeared that a few user accounts still had a redirected app data directory, presumably because they weren't around when it was removed.

Thankfully fixing it is pretty easy (although potentially time consuming depending on your setup), if the redirection policy isn't active and is simply a case of changing the relevant entry under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders, and then logging off and back on, and migrating the redirected files back into the local profile directory.

As far as I'm aware the affected products are;

  • Adobe Acrobat and Reader 9
  • The entire CS4 suite

If you're not using redirected app data directories any more then this is obviously a handy fix. If for whatever reason you're still using redirected directories and not roaming profiles, then you're screwed as it appears that Adobe aren't planning on fixing this.

Things like this really piss me off and just make me feel like the majority of my work is working around bug, flaws or oversights and is just why I prefer open solutions and platforms; at least I'd have the possibility of trying to fix it in-house.

Outlook, Exchange and calendars asking for authentication

This one really had us at work and really threw us massively. Imagine a customer who has recently had a number of non trivial modifications to their network. Now imagine several users, whom have Outlook over HTTP RPC (Outlook Anywhere) configured and enabled for slow networks only, and get asked for authentication when accessing a handful calendars. On the same site as the servers (i.e. on the fast network). Disabling Outlook over HTTP RPC completely, or enabling it for slow and fast networks, and the problem would not occur. With no useful logs what so ever.

The main problem was that so much stuff had changed it was difficult to know where to start, and even harder with nothing useful being logged. It wasn't hitting the proxy server, which had recently had authentication forcefully enabled, it wasn't the IIS and Exchange box.

Turns out that the affected calendars that people were trying to view had recently had their mailbox moved from one storage group, to another, and we were obsessed with it being something else to the point that we'd dismissed this without looking into it. Without HTTP RPC enabled redirection happened without trouble, but with it on it required authentication. But the weird thing was that you could actually see the calendar if you selected Open other user's mailbox, rather than using the "shortcut" (i.e. tickbox) that had already been added in the calendar view.

Simple solution - remove and readd the affected calendars. Our best guess is that this is stored with various pointers or references to not only the mailbox, but also the storage group. After all, it would make sense from a performance point of view if you didn't have to look it up each time.

The moral for me personally, since I'd taken quite a lot of this problem on, is to never forget Occam's Razor. I might actually get a representation of that tattoo'ed on my body, whenever I get around to that part of life again.

Windows DFS shares, junctions and permissions

Here's another one that caught me out today, but I've never come across before.

Under a DFS share, any linked shares are created as junctions. It appears that the permissions on these junctions do affect the permissions of the data within the linked share. Whilst this is logical, given how junction points work, what really threw me was that the wonderful, wonderful GUI didn't reflect this and the permissions on the junction point had been inadvertently changed.

It's not like you ever need another reason to chalk one up for the command line, but there we go!