Carolyn Napier and Tyler Robinson (MSI team) - Installing apps in Windows Vista
- Posted: Nov 09, 2005 at 1:00 AM
- 90,619 Views
- 33 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
Windows Vista evangelist Ernie Booth came into my office a few weeks back and said "hey, let's go interview the MSI 4.0 team." Who's that? That's the team that makes the application install technology that'll ship on Windows Vista. Your app will probably
use their technology to install, so you'll want to hear this and see the demos they do for us.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
Within any MSI file provide the ability to specify an URL where patches will be posted by the ISV. Then, let the Microsoft Update engine check these locations for all installed MSI files regularily, like it checks for updates of Office etc. Just integrate third party updates into the Automatic Update feature of Windows, but ONLY requiring extra info in the original MSI file to take advantage of this feature. You would really do the whole Windows platform a great service, since a ton of these super annoying background processes could go away.
I like your idea for integrating all application updates with Microsoft Update. We really need one central place for updates.
BSP
The problem is that there is a class of apps where this is too risky. I fully understand that Realplayer, Java, Quicktime and thelike can't to it that way. If someone just very rarely watches videos in his browser that instantiate the player there is just a way to high likelyhood that he/she will hit some content that has malware against which the patch hasn't been applied at this first viewing.
Also, while there is another class of apps where option 1 would be nice, it seems that a whole lot of ISVs still opt for 2. I as the user pay the price by having countless services wasting my resources. The real solution here is to have a platform service that takes care of this.
Wasn't there talk that security would ALWAYS trump nice features in Vista? So, I assume MS at some point had to figure out whether to do AutoUpdate (I operate under the further assumption that they came up with that idea in the first place internally) or integration with restart manager. Hell, how could you decide for restart manager and against AutoUpdate in that case?!? Sure, if you mean by "We improve security only in our code", yes. But if you take the postion that security is an industry problem and once you realise that NOT having auto update for MSI in the platform will lead to significant worse security than having it in, this seems to be a no brainer to me. Am I wrong?
I just feel that having a seperate auto update feature for every app on the system is error prone and will decrease security. Just the sheer number of different configurations will completly confuse users, so that when in doubt they will just shut it off. Also, at some point I just HAD to disable some auto update services on an old machine since they took so much system resources that I was hardly able to use it for anything meaningful anymore.
Why can't we just click on the msp?
But isn't that already available in Windows, called Hiberation?
Stange, I've use applications that allow you to just click on the .msp file to install it.
Stephen.
The #1 mistake that software developers are making these days is assuming people will be administrators on their machines and assuming that people can update software.
If Microsoft succeeds with its LUA/UAP goal for Windows Vista then most people will not be running as an administrators on their machine which means that all of these auto updates that apps are doing these days will fail.
don't think so. if you watch the video again you'll notice that if the msi has a certificate of the author embedded into it the non-administrator user can allow the app to go to the web and update itself. msi engine will automatically raise the privileges to admin level for the application during install. this is only true if the app has been installed by an administrator, though... at least that's what i got from the video.
regards,
martin.
Now, to make sure that everyone uses Windows Installer!
Office however does use the Windows Installer technology and you can see which patches are installed for Office (and Windows too) in the add/remove programs dialog. But not all patches are uninstallable!
Depends, but I think we've seen what happens to business and people running old versions. Would you like to give your personal information to company still running Windows 2000 or older? It can be assumed that company isn't very up to date in their router, firewall and other software either. Bad guys will have a field trip in such companies, without the IT staff ever knowing it.
The software should keep itself up to date. When the software is first installed, if future updates require admin right, the installation will most likely also require admin rights - thus it will be possible for the software to make itself have permanent rights it needs for the auto-update or use some system provided auto update service.
User should only be inconvenieced when the update involves breaking changes and other things user might be interested in.
Like many of you, I'd like to see a solution in the platform but until then we're building technologies in the WiX toolset to enable many of the scenarios people describe above. Also note that the WiX toolset is Open Source so if you want to see how it is done or contribute to the cause, you're welcome to join the community.
As a matter of fact, we are.
- Take a look at our talk from
PDC 2005. (FUN222)
- Attend our upcoming MSDN Chat on Tuesday, November 15.
- Check out our Team Blog.
Now, to address some specific questions on the thread so far ...The Restart Manager is actually a standard set of Win32 API's that will be available for anyone to plug into. Some information about this was given in the Reliable Apps PDC 2005 (FUN308) talk. So, while the Windows Installer provides the easiest way to support the Restart Manager from your installation, it is not the only way.
The Windows Installer has always had the ability to create double-clickable patches, you just had to do some extra authoring as part of the patch creation process. As of Windows Installer 3.0 (Windows XP SP2), we added automatic support for double-clicking of MSP files without any extra authoring required.
The Windows Installer provides lots of technologies that enable auto-updating of applications on Windows Vista. For example, if you combine our UAP Patching functionality along with our Restart Manager integration, you get a really great experience where applications can easily update themselves without requiring the end-user to consent to elevation and with the application automatically shutting down and restarting to mitigate the reboot. Additionally, our existing feature that allows you to apply patches at the time of install makes it super-easy for a bootstrapper to check the internet for updates and apply them automatically at install-time.
Granted, this isn't the centralized universal update mechanism in the operating system that many would like to see, but I think the Windows Installer has made great strides towards improving the application update story in Windows Vista.
Thanks so much for your comments, and please remember that we have an upcoming MSDN Chat on Tuesday, November 15 that focuses specifically on our Windows Vista feature set. Please attend.
- Tyler Robinson
- Program Manager
- Windows Installer Team
1 central place to update all your (msi) applications. What about companies that deploy applications using Active Directory? Can they use WSUS to update all those 3th applications?
Sorry Robmen, but I don't think Clickthrough is the way to go.
Note that Restart Manger itself doesn't save the application's state. It only tells the app to save its state, then closes the app and later re-starts it. The app needs to be coded such that it responds to the message from Restart Manager and saves its state. I too find this cool, and I hope that application developers will start to prepare their apps to support this.
There are two problems in the update story: 1. Being notified about available updates (or app automatically checking for updates), and 2. actually applying them. Often updates don't get installed because they would require a reboot or at least a restart of the app, which the user doesn't want to do right now*, or there's no user sitting in front of the machine to save their open documents when you deploy updates at night. Restart Manager can help with problem number 2.
But I agree that a central location for all updates would be great.
* Typical situation: When I double click a PDF file Adobe Reader tells me that an update is available. But at that very moment I want to read the document, not install an update, so I decline the update.
I mean take a look at uninstalling VS.NET 2005 and SQL Server 2005 and you'll know what I mean. (and there is actually a tool to uninstall the betas etc because it's so damn hard to do it right!!!!)
Please please please for V4 of the Windows Installer engine provide us with the ability to sign Merge Modules and patch them separately from the application.
By doing this you achieve the following:
1. A Microsoft signed merge module could then write to the system directories thus updating/installing system components. (Add this functionliaty for a special exception to the rule please!)
2. Patching the modules gets rid of the reason why the MSDE merge modules were pulled. By allowing patching of merge modules (registered on the machine separately) all merge modules and system components can be updated independant of the application thus allowing MS to update the system components that were installed via merge module without relying on 3rd parties to patch their applications.
End result, by doing these two small things and implimenting an exception to the "no install to system dir" rule (and also allowing by pass of System File Protection for signed merge modules from MS) we get rid of the need for all bootstrapping and can again provide our end users with a seamless install experience and only install those things that are actually needed to be installed by our application based on the choices of our end users instead of having to install every system component even if it isn't needed for the choices of the user (i.e. SQL Express Edition etc.)
Please please please put this in and end the bootstrap crap. A boot strap should only be needed (and included in the dev kit) to download and install (or grab off of the CD) the Windows Installer V4.0 setup and then run the installation. There is NEVER an excuse for anything else to be installed before the application installer runs. It should all be done transparently for the user. There is no reason why the end user should ever know that SQL Server Express is also being installed on the computer. And the end user shouldn't ever have to know to uninstall SQL Server Express separately from the application to get rid of your application on uninstall (i.e. VS.net 2005, SQL Server 2005 mess in Add/Remove Programs)
I can't say enough about how important this is to fix. It is the most important thing of ANY bug (yes it's a bug) that MS has in any of its products that need to be fixed. You're creating an installation experience that results in users being confused and the uninstall experience is even worse (you shouldn't need a knowledge base article to be able to correctly uninstall an application, and if you dont' follow it you can end up with a non-functioning installation of the OS, both of which can happen uninstalling VS.net 2005 and SQL Server 2005 by hand now)
Please fix this.
I so totally agree with that. I just hate using Adobe reader for that reason. They seem to ship updates every week (more or less)
Seriously, a central way of updating ALL your applications (regardless if there were written by Microsoft or not) would be a dream come true. Especially for us IT-administrators. It's not too fun to browse the web all over just to see if there's an update available or not. I'm not saying that it's Microsofts responsiblity to notify the users of thirdparty updates, but it sure would be cool if someone took the first step and made it all easier somehow. So why not the one with the core?
Furthermore, most administrators want to keep consistency and upgrade only after they have thoroughly tested updates. Relying on end-users to update their own desktops is not an option--you end up with a hodge-podge of different patch levels for different applications from machine to machine. Worse yet, as you add integrating apps into the mix--a couple plug-ins to Outlook, say--things can get really nasty. Update plug-in A, plug-in B breaks; update plug-in B, plug-in A breaks; or better yet, update either, and take out Outlook altogether. Giving the end user the ability to update at their whim--even if it's a security update--is something that must have a switch that administrators can turn off (perhaps through Group Policy). There are usually work-arounds for security issues, and you can't let a security update totally stop the company.
Edit--Nevermind, I see that they mention this in the video. The administrators can turn this function off. (Yay!)
Do whatever it takes to add the functionality into MSI to let me install MSDE/SQL Express as part of my own MSI installer. And also let it uninstall my custom instance when my app is removed.
If the functionality already exists in MSI, go to the SQL team's building and give them evil stares until they fix it.
I can't stress enough what a nightmare it is trying to bootstrap these things onto the front end. Bootstrappers don't deploy over IntelliMirror/SMS! [C]
Be careful what you ask for there or you'll end up with cack like the "InstallShield Update Manager". When I first saw this braindamage pop up in the taskbar tray I was like, WTF? An update manager for the freakin install program? Well, it turns out that it is also a shared update manager for other programs. How I was expected to be aware of that I do not know. I just wanted the abomination to sanity off my system. I'm not even sure what junkware that came with my new Dell relied on it, since I managed to uninstall most of that as well.
I'm sorry but end users don't give a rats hindquarters about the InstallShield brand. Keep that to the MSDN magazine ads.
And while we're on the subject of both Adobe Acrobat Reader and inappropriate brand whoring, what's up with the "Netopsystems FEAD optimizer" technobabble you get when installing the Acrobat Reader trhese days? Adobe, did you ever consider just saying "decompressing" or "unpacking", or dare I say "installing" while showing a progress bar? And while you're at it, add a cancel button to that dialog. Its absence was made all the more obvious as I once watched the "decomposition" process crawl for several minutes on an older machine, left only to bask in the dialog box's utter ridiculousness.
On a similar but more subtle note, Why do the dialogs on some uninstall routines display messages like "configuring UnwantedProgram". Shouldn't it just say "uninstalling UnwantedProgram"?
Bah.
</rant>
Sorry for that. I just had to unload. Spending a couple hours uninstalling all the crud Dell puts on a new PC will do that to you.
I have a question about how it will save state and reboot the system. On a fully locked down machine, lets say you have it install something it appears to be done it reboots and then the use logs in to complete the install (not the admin), does it encounter the same problem as it currently does? Or will the Windows Installer Service be running with special privileges that will enable to take full control of the system to handle a download without user interaction? (this is how it should work, perhaps with signed msi's only or something for security?)
Anyways just curious...
We have been keeping a close eye on the thread here and I wanted to reply to some of the messages...
The Windows Installer team completely understands the pain associated with bootstrappers, and we will be working hard in the future to address the situation. Unfortunately, we were not able to do this work in Windows Installer 4.0, but rest assured that we will be looking at this very closely for our next release.
I agree completely with the other sentiments on this thread that the operating system really needs a central application update mechanism. I believe that the Windows Installer 4.0 provides the necessary infrastructure so that it will be possible for Microsoft (or a 3rd party) to build such a solution in the future.
And finally, thanks to those of you who attended our Windows Installer 4.0 chat on Tuesday. If you were not able to attend, a transcript will available here within the next few days.
- Tyler Robinson
- Program Manager, Windows Installer
ShadowChaser: See my post. This is what MS has to do to fix this bootstrap uninstall nightmare that they have created. Instead they seem fixated on boostrappers as a way to solve the problem instead of fixing the originating problem that caused bootstrappers to be necessary in the first place.
Fix the real problem, don't bandaid it please!!!!!!!!!
Don't bother releasing a new version until you've fixed Bootstrappers. Update features are a pointless waste of time until you give us a seamless single install point. You're greatest problem is exemplified by trying to uninstall VS.net 2005 and SQL Server 2005. Do whatever it takes to fix this NOW as opposed to later and worry about the rest later. There are a ton of 3rd party systems (Wise for example) that give Windows Installer most of this functionality. However, there is absolutely NO WAY to get around the bootstrap disaster. Yes it is a disaster and I'm not exagerating. Any application that needs a KB Article and a uninstall tool released by the dev guys that wrote it after the fact is a disaster waiting to happen. Windows Installer Team should be absolutely asshamed that they have created this mess. And be doing whatever it takes to undo this and posting a huge appology to both 3rd party people forced to use Windows Installer and to the dev teams in MS that have to release crapware that can damage an OS installation of not uninstalled with careful instructions that are many pages long.
Get your priorities straight People.
True, but MSI is a fairly complicated platform, and certain changes might cause serious problems to existing apps.
I do agree 100% about the bandaid comment though, but bootstrappers have been around for ages. Creating a bootstrapper *is* a good stop-gap solution, but I do think that eventually this problem needs to be solved.
I don't think it's the windows installer team's fault - it's more that they've been left out of the loop on decisions made by other teams - system file protection would be a good example. The other product teams (MSDE, Windows Security/Patching, etc) seem to run into a small snag - some function or minor API windows installer is missing.
They then create large hacks and workarounds, causing serious problems for ISVs. If they had just worked together to add the functionality to windows installer in the first place, none of this would be an issue.
Updates is a big concern as well though - as big as the bootstrapper problem. Most "app updaters" run with the assumption that the user is logged in as an administrator - which is a very bad thing for security. As a developer *and* and IT guy, I find it extremely frustrating how many applications completely ignore LUA best practices. Integrating low-trust user app updates into MSI seems like a great idea to me, and does fit nicely into the Vista feature set. I wouldn't get too upset about it:)
And I can't believe for a second that the Windows Installer team is out of the loop at any step of these teams running into this stuff. If they are, then there is a collosal problem in MS that needs to be fixed and people's heads need to roll over it. I know for a fact that both the VS.net and SQL Server 2005 teams were bitching about this very thing regularily, and I don't think ANYONE missed Slammer which was a large part the responsibility of the Windows Installer team's mistakes with design in Windows Installer. They would to have had their heads so far up their ... that they would have been tickling their tonsils.
This has been coming for almost 6 years now, they had lots of warning and have chosen to not do anything about it. That's unacceptable and inexcusable. 6 YEARS!!!!
We are informed users. In this clip for example, the interviewer is good, he's quiet and asks questions that are pertinent.
The cameraman however, annoys the hell out of me. I don't watch these videos to hear someone complain about how someone's computer had to reboot last night because of updates, and more than once he interrupts interviewees from saying what they have to say. This isn't Fox News.
Kudos on the interviewer. Cameraman, shut it and listen: you might learn something new.
Pv
Remove this comment
Remove this thread
close