In my last post, I mentioned how at least for the team I worked on, that Windows releases typically needed to reflect how they aligned with the needs of three customer segments; OEMs who build PCs, businesses who run Windows, and retail customers who would buy it off the shelf to run on their own home PC.

I lied. Well, I simplified. For our team, that was true. For some Windows client teams, they may have only had an OEM story, or only had an enterprise story, depending on what the feature did. (Think about how some features in Windows are clearly designed for consumers and make little or no sense for business users, or vice-versa.)

The same is true of Windows Server. Generally, however, the priorities are totally different. For Windows Server, was designed to meet the needs of businesses. This is because it is primarily licensed through Microsoft’s volume licensing machine to businesses depending on how much they need.

Then a small amount of Windows Server is designed to meet the needs of OEMs who build Windows Server systems. Unlike Windows client—regardless of edition—where a large percentage of sales each year come from new PCs, very few Windows Servers are sold that way. Some are, but not many, and they tend to be designed to meet the needs of small businesses, system integrators who would specialize in installing a specialty Windows Server system in a business where IT isn’t the focus of the business, or fixed-function “embedded” style devices that needed the features of Windows Server rather than the Windows client. For example, Windows Storage Server devices, which would typically be hamstrung and not offer some features in enterprise editions of Windows, to make the OS more affordable for the OEM and in turn the customer buying the “device”.

Short story long, Windows client installs tend to live a very different life than Windows Server installs.

But unless features are carefully curated by the team that brings their new feature to the Windows potluck—which the Windows Embedded team learned was almost always not the case—the feature could wind up installed in editions of Windows that didn’t make sense, or worse, consumer features could be flung into Windows Server installations where they made no sense whatsoever.

Notably, I cannot recall the opposite ever happening, where a Windows Server feature that made no sense on the client was accidentally flung into desktop editions of the OS. In a way this makes sense, because the Windows Server team was its own vertical unit, even back then. When I joined the Windows team, for example, I sat in the “Windows Core OS Team” under VP Rob Short. At the time I joined, this team included everything from the Windows loader, kernel, and memory management, to the OS Deployment team (where I was during my time in Windows) where the team designed and built the features that put Windows down on disk, performed upgrades (but not migration, that was elsewhere for now), and all other OS deployment features, like RIS (replaced by Windows Deployment Services), WinPE (initially called “MiniNT” until legal apparently had a fit), and sysprep. There were a bunch of teams under Rob that did horizontal things for Windows, like the deployment and kernel teams, but many more than that.

When I joined, the Windows filesystems team was also under Rob. I can’t remember exactly when it changed, but eventually it was moved over to the Windows Server team, where I’m sure it still lives today.

Initially, that might not make sense – but it does. I didn’t get it at first either, but at the end of the day, the Windows Server team was the team that “pulled at” the capabilities of Windows Server, and helped guide it due to their unique performance and scale requirements that were completely different—and totally overshadowed—those needed for a PC running the Windows client. You can look at features like the ReFS filesystem today, NTFS back then. VSS snapshotting capabilities, and see the Windows Server team pulling through features they need in order to sell newer versions of the OS.

While the Windows Server team was vertical and highly focused, the Windows Shell team (the group that owns Windows eye candy, typically regardless of edition) was also very vertical, but effectively driven by consumer scenarios, and in some very isolated cases, business scenarios. Note here that I said Windows Shell, not “Windows Client”. There isn’t – or at least wasn’t, any team that owned Windows enterprise scenarios. For a long time, I felt very Don Quixote as I tried to work with other Windows feature teams to get the things done that customers… complained about. For example, Windows Movie Maker, which arrived in XP builds very late as I recall, couldn’t be uninstalled. This made one of the early adopter customers that I worked with—a very large and very important business—absolutely furious. This is the kind of thing that, like many of the “consumer creep” features in the Windows 10 and Windows 11 shells, that can really chafe at business customers and make them feel unimportant, particularly when they’re spending hundreds of thousands of dollars or more with the firm every year. But I digress…

When Bill Veghte took over as the VP of Windows Server in the summer of 2001, he decided to have “scenario reviews” as I recall they were titled, where he would meet with each of the feature teams that affected server, to see how their feature interacted with Windows Server. Since I owned corporate deployment from a setup perspective, and I already knew some of the team running the reviews, I was requested to do one where we walked through Windows setup. This would include winnt.exe, the legacy MS-DOS 16-bit installer that I lovingly call “old blue” in my head, as well as winnt32.exe, the 32-bit Windows upgrade engine I mentioned in my last post.

I sat down with Bill, his team, and the aforementioned friends from the Windows Server team that had requested me, and we walked through both setup processes, taking notes as we went about things that didn’t fit. This included the “billboards” shown during setup, which would be tweaked to be brand-consistent and feature-emphatic towards Windows Server rather than talking about consumery/knowledge workery-centric features that XP showed. It even included a conversation around the choices for formatting a disk (quick or slow, NTFS or FAT32) and making some decisions to change things to fit the server scenarios better.

It was a really enjoyable process both because I enjoyed working with Bill and pretty much everyone I ever worked with in Windows Server, but also since Bill was approaching this review from a “clean room” perspective, it felt like we were really attenuating these decisions to reflect the needs of the Windows Server end-user base. Even though I’d seen these same screens for over a year in Windows and before, it also caused me to really reflect about the Windows Server end-user, and I think this one meeting, and another review I’d have with Bill about RIS, profoundly changed how I focused and probably affect how I write today. I also went to several reviews where Windows Server feature teams needed to consider how their feature interacted with setup (was it an optional component, how should it work with unattended setup, did they need special setup UI during or after setup, etc…)

Anyway, pretty much nobody escaped these reviews unscathed, which is good.

For me, there were several action items I worked through after my reviews. But most notably was… the Start menu. Recall that this is what the Start menu looks like when you log on as Administrator on Windows XP:

Theming aside, the consumer-centric focus of the Start menu wasn’t great for Windows Server admins. Sure, we could have left it alone as had been done before with Windows Server 2000, but this creates two problems:
1: You’re making the end-user jump through extra hoops to configure the OS on the system they just installed, when they just paid you a lot of money – more than XP – to get there
2: You are, in effect, telling the end-user that their time, wasn’t worth your time.

When I did my review, we talked through what things made sense and didn’t make sense to have highlighted on a server. Obviously it makes no sense to emphasize a Web browser, e-mail client, or media player. Conversely, it was silly that we didn’t help a server admin launch the things they were likely to need. Talking through this with Bill, my friend David from the server team, and I decided what applications should be there, and which should be pinned (you would want to use them all the time) and which should be suggested in the MRU (most recently used), separated below them on the Start menu but would fade off if you didn’t use them.

The end result would be the below:

I didn’t know exactly what was involved in getting this sort of change done in terms of the actual code change, but I knew the one person I could ask who could quickly answer it, probably make the change, and tell me why or why it might not work. So David and I had a quick meeting with Raymond Chen, who suggested a few different options. We wanted to be careful and not screw up the new user experience for orgs setting up Terminal Services/Remote Desktop Services where a server looks and acts “clientish”, so it was decided the change would only affect the Administrator account, and, as I recall, users who were a member of the local administrators group at the point where they first logged into a Windows Server 2003 system. (It’s been a while so I might be misremembering nuance) but it definitely only affected administrators, not users.

It was a tiny little thing, perhaps seemingly silly in the grand scheme, but I really did enjoy the scenario reviews, learned more about the Start menu and the gunk that goes into creating new user profiles on Windows. I also remember getting feedback from field employees that the changes were noted and appreciated. If I made an administrator’s life easier on Windows Server, that makes me happy.