Jamshed's blog

Yesterday was patch Tuesday, and Microsoft released security updates targeting a few products including the .NET Framework (see security bulletin MS07-040). This bulletin contains updates for the .NET Framework 1.0, 1.1, and 2.0.

The updates for the .NET Framework 1.0 and .NET Framework 1.1 are noteworthy because of a drawback both updates suffer from. Lets say you have an update for the .NET Framework installed and you then install a second update. Later on if you uninstall the second update, you would expect that your system would go back to the previous state i.e. update 2 is gone, update 1 is present. We think of this as a stack. You would be right if you were talking about the .NET Framework 2.0. But for the .NET Framework 1.0 or .NET Framework 1.1, when you uninstall the second update your system would not be reverted back to the first update, instead your would system would revert back to the last Service Pack. Once you are reverted back to the last SP, you would still not be able to easily install the first update.

This issue is caused due to the limitations in the installater technology used for these updates viz. Windows Installer (MSI) 2.0. KB939160 describes the issue and also provides a link to download a tool which will cleanup your system in case you need to uninstall the updates released for the security bulletin MS07-040. So if you plan on uninstalling these security updates for some reason, you should first take a look at KB939160.

Update on  11/9/2007 -

The issue described above affects updates for not just the .NET Framework 1.0 and .NET Framework 1.1, this also affects updates for Visual Studio .NET 2002 and Visual Studio .NET 2003. This problem is discussed more thoroughly in KB938244.

A new tool has been released that can be used to address this specific problem with any update for the Microsoft .NET Framework 1.0, the Microsoft .NET Framework 1.1, Microsoft Visual Studio .NET 2002 and Microsoft Visual Studio .NET 2003; more information about downloading and using this tool can be found in KB938244.

Note: The tool referenced in KB939160 may be used to address the issue only for MS07-040 unlike the new tool referenced in KB938244 which may be used to address the issue for any update for the previously mentioned products.

There is often a need to have a way to detect whether or not a certain update for the .NET Framework or Visual Studio is installed on a PC. A user might easily go and look this up in ARP (Add-Remove Programs), but if you are an IT administrator for an enterprise you do not want to walk around and look this up one machine at a time for a few hundred or even a few thousand machines.

What you need in that case is a scriptable/deployable way of detecting whether the update is question is installed. One way to do this is by using registry key detection. Many of the updates Microsoft ships create entries in the registry that can be used to detect whether an update is installed or not. All updates for the .NET Framework 1.0, 1.1, 2.0, and 3.0 as well as Visual Studio .NET 2002, Visual Studio .NET 2003, and Visual Studio 2005 create these registry keys which may be used for detecting whether an update is installed - all you need is the KB number corresponding to the update you are trying to detect.

The format of the registry key varies slightly for different versions of the products and can be generalized as:

HKLM\Software\Microsoft\Updates\[Product]\[MajorVersion]\[identifier]
or
HKLM\Software\Microsoft\Updates\[Product-Version-SKU]\[KB Number]

Updates for the .NET Framework 1.0, .NET Framework 1.1, Visual Studio .NET 2002, and Visual Studio .NET 2003 use an identifier instead of the KB number. The identifier is simply the KB number with the prefix "KB" replaced by either an S (for Service Packs) or an M (for all other updates such as security updates, hotfixes, etc).

Updates for the .NET Framework 2.0, and Visual Studio 2005 use the KB number with the "KB" prefix retained.

Here's the list of registry keys for detecting updates for various versions of the .NET Framework as well as Visual Studio:

.NET Framework 1.0 : Hotfixes, Security Updates, and other updates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.0\M886906

.NET Framework 1.0 : Service Packs

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.0\S867461

.NET Framework 1.1 : Hotfixes, Security Updates, and other updates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M886903

.NET Framework 1.1 : Service Packs

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\S867460

.NET Framework 2.0 : All Updates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Microsoft .NET Framework 2.0\KB917283

Visual Studio .NET 2002 : Hotfixes, Security Updates, and other updates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Visual Studio\7.0\M924642

Visual Studio .NET 2002 : Service Packs

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Visual Studio\7.0\S837234

Visual Studio .NET 2003 : Hotfixes, Security Updates, and other updates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Visual Studio\7.1\M927696

Visual Studio .NET 2003 : Service Packs

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Visual Studio\7.1\S918007

Visual Studio 2005 : All Updates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Microsoft Visual Studio 2005 Professional Edition - ENU\KB925674

Microsoft has released a security update on Tuesday (10/10/2006) as part of the monthly patch Tuesday cycle for the .NET Framework 2.0 that addresses a vulnerability which could allow information disclosure. This security update is described in security bulletin MS06-056 and in Knowledge Base Article 922770.

A small number of users have reported issues with installing this update. It appears that the issues reported fall into 3 categories:

Problem 1
The installation fails because Windows Installer 3.1 (a pre-requisite for all .NET Framework 2.0 updates) is not present on the computer. This is easily remedied by installing Windows Installer 3.1 from here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=889482fc-5f56-4a38-b838-de776fd4138c
All .NET Framework 2.0 patches require Windows Installer 3.1, so it is worthwhile doing this now.

Problem 2
The installation fails with an error code 0x643 (hex) or 1603 (decimal).
A workaround for this issue is described here in KB Article 923100

Microsoft has put up a little teaser site for Zune here, allowing you to signup for notifications/emails as and when more information will be made publicly available.

Is it me or is everyone wondering what the new Zune player will look like ? I definitely wonder whether Zune will it have the basic but polished appearance of the competitor's product or will it target a more geeky audience with features and buttons ? What would the storage capacity be like ? What would the screen size and resolution be ?

We're starting this race way after the competition has got their headstart, so there needs to be a compelling reason for this player to grab the market by storm. I think issues like DRM i.e. can the user easily move over content they already own between their player and their PC will ultimately determine the success or failure for this device more than its appearance. But I don't underestimate the weightage of the coolness factor either ;-)

I would love to hear your comments.

Earlier this week hackers from around the country met in Vegas at the annual Black Hat event. Vista is the first Microsoft operating system built from the ground up with security in mind i.e. using Microsoft's Secure Development Lifecycle. At Black Hat, Microsoft handed over around 3000 copies of Vista to hackers.

This IMHO is fantastic for all concerned. Microsoft will have the best hackers out there poking at Vista trying to find holes in it, while the hackers have an opportunity to flex their muscles too. Since the hackers may at least indirectly help Microsoft in securing Vista further, they will hopefully be a little kinder in the future when a vulnerability is reported. 

Mind you I say when, and not if, because there is no operating system so secure that someone given enough time and resources cannot find a security vulnerability in it. Going by the obnoxious Apple ads on TV, one might assume that an Apple never catches a virus or worm, is never infected by spyware, and is absolutely secure. This is far from the truth as demonstrated by Jon Ellch and David Maynor during a presentation earlier this week.

Operating systems are huge complicated pieces of code. Microsoft has several additional burdens - the operating system has to run on a very wide range of hardware over which Microsoft has very little control if any. The success of its operating system also means a new OS version is expected to maintain a high level of compatability with previous versions so that most applications that have been developed for an earlier operating systems will continue to run with minimal changes if any. Mind you no one is complaining about the success of Windows, but this is a burden our competitors that own the entire stack viz. the hardware, the OS, and the applications do not have to be concerned about. The complicated nature of the operating system naturally increases the possibility that a piece of code somewhere that under normal circumstances is secure, may misbehave when an exact set of conditions are met.

I doubt any OS vendor will ever be able to honestly claim that their platform is a hundred percent secure and has zero vulnerabilities. If someone claims zero vulnerabilities have been found, this only means that the vulnerabilities may be lurking just around the corner ready to hit them like a pie in the face.

In my first post whoami I mentioned that that I am a PM on the DDCPX team handling the release and distribution channels. I mentioned that I took up this position to replace another team member who moved to a different team.

Well, lightning does strike the same place twice sometimes. Shortly after I took on this role, another team member who was the primary Security PM for the division moved elsewhere, and I was given an opportunity which I just had to grab.

Microsoft releases fixes for security vulnerabilities in its products via security bulletins on a day folks outside Microsoft refer to as Microsoft Patch Tuesday. This is (almost) always the second Tuesday of every month. Each division has a Security PM, and the role I have picked up is Security PM for the Developer Division.

So what does the Security PM do ? He or she is responsible for security updates for the division. In my case, this means that when there is a security vulnerability reported in any product coming out of the Developer Division (e.g. Visual Studio, .Net Framework, etc), I would be the first point of contact for the MSRC team which handles and is ultimately responsible for all security updates company wide. I would need to identify the appropriate owner(s) for the vulnerable component/dll, work with the teams to anlayze the issue and  prioritize, implement a fix, and simultaneously work with the MSRC team for the release of this update to the general public. Yup, that means I expect to live and breath by Microsoft Patch Tuesday schedules.

In the short term, I continue to handle the release distribution channels I picked up earlier, but I expect to hand that over to another team member.

I am a Program Manager in the DDCPX (Developer Division Customer Product-lifecycle Experience) team. This team services (provides regular and security updates, hotfixes, etc. for) products including Visual Studio and the .Net Framework.

I have very recently stepped into the release arena, filling for another team member who moved to a different group. I own the distribution channels for the products we service. These include all the possible means for getting an update out to all our users, including Microsoft Update, Windows Update, the download center, SUS, and WSUS (the last 2 are technologies used by enterprise customers for deploying updates to thousands of desktops easily).

I hope that this blog will be a channel for us to discuss some of the work we're doing, and for you to let me know what in your opinion works, what doesn't, and what could be better. On occassion I might also ramble on about other things I find interesting outside of work. That being said, everything here is my personal opinion, and Microsoft neither endorses nor edits anything posted here. Please read the disclaimer for more information.

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the views, thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.