3 scenario's where we use transforms and Different kinds of customisations used in transforms?

Ans: Primary uses for transforms include: Customization of base installation packages for particular groups of users. Transforms can be used to encapsulate the various customizations of a single base package that are required by different groups of users. For example, this is useful in organizations where the finance and staff support departments require different installations of a particular product. A product's base package can be available to everyone at one administrative installation point with appropriate customizations distributed to each group of users separately. Synchronization of applications across languages. Transforms are useful for keeping packages authored at widely separated locations synchronized during authoring. For example, if an upgrade is first developed for an English version of an application that exists in English and French, a transform can be applied to the upgraded English version that converts it into an upgraded French version. Multiple transforms can be applied to a base package and then applied on-the-fly during installation. This extends the capabilities of the installer to create custom packages and provides a mechanism for efficiently assigning the most appropriate installations to different groups of users. Patching applications. Transforms can be used to apply a minor fix to an application that does not warrant a major upgrade. For more information about patches, see Patch Packages. The following are the most common application customizations that you can generate using transforms. You can:  Specify the features to be installed.  Define the level of user intervention permitted during an installation. This works in combination with the command-line options you set.  Specify the answers to be provided to the Setup UI during the installation.  Specify a location to install the files.  Specify the placement of shortcuts.  Add files to the installation.  Specify the registry settings to be added or changed during the installation. What are Merge Modules? Ans: Merge modules are a feature of Windows Installer that provide a standard method for delivering components, insuring that the correct version of a component is installed. A merge module contains a component, such as a .dll, along with any related files, resources, registry entries, and setup logic. Merge modules are essentially simplified .msi files, which is the file name extension for a Windows Installer installation package. A standard merge module has an .msm file name extension.

A merge module cannot be installed alone because it lacks some vital database tables that are present in an installation database. Merge modules also contain additional tables that are unique to themselves. To install the information delivered by a merge module with an application, the module must first be merged into the application's .msi file. Which are the tables updated when we write custom actions? Ans: Following Tables are updated when we write any custom action: 1. CustomAction 2. nstallExecuteSequence 3. InstallUISequence 4. AdvtExecuteSequence 5. AdvtUISequence 6. AdminExecuteSequence 7. AdminUISequence Advantages and disadvantages of advertised shortcuts and unadvertised shortcuts? How to advertise any package? Ans: a) To advertise a package using the command line 1. Open Command Prompt. Type: msiexec /j{u | m} package Value 2. Description Advertises a product. This command-line option ignores any property /j values entered on the command line. u Advertises to the current user. m Advertises to all users of this computer. package Specifies the name of the Windows Installer package file.

b) ADVERTISE Property The value of the ADVERTISE property is a list of features delimited by commas that are to be advertised. The features must be present in the Feature column of the Feature table. To install all features as advertised, use ADVERTISE=ALL on the command line. Do not enter ADVERTISE=ALL into the Property table because this generates an advertised the package that cannot be installed or removed.

6. how to apply pathces and upgrades? 7. Packaging process in brief?

8. Microsoft best practices for components? Ans: these rules are: a) Each component must be stored in a single folder. b) No file, registry entry, shortcut, or other resources should ever be shipped as a member of more than one component. This applies across products, product versions, and companies. General Rules to have a components in an application:  Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies.  Note that the previous rule means that no two components can ever have the same key path file. The key path value points to a particular file or folder belonging to the component which the installer uses to detect the component. If two components had the same key path file, the installer would be unable to distinguish which component is installed. Two components however may share a key path folder.  Never create a version of a component that is not compatible with all previous versions of the component. This rule should be applied across applications, products, product versions, and companies.  Don't create components that contain resources which will need to be installed into more than one directory on the user's system. The installer installs all the resources in a component into the same directory. It is not possible to install some resources into subdirectories.  Don't include more than one COM server per component. If a component contains a COM server, this must be the key path for the component.  Don't specify more than one file per component as a target for a Start menu or desktop shortcut.

9. Advantages and Disadvantages of applying different kind of patches? Ans: The Four Upgrade Methods Decide on your method before you begin working on the upgrade; it could save you a lot of time. Here are summaries of the four methods I've listed, as well as some points to consider in the decision-making process. MSP Patch File The idea of a patch file for an installed MSI is great-however, until Windows Installer 3.0 is a reality, I personally don't think MSP patches live up to the

expectation. Advantage: creates a very small MSP file which includes only the changes required to update the MSI, which might be good for Internet downloads. Disadvantages: with anything before MSI 3.0 you need to do a complete reinstall of the application in order to install the patch file, which can be a huge waste of time for small patches on large installations; also, MSPs aren't so great for adding new features, components, and such-better save that for MSI upgrades. Reinstall-in-Place MSI Upgrade If you only need to make a minor fix but the MSI has already been installed on some of the client systems, you can simply make the changes in the original MSI and do a re-install on the target workstations using the command line "msiexec /fvomus updated.msi" (the '/f' for the reinstall, 'omus' for the usual reinstall options, and the 'v' to re-cache the MSI from the new source). However, note that (a) this is not a good way to add files, features, etc. and (b) the reinstall and recache can be buggy (but no one knows why). Uninstall-First MSI Upgrade Possibly the simplest to create, in this method you simply create a full MSI with the new version and add a custom action early in the sequence to uninstall the old version if it exists on the target machine. Sounds easy, right? There are disadvantages: (a) end-users are likely to lose their custom settings when the uninstall cleans up, and (b) this won't work for uninstalls that require a reboot, or leave around in-use files that will need to be installed with the new version. Then again, if both your original and your updated package were made from a SetupCapture, this may be your best option. Typical MSI Upgrade For developers who have prepared both the original/old MSI and the new/upgrade MSI with the same components, features, etc., this is the perfect and sensible solution. Wise Package Studio (or InstallShield AdminStudio) can help you make an intelligent package which can upgrade in place any existing features and components. When some of the components haven't changed at all, then they will remain just as they are; for those components which have new files, they will be upgraded in place; and of course new features and their associated components will be installed as assumed. The problem for repackagers is that for the upgrade-in-place to work correctly, the Component IDs and such have to line up exactly-you can't have two different components install two different versions of the file in the same place, or the selfhealing will go nuts. WPS tries to help you out in this regard with the UpgradeSync tool, which can do a lot to automatically align the Component IDs and such; however, it will still leave you with a list of things which need to be fixed by hand, and this process will involve some thought, investigation and work. But if you make a clean upgrade package, it may be worth it. In the documents to follow I'll attempt to outline the process to create an upgrade package using the above listed methods.

10) how does ICE validation works in backend? Most Windows Installer authoring tools use internal consistency evaluators (ICEs) to perform package validation. ICEs are custom actions written in Microsoft Visual Basic Scripting Edition (VBScript), Microsoft JScript®, or as a .dll or .exe file. When you run an ICE, it scans the package's database to identify entries that are valid individually but which might cause incorrect behavior in the context of the entire database. ICE custom actions return four kinds of messages: • Informational. Provides information from the ICE and does not indicate a problem with the database. Often, the information is about the ICE itself, such as a brief description. These messages can also provide progress information while the ICE runs. • Warnings. Reports database authoring that causes incorrect behavior in certain cases. Warnings can also report unexpected side effects of database authoring (for example, entering two separate conditions of the same property name spelled the same but with an uppercase/lowercase difference—such as High and high). Because Windows Installer is case-sensitive, it treats these as two different properties. • Errors. Reports database authoring that causes incorrect behavior. For example, duplicate component GUIDs cause Windows Installer to incorrectly register components. • Failures. Reports the failure of the ICE custom action. Failure is commonly caused by a database with such severe problems that the ICE cannot run. 11) What are configurable Merge Modules? Ans: Configurable Merge Modules Merge modules (.msm files) may be authored to contain attributes that are configurable by the consumer of the merge module. This enables the merge module to be configured at the time the installation package and module are merged and installed by the end user. Configurable merge modules require version 2.0 of Mergemod.dll but can run on any version of the Windows Installer. The implementation of configurable merge modules consists of two parts. First, when creating the merge module (.msm file), the merge module author adds information to the module database that specifies which items can be modified and how these items can be configured by the module user. The author adds entries to the Merge Module Database Tables that are reserved for configurable information (ModuleConfiguration table and ModuleSubstitution table), updates the _Validation table, and adds entries for the configurable merge module tables to the ModuleIgnoreTable table. The additions to the ModuleIgnore table are required to make the module compatible with Mergemod.dll versions earlier than 2.0. Second, when merging the module into an installation package (.msi file), the end user of the module uses a merge tool. The merge tool calls Mergemod.dll to expose the configuration information in the module to a client configuration tool. The configuration tool may interact with the end user but is not required to expose all possible configuration options. If the user declines to provide a

selection for a configurable item, the module may provide a default value. After the user gives the configuration tool his selections, the merge tool calls Mergemod.dll to perform the merge. Configurable merge modules are fully compatible with tools earlier than Mergemod.dll version 2.0. In these cases, the tool uses the default values in the module. 3 scenario's why we use merge modules? Ans: a) Ensures that the component is installed consistently for all applications and eliminating problems such as version conflicts, missing registry entries, and improperly installed files. b) Merge modules are used to deliver shared code, files, resources, registry entries, and setup logic to applications as a single compound file c) Contains unique version information - Prevents premature removal of a component. How to create Configurable Merge Modules? Ans: Creating a Merge Module that Can Be Configured by the End User  To create merge modules, use the general guidelines that are described in the Authoring Merge Modules topic. In addition, you must do the following to create a merge module that may be configured by the end user of the module:  End users need to have Mergemod.dll version 2.0 to configure your module. Users who have earlier versions of Mergemod.dll can apply the module, but they always get the default settings.  Add a ModuleConfiguration Table to the merge module to identify the items that may be configured by an end user. Add a record in this table for each configurable item. These items are substituted into the templates that are specified in the ModuleSubstitution Table. Enter a name for each configurable item into the Name field. Enter the format, type, and semantic context for each item in the Format, Type, and ContextData columns. For more information, see Semantic Types. Enter a default value for the item in the DefaultValue field using the CMSM Special Format.  Add a ModuleSubstitution Table to the merge module. Each record in this table corresponds to a substitution of one or more configurable items into one field of the merge module database. Enter the table, row, and column of the field that receives the substitution. Enter a formatting template for the substitution into the Value column using the CMSM Special Format.  Add records to the Validation Table for the ModuleSubstitution and ModuleConfiguration tables.  Add records to the ModuleIgnoreTable Table for the ModuleSubstitution Table and the ModuleConfiguration Table. This ensures that the module is compatible for users who have versions of Mergemod.dll that are earlier than version 2.0.

14) How do I include patch specific custom actions? A: You can add custom actions using a patch. All that is required is that the new custom action be included in your update package from which you generate the patch. Whether or not the custom action executes depends upon the condition on the custom action. How can we control the msi entry in control panel? Ans: MSI Entry appearance in control panel can be controlled using following properties: ARPNOMODIFY ARPNOREMOVE ARPNOREPAIR NEW Features of Windows Installer v3.0? Ans: New features in Windows Installer 3.0 1] Patch sequencing With patch sequencing, a set of new or existing patches are deployed in the correct logical order, regardless of the chronological order that the patches were received in on the computer. 2] Removable patches You can now remove patches that are installed with Windows Installer 3.0 if they are marked as removable in the patch package. Patch removal enables the patched program to be returned to the state that the program was in before the patch was applied. 3] More efficient patching Several improvements have been made to patching in this release. These improvements include the following:  You can double-click a patch file to apply it.  Patches are smaller and more reliable.  Delta compression patches no longer require the source media.  You can install multiple patches in one transaction.  You can install patches that are targeted to different products in a single transaction.  Non-administrator patches and patch elevation 4] User with Limited accounts can now apply patches that have been marked as trusted by the system administrator.

5] Source list APIs and inventory management APIs With new source list APIs, system administrators can easily examine and change the list of source locations that are registered with the Windows Installer. Windows Installer 3.0 also supports rich product, feature, component, and patch inventory queries through new inventory management APIs. Users with privileged accounts can use these APIs to enumerate across all user and installation contexts. 6] Standard command-line options To ease program deployment, the Windows Installer supports standard, easy-tounderstand command-line options that control display and restart behavior, and the installation, removal, logging, and application of updates. Windows Installer 2.0 command-line options will continue to be supported and can be used with new command-line options. The following new command-line options are supported:           /help/quiet/passive/norestart/forcerestart/promptrestart/uninstall/log/package/update-

7]Windows Installer 3.0 also supports the msiexec /? option. You can use this option to display all the command-line parameters that are available in Windows Installer 3.0. 8] Better assembly servicing Support for binary delta patching and new assembly authoring and servicing guidelines improve assembly servicing. 9] Improved interface for Add or Remove Programs in the Windows XP Control Panel 10] The Add or Remove Programs feature in Control Panel now lets users view and interact with the installed updates to programs. With Windows XP SP2, users can select a single check box to view program updates and their relationship to a program. Updates are now grouped with a relevant program and include an installation date.

Issues with Windows Installer 3.0? Ans: Issues that are addressed in Windows Installer 3.0  Windows Installer did not use a correct token after the LogonUser function had been called.  Failure occurred when a custom action called an API that queried for a string that was larger than 256 characters.  “The Windows Installer Service could not be accessed" error was displayed when MSIServer class registration was missing on the server.  The MsiOpenProduct function failed when the product's registration was corrupted.  Setup failed if you closed a browsing window by double-clicking the program icon after you opened the program icon menu.  The ServiceInstall table did not install services correctly if the path contained a space.  The MsiGetComponentPath function sometimes failed unexpectedly.  When you canceled program installation during the installer engine initialization, the action was ignored and returned an unexpected error.  When you tried to remove a program, an incorrect program name was displayed as the running program.  An MsiAssemblyName table that was not written correctly could prevent the removal of global assemblies on your computer.  Windows Installer rolled back an installation when commit custom actions failed, but ultimately reported that the installation was a success instead of a failure.  The Windows Installer did not let the external user interface filter for files in use messages. Windows Installer 3.0 now adds the INSTALLLOGMODE_FILESINUSE = (1 << (INSTALLMESSAGE_FILESINUSE >> 24)) parameter to public headers.  The DependantService registry value was truncated.  Windows Installer provided insufficient logging information when the BindImage API failed.  Windows Installer did not declare the INSTALLMODE_NODETECTION_ANY parameter in the public header for the MsiProvideAssembly function.  COM activation failed if a component was run from a source and if source validation failed.  An actionable pointer was displayed as an hourglass and did not change.  A service did not shut down after it failed.  If an administrator or local system was denied access to a file, the Windows Installer could not delete the file.  The ServiceInstall table did not respect the msidbServiceInstallErrorControlVital bit if modal dialogs were disabled by the /qb- or /qn switches.  The OpenPackage method ignored the Safe Session flag.

       

 

The msiUILevelSourceResOnly installation table definition was missing from the typelib definition for the Windows Installer Automation interface. Versioned files could not be installed if companion files were specified with run-from-source components. The error dialog box that is used by the Customer Information dialog box used the wrong pointer. When you pressed the spacebar or the ENTER key, you enabled a hidden Cancel button. Windows Installer did not let non-administrators generate advertisement scripts when DisableMSI=1. Security errors displayed only the OK button when you were prompted to click Retry or Cancel. Environment variables were lost when you removed programs. The Windows Installer API that provides component paths returned incorrect paths if the component was installed with a run-from-source component and if the media disk ID for the component was more than 99. Windows Installer could not remove files with read-only permissions for the administrator and system accounts. The FilesInUse dialog box may have displayed incorrect window titles if the window titles contained [propertyname] references.

New Features of Windows Installer 3.1? Ans: New features in Windows Installer 3.1 New minor UpdateTargetRTMProperty property: Patch files can now target both • the original release baseline and the latest service-pack-level baseline that is on the system. New MsiSetExternalUIRecord API: Packages that use an external user interface can • now receive messages as records instead of receiving the messages as strings. New x64 and Msix64 properties: Packages can now use the x64 and Msix64 • properties to indicate x64 processor-based operating system support. New MsiNotifySidChange API: You can use this API to upgrade the Windows • Installer configuration if the security identifier (SID) of a user changes. Flyweight patching is now an opt-in behavior: Windows Installer 3.0 introduced new "flyweight patching" functionality. By default, this functionality was enabled for all • patches. Windows Installer 3.1 now disables this functionality unless you specifically enable the functionality by setting the OptimizedInstallMode property in the MsiPatchMetaData table.

Issues with Windows Installer 3.1? Ans: Issues that are addressed in Windows Installer 3.1 Windows Installer now logs null characters ("[~]") correctly when the characters are used in a registry value marker or in a service dependency. The MsiGetFileHash function now works correctly for very large unversioned files. • These files may be about 2 GB. The MediaSrcProp property of a patch is now set to the original launched-from • location when the patch is installed. The MediaSrcProp property is set to the cached patch location for subsequent transactions. • Progress bar now works correctly even if the package installs more than 2GB of files. • Patching of isolated components now works. Target information for a custom action is no longer logged when the custom action • fails if the custom action is marked to hide the target. Error 1642 (ERROR_PATCH_TARGET_NOT_FOUND) is returned even if only one • Windows Installer 2.0-style inapplicable patch is being applied. Applying a full-file Windows Installer 2.0-style patch that contains companion files no • longer requires access to the source media. Windows Installer 3.1 now correctly handles the scenario where a minor update • package is installed when an obsolete or superseded patch also exists. Windows Installer 3.1 now supports application of patches for packages that have • large numbers of files. (Sequence column of File table includes values larger than 32767.) Windows Installer 3.1 now sends INSTALLSTART_ACTIONSTART messages for all • actions. In Windows Installer 3.0 and earlier versions, if you applied several major upgrade • patches, subsequent installations occasionally failed. This issue is now fixed. The patch sequencer no longer incorrectly rejects a valid patch during administrative • image patching. Windows Installer 3.1 no longer skips script custom actions that are marked as • asynchronous. • Different ways of registering a dll through msi? Different ways of installing services through msi? Ans: 1)Through Service table 2) Though registries. How many types of Properties are there and what are they? Ans: Private properties: The installer uses private properties internally and their values must be authored into the installation database or set to values determined by the operating environment.

Public properties: Public properties can be authored into the database and changed by a user or system administrator on the command line, by applying a transform, or by interacting with an authored user interface. Restricted public properties: For security purposes, the author of an installation package can restrict the public properties a user can change. Which are required Properties for any basic installation? Ans: ProductCode ProductLanguage Manufacturer ProductVersion ProductName 24) Order of Property Precedence The installer sets properties using the following order of precedence. A property value in this list can override a value that comes after it and be overridden by a value coming before it in the list. Properties specified by the operating environment. Public properties set on the command line. Public properties listed by the AdminProperties propertyset during an administrative installation . Public or private properties set during the application of a transform. Public or private property that set by authoring the Property table of the .msi file. Latest Windows Installer Version? Ans: Windows Installer version 4.0 Windows Installer 4.0 is available for Windows Server "Longhorn" and Windows Vista. For a complete list of all Windows Installer versions and redistributables, see Released Versions of Windows Installer. This page is provided as a guide to the documentation. You should refer to the Requirements section on the main reference pages to determine the actual operating system requirements. Parts of the Windows Installer that are not linked to from this page may be available in another version of the Windows Installer. Properties MsiLogging Property : The MsiLogging property sets the default logging mode for the Windows Installer package. If this optional property is present in the Property table, the installer generates a log file named MSI*.LOG. The full path to the log file is given by the value of the MsiLogFileLocation property. MsiLogFileLocation Property : The value of the MsiLogFileLocation property is set to the full path of the log file, when logging is enabled. The MsiLogFileLocation property can be used to display the log file, or location of the log file, in a user interface at the end of the installation. Summary Information Properties Word Count Summary Property has new flag bits to specify whether the installation of the package requires elevated privileges. System Policy

DisableLoggingFromPackage : The value of this per-machine system policy is set to "1" to disable the logging that is specified for the package by the MsiLogging property for all users of the computer. Registry Key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer Data Type REG_DWORD Database Tables Shortcut Table New columns: DisplayResourceDLL, DisplayResourceId, DescriptionResourceDLL, and DescriptionResourceId Windows Installer on 64-bit Operating Systems msidbComponentAttributesDisableRegistryReflection attribute in Component Table Where does Product code of an msi goes into registry HIVES? Ans: HKEY_CLASSES_ROOT\Installer\Products And HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products What is the deference between Package code and Product code? Ans: Product Code: The product code is a GUID that is the principal identification of an application or product. If significant changes are made to a product then the product code should also be changed to reflect this. It is not however a requirement that the product code be changed if the changes to the product are relatively minor. Package Code: The package code is a GUID identifying a particular Windows® Installer package. The package code associates an .msi file with an application or product and can also be used for the verification of sources. The product and package codes are not interchangeable. No two nonidentical .msi files should ever have the same package code. Although it is common to ship an application that has the same package code and product code, the two values can diverge as the application is updated. How many types of transforms are there and what are they? Ans: The four types of Windows Installer transforms are embedded, unembedded, secured, and unsecured. Embedded transforms. Embedded transforms are stored inside the .msi file of the package. This guarantees to users that the transform is always available when the installation package is available. If the installation source is read-only, such as a CD or a network share to which the person creating the transform has read-only access, this is not an option because you must be able to write to the source to embed the transform in the *.msi file. To add an embedded transform to the transforms list, add a colon (:) prefix to the file name. Embedded transforms are not cached separately on the client computer, because Windows

Installer can always obtain the transform from the .msi file. .Embedded transforms might be used in combination with secured or unsecured transforms. Unembedded transforms. Unembedded transforms are stored separate from the .msi file of the original package. Unembedded transforms are cached separately on the client computer. You can use unembedded transforms in combination with secured or unsecured transforms. Secured transforms. Secured transforms are recommended for security reasons. If an application is installed at an elevated level, either per-user or percomputer, a user with low rights can modify an unsecured transform and use it to make changes to the computers that have elevated privileges. Secured transforms are stored locally on the client computer in a location where, on a secure file system such as NTFS, the user does not have write access. Such transforms are cached in this location during the installation or advertisement of the package. During subsequent installation-on-demand or maintenance installations of the package, Windows Installer uses the cached transforms. To specify secured transform storage, set the TransformsSecure policy, or set the TRANSFORMSSECURE property, or pass the @ or | symbol in the transforms list. You cannot combine unsecured transforms and secured transforms in the same TRANSFORMS list. Unsecured transforms Unsecured transforms have not been secured as described in Secured Transforms in the preceding list. When a package is installed or advertised as a per-user installation, and the package has unsecured transforms, Windows Installer saves the unsecured transforms in the Application Data folder in the user's profile. This enables a user to maintain a customization of a product while roaming from computer to computer. When the package is installed or advertised as a per-computer installation, and the package uses unsecured transforms, Windows Installer saves the unsecured transforms in the %windir%\Installer folder. If the cached copy of the transform becomes unavailable, Windows Installer can restore the transform cache using a source listed in the SOURCELIST property. Windows Installer uses the same method to search for a transform source as it uses to search for an .msi file. To apply unsecured transforms when installing a package, pass the transform file names in the TRANSFORMS property or in the command-line string, and do not begin the string with the @ or | characters. Do not set the TransformsSecure policy or the TRANSFORMSSECURE property. Different methods of applying transforms? Ans: Applying a Transform to an .msi File You can apply a transform to an .msi file by one of two methods: dynamic and static. Dynamic method. Place the transform on the same share as the .msi file, and configure installation options to reference that transform. You can use this method where multiple sets of customizations exist for users in an organization

and where the application vendor might need to update or patch the original .msi file. Keeping the customizations separate from the original package helps to isolate them from changes to the original .msi. Static method. Run the transform against an administrative image of an application to permanently change the .msi of the administrative image. The customizations the transform initiates are persistent until the administrative image is deleted and recreated. Because of this, applying a transform by this method is does less often. Command Line Switches supported by Windows Installer: Ans: What command line switches are supported? /i [package] Installs the specified product /f p,o,e,d,c,a,u,m,s,v p - Reinstalls a product only when a file is missing o - Reinstalls a product when a file is missing or an older version of a file is installed e - Reinstalls a product when a file is missing or an equal or older version of a file is installed d - Reinstalls a product when a file is missing or a different version of a file is installed c - Reinstalls a product when a file is missing or the stored checksum value doesn''t match the calculated value a - Forces all files to be reinstalled u - Rewrites all required user-specific registry entries m - Rewrites all required computer-specific registry entries s - Overwrites all existing shortcuts v - Runs from the source file and re-caches the local product /a [package] Installs a product on the network /x [package] Uninstalls a product /j u,m [package] Advertises a product. u is current user; m is all users

/l i,w,e,a,r,u,c,m,p,v,+,![log file] i - Status messages w - Non-fatal warnings e - All error messages a - Action startups r - Action-specific records u - User requests c - Initial User Interface (UI) parameters m - Out-of-memory p - Terminal properties v - Verbose output + - Appends to the existing file ! - Clears each line in the log file * - Wildcard. Logs all information, but the use of the v option isn''t included. To include the v option, type "/l*v" /p [patch] Applies a patch. To patch an installed Administrator image, you should also use the /a switch /q n,n+,b,b+,b!,r,f n = No UI n+ = No UI except modal dialog at end b = Basic UI b! = Basic UI w/no Cancel button b+ = Basic UI w/modal dialog box at end b- = Basic UI w/no modal dialog box at end r = Reduced UI f = Full UI /y Calls system API DLLRegisterServer to register the module /z Calls system API DLLRegisterServer to un-register a module 30) What does the 1603 error mean? Ans: Error: 1: Event 'E3250601' is created 1: GetInstallDriver, Can not find InstallDriver in ROT table, Return code = 0x800401e3

1: [GUID] 1: ISMsiServerStartup Failure, Failed to create InstallDriver, Error = 0x8000401a Action ended ISMsiServerStartup. Return Value 1603 This error is a pain, because you see little to no detail in the event log. This error is telling you that the local system (or current account) does not have access to launch DCOM. Particularly if you are using Group Policy to deploy the MSI, this appears because it is the local system account that initiates action before any user is logged on. In doing so, Windows Installer launches the InstallScript DCOM engine as user "interactive user" and generates this failure. To resolve this problem you may use C:\WINDOWS\system32\DCOMCNFG.EXE to change the launch identity of "InstallShield InstallDriver" and "InstallShield InstallDriver String Table" to "Launching user". 31) How can I correct problems with Windows Installer itself? When registration of the engine is corrupted, all attempts to run .msi packages fail. To correct the registration of the Windows Installer, unregister and then register the Installer service using the command line switches shown below. This shuts down and reregisters the service, which assures that the Windows Installer engine should function properly. Enter the following commands from a command prompt: msiexec /unregister msiexec /regserver If this fails to resolve your problem try performing the following steps: 1) Unregister Windows Installer: msiexec /unregister 2) Rename the following files from the command prompt: Msi.dll, Msiexec.exe, and Msihnd.dll (by changing the names to msi.dll.bak, msiexec.exe.bak and msind.dll.bak respectively.) 3) Restart Windows. 4) Install the Windows Installer service again (InstMSI.exe). Don't have this? Check here. Note: when attempting to delete/rename the MSI files Windows File Protection may keep you from being able to do so. One visitor suggests starting Windows

in safe mode with a command prompt to deal to the 3 msi files. 32) How to Deploy Patch? Ans:? msiexec /p [path\name of update MSP file]/a [path\name of MSI file] SHORTFILENAMES=TRUE /qb /L* [path\name of log file] If an update contains multiple MSP files, you will need to run the command line separately for each MSP file that you apply to the administrative installation point — you cannot reference multiple MSP files on the same command line. The command-line options are described below: Msiexec Executable file name for Windows Installer. /p Enables Windows Installer to apply an update to an existing installation. [path\name of update MSP file] Path and file name of the MSP file for the update. /a Enables Windows Installer to perform an administrative installation of a product on a network share. [path\name of MSI file] Path and file name of the Windows Installer package for your original administrative image. SHORTFILENAMES=TRUE Directs Windows Installer to create all file names and folders with MS-DOS– compatible file names. Required when you run Windows Installer from the command line. /qb Sets the user interface to the basic level (simple progress and error handling). /L* Turns on logging and sets a path for the log file. The * flag causes the switch to log all information. [path\name of log file] Path and file name of the Windows Installer log file. 33) How Do I Apply Transforms When Using Group Policy? When adding your software package, choose the deployment method, "Advanced published or assigned." Only when you choose this method will you see the "Modifications" tab where you may specify multiple MST. Transforms are applied in order, from the top to the bottom of the list- where a conflicting value is encountered the later take presedence, overwriting earlier ones. Don't press "OK" until you have everything the way you want it! As soon as you say "OK" the object is published and may start immediate deployment.

34)

How Do I Control Windows File Protection (WFP)? You never want to include files protected by the Windows File Protection (WPF) feature of Windows 2000 and later in your packages. Below is some configuration notes on controlling WFP from the registry: All registry settings for WFP/System File Checker are located in HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon. By default, only Administrators and System will be able to modify these settings. SFCDisable (REG_DWORD) 0 = enabled (default). 1 = disabled, prompt at boot to re-enable (debugger required). 2 = disabled at next boot only, no prompt to re-enable (debugger required). SFCScan (REG_DWORD) 0 = do not scan protected files at boot (default). 1 = scan protected files at every boot. 2 = scan protected files once. SFCQuota (REG_DWORD) n = size (in megabytes) of dllcache quota. FFFFFFFF = cache-protected system files on the local hard drive. SFCShowProgress (REG_DWORD) 0 = System File Checker progress meter is not displayed. 1 = System File Checker progress meter is displayed (default). SFCDllCacheDir (REG_EXPAND_SZ) Path = local location of dllcache directory (default is %Systemroot %\system32\dllcache). 35) What should be left out when repackaging? Ans: Windows File Protection manages certain system files due to integration with the operating system. Including these files (or other important system files) in an installation package can cause damage or unpredictable behavior on destination computers. Resolution Exclude the files listed below from any installation package. Only Windows service packs and other Microsoft-produced installations should modify, replace, remove or move these files. Including any of the files listed below can cause an installation to produce unexpected and undesirable results. Win16 .DLL files: COMMDLG.DLL, DDEML.DLL, GDI.DLL, KERNEL.DLL, KEYBOARD.DLL, LZEXPAND.DLL, SHELL.DLL, TOOLHELP.DLL, USER.DLL, VER.DLL, WIN87EM.DLL

Win32 .DLL files: ADVAPI32.DLL, COMCTL32.DLL, COMDLG32.DLL, DSKAPI32.DLL, GDI32.DLL, ICM32.DLL, IMM32.DLL, KERNEL32.DLL, LINKINFO.DLL, LZ32.DLL, MSIDLE.DLL, NTDLL.DLL, OLE32.DLL, RICHED32.DLL, SAGE.DLL, SCRRUN.DLL, SHDOCVW.DLL, SHELL32.DLL, SHFOLDER.DLL, SHLWAPI.DLL, URL.DLL, USER32.DLL, VERSION.DLL, WININET.DLL, WINMM.DLL, WINSPOOL.DRV, WSOCK.DLL, WSOCK32.DLL In addition, exclude the WININIT.INI file from any installation. The WISE.ini file already lists these files (with the exception of SCRRUN.DLL) for exclusion from any installation. You can add other files to this list, always ending with a comma, and thus delimiting them. Additionally, the following files might cause problems: ATL.DLL, COMCAT.DLL, CTL3D32.DLL exist in different versions for Windows 9x platforms and Windows NT/2000 platforms. MSIMG32.DLL exists in different versions for Windows 98/NT and Windows Me/2000 platforms. When installing the wrong file various problems might occur. ATL.DLL and CTL3D32.DLL may prevent Windows from booting, and incorrect versions of COMCAT.DLL damage Visual Basic. 36) What Is The Best Way To Test A Package In A Locked-Down Environment? Per-machine advertisement followed by installation by a normal user account is the most comprehensive test for this situation. As an administrator use the following command line to advertise the application to the local machine: msiexec.exe /jm package.msi ALLUSERS=1 /qb Note: No package components will actually be installed, MSI will simply install the advertised shortcuts and icons, file types and extensions, COM class registration, and package installation information. Next, logon with a normal user account and trigger the installation process by running the shortcut or via a file type association. The application should start and run with no problems at this point. Be sure to make changes to settings, toolbars, and other preferences- then exit and relaunch the application to ensure such information is capable of being retained in this security context.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times