Recently in microsoft Category

In the last month-ish I've had a chance to read about and use two new graphical shells that impact my life:

• Windows 8 Metro, which I already have on my work-phone
• Gnome 3

Before I go further I must point out a few things. First of all, as a technologist change is something I must embrace. Nay, cheer on. Attitudes like, "If it ain't broke, don't fix it," are not attitudes I share, since 'broke' is an ever moving target.

Secondly, I've lived through just enough change so far to be leery of going through more of it. This does give me some caution for change-for-change's-sake.

---

As you can probably guess from the lead-up, I'm not a fan of those two interfaces.

They both go in a direction that the industry as a whole is going, and I'm not fond of that area. This is entirely because I spend 8-12 hours a day earning a living using a graphical shell. "Commoditization" is a battle-cry for change right now, and that means building things for consumers.

The tablet in my backpack and the phones in my pocket are all small, touch-screen devices. Doing large-scale text-entry in any of those, such as writing blog posts, is a chore. Rapid task-switching is doable through a few screen-presses, though I don't get to nearly the window-count I do on my traditional-UI devices. They're great for swipe-and-tap games.

When it comes to how I interact with the desktop, the Windows 7 and Gnome 2 shells are not very different other than the chrome and are entirely keyboard+mouse driven. In fact, those shells are optimized for the keyboard+mouse interaction. Arm and wrist movements can be minimized, which extends the lifetime of various things in my body.

Windows 8 MetroUI brings the touch-screen metaphor to a screen that doesn't (yet) have a touch-screen. Swipe-and-tap will have to be done entirely with the mouse, which isn't a terribly natural movement (I've never been a user of mouse-gesture support in browsers). When I do get a touch-screen, I'll be forced to elevate my arm(s) from the keyboarding level to tap the screen a lot, which adds stress to muscles in my back that are already unhappy with me.

And screen-smudges. I'll either learn to ignore the grime, or I'll be wiping the screen down ever hour or two.

And then there is the "One application has the top layer" metaphor, which is a change from the "One window has the top layer" metaphor we've been living with on non-Apple platforms for a very long time now. And I hate on large screens. Apple has done this for years, which is a large part of why Gnome 3 has done it, and is likely why Microsoft is doing it for Metro.

As part of my daily job I'll have umpty Terminal windows open to various things and several Browser windows as well. I'll be reading stuff off of the browser window as reference for what I'm typing in the terminal windows. Or the RDP/VNC windows. Or the browser windows and the java-console windows. When an entire application's windows elevate to the top it can bury windows I want to read at the same time, which means that my window-placement decisions will have to take even more care than I already apply.

I do not appreciate having to do more work because the UI changed.

I may be missing something, but it appears that the Windows Metro UI has done away with the search-box for finding Start-button programs and control-panel items. If so, I object. If I'm on a desktop, I have a hardware keyboard so designing the UI to minimize keystrokes in favor of swiping is a false economy.

Gnome 3 at least has kept the search box.

---

In summation, it is my opinion that bringing touch-UI elements into a desktop UI is creating some bad compromises. I understand the desire to have a common UI metaphor across the full range from 4" to 30" screens, but input and interaction methodologies are different enough that some accommodation-to-form-factor needs to be taken.

This is a question from ServerFault that was there and then was no longer there because it's rampant flame-bait and got mod-hammered. But sometimes flame bait can make for good blog-posts, so here it is. Unattributed since the source no longer exists and I don't want to embarrass the asker.

As someone who has a good amount of experience with basic server setup exclusively on Linux, I'm wondering why anybody would want to use Windows.

I'm not asking this to make it into some snide comment, I just don't see any advantages.

The big things I think I would miss are:

• SSH access. As far as I know, the only real way to remotely access a Windows service is via RDP or VNC or something similar, which is a lot more work if all I want to do is restart a service.
• Open source software. From my experience, almost all open source server software is made for Linux. While some, like Apache, can also be run on Windows, a lot of the times it feels like it was added as an afterthought.
• Easy configuration. I've never used Windows tools, but I love being able to apt-get install libapache2-mod-whatever. While package systems aren't technically part of Linux, most popular distributions use yum or aptitude or some packaging system which makes it a lot easier to handle updates.

Again, I've not used Windows extensively as a server, so please forgive me if some of these points are inaccurate.

A valid question. We had a thread much like this one on the LOPSA mailing list a while ago. And really, to a Linux admin, Windows looks like an expensive, opaque, and above all annoying way of doing what Linux can do in its sleep. This view is very couched in the observer's biases.

The consensus of the web this year is that if you want to do large scale web-application infrastructures, Linux is where it is at in spades. During my job hunt there were exceedingly few job-postings for Linux admins that mentioned something other than Web or DB duties. Web, DB, load-balancing, routing, orchestration, caching layers, it's all there and very well documented.

So why WOULD you use use Windows?

The number one reason I know of...

Because the application you're using requires it.

At WWU we had quite a number of off-the-shelf products require a Windows server because they were .NET applications. FLOSS versions may exist, but that's not what our users wanted. They wanted this piece of software that they picked out and is kinda standard in their industry, not some half baked open source project out of some other University.

Or for my current employer, a number of the key processing tasks we need to do are most accurately accomplished on Windows. The open source versions of these software packages get close enough, but part of what distinguishes us from our competitors is that we get closer then that.

The number two reason...

Because that's what you know.

This was why WWU was running Blackboard on Windows servers, even though it's a Tomcat application at the core. I'm pretty sure the reason for this is because what came before Blackboard was also running on Windows and our Windows admin inherited the new environment, not that the Linux admin said "Not it!" faster than the Windows admin. I know that admin found Linux confusingly opaque and convoluted.

The number three reason...

Because you don't have time/skill to maintain it yourself, and/or you're willing to pay someone else to do it for you.

If that application comes in a box, wrapped in an installation wizard, and comes complete with phone-home abilities to pull updates, notify the vendor (and later you) of problems, a lot of the effort in keeping that application going has now been outsourced to the vendor. Few FLOSS-stack products can do that, they need some skilled time to keep 'em up. To an organization looking to fire-and-forget, this kind of software is really attractive.

---

Now on to some of the asker's specific concerns regarding remote access, scalability, and software installs. Below the fold.

I deal with some large file-systems. Because of what we do, we get shipped archives with a lot of data in them. Hundreds of gigs sometimes. These are data provided by clients for processing, which we then do. Processing sometimes doubles, or even triples or more, the file-count in these filesystems depending on what our clients want done with their data.

One 10GB Outlook archive file can contain a huge number of emails. If a client desires these to be turned into .TIFF files for legal processes, that one 10GB .pst file can turn into hundreds of thousands of files, if not millions.

I've had cause to change some permissions at the top of some of these very large filesystems. By large, I mean larger than the big FacShare volume at WWU in terms of file-counts. As this is on a Windows NTFS volume, it has to walk the entire file-system to update permissions changes at the top.

This isn't the exact problem I'm fixing, but it's much like in some companies where granting permissions to specific users is done instead of to groups, and then that one user goes elsewhere and suddenly all the rights are broken and it takes a day and half to get the rights update processed (and heaven help you if it stops half-way for some reason).

Big file-systems take a long time to update rights inheritance. This has been a fact of life on Windows since the NT days. Nothing new here.

But... it doesn't have to be this way. I explain under the cut.

Last week and this week had me upgrading a certain piece of software that desperately needed it. We're moving from a version released about 2006 to one released this year. The 2006 version (v06 for this blog-post) was installed on a Server 2003 32-bit install, and was written at a time where 64-bit was still in the future a fair piece for most offices. As you'd expect v11 was written with 64-bit in mind, heck, it's a .net 3.5 app so it should work just peachy.

The problem comes with upgrading this package. Not only am I upgrading several major point revs, but I'm also installing to Server 2008 R2 which is unavoidably 64-bit. Happily, there is a migration path. I have to upgrade to v08 first to deal with a data-conversion routine no longer present in v11, and then move up to v11.

The thing that had me pulling my hair was how to get v06 to install to Server 2008 R2. The migration documentation was pretty clear on how to migrate v06 to a new server:

1. Install the software to the new server
   
2. Export this one reg-key in HKLM/Software on the old server
   
3. Stop the services on the new server
   
4. Import the .reg file on the new server
   
5. Copy over the datafiles to the new server
   
6. Start the service.

Straight forward! However, there was a problem.

v06 didn't install right to 2008 R2. Whatever it was using for installing the needed service wasn't creating everything it needed to create. Even after I nudged things along, it was pretty clear that all was not right. In the end I had to set the installer executable to run in "Server 2003 SP1" compatibility mode. THAT got it installed, yay.

But the reg-import clearly wasn't giving it the data it needed. It was only after I threw "procmon" at it to see where it was trying to pull registry data from that I noticed it was doing it from some new place. Down there in HKLM is a new reg-key for 32-bit applications on 64-bit installs, called [HKLM/Software/Wow6432Node/]. Since this is my first time going to the registry level for this kind of pure-32 application, I hadn't run into this before.

Sure enough, the install created the needed nodes under THAT reg-key instead of HKLM/Software like the upgrade doc said. A simple search-and-replace on the exported .REG file for "Software/$Vendor" to "Software/Wow6432Node/$Vendor" and reimport got it all going again.

Yay!

And the upgrade to v08 worked just fine, as did the upgrade to v11. Whew.

Today I ran into a limitation of robocopy that just might have bitten me in the past and I never knew it.

I got pulled aside to ask my opinion of how a robocopy of a large filesystem yielded no errors in the robocopy log, but differed in file-count by 6 files. The user was able to identify a directory with a file that got missed, which helped. The files in the directory were named similar to this:

1. ITWA-National Introduction.doc
2. ITWA-National Overview.doc
3. ITWANA~2.DOC

The destination directory had only the first two files, but most interestingly, the second file had the same size as the third file on the source. Hmmmm.

Looking at the short-names of the two directories I noticed something else. In the source directory...

ITWA-National Introduction.doc = ITWANA~1.DOC
ITWA-National Overview.doc = ITWANA~3.DOC
ITWANA~2.DOC

And on the destination directory...

ITWA-National Introduction.doc = ITWANA~1.DOC
ITWA-National Overview.doc = ITWANA~2.DOC

AHA! Robocopy isn't preserving the short-names! When it copied the second document to the destination it allowed the system to auto-generate the short-name, and as that was the second ITWANA document, it got ~2. So when it copied ITWANA~2.DOC in, it overwrote the already existing ITWANA~2.DOC file.

We're now looking for a tool, preferably scriptable, that'll preserve short-names. I found a couple of 'em, but they're !free. Currently we're laundering things through the Windows backup facility since that preserves ALL attributes. If you know of such a tool, drop a comment.

The historic 'rdesktop' product (located here) hasn't been updated in a while, and critically lacks support for a major new feature Microsoft introduced in 2008. Network-level authentication. This enhancement requires a login to even connect the RDP session. The rdesktop client hasn't been able to support this, so for my servers that I wish to RDP to I have to remember to turn that off.

Happily, the FreeRDP fork of rdesktop now has support for NLA. It's in the GIT repo, not the stable branch, but it is there. The next stable version should have support for NLA.

Yay!

Yesterday morning we took the first user-visible step in our Exchange 2010 migration. We put the Exchange 2010 Client Access servers into place as our OWA servers. Since we have no one in an Exchange 2010 mailbox, all they'll do is proxy incoming connections to the old 2007 CA servers. Nothing should change in the end-user experience.

However, something else has cropped up.

We actually got the first few reports last week when Entourage stopped working reliably. After the 2010 swap, some mobile devices had their ActiveSync stop working.

We caught some fire today because we didn't catch the fact that certain ActiveSync setups don't work with Exchange 2010. The Android and iOS devices we tried all worked, so we just presumed it wasn't a big problem. Apparently that's wrong.

It seems that the DroidX and certain iOS versions under 4.2 don't sync correctly with Exchange 2010 ActiveSync. It just so happens that a Dean was using an iOS device running a 3.something version and was out of luck, and Deans are high enough the food chain to make their pain felt. We felt it.

The Mobile space is highly, highly fragmented. We simply do not have the resources to test and validate each OS rev on each hardware device out there and provide a 'How To' page for everything. Being expected to provide this is unreasonable. Unfortunate, but unreasonable.

We do warn people that using ActiveSync is a 'best effort' solution. However, today's 'best effort' is tomorrow's broken critical service.

The solution right now is to upgrade your iOS or not use DroidX. The iOS upgrade is free. DroidX users are out of luck until Motorola fixes the problem. There is nothing we can do about that.

Summary:
The end-user environment is becoming heterogeneous at a time when our central computing environment is becoming more homogeneous due to cost constraints. This has impacts to how we do business. The latest features may not be able to be deployed until the lagging platforms get sufficient support. Formerly ignored platforms will need central resources to effectively manage them.

A friend of mine recent tweeted the following:

STILL trying to rebuild my productivity after losing my work hard drive. I miss my mapped drives!

Because we were so recently in the NetWare paradigm of networks, we still have a login-script that gives everyone the drive-mappings they need. Organic mappings are beginning to crop up, but because we give users nearly everything they need for data-access right out of the box our users haven't gotten in the habit of mapping drives to every little thing in their own way. The P: drive is universal, everyone has one, and our Helpdesk gets calls like "I can't get access to the P: drive."

Pure Windows networks, I gather, are much more organic affairs. The worst offenders are small offices without a central filer of some kind, so everyone just shares directories off of their own workstations. Even if they do have a NAS, there are probably lots of shared directories on workstations. I've seen them, it made me cringe.

Larger pure-Windows offices... I don't have much experience in, but I suspect undisciplined server growth leads to multiple file-servers with data scattered on all of them. This makes new users have to do detective work to figure out where all of their needed data is and then map accordingly. Disciplined server growth, on the other hand, is beyond my experiences.

Because we're so drive-letter centric our helpdesk occasionally gets calls like, "My M: drive went away." In this case, the M: drive is not one we routinely map so the user set it up themselves (or worse, had it set up for them by someone else), so the helpdesk tech gets to ask the questions to figure out where their M: drive was pointing and assist them in re-mapping it. In the few pure-Windows environments I've touched such questions seem to be of the "I can't get to the Faculty share" type, which still requires a bit of helpdesk detective work to figure out which server the 'faculty' share is on.

For those of you who've spent a lot of time in pure Windows environments, how are your users handling drive-mappings, and how are shares administered? We're pretty tightly controlled around here (hello, legacy speaking) but I know there is a lot of variability out there.

It has been around a year since we did the heavy lifting of migrating off of NetWare and retiring our eDirectory tree. By this point last year we had our procedures in place, we just needed to pull the trigger and start moving data around. I was asked to provide some hints about it, but the mail bounced with a 550-mailbox-not-found error *ahem*.

Because it's such a narrowly focused topic, and the WWU people who read me lived through it and therefore already know this stuff, I'm putting the meat of the post under the fold.

You're welcome.