Alexander’s Blog

Redmond Magazine has an interesting article this month called Microsoft Math. They’ve examined Microsoft’s track record in hitting the product ship dates. Although the results don’t surprise anyone because everyone, including Microsoft employees themselves, assumes their products will not ship on time.

Microsoft has been late delivering products going back to Windows 1.0. Looking at the numbers, it has been a common practice for them to deliver products that are 12, 14, 18 or even 21 months late. According to the graphics from Redmond Magazine below, the Windows desktop products are delayed on average 10 months and the Windows servers on average 9 months. Windows NT 3.5 was the only server product that was shipped on time.

I believe having these numbers published would help Microsoft make more realistic promises for the release of their products because they would realize that it’s pretty embarrassing for a company to not deliver on time so consistently. I would rather see a product that works and is well tested, instead of seeing it released on time. But why not say that Longhorn will be released in the Spring or Summer of 2007, instead of end of 2006? Perhaps Microsoft will release Longhorn on time and surprise all of us. I also don’t mind at all if Microsoft drops or adds features at the last minute. They have every right to do that. They want to release a product that works properly. If they can’t include WinFS in Longhorn then that’s fine. They will offer that at a later time when it’s ready. However, I do have a problem when organizations don’t deliver their products on time because it shows that the company is not organized, lacks project management, and doesn’t care what the impact might be on their customers.

It’s unfortunate that being consistently late in delivering products affects Microsoft’s credibility because there’s a lot of time, talent, and energy goes into each and every product.

You can enable logging of Group Policy Objects by following one of the two methods listed below. The log file will be created in the %windir%\temp folder. To locate the Temp folder type cd %temp% at the command prompt. The name of the logging file is randomly selected. It begins with “msi” and ends with a .log extension, e.g. MSIef63.LOG.

Enabling Windows Installer Logging Manually
1. Start the registry editor, regedit.exe.
2. Go to HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
3. Create a New, String Value called Logging. You will notice that the type is REG-SZ.
4. Double-click Logging and enter voicewarmup for Value data.
5. Click OK and close registry editor.

The letters in the value data field can be in any order. Here’s what the letters stand for.

v – Verbose output
o – Out-of-disk-space messages
i – Status messages
c – Initial UI parameters
e – All error messages
w – Non-fatal warnings
a – Start up of actions
r – Action-specific records
m – Out-of-memory or fatal exit information
u – User requests
p – Terminal properties
+ – Append to existing file
! – Flush each line to the log

WARNING: The above change to the registry should be temporary only for troubleshooting. If you leave this value in the registry it will have adverse effect on system performance and disk space. Each time you use the Add/Remove Programs in Control Panel, it will create a new Msi*.log file.

Enabling Windows Installer Logging through Group Policies
You can also enable logging with Group Policies by modifying the appropriate Group Policy. Go to Computer Configuration, Administrative Templates, Windows Components, and select Windows Installer. Double-click Logging and then click Enabled. In the Logging box, enter the options you want to log, e.g. vmeap.

According to Microsoft’s KB article Q223300 this only applies to Windows 2000/NT/Me/98SE/95. However, this also works for Windows Server 2003. If you have tried enabling the logging in Group Policy and can’t get it to work, use the manual method by modifying the registry as shown above.