Re: Future of the MSI provider?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Yan-Hong Huang[MSFT],

Thank you for taking this up with the product team. I'd also like to say the managed newsgroup service is an excellent facility that puts other software vendors to shame, and it's also fantastic that it uses the open standards NNTP protocol.

However, I'm very disappointed with the recent responses from Microsoft representatives to my three questions regarding Microsoft's core technologies, WMI and MSI. The responses vary between buck-passing, lame excuses and misinformation - as I will explain.

Firstly I reported a bug in StdRegProv on 20 Jun 2007 in this newsgroup with the title "Default Value BUG in StdRegProv.EnumValues()", I spent a lot of time explaining it, even though it was already in Microsoft's database. The response from Steven Cheng was that he can't do anything, doesn't have access to source code, and doesn't even have access to the product team, and that I need to call PSS! I'm paying a fortune to Microsoft every year and I'm doing all the work here, I expect your departments to be able to communicate with each other and I expect them to get off their butts and do some work. I could fix and test all regression issues in two hours. They've left it broken for five years - just not good enough.

1) About optional installation of Windows Installer provider
Moving a component to be optional is a very different decision than depreciating a component.

It's a WORSE decision! The whole point of WMI is that it's supposed to offer a management interface that abstracts the quirks of each Microsoft operating system platform and version. The moment it was removed from Windows 2003 Server and x64 versions of Windows is the moment the WMI dream collapsed, so I should really have asked "What is the future of WMI". It means bits of it can be taken away on the whim of what's in fashion that week.

If we can't rely on all providers being installed cumulatively to each newly released o/s, we can't design solutions for Microsoft's range of o/s, and we can't expect customers to have to install "optional" components to hundreds of servers on their sites in order to bring them back into compliance. You also have not explained the text from the documentation that states:

"Optional installation of the Windows Installer provider ensures backward compatibility with the Windows XP and Windows 2000 feature sets, but does not indicate future availability of the provider."

What does that mean? Will it be installed to Longhorn, Windows Server 2008??

> As I mentioned, for Windows 2003, the MSI provider to WMI was
off by default due to Microsoft Trustworthy Computing principles Defense in Depth and Secure by Default.

Windows is not "Secure by Default", they [Microsoft] put the user straight into the Administrators group, even on Vista, and UAC isn't a security boundary as confirmed by Mark Russinovich [MSFT]. I could design a better security model in my lunch hour. Actually, it was already there in NT 3.51

So let me get this straight; the MSI provider constitutes a security risk on Windows Server 2003, but NOT on Windows 2000, XP and Vista?? I'm sorry but I find that hard to believe. Are Windows 2003 customers aware they are putting their servers at risk when they install the MSI provider? Has this been reported to the Microsoft security team and have they issued a security bulletin about it?? Why is this not stated in the PSDK documentation?

2) About MSI and DCOM issue
Our product group PM has looked into that newsgroup thread. Basically, the technical discussions hit on the right themes. SMS and GP are the current solutions to this type of issue.

Sorry, but this is incorrect. SMS and GP are NOT a substitute for using MSI over DCOM as I explained in the original thread on the MSI newsgroup. I don't know if you guys do big corporate roll-outs, e.g. Office 2007, but GP is flawed in this context. An example is this week both Flash and Java reported security problems, you need to uninstall and re-install in both cases. I've just done this on a site with 1500 desktops without needing a reboot, can you do that using GP? Regarding SMS, it's bloated and badly designed and requires special package format and a client agent, plus an SQL back-end. Why would I want that when I can do the same job in five minutes using ECMAScript and COM interfaces without having to install anything?

The correct solution is using MSI with DCOM but some have said, unofficially that they [Microsoft] are deliberately dumbing down the vision of the MSI team in order to try and push sales of SMS. If that's true, again I'm very disappointed. What about Bill Gates when he was talking about external regulators stifling innovation? Now it's happening INSIDE Microsoft:(

> We truly understand your concern and situation here. Our
PM will bring your suggestion back for future consideration.

Thanks, this is very helpful.

3) About PowerShell information
It is implemented by a 3rd party project maintained by Windows Installer community; see the link below for details:
"Windows Installer PowerShell Extensions"
http://www.codeplex.com/psmsi

OK, it's not even an official Microsoft release yet. It will be years before we can use it to manage thousands of desktops in default config across multiple Microsoft operating systems. We need WMI and MSI fixed NOW on all o/s from Windows 2000 onwards and the fix needs to be put on WindowsUpdate so all supported machines are brought into line.

If not, we may as well give up with WMI as it will just be a disjointed legacy mess.

--
Gerry Hickman (London UK)
.

Quantcast