Update Deployment for Visual Studio and the .NET Framework

Changes

You may have noticed that I haven't been maintaining this blog recently. Some life changes have happened in my life and as a result I am no longer actively working on "Update deployment for Visual Studio and the .NET Framework." Specifically, I've gotten engaged and moved from Redmond, WA to Silicon Valley, CA where I am now helping Microsoft deliver the next version of Office for Macintosh systems. You can rest assured that the update deployment space for Visual Studio and .NET Framework are left in good hands back in Redmond.

I am leaving this site online as a resource (for what it's worth). I consider this to be my personal blog for information pertaining to my current role at Microsoft: If and when I choose to start blogging on this site again, I may change blog title to better reflect the current subject matter but will strive to leave any existing content online.

How to install and update the .NET Framework 1.1 on different operating systems

I've blogged previously about how confusing our servicing story is for .NET Framework 1.1 on Windows Server 2003 and 64-bit versions of Windows XP and Windows Server 2003. Now there's a new KB article in the Microsoft Knowledge Base to help customers understand and address these and other issues regarding .NET Framework 1.1 on various operating systems.

Here are some links:

.NET Framework 1.1 Servicing Releases on Windows Update for 64-bit Systems

Among the most confusing stories that we have asked .NET Framework customers to understand has been .NET Framework 1.1 support on Windows Server 2003 and 64-bit versions of Windows. I've blogged about this before. Today I get to tell you that we've done right by putting .NET Framework 1.1 servicing releases on Windows Update for 64-bit platforms.

Microsoft releases security updates on the second Tuesday of every month and Windows Update releases non-security updates on the fourth Tuesday of every month.  Well, today is the fourth Tuesday in March and we went live with .NET Framework 1.1 Service Pack 1 on Windows Update for supported 64-bit versions of Windows.

None of these are new releases; they are the exact same binaries that are already on Windows Update for .NET Framework 1.1 running on 32-bit Windows operating systems and have always been available for supported 64-bit Windows operating systems on Download Center.  What's new is that now if you have .NET Framework 1.1 installed on your x64 or supported Itanium version of Windows then you can keep that .NET Framework 1.1 installation up-to-date using Windows Update, SUS, and WSUS.

It should be noted that there do exist performance issues running .NET Framework 1.1 on Itanium-based systems (here).  There is also a known compatibility issue between ASP.NET 1.1 (a component of the .NET Framework 1.1) and IIS 6.0 on 64-bit versions of Windows (here).  These are known issues and the current announcement does nothing to mitigate these concerns.  Rather, we assume that if you have the .NET Framework 1.1 on a 64-bit Windows system then you have already evaluated and addressed these concerns for your environment.

The supported operating systems are the following:

• Windows XP Professional x64 edition
• Windows Server 2003 x64 editions
• Windows Server 2003 for Itanium-based systems w/ Service Pack 1

Deployment Channels

I stated in an earlier post that "I am the person in charge of getting product updates (service packs and hotfixes) for Visual Studio and the .NET Framework into distribution channels like Windows Update, Microsoft Update, and the Microsoft Download Center."  It occured to me that some of you might care which updates go where.  If you do, read on!

In a nutshell, updates to the .NET Framework go on Windows Update while updates for everything else (in this case, Visual Studio) go on Microsoft Update.  Because all Windows Update content is on Microsoft Update as well (but not vice-versa), one could look at that the other way around and say that all updates (Visual Studio and the .NET Framework) go to Microsoft Update while only .NET Framework updates go to Windows Update.  All updates that go to either Windows Update or Microsoft Update must go to the Microsoft Download Center as well.

Tables have been known to help:

You may be saying to yourself, "I've never seen any Visual Studio updates on Microsoft Update."  That's true, but we're working on it.  Expect to see updates targeting Visual Studio 2005 on Microsoft Update starting in Q1 of calendar year 2006.  We will also be evaluating whether to service Visual Studio.NET 2002 and Visual Studio.NET 2003 in the same way.  These latter Visual Studio versions (2002, 2003) are more complicated because they were released before Microsoft Update existed and therefore were not built with Microsoft Update integration in mind.  We'll need to make do with what we have for these.  Let me know how we do!

.NET Framework Installer Technologies: A Primer

Updates for the the .NET Framework 1.1 come in two flavors: One set of packages for 32-bit x86 versions of Windows Server 2003 and a different package for everything else.  Similarly, updates for the .NET Framework 1.0 come in two flavors as well: One set of packages for Tablet PC and Media Center editions of Windows XP, and a different set of packages for everything else.  Confused?  You're not alone.  I'll try to help.

What happened?  To understand this you first need to understand that the .NET Framework is a Windows component that shipped well after many versions of Windows that it targets.  For example, Windows XP shipped in 2001 but the first version of the .NET Framework (1.0) shipped in 2002.  All versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework.  We call these .NET Framework installations "OCM" installs because they are installed using the Windows Optional Component Manager.  (This is the same OCM technology behind the Add/Remove Windows Components functionality in Add/Remove Programs in the Windows Control Panel.)  But what about Windows XP Home and Professional?!  Or Windows 2000, NT4, or 9x/ME for that matter?  We want .NET Framework applications to run on these downlevel platforms as well, so in addition to the OCM installations of the .NET Framework we also released the exact same .NET Framework as "redistributables" using the Windows Installer (AKA: "MSI") installation technology.  This seemed like a great solution for a while: The .NET Framework goes everywhere that Windows goes and everybody is happy.  Not quite.

The problem with this solution is that now we are required by the technologies (MSI and OCM) to service each of these two broad classes of .NET Framework installations differently.  That is, we need different update packages for OCM than we need for MSI, even for the same logical fix!  This isn't a terribly difficult thing to accomplish technically: We just need to do the same thing twice, once for OCM and once for MSI.  But it's not so hot for our customers (you guys) who need to translate all this for your systems: You don't need the same fix twice; you need one of two fixes once.  "Let's see: Security Hotfix KB123456 was just released.  Do I want the 'Security Update for the .NET Framework (KB123456)' or do I want the 'Security Update for the .NET Framework on Windows Server 2003 (KB123456)'? And does it matter that this is for my x64 or Itanium servers?" (It turns out that it does.)

I said earlier that "All versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework."  Well, this was an overstatement.  More correctly, "All 32-bit x86 versions of Windows that have shipped since the .NET Framework was first released have contained a built-in version of the .NET Framework."  To date, our x64 and Itanium versions of Windows have not shipped with the .NET Framework built-in and are therefore considered MSI.  Sorry for the confusion.

(Side-note: It probably sounds redundant to refer to "32-bit x86".  The rationale here is that the x64 architecture is a superset of x86 and therefore simply referring to "x86" would be ambiguous.  Further, "32-bit" could refer to any number of processor architectures, so neither "32-bit" nor "x86" alone would suffice.  Therefore, for precision, we say "32-bit x86" to refer to all those "mainstream" 32-bit x86 boxes out there.)

There's a tabular answer to the question of which version of the .NET Framework your system has: The .NET Framework version that you have depends on two factors: (1) the operating system edition that you are running (including its target processor architecture: 32-bit x86, x64, Itanium), and (2) the version of the .NET Framework that you want to update. Your system is considered "MSI" unless it is specifically targeted as "OCM". Here it is in tabular form:

Please note the following details for .NET Framework support on 64-bit platforms:

• .NET Framework 1.0 is not supported on 64-bit platforms at all.
• Windows XP for Itanium is not supported at all (though Windows XP for x64 platforms is supported).
• Support for Windows Server 2003 for Itanium requires Windows Server 2003 Service Pack 1.
• Use the 32-bit .NET Framework 1.1 redistributable (MSI) on supported 64-bit platforms.  There are no 64-bit native versions of the .NET Framework 1.1. 
• .NET Framework 2.0 is compiled natively for each supported processor architecture.
• It is possible to run a 32-bit x86 version of Windows on an x64 hardware system.  In this case, use the table row for your 32-bit x86 version of Windows.

We usually market OCM updates using the names of their target operating systems.  For example, "KB123456 for Windows Server 2003" means that it is a .NET Framework 1.1 OCM update.  Similarly, "KB123456 for Windows XP Tablet PC and Media Center Editions" is a .NET Framework 1.0 OCM update.  Also, we usually market MSI updates using the name of its target .NET Framework versions.  For example, "KB123456 for the .NET Framework 2.0" is an MSI update.

The good news is that we are learning our lessons and we are not making the same mistakes again.  Without giving too much away, I think it's safe to say that Windows Vista will come with the .NET Framework built-in but there will not be any need do this OCM vs. MSI mumbo-jumbo.  In other words, we're cleaning things up a bit.  But we cannot go back and change the past: What you see above is what we've got for these .NET Framework versions and these operating systems.  We just plan to do it better next time.

Hope this helps!

Why this Blog?

The intention of this blog is to help give the interested public some view into the complexities of servicing Visual Studio and the .NET Framework.  Other blogs exist on the subject, and this blog is by no means official or authoritative.  Rather, this blog represents the personal views of its author where that author is in the unique position of being responsible for the deployment of updates for Visual Studio and the .NET Framework.

I would like this blog to be a forum for appropriate customer feedback on deployments that we have or, for that matter, for those that we do not have.  Our mission is to serve our customers.  If you walk into a restaurant and order a sandwich then you expect that a sandwich will be delivered to you in a timely manner.  You don't expect a taco or a tailor.  If you think that you've ordered a sandwich and I've given you a taco and cuffed hems, I want to know about it.  This blog is intended to be a vehicle through which you (our customers) can communicate directly with me (the update deployment manager for Visual Studio and the .NET Framework).

I also think that there is very real value in articulating complex ideas simply for the sake of articulation.  That is, if nobody ever read this blog, I would still post it.  I believe that the process of articulation alone helps me to consolidate my understanding.  Moreover, there is the added benefit of transparency when customers do read this.  In other words, I expect this blog to be a win-win for myself and for our customers.

In a very real sense, I am the interface between my group (DD.CPX) and our customers.  I don't mean that in the sense that I have a blog while others on my team do not (see the statement above about this blog not being official), but in the sense that I am responsible for getting my group's products (updates for Visual Studio and the .NET Framework) into the hands of our customers.  At worse, I hope that our customers will always know why we've done what we've done.  At best, our customers should feel that they have a voice in the activities of this organization.  Let's get blogging.

Vision

I have a vision statement up on my wall.  It says this:

"Deliver the right updates to the right customers at the right time."

I parse this statement with "the right updates to the right customers" as a single unit: A large part of the complexity of the update deployment space is mapping our update packages to an absolute partition of our client space.  It doesn't do anybody any good (in fact, it can do very bad) if we deliver the right update to the wrong customer.  The right update to the wrong customer is just plain wrong: It will not do.  The wrong update to the right customer is just as bad.

The "right time" part of the vision statement basically means that we expect our updates to be timely.  That can mean that we get a mission-critical security update out the door fast.  It can also mean that we understand our customers' needs and respond in a timely manner when those needs change.

About the Role: Update Deployment PM

In the bad old days, before specialized update deployment program management, it was the responsibility of the update release manager to deploy their own updates.  And in a sense, things haven't really changed so much from the bad old days, except that they have.  Let me explain.

Believe it or not, getting important hotfixes and service packs into the hands of millions of customers worldwide is a somewhat complicated thing to do.  A recent security update from our team consisted of over 100 unique packages (patch executables), each functionally equivalent (that is, each contained the same logical fix), but each targeting a unique subsection of the .NET Framework ecosystem.  And believe it or not, exactly one of my colleagues was responsible for that update end-to-end.

The fix itself was easy, it was packing and deploying that fix that was complex.  Over 100 unique packages deployed via three versions of Windows Update, one managed network security tool, and the Microsoft Download Center, all with an international focus.  All in all, there were something like 400 unique ways that an arbitrary customer could get this necessary fix.

My colleague worked extraordinarily long hours with many sleepless nights (seriously) to get it out the door as fast as humanly possible before the black hats could do their worst.  That time frame was on the order of six months.

Getting all of that done was a full-time job for my colleague for literally months on end, and these were months after the update packages were already signed-off by everybody else: The bits were golden, my colleague just needed to get them into our customers' hands.  But what makes this story tragic is that it didn't need to be that way.  Most of that deployment work could have been done in parallel with the earlier work, the only reason it wasn't was a resource constraint: my colleague was only one person and the work required could have been more efficiently performed by two.  In this case, two resources instead of one could have literally cut the end-to-end time in half.

Those were the bad old days.  Those days are past.  Today we recognize that much of this deployment work can be done in parallel with other activities.  That's where the update deployment manager role comes in.  It's my job to help streamline the process: Get updates into customers' hands faster by parallelizing the work and specializing in deployment.

In a sense, things haven't changed so much at all.  If the same security issue were felt today, my colleague would still own the issue end-to-end.  What would be different is that my colleague would now have the support of resources dedicated to facilitating the deployment aspects of the update release.  In a nutshell, that's what I do: I do everything that I can day-to-day to make sure that valuable updates are delivered efficiently to exactly the right customers.  It's a complex mission (as I am hoping this blog will help to show), but it is both achievable and necessary.  I definitely feel up to the challenge.

About the Author

My name is Blair Neumann and I am the Microsoft Program Manager in charge of update deployment for the Developer Division Customer Product-lifecycle Experience (DD.CPX) team.  That's a long way of saying that I am the person in charge of getting product updates (service packs and hotfixes) for Visual Studio and the .NET Framework into distribution channels like Windows Update, Microsoft Update, and the Microsoft Download Center.  Okay, that was longer.

I started doing this full-time in August, 2005.  I had been the go-to guy in QA for update deployment issues on the same team for about the year and a half previous.

I love the update deployment space.  I truly believe that every single update that we deliver helps make the internet a better and safer place.

I grew up about a mile from Microsoft main campus and literally watched it grow.  It was always a dream of mine to work here.

Stepping back, I took a bachelor's degree in Psychology before deciding to enter the tech world as the dot-com bubble was still forming.  I did product support for Windows 98 the day that it shipped and later helped test Windows 98 Second Edition and Windows Millennium Edition.  I was away from Microsoft between 2000 and 2003 during which time I helped to develop in-flight email services and went back to school to brush up on my Computer Science fundamentals.  I dropped out of CS graduate school in 2003 (in good standing) to join Microsoft full-time.  The rest of this history can be found above.