New batch of Application Packaging Classroom Training at Hyderabad from 10th October 2011.
Course Duration: 1 Month ( 1hr/day)
Anyone interested?, please contact me on Virtual.App.Packager@gmail.com
visit www.AppRepack.in for more information on training topics.
Note: Send me an email, if you are looking for online training details. Thanks
Saturday, 17 September 2011
Monday, 12 September 2011
How to create Minor Upgrade MSI
Steps to create Minor Upgrade:
- Change the Package code and Product Version to create a minor upgrade
- Add feature / component by following the guide lines in Section: Requirement for Minor upgrade
- Add Remove or Modify files, registry keys and shortcuts.
- Add minor upgrade item in upgrades view (this is optional).
- Build and use the installer for upgrade.
Wednesday, 7 September 2011
Application Packaging Services - AppRepack Technologies
AppREPACK Technologies is a privately-owned company offering Application Packaging and Virtualization solutions. Our work is driven by vast expertise, advanced technology and quality focus.
You will experience your requirements being met on time, within budget and with high quality; top-class solutions at competitive prices.
We can provide services on
You will experience your requirements being met on time, within budget and with high quality; top-class solutions at competitive prices.
We can provide services on
- Microsoft Windows Installer (MSI) using Wise Package Studio / Installshield / AdminStudio
- Microsoft App-V
- VMware ThinApp
- SCCM 2007 Support
Tuesday, 6 September 2011
What is Application Repackaging
Repackaging (Customized Installation) is the process of capturing the changes made by an Installation Program (Package) and it is designed to support company standards and distribution methods. Following are the steps for repackaging an application.
- Review the packaging requirements with the projects sponsor
- Analyze the vendor package (Tech Review)
- Repackage the application (Scripting)
- Customize the package
- Test the package
- Release the package to end users
Processing Options in Custom Actions
- Synchronous
- Synchronous, ignore exit code
Windows Installer runs the custom action synchronously to the main installation. It waits for the custom action to complete before continuing the main installation; the action can be either success or fail.
- Asynch, wait at end of sequence
Windows Installer runs the custom action simultaneously with the main installation. At the end it waits for the exit code from the custom action before continuing.
- Asynch, no wait
Limitations of App-V
1. Device Driver: Microsoft Application Virtualization does not support sequencing of device drivers thus any application which install device driver should not be sequenced.
2. Application Size: If the maximum client cache size is set for 2 GB (The max can be 64 GB), then the maximum size of application (sft file) which can be streamed on that machine is 2 GB. All applications which have the installed footprint greater than or equal to the max client size, set by the client, should not be sequenced. Also the Max application size App-V can handle is 4GB, [Q: drive has FAT file type and the max file size FAT can handle is 4GB]. This issue is discussed in more details at http://www.softgridguru.com/viewtopic.php?t=2763
3. Shortcuts: Application should have minimum of one shortcut. If no shortcuts are present then the application should be sequenced in a suite along with the application which needs it. For example if Macromedia Flash is the application in question to be sequenced then the shortcut should be pointing to the locally installed Internet Explorer
4. Middleware: Middleware applications are not a good candidate for sequencing as they can be used as a prerequisite by multiple applications, thus should be installed locally. but if multiple version of it are needed then they should be sequenced along with the application which needs them. It is always advised to have only one version of any application/middleware in the organization thus conditions for multiple versions should be avoided With Version 4.5 most of the middle-wares can be sequenced and used as secondary packages.
5. Path hard coding: The application should not have folder/file path hard coding in the application itself. Some application hard code the path of files in registry or ini file or executable. In these cases it has been found that they can be sequenced most of the time using VFS sequencing method, but extreme care should be taken while sequencing & testing these applications. Also Configuration files such as ini, conf, txt, registries etc are good places to look for the hard coding
6. Base Build Applications: Applications which are already part of base build should not be sequenced. One can sequence them but they are of no real value as they will already be present on the client machines
7. Auto Update: Application with automatic updates should not be sequenced. Sequenced application most of the time fails to properly update itself. Also allowing auto update leads to non compliance of application version. These types of applications should only be sequenced if the auto update feature can be disabled during sequencing procedure
8. Services: Services which can be started when application starts and shuts down when application main executable shuts down can be included in sequence. Services that run as their own (like boot-time services do but there are others also) are not suitable for sequencing since under App-V all application starting happens under user’s session context. Also applications which install services which run using specific user credentials cannot be sequenced
9. COM+: Some application which uses COM+ might not work properly in virtual environment, thus this type of applications needs be tested properly
10. COM DLL: Few application which uses COM DLL surrogate virtualization, i.e. DLL’s that run in Dllhost.exe, does not work properly in App-V Environment. Thus this type of applications needs be tested properly
11. Licensing Policies: Applications with licensing enforcement tied to machine, e.g. the license is tied to the system’s MAC address, username etc. It should not be sequenced if activation cannot be done by the user at the first launch 2009 c Mayank Johri Microsoft Application Virtualization - An Introduction to Sequencing Source Files Validation 10 of sequenced application
12. Internet Explorer & Service Packs: Internet Explorer, Windows service patches and service packs cannot & should not be sequenced
13. Network Share Application: It is not a good practice the run applications from network share as they tend to violate the enterprise desktop integrity and thus known to cause integration issues. It is advised to have to entire application inside of App-V package
14. Hosts file located in “%windir%\system32\etc” cannot be sequenced and should be updated on local machine before the sequenced application is launched
2. Application Size: If the maximum client cache size is set for 2 GB (The max can be 64 GB), then the maximum size of application (sft file) which can be streamed on that machine is 2 GB. All applications which have the installed footprint greater than or equal to the max client size, set by the client, should not be sequenced. Also the Max application size App-V can handle is 4GB, [Q: drive has FAT file type and the max file size FAT can handle is 4GB]. This issue is discussed in more details at http://www.softgridguru.com/viewtopic.php?t=2763
3. Shortcuts: Application should have minimum of one shortcut. If no shortcuts are present then the application should be sequenced in a suite along with the application which needs it. For example if Macromedia Flash is the application in question to be sequenced then the shortcut should be pointing to the locally installed Internet Explorer
4. Middleware: Middleware applications are not a good candidate for sequencing as they can be used as a prerequisite by multiple applications, thus should be installed locally. but if multiple version of it are needed then they should be sequenced along with the application which needs them. It is always advised to have only one version of any application/middleware in the organization thus conditions for multiple versions should be avoided With Version 4.5 most of the middle-wares can be sequenced and used as secondary packages.
5. Path hard coding: The application should not have folder/file path hard coding in the application itself. Some application hard code the path of files in registry or ini file or executable. In these cases it has been found that they can be sequenced most of the time using VFS sequencing method, but extreme care should be taken while sequencing & testing these applications. Also Configuration files such as ini, conf, txt, registries etc are good places to look for the hard coding
6. Base Build Applications: Applications which are already part of base build should not be sequenced. One can sequence them but they are of no real value as they will already be present on the client machines
7. Auto Update: Application with automatic updates should not be sequenced. Sequenced application most of the time fails to properly update itself. Also allowing auto update leads to non compliance of application version. These types of applications should only be sequenced if the auto update feature can be disabled during sequencing procedure
8. Services: Services which can be started when application starts and shuts down when application main executable shuts down can be included in sequence. Services that run as their own (like boot-time services do but there are others also) are not suitable for sequencing since under App-V all application starting happens under user’s session context. Also applications which install services which run using specific user credentials cannot be sequenced
9. COM+: Some application which uses COM+ might not work properly in virtual environment, thus this type of applications needs be tested properly
10. COM DLL: Few application which uses COM DLL surrogate virtualization, i.e. DLL’s that run in Dllhost.exe, does not work properly in App-V Environment. Thus this type of applications needs be tested properly
11. Licensing Policies: Applications with licensing enforcement tied to machine, e.g. the license is tied to the system’s MAC address, username etc. It should not be sequenced if activation cannot be done by the user at the first launch 2009 c Mayank Johri Microsoft Application Virtualization - An Introduction to Sequencing Source Files Validation 10 of sequenced application
12. Internet Explorer & Service Packs: Internet Explorer, Windows service patches and service packs cannot & should not be sequenced
13. Network Share Application: It is not a good practice the run applications from network share as they tend to violate the enterprise desktop integrity and thus known to cause integration issues. It is advised to have to entire application inside of App-V package
14. Hosts file located in “%windir%\system32\etc” cannot be sequenced and should be updated on local machine before the sequenced application is launched
VFS Sequencing
In VFS sequencing the application and its supporting applications are installed in there default location. VFS sequencing is recommended process for sequencing DSC Sequencing.
Benefits
- Applications with hard-coded path entries can only be sequenced using this method.
- This is the best solution for sequencing DSC based applications which copy files in sub-folder of base applications.
- Sequenced applications run slightly slower then Q Drive based sequence
- Some applications might not work properly, especially apps which try to evaluate the launch location at the launch time.
Dynamic Suite Composition (DSC) in App-V
Generally Middleware apps are dependency for most of the apps, so we virtualize both the apps separately and add HREF attributes of dependency appl to main appl.
Process: Sequence this dependency first and revert it to clean machine. Then before starting main applications sequencing, install dependency and start sequencing process. At the end of sequencing, open OSD in notepad, add HREF attributes of middle ware appl to main appl also add one more tag MANDATORY=”TRUE” True – Interacts with middleware appl, False – does not interact with middleware
Process: Sequence this dependency first and revert it to clean machine. Then before starting main applications sequencing, install dependency and start sequencing process. At the end of sequencing, open OSD in notepad, add HREF attributes of middle ware appl to main appl also add one more tag MANDATORY=”TRUE” True – Interacts with middleware appl, False – does not interact with middleware
How to resolve ICE38 Error
ICE38 ERROR
Component DesktopFolder installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
Solution:
In the Components Tab, find the CurrentUser component, which holds all the user's information. Pick one of the registry keys (except the one set as a keypath), right click on it and select the option 'Move'.
Move that key to the component referred on the ICE error message. Go to thatcomponent, open it and find the 'new key'. Right click on the entry and select'Set as Key' option.
Windows File Versioning Rules
At the core of any installer is the actual installation of files. But determining whether to install a file is a complex process. At the highest level, making the determination depends on whether the component to which a file belongs is marked for installation. Once the determination is made that a file should be copied, the process is complicated if another file with the same name exists in the target folder. In such situations, making the determination requires a set of rules involving the following properties:
Highest Version Wins — All other things being equal, the file with the highest version wins, even if the file on the machine has the highest version.
Versioned Files Win — All other things being equal, a versioned file gets installed over a non-versioned file.
Favor Product Language — All other things being equal, if the file being installed has a different language than the file on the machine, favor the file with the language that matches the product being installed. Language neutral files are treated as just another language so the product being installed is favored again.
Mismatched Multiple Languages — All other things being equal, after factoring out any common languages between the file being installed and the file on the machine, any remaining languages are favored according to what is needed by the product being installed.
Preserve Superset Languages — All other things being equal, preserve the file that supports multiple languages regardless of whether it is already on the machine or is being installed.
Non-versioned Files Are User Data — All other things being equal, if the Modified date is later than the Create date for the file on the machine, do not install the file because user customizations would be wiped out. If the Modified and Create dates are the same, install the file. If the Create date is later than the Modified date, the file is considered unmodified, install the file.
Non-versioned Files Using Companion — All other things being equal, a non-versioned file that is associated with a versioned file using the companion mechanism abides by the rules for the versioned file. The only exception is if the versioned file on the machine and the versioned file being installed have the same version and language but the companion file is missing on the machine. In this case the companion file being installed is used even though the versioned file on the machine is used.
Rules Are Global — The rules for determining when to install a file reside in one place within the installer and are global, meaning they apply to all files equally.
- Version
- Date
- Language
Highest Version Wins — All other things being equal, the file with the highest version wins, even if the file on the machine has the highest version.
Versioned Files Win — All other things being equal, a versioned file gets installed over a non-versioned file.
Favor Product Language — All other things being equal, if the file being installed has a different language than the file on the machine, favor the file with the language that matches the product being installed. Language neutral files are treated as just another language so the product being installed is favored again.
Mismatched Multiple Languages — All other things being equal, after factoring out any common languages between the file being installed and the file on the machine, any remaining languages are favored according to what is needed by the product being installed.
Preserve Superset Languages — All other things being equal, preserve the file that supports multiple languages regardless of whether it is already on the machine or is being installed.
Non-versioned Files Are User Data — All other things being equal, if the Modified date is later than the Create date for the file on the machine, do not install the file because user customizations would be wiped out. If the Modified and Create dates are the same, install the file. If the Create date is later than the Modified date, the file is considered unmodified, install the file.
Non-versioned Files Using Companion — All other things being equal, a non-versioned file that is associated with a versioned file using the companion mechanism abides by the rules for the versioned file. The only exception is if the versioned file on the machine and the versioned file being installed have the same version and language but the companion file is missing on the machine. In this case the companion file being installed is used even though the versioned file on the machine is used.
Rules Are Global — The rules for determining when to install a file reside in one place within the installer and are global, meaning they apply to all files equally.
Windows File Protection
A common problem in the history of the Microsoft Windows operating systems has been the ability for shared system files to be overwritten by non-operating system installation programs. After such changes are made, the user may experience unpredictable system performance, ranging from application errors to operating system crashes. This problem affects several types of files--most commonly dynamic link libraries (.dll) and executable files (.exe).
In Windows 2000 and Windows XP, the Windows File Protection (WFP) feature prevents overwriting or replacement of certain system files. Overwriting shared system files can result in unpredictable system performance that ranges from application errors to operating system crashes. System instability caused by non-standard replacement of system files has been a common problem. By preventing the replacement of these essential system files, file version mismatches are avoided, and the overall stability of the system is improved.
In Windows 2000 and Windows XP, the Windows File Protection (WFP) feature prevents overwriting or replacement of certain system files. Overwriting shared system files can result in unpredictable system performance that ranges from application errors to operating system crashes. System instability caused by non-standard replacement of system files has been a common problem. By preventing the replacement of these essential system files, file version mismatches are avoided, and the overall stability of the system is improved.
What are MergeModules
Merge modules provide a standard method by which developers deliver shared Microsoft® Windows® Installer components and setup logic to their applications. Merge modules are used to deliver shared code, files, resources, Registry entries, and setup logic to applications as a single compound file. Developers authoring new merge modules, or using existing merge modules, should follow the standard outlined in this section.
A merge module is similar in structure to a simplified Windows Installer .msi file. However, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers wanting to use merge modules must obtain one of the freely distributed merge tools, such as Mergemod.dll, or purchase a merge tool from an independent software vendor. Developers can create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.
When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application's .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user. Because all the information needed to install the components is delivered as a single file, the use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files.
A merge module is similar in structure to a simplified Windows Installer .msi file. However, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers wanting to use merge modules must obtain one of the freely distributed merge tools, such as Mergemod.dll, or purchase a merge tool from an independent software vendor. Developers can create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.
When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application's .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user. Because all the information needed to install the components is delivered as a single file, the use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files.
Advantages of MSI Packaging
Following are the advantages over legacy setup
Transaction based operation: All installation operations are transactional. For each operation that Windows Installer performs, it generates an equivalent undo operation that would undo the change made to the system. If a failure occurs during the middle of an installation, Windows Installer can roll back the machine to its original state.
Self-healing: Windows Installer supports "self-healing" abilities for applications. Applications can detect common installation problems at launch, like missing files or registry keys, and automatically repair themselves.
Installation on demand: Windows Installer supports on-demand installations of application features. For example, the spelling checker in Microsoft Office Word may not be installed by default, but a user can trigger an on-demand installation of this feature.
Installation in locked-down environments: In fully locked-down environments, users don't generally have permission or the ability to install applications. In most cases, they don't have write-access to the Program Files folder of their computers or to the HKEY_LOCAL_MACHINE registry location. If an administrator approves an installation package by means of Group Policy, for instance, Windows Installer can perform an installation on the user's behalf.
Managed Application: Windows Installer provides a set of standard Win32® application programming interfaces (APIs) and automation interfaces for applications and administrators to use for querying the installation state on the machine. The APIs allow querying of the current state, verification of the existing state, repair of a corrupted state, and transition from one state to another.
Transaction based operation: All installation operations are transactional. For each operation that Windows Installer performs, it generates an equivalent undo operation that would undo the change made to the system. If a failure occurs during the middle of an installation, Windows Installer can roll back the machine to its original state.
Self-healing: Windows Installer supports "self-healing" abilities for applications. Applications can detect common installation problems at launch, like missing files or registry keys, and automatically repair themselves.
Installation on demand: Windows Installer supports on-demand installations of application features. For example, the spelling checker in Microsoft Office Word may not be installed by default, but a user can trigger an on-demand installation of this feature.
Installation in locked-down environments: In fully locked-down environments, users don't generally have permission or the ability to install applications. In most cases, they don't have write-access to the Program Files folder of their computers or to the HKEY_LOCAL_MACHINE registry location. If an administrator approves an installation package by means of Group Policy, for instance, Windows Installer can perform an installation on the user's behalf.
Managed Application: Windows Installer provides a set of standard Win32® application programming interfaces (APIs) and automation interfaces for applications and administrators to use for querying the installation state on the machine. The APIs allow querying of the current state, verification of the existing state, repair of a corrupted state, and transition from one state to another.
ActiveSetup Implementation
If you are using Windows Installer for per-machine-based installations, it could be the case that your setup contains components with user-related resources that have no entry-points to initiate the install-on-demand/self healing function of MSI. This, of course, will mean that when deployed the package will not install the user resources required to run the application properly.
But wait, don’t lose hope! In such a case you can use the Active Setup for a self healing on demand. It needs just one registry key in your msi file.
This registry key can be assigned to any Component that installs per-machine resources or you can create one component just for this key.
How it works:
The value in the StubPath key will be executed at a special time during which the Active Setup tasks are running and no other Windows Installer processes are running in the background that could cause the repair not to run (which would be the case if you attempted to run this command in the Run-Once registry key).
The command will thereby perform a repair for HKCU registry keys and missing files.
If this command runs successfully, it will create a registry key in HKCU and the command will not run again. However, if you wish to trigger this command again, because of a small update, then use the Version Key and increment its value each time you wish to run this command again when a user logs in.
Important Note:
Remember to use this command only if your setup does not contain any entry-point that would not allow the repair on demand, because this repair will run when a user on the target workstation logs in after the installation has been run. That means, even if the user doesn’t use the installed application, it will run the repair. And as you may already know, those repairs can take some time depending on the workstation’s hardware configuration and the size of the package.
SetACL Permissions Examples
Using SetACL to provide permissions
Command1: Providing registry permissions to Authenticated Users group
1. setacl.exe "MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /grant "Authenticated Users" /full /i:cont_obj_inh /p:yes /r:cont_obj /silent
OR using S-ID
"MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /set "S-1-5-11" /full /sid /silent
Command2: Providing Folder permissions to Authenticated Users group
setacl.exe "c:\AudioTools\GIMP" /dir /set "S-1-5-11" /change /sid /silent
Change the group name / S-ID according to your requirement
Why multiple MSIExec.exe processes running on machine during aninstallation
A number of MSIExec processes can be running during an installation. The reason for this is that Windows Installer uses a client-server model for performing installations. Additionally for security reasons, Windows Installer hosts DLL and script custom actions in a "sandbox" process. Depending on how the install was initiated, one of the MSIExec processes can be the client process. Another MSIExec process is Windows Installer service. Any remaining MSIExec processes are usually sandbox processes for hosting custom actions. The determination as to which MSIExec process will serve as the sandbox process for a script or DLL custom action depends in part on whether the custom action will run elevated or impersonated and whether the custom action is 32-bit or 64-bit.
Difference Between Execute Immediate and Execute Deferred
- Deferred custom actions can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Immediate custom actions, on the other hand, can be sequenced anywhere within any of the sequence tables.
- Deferred custom actions cannot access the installation database. In fact, deferred custom actions have very limited access to the installation session because an installation script can be executed outside of the installation session that created it. Immediate custom actions have access to the installation database and can read and set installation properties, modify feature and component states, and add temporary columns, rows, and tables among other things.
- While both deferred and immediate custom actions can run in the context of the user initiating the installation, only deferred custom actions can run elevated using the system context.
- Deferred custom actions are not executed immediately. Instead they are scheduled to run later during the execution script. The execution script isn't processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run.
Monday, 5 September 2011
SCCM 2007 Ceritification Dumps
Please visit following link to get latest dumps on SCCM 2007 Certification 70-401
http://www.examcollection.com/70-401.html
http://www.examcollection.com/70-401.html
Kaviza VDI-in-a-box
VDI-in-a-box brought to you by Citrix makes desktop virtualization easy and affordable without sacrificing performance. An all-in-one software appliance with many platform and end-point options, VDI-in-a-box deploys quickly on inexpensive off-the-shelf servers, and delivers high-availability without requiring shared storage. VDI-in-a-box eliminates over 66% of VDI infrastructure costs and delivers virtual desktops for less than the cost of PCs.
For more information, visit http://www.kaviza.com/VDI/VirtualDesktopsProducts/Overview.html
Windows Intune
Your employees depend on you to keep their PCs running at their best, whether they are in the office or on the road. Windows Intune simplifies and helps businesses manage and secure PCs using Windows cloud services andWindows 7. The Windows Intune cloud service delivers management and security capabilities through a single Web-based console so you can keep your computers and users operating at peak performance from anywhere. Give your users the best Windows experience with Windows 7 Enterprise or standardize your PCs on the Windows version of your choice. Windows Intune fits your business by giving you big tech results with a small tech investment. The result? Less hassle, and peace of mind knowing that your employees' PCs are well-managed and highly secure.
Windows Intune can be used by in-house IT professionals or by solution providers to manage the PCs of multiple businesses.
Whether you are in search of a solution that can deliver the essentials of management and protection for all your PCs or just those hard-to-reach PCs—highly distributed workers, non-domain joined PCs, field employees, or recent acquisitions—Windows Intune can help.
For more information please visit http://www.microsoft.com/windows/windowsintune/pc-management.aspx
Windows Intune can be used by in-house IT professionals or by solution providers to manage the PCs of multiple businesses.
Whether you are in search of a solution that can deliver the essentials of management and protection for all your PCs or just those hard-to-reach PCs—highly distributed workers, non-domain joined PCs, field employees, or recent acquisitions—Windows Intune can help.
For more information please visit http://www.microsoft.com/windows/windowsintune/pc-management.aspx
Subscribe to:
Posts (Atom)