A blog about System Center configuration Manager,System Center Orchestrator,PowerShell Scripting, MSI Re-Packaging and other automation stuffs
Pages
▼
Difference between Run, RunOnce, Active Setup and RunOnceEX
RunOnceEx: clears the registry key on completion of the command.
Modifying the File-Transfer Behavior for MSI's
Windows Installer (MSI) file-transfer behavior for installation and uninstallation are the following:
- Using the Never Overwrite component setting.
- Changing the REINSTALLMODE property.
- Specifying companion-file relationships.
- Using the Permanent component setting.
- Using the RemoveFile table to delete files created by your application.
Never Overwrite component: i work on Install shield and you can modify the Never Overwrite setting in the Components view or the Setup Design view of the InstallShield environment. If you set the Never Overwrite component property to Yes, Windows Installer will skip installing the component if its key file is already present on the target system. If the component’s key file is not present on the target system, Windows Installer will follow the normal file-overwrite behavior.
REINSTALLMODE property:The REINSTALLMODE property to modify the default file-overwrite behavior. The REINSTALLMODE property contains a string made of a collection of letters indicating how files should be overwritten. The default value is “omus”, where o indicates that older files should be overwritten with new files, m and u indicate that machine and user registry data should be reinstalled, and s indicates that shortcuts should be reinstalled.
To modify file-overwrite behavior, you can replace the o in the REINSTALLMODE value with another letter indicating the desired behavior. Some of the possible values are e, to overwrite a file with an older or equal version, or a, to overwrite existing files without checking their version information.
NOTE: The REINSTALLMODE value cannot be limited to a component or feature, but instead applies to all features that will be installed.
Companion-Fle:Another technique for adjusting file-overwrite behavior is to use companion files, which associate one file’s overwrite behavior to another file’s behavior. At run time, if the “parent” of the companion file relationship is installed, the “child” will be installed without regard for its version relationship with an existing file. To set up a companion file relationship, for the child’s Version data, enter the File-table key of the parent file. By default, the File-table key of a file is displayed in the rightmost (Key) column of the properties in a component’s file list.
To enter the parent file’s File-table key in the child’s version information, you can use the file’s Properties
panel, available when you right-click the file icon and select Properties. In the Properties panel, select the
“Override system version” check box, and then enter the desired Key in the version field.
Equivalently, you can enter the desired key in the Version field of the File-table record using the Direct
Editor view.
Permanent component: Another aspect of file-transfer behavior is the product’s uninstaller. If you set the Permanent property to Yes for a component, the component’s data will not be removed when the component is uninstalled. By default, when a product is uninstalled, any data installed by the installation will be removed.
RemoveFile table:a product’s uninstallation will remove only files installed by the original installation. Files created by an application after the installation is complete will not be removed automatically. If you want to remove files created by your application, you can add records to the RemoveFile table of your project. The
RemoveFile table is where you specify extra files to be removed when a given component is installed or
removed.
What version of .NET is installed on a user’s system?
This article illustrates one approach in determining what Microsoft® .NET Framework version is installed on a user’s system. Also, it describes how to determine whether service packs are installed for your .Net Framework installation.
MsiNetAssemblySupport Property:
Starting with Windows Installer 2.0 and later, MsiNetAssembly property is available. If the .NET Framework is not installed, the MsiNetAssemblySupport property will not be set. On machines that have .NET Framework installed, Windows Installer sets the value of the MsiNetAssemblySupport property to the file version of Fusion.dll. When multiple versions of Fusion.dll are installed side-by-side on user’s machine, this property is set to the latest version of Fusion.dll file by Windows Installer.
For .NET Framework 1.0, the possible values of MsiNetAssemblySupport property are as
follows:
For .NET Framework 1.1, the possible values of MsiNetAssemblySupport property are as
follows:
For additional information, click the following link to view the article in the Microsoft
Knowledge Base:
http://support.microsoft.com/kb/318785
MsiNetAssemblySupport Property:
Starting with Windows Installer 2.0 and later, MsiNetAssembly property is available. If the .NET Framework is not installed, the MsiNetAssemblySupport property will not be set. On machines that have .NET Framework installed, Windows Installer sets the value of the MsiNetAssemblySupport property to the file version of Fusion.dll. When multiple versions of Fusion.dll are installed side-by-side on user’s machine, this property is set to the latest version of Fusion.dll file by Windows Installer.
For .NET Framework 1.0, the possible values of MsiNetAssemblySupport property are as
follows:
follows:
Knowledge Base:
http://support.microsoft.com/kb/318785
Applying MSP to the MSI
Applying MSP to the MSI
The following
steps can be used to apply MSP over the MSI.
1)
Extract the MSI file from setup.exe (if it is not available in source)
Setup.exe /a
2)
Create AIP for the source MSI
msiexec /a sample.msi
TARGETDIR="C:\Extracted Source\"
(This will dump MSI and its files to the location "C:\Extracted
Source\")
3)
Extract the MSP file from Patch EXE (if it is not available in source)
PATCH.EXE /Q /C /T:C:\ProjSP (This will extract patch from EXE say for example
Sample.msp to the location "C:\ProjSP\")
4)
Apply the Patch from "C:\ProjSP\" over the extracted MSI at
"C:\Extracted Source\"
msiexec /p "C:\ProjSP\Sample.msp" /a "C:\Extracted
Source\Sample.msi" SHORTFILENAMES=TRUE /qb
The MSI and
its files under the Admin installation location "C:\Extracted
Source\" will now include Patch and its files changes.
We need
to create MST for the resultant MSI at "C:\Extracted Source\"
Using Active Setup
Active
setup:
Active
setup is a process that runs automatically once when a user logs in.
Active
setup usage:
If
an application requires installation of components such as files or registry
keys on a per-user basis (HKCU or User Profile files
such as LocalAppData, My Documents folder etc.) and the application
has
no advertised
entry points
or other triggers to initiate the installation process, then Active Setup is
the solution.
Scenarios
Registry
|
Files
|
Shortcut
|
Active
Setup
|
HKCU
|
User
Profile Files
|
No
Advertised Shortcut
|
Required
|
HKCU
|
No
User Profile Files
|
No
Advertised Shortcut
|
Required
|
No
HKCU
|
User
Profile Files
|
No
Advertised Shortcut
|
Required
|
No
HKCU
|
No
User Profile Files
|
No
Advertised Shortcut
|
Not
Required
|
HKCU
|
User
Profile Files
|
Advertised
Shortcut
|
Not
Required
|
Steps
to include Active setup in Application:
1. Create a component
and add the below HKLM Registry keys.
HKLM
Registry Keys
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active
Setup\Installed Components\[ProductCode]] @="[ProductName]"
"StubPath"="msiexec.exe
/fu [ProductCode] /qb!"
"Version"="[ActiveSetupVersion]"
2. Create a
component and add the below HKCU Registry keys.
HKCU
Registry Keys
[HKEY_CURRENT_USER\Software\Microsoft\Active
Setup\Installed Components\[ProductCode]]
"Version"="[ActiveSetupVersion]"
3. Create a Property
called “ActiveSetupVersion” with the value containing the Product
version separated by comma.
Eg: If the Product
Version is 16.0.2 then use 16,0,2
How To Quickly and Easily Provide Access to Your Application Catalog Data While Maintaining Data Integrity
How To Quickly and Easily Provide Access to Your Application Catalog Data While Maintaining Data Integrity
Often times in the Enterprise environment, you may have a requirement to provide general
access to data and at the same time provide a measure of security on the same data to
ensure integrity. These conflicting requirements are often satisfied by creating a working
copy of the data for general use while maintaining tight access restrictions to the primary
data. This following tip will show you how.
In AdminStudio ConflictSolver v5.5, we support two ways in which you can create a copy of
your Application Catalog data:
1. Merging Application Catalog Information—Use the Merge Wizard to merge the source
Application Catalog's data into the currently open Application Catalog. The merged
data is not linked in any way to the source Application Catalog.
2. Linking to Application Catalog Information—Use the Remote Package Alert Wizard to
link to individual packages in remote Application Catalogs, and import these packages
into your local Application Catalog. To update the contents of your local Application
Catalog with the data on the remote Application Catalogs that you are linked to, you
can choose to Refresh package data.
Both wizards to allow you to effectively copy MSI package data between Application
Catalogs. However, these operations have some inherent limitations in that they require
user interaction and the mode of data duplication is to repeat the import process for the MSI
packages.
If you use SQL Server, then you have a third way to quickly and easily create working
copies of your Application Catalog:
Replicating Application Catalogs—Use Application Catalog Replication's Publication and
Subscription Wizards to distribute an Application Catalog database where it is needed across
a large enterprise or multi-national corporation. Data is replicated between a Publisher
Database Server and a Subscriber Database Server, which do not need to be available on
the same network.
AdminStudio v5.5 Enterprise edition includes a SQL Server replication tool available through
the main AdminStudio IDE – Catalog menu which makes the process of replicating large
amounts of ‘Application Catalog’ data very simple. You can provide wide ranging user access
to the replicated Application Catalog while maintaining tight access restrictions to your
primary Application Catalog.
Please refer to the AdminStudio v5.5 help topic, Sharing Application Catalog Data and
Application Catalog Replication, for more information on all of the options available for the
user who needs to create working copies of their Application Catalogs.