Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Nick Beaugeard: Good morning, everybody. My name is Nick Beaugeard. I'm a program manager in the Systems Management Server (SMS) group here at Microsoft in Redmond.

I'm really exited to be here with you today to talk about the new upcoming release of Microsoft^® SMS Installer with the Installer Step-up Utility. This is a big move forward for Microsoft SMS Installer, and I'm really pleased to be able to present to you some of the content today, and introduce some of our topics.

Let's look at the agenda for today's session (slide 2). I'll go through some of the things we'll be covering today. First of all, I'm going to introduce you to the new Microsoft SMS Installer with ISU. You should be seeing this released on the Web within the next month, and that will be available from the normal SMS page, which I'll give you a link to at the very end of this presentation.

We're going to have a look at what we've done with SMS Installer, how it integrates with ISU, and how we've linked that together to get some pretty great functionality. I'm also going to go into some of the things you can do with SMS Installer. I'll talk about the Repackaging feature, the Watch feature, I'll talk about some of the more common script items, and then I'll talk about making .msi or Windows^® Installer files and how you accomplish that with SMS Installer. At the end, I'm going to talk to you about some of the tools we've made available to convert the existing .exe files that you may have, and turn them into Windows Installer files that you can distribute, using either SMS or Group Policy with IntelliMirror^®.

Moving on to the introduction (slide 3), SMS Installer with ISU. This is a newer version of Microsoft SMS Installer, with the integrated Installer Step-up Utility, which will be posted to the Web, as I said, within the next month. The version we're posting to the Web is aimed at SMS 2.0 customers. SMS 1.2 customers can already download a version of Microsoft SMS Installer that doesn't include the ISU functionality. And we'll be doing a refresh of that as we post the new version to the Web.

SMS Installer can create .exe files for distributing software in silent or attended modes, and Windows Installer or .msi files. We're really pleased that we've managed to get this functionality into SMS Installer, because I know a lot of you use this as one of your tools of choice right now.

The Advertisement and Repair functions are also supported. That's not to be confused with the SMS Advertisement function. That's a Windows Installer feature where you can just publish an icon. When they double-click on it, it will install the software for them. And if they delete the files or corrupt them, Windows Installer will detect that, and reinstall the application for them. We put that functionality into the Installer Step-up Utility to allow you to get that functionality with your existing SMS packages or new ones that you may want to create, using either the Repackager or Watch.

What I'm going to talk about now is what this new tool can do (slide 4). We've integrated the Installer Step-up Utility into the SMS Installer console, so you can create either Windows Installer packages or .exe files, as you traditionally have been able to, from the SMS Installer. That will allow you to have MIF support for reporting status back up through your infrastructure, and also allow you to use some of the more advanced features available in Windows Installer.

We also provide a command-line utility, which I'll be discussing in depth a little bit later. The command-line utility allows you to convert your existing .exe files without the need to totally rebuild your original reference computer that you built them from.

The other things we're allowed to do, which are part of SMS Installer and have been for a while, include the ability to repackage existing setup utilities and turn them into customized or silent installations. There is also a feature in SMS Installer to allow you to watch an installed program, see which files it calls, which registry entry it modifies, and build a setup from that. I know a lot of customers have had a great deal of success using that.

The key thing here is being able to take what were installations that could be customized by any user or any support person and convert them into a single package. Which means whenever you install these across your enterprise, you install it in the same way, which lowers support costs in your environment. With that, we also have the ability to integrate into Microsoft Systems Management Server to allow automated distribution and tracking of the success or failure of those installations across your environment. So we're really pleased to bring you this new version, expanding into new areas of technology, and allowing you to expand your existing functions and do more and more with our tools.

I'm now going to delve into some of the functions that are available in SMS Installer today, for those of you who haven't used it, or who haven't used it lately, and I'll talk about how we suggest that you use them in the most appropriate way. The first function I'm going to touch on is Repackaging.

Repackaging (slide 5) is taking an existing setup or set of modifications and converting them into a single install file, which can be installed either with user prompt, as you configure, or silently.

The key thing you need to do here is start with a clean reference computer. SMS Installer examines the machine before you install your software, examines it afterward, and it works out what the changes are. If you don't have a clean reference computer with basically just the operating system there, there is a risk that we might miss files. Files may not have been modified by the setup, and we may not pick those up. It's really important, when you're performing a repackaging exercise, to have a clean reference computer. For example, one with just your standard operating system build, or one with your standard operating system build with just a few applications installed, as would normally be on every desktop in your environment.

The next thing you need to do is install SMS Installer. The SMS Installer product is very well contained within its own directory, so it won't affect your repackaging operation after you've installed it.

What you do from there is run the Repackage wizard, which will check the computer, read the registry, read all the files, find out what's on there right now, and prompt you to run an installation .exe. Now one thing I commonly do in the field is, instead of running an installation .exe, I run a command prompt. That allows me to run a number of installation programs in the order I specify, or move through and make modifications of my device that the Repackager can capture.

After you've completed that, close down your installation and complete the Repackage. SMS Installer will analyze what your machine looks like now and compare it with what it looked like before, thus generating a whole list of files, registry settings, any file modifications, that setup or that operation has completed.

The next key step is to go in and look at the script that SMS Installer has generated. SMS Installer may pick up things that you don't want to copy across. One of the common ones is the Most Recently Used list, which you may not want to be distributed to all your machines. So what you need to do then is go in, look at all the things that SMS Installer will be changing, and make sure that those are things that you wanted to capture. There are a number of those that you may want to pull out and not use as you go through. Then, after you've completed that, you can compile it as Windows Installer package or compile it as an SMS Installer executable, as you historically have been.

The next slide (slide 6) I'm going to move on to is a sample showing you where to get those bits from the UI. When you normally start SMS Installer, it will start in what's called the Installation Expert. You see a screen shot of the Installation Expert, showing a number of buttons down at the bottom. The Repackage button is the one I talked about before. That will prompt you for an installation program to run, take a snapshot of your machine beforehand, take snapshot of it afterward, and work out that delta. The Watch button is something I'm going to cover in the next couple of slides. Compile, Test, and Run are all about compiling SMS Installer executables. That's one of the key things there. It's from the menu bar and the toolbar that you'll compile a Windows Installer package. We've added new toolbar icons in the Script Editor, and new menu items to allow you to go in there.

If you look at the menu in SMS Installer, in the Build menu, we have three new options. Those are Compile as Windows Installer Package, which could be accessed using CTRL+M, Run as Windows Installer Package, which can be accessed using CTRL+I, or Uninstall Windows Installer Package. It's important to realize the way Windows Installer works is after you've installed a Windows Installer or .msi package on a machine, you have to uninstall that to run it again. We've provided that for you in the UI, so you can test, compile, and run those Installer packages again, again, and again, to make sure they're working as you expect them to, in the most effective manner for you.

From a UI perspective, it hasn't really changed. We have three new options in the Build menu, and if you go to the Script Editor, there are three new toolbar buttons. They have the same toolkit information as the rest of them. Moving the mouse pointer over them will allow you to see Compile as Windows Installer Package, Run as a Windows Installer Package, or Uninstall a Windows Installer Package. Always remember to uninstall before you try to run one again.

So we try to keep things consistent, and make them look and feel exactly as you've seen before, while adding the extra functionality. One thing you'll notice from the UI point of view is in the actual Script Editor, when you compile a Windows Installer package, a new window will appear at the bottom of the Script Editor. That is for verbose or nonverbose outputs on exactly what the Installer Step-up Utility is doing to convert your files into a Windows Installer package. And that's extremely useful for troubleshooting or diagnosing problems you may have.

What I'm going to cover now is the Watch functionality within SMS Installer (slide 7).

Watch is a piece of functionality that's been in SMS Installer since it originally shipped, and although it's used by a number of customers, it isn't as heavily used as we may have expected. This allows you to watch an existing application. The way it works is, it examines that application to see which .dll files it calls, which files it edits, how it works against the registry, et cetera, to build you an installation package for that program. That's really rather useful if you have a program where you've lost the setup, or you don't have setup anymore, and you want to distribute that to other machines in your environment.

The way to use Watch is to run the Watch command from the UI example I showed you before, chose the program you want to run, and run through every feature in that program, apart from printing. The reason we don't suggest that you watch printing is that it will call into the printer drivers, which you may or may not want to repackage for a user. So you run through the application, you use those features, and it will create a script based on the modified files. Once again, that script can be compiled as either a legacy .exe file, as we've always used them, or compiled as a Windows Installer package, with all the functionality and features that gives you. So that's the Watch feature.

What I'm going to talk about now is some of the key technology differences between Windows Installer, or .msi, and the original .exe files (slide 8). A lot of customers have used these .exe files to create utility-style scripts, scripts that will prompt the user for action, and then go and perform actions, and prompt the user for some more actions, and then do it again. Windows Installer has not been designed with that in mind. The Windows Installer technology is designed for setting up applications. To do that, it's built into two discrete phases. Those are called acquisition and execution. Let me drill in and explain those a little bit.

The way a Windows Installer package works is it will first perform the acquisition piece of the install. Things like finding out what the Windows directory is, finding out how much hard disk space there is, querying registry keys, querying values from any files and from any environment variables. After it has that information, it then moves into execution. Execution is where it goes and copies the files, makes modifications, adjusts any files, runs custom scripts, etc. With a single Windows Installer package, I can only do one acquisition phase and one execution phase.

Now in most SMS Installer executables, acquisition and execution is scattered throughout the script. To support the Advertise and Repair in Windows Installer, we're limited to only being able to use one package. So if you use the switches and the features in SMS Installer to create a Windows Installer package with those features, you'll find that SMS Installer will reorder your script to ensure that there is a single phase of acquisition and a single phase of execution.

However, if you don't need that support, SMS Installer will build multiple packages and then nest them together in a single package. So you have the Windows Installer package, and it matches the functionality you have in the executable. However, at this stage, we're recommending that for setting up applications, use Windows Installer technology; it's great for that. However, if you're trying to create utility scripts, we believe you're far better off still working with the legacy executable files. That gives you far more functionality and flexibility in that space than Windows Installer gives you.

Just to go back there, I want to cover this again, it's important to remember how Windows Installer works — the two discrete phases of acquisition and execution. So if you're creating one of those utility scripts, it's important that you use the executable files. And if you want to create setups, you then use Windows Installer. And we support that through SMS Installer.

One of the questions I get asked a lot with this new version is, can you open Windows Installer files and edit them with SMS Installer? The answer to that is no. That is not functionally we put in here. We put in functionality to allow you to open your original executable files or create scripts using Repackage, or Watch, or using the Script Editor, but we haven't put in functionality to allow you to open and edit .msi or Windows Installer files. That's because Windows Installer files are a very different technology to SMS Installer technology, and we wanted to give you a very consistent look and feel in the interface, and leave you with something you're very familiar with, especially at this phase, in-between product cycles.

I'm going to talk about how you create .msi files with the Advertise and Repair support (slide 9), because I know that's something that people will want to be looking at.

Okay, how do we create these files? Well, we've provided an ISU command-line utility, which will allow you to convert your existing executables into .msi files. The switch for that utility is the /j switch, and that will go through and create a single Windows Installer package that supports the Advertise and Repair functionality. You can also use the user interface.

If you look at the installation properties, and the global installation properties, using SMS Installer, we've added two more check boxes there. The check boxes you'd normally see were the ones around maximum compression, controlling the installation speed, Zip compatible, etc. What we've also added are two new areas: first, the ability to use verbose output during .msi compilations, and that gives you the ability to see a lot more detail about what we're compiling. The other one is the Include Advertisement Support in MSI Output, and that equates to the /j switch, using the ISU command line.

So when you've enabled that, it creates a single Windows Installer or .msi file, with no nesting of packages. It also modifies your script, and it modifies your script to allow the acquisition at the top and the execution at the bottom. This is great for setup-style packages, the packages that can install software and applications for a user. Those utility scripts I was mentioning before, we're not recommending that you use those right now. Those are the features that allow you to use some of the more advanced Windows Installer functionality.

What I'm going to talk about now is some of the script actions that are available in SMS Installer (slide 10). SMS Installer supports 69 script actions. If you go into the Script Editor on SMS Installer and work through all of the actions on the left side, there are 69 of them. They allow you to do things like flow control, file installation, add directories to the path, modify environment variables, modify the registry, install files, remove files, install directories, remove directories, find files, iterate through files, install ODBC, et cetera. And there are a whole range of them.

What I want people to be aware from this slide is the amount of functionality that is available from SMS Installer. There are a whole lot of things. When I first started using SMS Installer when it was released, I wasn't really aware of the number of things you can do with this product. But as things have grown, we've found it to be very flexible. Here at Microsoft, we have teams that use SMS Installer to compile things that are sent out to customers, build installation scripts, and use it for hot fixes. It's also used in a number of other areas. So it's a very powerful tool that we use a lot here, and we understand there is a large user base that has been using this tool, as well. There are a large number of actions you can use, and you can create scripts by hand, or use the Installation Expert to build those scripts for you.

I'm going to now move into a little bit more detail on those script actions (slide 11). As I just said, it's really advisable if you're new to SMS Installer to use the Installation Expert to initially create a package. The Installation Expert will allow you to walk through the various actions of creating that package — scroll through which files you want to modify, which registry keys, any files you want to edit, how many components do you have, which icons do you need to put in? That gives you a great basis for a fully working package that supports uninstall, and some other features.

You then can flip to the Script Editor to add custom actions, custom dialog boxes, and perform some more complex tasks, like complex IF/WHILES, IF/THEN, ELSES, BLOCKS, getting registry keys into variables, and manipulating those to do specific tasks.

If you want to extend SMS Installer functionality, you can use the Execute program to call out to a script, or a program that you've written, or a custom .dll. SMS Installer comes with a number of samples of those that you can work through and use in your own script and your own environment. SMS Installer is extremely flexible and very extensible, from that point of view.

There are a lot of things that you get out of the box. Using Repackage or Watch gets you in a really good position to get a consistent library of packages you can use to distribute throughout your environment. That's a great support benefit to the customers. That's something we're very exited about, and we're exited about the way customers use this, have used this, and hopefully will continue to use this in their environment to reduce support costs and improve the functionality and the stability of their environment.

SMS Installer also supports multiple languages, and I'm going to talk about that right now (slide 12).

The SMS Installer product itself is released in all SMS Server languages. The way we've worked SMS Installer is you use the English version to create multilanguage scripts. If you want to create a script that installs in German, French, and English, use the English version to do that. If you have the German version of SMS Installer, it will only allow you to do German and English. So if you're building multilanguage scripts, use the English version, when that gets posted to the Web. You can create your own translated text, so that anyone in any of your supported countries can install these scripts and understand what's going on.

If you use double-byte character languages, for example, Japanese, Korean, or Chinese — for Japanese, use the Japanese version of SMS Installer for those languages, and that will allow you to create scripts in Japanese and English. We also have a Chinese Traditional, Chinese Simplified, and Korean version of SMS Installer for those countries. We are able to use it across the world in multiple languages.

To find out which languages are supported, there is a file called Language.ini. When you open that file, which is installed with SMS Installer, you'll see which languages are supported. You're able to create different messages, dialog boxes, and script actions, depending on the language you want to use. So we have a lot of multilanguage support in the product.

What I'm just going to flip across to now is how can you understand the Installer Step-up Utility command line (slide 13). When we first spoke about the Installer Step-up Utility, it was to be a command line, and it was going to be delivered in that form. We felt, as we were working through it, that we have the ability to integrate it into SMS Installer and give you a whole extended set of functionality.

What I've included on this slide is the actual command line for the Installer Step-up Utility. The syntax is isu, then you have to prompt it with a number of keys, and I'm going to talk about that. The {file} is the file you want to migrate, and that's an SMS Installer-created executable file. That file will be, for example, Myinstall.exe, or something you compiled with SMS Installer historically, or a whole range of them, if you want to do batch manipulation.

/j is the switch that we've talked about, and it adds support for the Windows Installer install on demand and repair support.

The /s switch is the batch switch that allows you to migrate the executable files in the current or specified directory and subdirectories. So you're able to move through a number of directories and convert all those executables into Windows Installer packages.

The /xf switch allows you to place the extracted files, because SMS Installer allows you to extract from executables, into a specified directory. The key thing here is to make sure that that directory exists before you try to place extracted files in there.

The /co directory converts. It places the migrated Windows Installer files in the specified directory. Here we see some of the functionality we have in ISU. We can extract the original files from an original SMS Installer executable, or we can convert purely to an .msi.

/e is the switch that would say "just extract the files in the .ipf, and let me manipulate that later."

/c converts the script and the files only; so if you have a script and files, it will run through and convert them.

The /langid switch allows you to set the code page to use during the conversion process, if you're going to do multiple language scripts.

/v gives verbose output for diagnosis and troubleshooting.

/t will tell you whether or not the executable is SMS Installer-generated.

SMS Installer files that are protected with passwords can't be opened, by default, with ISU. You need to specify the password, and the release notes talk about how you use that functionality.

/? displays the command-line help, exactly the same as what we're looking at in this slide, and /help launches the Installer Step-up Utility help file, which goes into detail about which script actions we support, which we don't, how the functionality works, and full usage instructions. I recommend that everybody, when they get this new version, first of all go through the release notes and then read through the ISU help file, to understand the new functionality we've made available in SMS Installer.

So, wrapping up this session (slide 14). SMS Installer is now better than ever. We've worked very hard to make this the most robust, scalable, and stable build of SMS Installer you've ever seen. We've given you the ability to create great Windows Installer and executable files. That's the fantastic thing that we're really proud of, and we're really proud to be able to deliver it to you.

You have the ability to convert and open earlier version SMS Installer .exe files. You can open them through the UI, and that gives you the ability, if you don't have that reference computer anymore, to open those files and find out what they do. That's functionality that's been asked for very much.

We have a really extensive beta program that involves many participants who have provided an excellent amount of feedback. I'd really like to thank the beta participants for working with us on this release. Your feedback has been invaluable, and we've used it to help make this a really powerful, robust, and strong product.

In conclusion, we've done a lot of work here. We've been working for a long time to deliver you the best release of SMS Installer with some great new functionality, and we're really pleased with it. I hope this WebCast has helped introduce that and helps you to understand some of the new things that will be available to you when we ship this product to the Web. That's going to be with you in about a month's time. [Editor's note: The SMS Installer with the Installer Step-up Utility is currently available from http://www.microsoft.com/smsmgmt/.]

We have some more information for you (slide 15). You can go to the Microsoft SMS Web site at http://www.microsoft.com/smsmgmt/, and the Download section is where you'll find the new version of SMS Installer with ISU. For more information on Microsoft Management Strategy, you can go to http://www.microsoft.com/management/.

Thank you very much for listening to my presentation today. I'm now going to hand it over to our host, and we'll work through some questions.

Jason Bennet: Great. Thanks for that presentation, Nick. Just a couple of quick notes before we move on to the Q&A portion of this Support WebCast. To access information on all upcoming Support WebCasts and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of the Support WebCasts. If you do need technical assistance, please submit an incident on the Web (http://support.microsoft.com/directory/onlinesr.asp), or call Microsoft Product Support Services (http://support.microsoft.com/directory/phone.asp) and speak to a Support Professional.

Here's the first question: What other new functionality is included in the new version of SMS Installer, besides the inclusion of ISU?

Nick: Okay. Thanks. There are a number of new pieces of functionality. We basically set our level at delivering the same quality SMS Installer you had with Service Pack 3. We worked hard to improve on that. Our key deliverable here is integrating the ISU and the .msi features.

To find the specifics that we worked on, it's worthwhile, when this is released, to have a look at the ISU release notes, because they will detail all the specifics. At the moment, we're working through to that release phase, to give you the actual details. We're fairly locked down, but they may change; I'd rather point you to the release notes when we ship the product. So when you download the installer, there will be some release notes. You're able to get it from the help file. I suggest you go and have a look at those, and those will detail that functionality in full.

Jason: Okay. Great. Next question: Can you create transforms with the new version?

Nick: Interesting question. The answer to that is, no, you can't. The way we've built SMS Installer with ISU is really to allow you to move to the .msi technology using SMS Installer, and because they are very different technologies, without a very large revamp of the SMS Installer product, the transform support wouldn't be available. So we haven't given you the ability to create transforms, because that's very different than the stuff we provide in SMS Installer. However, you still have SMS Installer functionality to be able to do different installs, based on different parameters you can pass it.

So the answer to that is no, not directly. However, you can open those .msis in existing Windows Installer editing tools that are available from third-party vendors.

Jason: Excellent. Next question: How has the Watch function been improved in detecting the system .dll files to ignore?

Nick: We worked on a number of bugs we had historically on the Watch function, and we've solved a number of those. I know my team has been focusing quite closely on that functionality. So we've worked through that, and that is fully detailed in the release notes.

Jason: Great. I do want to take just a moment here to solicit some feedback from all of our listeners today. We are very interested in your feedback regarding the WebCast program. You can send us your comments and suggestions using the e-mail alias feedback@microsoft.com. If you use that alias, please be sure to include "Support WebCast" in the subject line.

The next question we have is: What language is SMS Installer written in?

Nick: That's something that we by policy don't tend to answer on our products at this stage; however, you can e-mail smswish@microsoft.com and they may be able to help you with questions like that.

Jason: Next question: Are there any training options for SMS Installer?

Nick: There aren't any training options provided directly by Microsoft. However, there are some third-party organizations that do provide training on SMS Installer, and I believe they're called out on the Microsoft SMS Web site, which is http://www.microsoft.com/smsmgmt/. You should be able to find training options there.

Jason: Great. Next question: When using the SMS Installer UI to generate in .msi, does the SMS Installer call the ISU to generate the .msi?

Nick: It calls the ISU code, but we've integrated that into the UI, so we don't shell out to a command prompt. That's fully integrated. So yes, we use the same code, but we're not calling out to that exact application. We're using its function.

Jason: Great. The next question we have: You mentioned that the new version will be available in the next month. What will that version number be?

Nick: We've yet to lock down on the full version number. The last version number we released was 2.00.92. I believe this will be 2.00.147. We're working with our people to lock down that version number, and as soon as that's released to the Web, you should be able to see that.

Jason: Good. The next question: We've experienced many times that the registry settings and/or files, like .dll files in the System32 folder, aren't rolled back or restored during the uninstall phase. And manually putting the registry keys into the script will cause the keys to be completely deleted in a rollback, which is not always desirable. Has this been improved in the Installer release?

Nick: We've done quite a bit of work to document how uninstall works, so you're able to see what the uninstall functionality does. It's very difficult for us to start rolling back files that are in use, and we work to put them in the cache, so the next time you restart your machine, that will be removed.

It depends on the types of uninstall you're using, whether you're doing a manual uninstall or an automated uninstall. And it's all a case of working through your script and performing testing in your environment before you roll that out to users, so you know the behavior you're going to be seeing. With something like SMS Installer, you can do a lot of custom work. So it's very important that you test that in your environment before rolling it out.

Jason: Okay. Good. Next question we have: Does SMS Installer handle command-line flags with more aplomb? I'd like to use /small, but it conflicts with /s for silent, just as an example.

Nick: We haven't improved any command-line flags that are available in SMS Installer, right now, versus the versions you already seen. The best way to do it is to use variables, put those in a file, and when you're running the SMS Installer file, point it to that file so it can read the variables. That gives you the ability to work through those in a far better manner than using a large number of command-line flags.

Jason: Can the new installer import .reg files into the registry?

Nick: The new SMS Installer has no difference in the way it works with the registry. You can of course call out and execute a program and run a reg file after you've installed that, that's something I've done in my own scripts. Or you can manipulate the registry using the tools and functionality in SMS Installer. But as for importing .reg files directly, that's not something we put in. You can make that work, but it's not something that's there as a default script action.

I think we can cover Can we expand the registry window? We haven't improved the registry window in this version of SMS Installer. As I've said before, we've been really focusing on getting the Windows Installer functionality built into this, and not working on a whole lot of user interface changes. So we still are aware of those, and we'll be looking at those for the next release.

Jason: Because the Installer creates an .msi file, will the application package be self-healing?

Nick: It will be self-healing if you are to use the /j switch or use the installation property to set include advertisement support in .msi output. If you included advertisement support, you will be able to use the self-healing type of functionality available through Windows Installer.

Jason: If I want to build new .msi scripts from a capture, should I use SMS Installer or third-party tools? How many third-party tools would there be available?

Nick: There are a large number of third-party tools available to manipulate Windows Installer files right now. The way I see it for customers is it really depends on your tool of choice, what you're trying to achieve, and what you're most comfortable with. If you're very comfortable with Windows Installer technology, you can use a detailed Windows Installer editor. However, if you're more familiar with SMS Installer and the functionality it provides, and you've been using it for along time, you don't have to ramp up as much to use SMS Installer to create .msi files as if you had to move to that technology in one big hit. So we're trying to make the transition simple and easy for you.

Jason: Okay. Great. Next question: How flexible is the Watch function? Can you manage the Watch function so you can tell it when to reinstall?

Nick: The Watch function is a function that allows us to look at an application as you use it and make that into an installation script, so you can install the application on another machine. I'm a little confused about the "Can we tell it when to reinstall" part. I don't quite understand that. However, Watch is really to allow you to create installation scripts from using an application. And that's fully documented in SMS Installer help, which you should have in your version of SMS Installer right now.

Jason: Excellent. Next question: When the SMS Installer generates an .msi, is it calling the ISU?

Nick: I think I already covered that question. The answer is we're calling the code in the ISU.

Jason: Will SMS Installer support functions, so that we can write improved utility code?

Nick: We haven't improved or worked with how the script is put together in SMS Installer. There are functions you can put in, and you can create utility code around that. It all depends on what you want to do. If you're creating very complex utility programs, it's almost worth looking at one of the development environments, like Microsoft Visual Basic^®. However, if you're very familiar with that SMS Installer and want to create basic utility programs in your environment, it's a great tool for that.

So we haven't looked at increasing the language in the installation scripts to any level. That would take a great degree of work, and we really wanted to get out there with the Windows Installer bits in this release.

Jason: Is there any documentation on the built-in uninstaller language?

Nick: The documentation is what we provide in the help file. That's everything we have. There are also some PostScript files, which you are able to print out, and which are available on the Microsoft Web site right now, so have a look in there. That's what we have on that. If you feel that that's lacking, please feel free to go to one of your support representatives and say you'd like this new feature. Alternatively, you can e-mail smswish@microsoft.com. We'll pick that up and look at incorporating that into future versions of their products.

Jason: Great. Next question: Do we need Windows Installer by Veritas?

Nick: No, you don't. Windows Installer is a Microsoft technology, which comes by default with Windows 2000 and later, and it is also available for download from the Microsoft Web site. You need Windows Installer to install Microsoft Windows Installer packages. And Windows Installer is available, as I said, from the Microsoft Web site, or you should have it if you're on Windows 2000 or later. Where to get that is documented in the release notes.

Jason: Okay. Good. Next question: I participated in the beta program. How close is the version the beta testers have to the final version available in a month?

Nick: The version the beta testers have is close. We've done a whole lot more testing, and have made quite a few changes in the code to make it more robust and more resilient. However, from a functionality perspective, the version you've seen in the recent beta refresh is very similar to the version you'll be seeing when we release in a month.

Jason: The next question: Where is the download address for ISU?

Nick: If you go to http://www.microsoft.com/smsmgmt/, the Downloads link is where the Installer Step-up Utility will be with SMS Installer. It's not up there now. We're just finishing some final pieces, and we'll be ready to ship that within a month [Editor's note: The SMS Installer with the Installer Step-up Utility is currently available from http://www.microsoft.com/smsmgmt/], so you'll be able to see that up there. It will all appear on the Downloads list, and you'll be able to download it from there.

Jason: Is it possible to send return codes from SMS Installer back to SMS for error reporting? If so, how is this accomplished?

Nick: It certainly is. Using SMS Installer, you use the Exit Installation script action. The Exit Installation script action allows you to set the exit code.

With Windows Installer, it's slightly different. Windows Installer has its own return code, dependent on how far it's gotten in its installation. What we do provide in SMS Installer is the ability to create MIF files. When you run through the MIF tab in the Installation Expert, if you're creating an SMS Installer file executable, or an .msi file, the .sms or .pdf file will have the command-line syntax, which will generate that status MIF file, which you can then import into an SMS, or SMS will import, and send up the status back up through your hierarchy, so you can see the status of that installation.

Jason: I would like to take just another moment to solicit your feedback. We are very interested in your feedback regarding these WebCasts. If you do have any comments about the WebCast today, a WebCast you've already seen, or future topics you'd like to see discussed, again, you can e-mail us at feedback@microsoft.com. If you use that alias, please be sure to include "Support WebCasts" in the subject line.

Moving on to our next question: Does install on demand work on the Windows NT^® 4.0 platform in Windows 9x?

Nick: Yes, but there are prerequisites. Please see the Windows Installer SDK at http://msdn.microsoft.com/ for more information.

Jason: The next question: We have a requirement to include a lot of conditions in our scripts prior to performing an actual installation, so we often execute the vendor-supplied setup from within the SMS Installer script. Will it be possible to execute an .msi file from within the SMS Installer script?

Nick: Yes, it will. For that you'll use Execute Program. The program you'll execute will be Msiexec.exe, and you'll put the relevant switches in to execute that .msi. You can do that from an executable or a Windows Installer package. So that functionality is available to you.

Jason: The next question: What do you mean by utility-style script? Can you give an example?

Nick: Yes, I can. A utility-style script could be something, for example, where it prompts the user for which building are you in or which floor are you on, and using that data it modifies the registry to set up that default printer connection. That's what we call a utility-style script. It's prompting for information. It's pulling information from the environment variables in the machine, and doing complex registry information and file manipulation. You're not really setting up software; you're manipulating the user's environment. That's a utility-style script.

Jason: Good. ODBC links created in SMS Installer today are not removed when uninstalled. Has this been fixed?

Nick: We've done a lot of work on the ODBC section itself. I'd like to point you to the release notes, so you can see the work we've done on that, and understand where we've gone. As for that specific example, I'm not 100 percent sure, but that will be detailed for you in the release notes.

Jason: Great. Do you have any recommendations on getting clear and meaningful status messages?

Nick: I would like a bit more information on that question, on what you mean by "Clear and meaningful status messages?" Are you after exactly where the installation has failed, at which point, and parsing that up, or are you after a meaningful success or failure? I'm just interested in that.

Jason: Next question: Why has Microsoft chosen not to continue the licensing agreement with Wise Solutions, and how will this change affect the product's future?

Nick: We originally licensed codes from Wise, and we then decided that we would both go in our own directions. The only effect for the product's future direction is that we now have our own code base that we're working against, and Wise has theirs. So being closely linked with Wise, over time, that is something that will go away.

So we still have a close relationship with Wise. They're still one of our very close partners. It's not going to really affect the future, except we're going to be driving this from an SMS point of view, whereas they're driving their product from an installation product point of view, which is a far greater scope.

Jason: Next question: By custom actions, are you referring to the SMS Installer actions, or can developers now create their own actions that can be imported into SMS Installer and used for other scripts?

Nick: The only way we support developers doing that is either by executing an external program or by writing your own custom .dll. You can't import your own action and put them in there, but you can put in your own custom .dll files with part of the scripts. There are a number of samples available with SMS Installer to show you how to do this. So there is a lot of flexibility there, and that's what I meant.

Jason: Next question: Will SMS Installer support return codes from called external .exe files?

Nick: From the SMS Installer help file:

Jason: Next question: Will you be doing a new release with the Topaz product I've been reading about?

Nick: We either will be releasing this version with the Topaz product, or we will be doing another pass on this product. The plans for that aren't finalized at this stage. This version gives us a lot of the functionality we need in that space, so we're very pleased with this one. The plans are not really defined yet, as to whether we'll do another release with Topaz, or another release after Topaz. At this stage, we have a different ship vehicle, which is to the Web, so we have flexibility to either be included or not included with SMS Topaz.

Jason: Okay. The current version doesn't have a script item to check for .exe files in use, one feature that is available on the Wise Installer. Has this ability been added to the new SMS Installer version?

Nick: No. It hasn't. We haven't added that ability into the SMS Installer version.

Jason: Okay. I am seeing a couple of questions in here as to when the next release of the SMS Installer is. Again, that is within a month? Is that correct?

Nick: The current release we've been talking about is coming within a month. Looking at that question, I think that's asking about releases after that version, and currently we're not able to put out any dates for you at this stage. We're focusing really heavily on getting this release out of the door right now. So I can't really give you any pointers to that now.

Jason: Okay. Has there been any added support for additional return codes outside the default ones? This would be helpful for distribution troubleshooting.

Nick: Yes. If you use the Exit Installation script item in an .exe, you can generate any exit code you wish to, and you can generate that into a status MIF. So there is a lot of functionality there to create different return codes, if you wish to. You do that using the Exit Installation script action. And that will help you with distribution troubleshooting. I understand that.

Jason: Great. Can I create brand new and complete .msi packages with SMS Installer?

Nick: You certainly can. You don't ever need to create the legacy executable file, if you don't want to. You can create your script as a Repackage or a Watch, or use the Expert to compile as .msi, and that's a Windows Installer package, just sitting there ready for you. You don't need to go through the step of the executable.

Jason: With the availability of many .msi tools, what is the future of SMS Installer? Where is it going?

Nick: At this stage, the SMS Installer team is focusing on getting this release to you. After that, we're going to be working on futures, and working on what our future direction is for that tool. As soon as we have something there, we'll be posting that to the SMS Web site, so you're aware of our future direction, as we have with SMS and our other products in the past. But at the moment, our team is working very hard on getting this version out to you, because we've been told that that's very important for customers, and that's something we're driving hard for, at the moment.

Jason: Okay. The next question: Based on these questions, it appears that the user community is interested in improving the existing feature set, rather than .msi integration. Is Microsoft going to improve the existing product now that ISU is integrated?

Nick: Excellent question. We're really interested in your user feedback. From our beta program, we've seen that people have been very interested in the ISU functionality, and that's something we're excited about shipping. Now we're getting feedback saying you need to work on existing functionality, as I'm seeing here today. We'll be taking that feedback and working it into our planning process to ensure that we continue to deliver strong products that meet customers' needs. We're extremely driven in the product teams by what the customers require, and we'll be looking to deliver as much of that as we can.

Jason: Okay. Next question: If an .msi file is created using SMS Installer, will it automatically install Windows Installer, if it's not on the computer?

Nick: No, it won't. That only applies to operating systems prior to Windows 2000, and also operating systems that you do not have another Windows Installer package on them. However, it is possible to get those executables to Windows Installer, and make sure they're on the computer, either using SMS software distribution or getting the user to run that first. So it doesn't automatically install Windows Installer. That's something that you'd need to do, if it's not on the computer.

Jason: When using Installer to convert a package to an .msi, if the package had condition statements that looked for specific files, and if they weren't there, it would exit. Does the .msi converted package work the same way?

Nick: The .msi-converted package would work the same way, unless you use the /j or include Advertisements/Repair support. If you're putting that support in, as I said earlier, we change the logic of the script to get the acquisition in at the top and execution at the bottom. However, if you're using the standard nested method, yes, we will exit the script, if required, at that stage.

Jason: Great. Can we use script variables when defining our .exe version information? I'd like to use MyVar in the dialog where we set the .exe version information.

Nick: Yes. These variables can be used as compiler variables at compile time.

Jason: Currently, in the SMS Installer, say it has a step to create a shortcut to a file in a network drive that is not available, such as when SMS is pushing the Installer, the path is chopped to eight characters per directly level. Example: if drive N is mapped to \\server\share and the shortcut points to n:directorylevel\file.exe, it would be changed to director\file.exe. It does not make a valid eight-character name. It chops the end of the path to eight characters. Is this something that's been fixed in the new version?

Nick: I know we have looked and touched that area. I'm not sure if that specific issue has been fixed. If that's something that was put in through Betaplace, it's definitely something we've addressed. If it's not something you've put in through Betaplace or through PSS, we may not have come across or addressed that. We've worked through a large number of issues with SMS Installer, and fixed a whole lot of things, so I'm not 100 percent sure on that one. So please verify if that works for you with the new release, and if not, you need to work with a product support professonal.

Jason: By using the MIF to obtain information regarding the package install, where does this status information appear in SMS? In the Advertise Status logs or somewhere else?

Nick: It will appear in the Status Message System, it will appear to have come from the machine that installs the package, and it will add to the summarizers as well, so you'll be able to see that status information come back up. There are status message queries available in SMS 2.0 that allow you to look and query on those, so you should be able to find it within the status messages.

Jason: Okay. Is it possible to leverage digitally signed packages in a Windows 2000 Group Policy environment to prevent users from installing only packages created by organization?

Nick: I'm interested in the question. Are you trying to prevent users from installing your packages or from anybody else's? Yes. It is possible to digitally sign those packages, and that's something that the Windows Installer SDK will tell you how to do. You digitally sign it after compilation, and that's something you should be able to do with our Windows Installer packages.

Jason: Okay. In response to your earlier answer, are you saying that if the script has any IF/THEN commands it is a utility script, and is unsuitable for use as a Windows Installer file?

Nick: Certainly not. The way I was explaining Windows Installer files is breaking up that acquisition and execution phase. If we have lots of IF/THENS, we will nest the packages, but remember the Windows Installer technology is not designed to do a whole lot of complex balance checking.

A utility script is really defined as a complex script, it is not setting up software, it is something you're using to manipulate your environment. Whereas a setup script is something where you're using it to install software, and you can use that based on IF/THEN. That's fully available to you. All I'm saying is utility scripts are more on the utilitarian side, rather than the setup side. It's a little bit of a gray area, and it's a recommendation, not a script directive.

Jason: Okay. We've not had any success executing .msi files from within an SMS Installer script today. Is that an issue with the SMS Installer version that we're running today, or an issue with the .msi file?

Nick: I'd be tempted to escalate that to Product Support Services at this stage. We've had success in the test lab executing Msiexec from within SMS Installer, so that may be worth going through a product support representative on that issue.

Jason: You can do that by submitting an incident on the Web, or by calling Microsoft Product Support Services and speaking to a support professional.

Next question: Does the new Installer have the ability to set a global On Error Go To?

Nick: No. The new SMS Installer hasn't really changed the script functionality, and I believe that's not available in the current one. I don't believe that will be available in this version. We haven't done a lot really to manipulate the script functionality that you already have today.

Jason: Okay. Next question: Will the installation of the extraction installer still be required to run from an SMS server?

Nick: When you download the product from the Web, because you're only a licensed user if you're an SMS customer, to extract that file, you need to perform that on an SMS site server. Remember, that's not making any system modifications. It's just dumping out some files to a directory. That's how we ensure SMS customers are using it.

After you've done that, you can then put SMS Installer from there on to a network share, or on to machines in your own environment, so you can then use it from there. But we need to make sure that customers who are downloading SMS Installer are SMS customers, because this is licensed for SMS customers, and SMS customers who bought that product.

Jason: Okay. Great. Can you repackage two applications that needed a reboot separately with this new version?

Nick: Reboots are a fairly difficult world, with all Installer products. Are you talking about repackaging two applications that need reboots separately? It's interesting to know why and how and where. If you want to discuss this in more depth, I'm probably going to point you to product support.

The thing there is testing and finding out how it works. Software will do reboots for a number of reasons. Some of those reasons are because they think they ought to do a reboot, some of them are because there are files in use. That's fairly difficult to capture with SMS Installer. So that's probably something that you need to work through with a support representative, or something you'd need to test in your lab.

Jason: Okay. What effect does this release have on Active Directory^®?

Nick: It has absolutely no effect at all. You can use those .msi files and distribute them using Group Policy, but we don't touch Active Directory (AD) at all with this release. So there is no effect on AD, and AD doesn't really have any effect on us.

Jason: Currently there are many items that are captured during a repackage, such as user ID registry entries. How are these entries handled if you repackage directly to .msi?

Nick: When you repackage with SMS Installer, you still repackage to a script, then you can compile that script to .msi. As I said earlier in the presentation, it's well worth going and looking at that script to ensure that things like SID entries or registry entries you don't want to be changed on the destination computer are removed from your script. That's really the human intelligence that needs to be applied to repackaging operations. So what you need to do there is make sure that those entries are changed and sorted and that you're not affecting anything like SID values, most recently used lists, et cetera.

Jason: Okay, next question: When will Installer include support for querying WMI information?

Nick: That's an interesting question. I know that's something we've kind of touched on, looking at it in planning phases. We have no concrete plans, as I said, for future versions of Installer right now. We're just getting this out the door, and then we'll be looking at what we're doing in the future. So understand that is a need, and we're taking it on board. It's worthwhile sending your needs and requests like that to smswish@microsoft.com.

Jason: Okay, next question: Which actions does ISU support?

Nick: That's available to you in the help file. Rather than reading the help file myself, we'll probably have to respond to that directly, offline.

Jason: Okay. Can you use the local drive on the site server option on a remote computer?

Nick: That's an SMS question, I believe, rather than SMS Installer question. I'd really like it if the person asking the question could just elaborate a little bit on that question, if you can. You're asking when you're creating the package and the program, and you're saying package source, can I use the local drive on Site server on the remote computer? I think that's detailed in quite some depth in the Systems Management Server Administrators Guide, if you want to refer to that. That should talk about that feature and how that works.

Jason: How do I use the new .msi files with SMS?

Nick: When you create the new .msi files, it will create a .pdf or an .sms file. It's exactly the same as this importing a .pdf or .sms file for an executable. It will give you a command line to allow that to run. You set it up as a package, normally, set up the programs that you'll be creating from that .pdf file. Make sure that you're pointing at the source, and then advertise it as you normally would. There is no real difference in functionality there from when you're using executable files. We just have a slightly different command line.

Jason: The next one is a comment. Thank you so much for adding the Free Disk Space item to the Get System Information script item. How soon can we get an Amount of RAM or Speed of Processor?

Nick: We have Kilobytes Available Memory. We don't have any information on the processor. You could extend that by working through some scripting and pulling that into a variable. I know that's a little bit more complex, but again, e-mail smswish@microsoft.com with your requests, and we'll look at putting that in future releases.

Jason: Okay. Great. That does clear the queue all of the questions for today, so that's going to wrap up our session. I want to thank all of you for joining us, and I hope the information was useful to you.

We're very interested in your feedback regarding the WebCast program. You can send us your comments and suggestions using the e-mail alias feedback@microsoft.com. If you use that alias, please be sure to include "Support WebCasts" in the subject line.

We hope you join us again in the near future. Thanks, and good-bye.