Blog Posts by pace-support

Ask a question

Windows 10 migration for enterprise: what to consider

When Windows 10 was released in 2015, the enterprise world reacted calmly – during the poll at Microsoft’s own Ignite conference around half of the respondents claimed their company would wait for more than a year before upgrading. The same answer was given by a whopping 80% of businesses with more than 100 000 end users.

However, 2017 is the high time to start a migration process. Here are the top 3 reasons:

  1. Windows 7 end-of-life is scheduled for 2020. Seems like a distant future? Not for the enterprise world – business had the same amount of time to move from Windows XP to Windows 7, and still, lots of them ran out of time. Migrations pilots, testing, and fixing compatibility issues (more on that later) may take over a year.

  2. Windows 7 is still the dominant OS in the enterprise market; however, Windows 10 adoption is gradually accelerating. According to Spiceworks’ survey, Windows 10 penetration is already at 11%. Ultimately, more enterprise software vendors will be shifting their focus to Windows 10 quite soon.

  3. Universal Windows Platform – a Windows 10 novelty – is a major focus for Microsoft, and software providers are following suit. For example, Sage’s popular CRM and accounting apps are already in Windows Store. Our own PACE Suite will support repackaging any installer into Universal Windows Platform format later this year.

Assuming the majority of businesses are planning to upgrade this year, we would like to highlight a few challenges that must be considered.

Cost of migration

The most recent similarly large OS migration was moving from Windows XP to Windows 7. According to Forrester, businesses have spent $1000 per average upgrade back then. While the cost of moving to Windows 10 will probably be smaller, it could still be a significant amount for any large company. What is more important, the application migration process was the most expensive part of that upgrade, and it will be a large investment this time as well.


Any migration project involves deploying business software to a large number of end users. To smooth this process, we would advise repackaging apps to MSI format for the following reasons:

  • Minimize end user involvement. With MSI silent installations, important configurations (licensing information, components to be installed, etc.) are pre-defined, and users can’t change that and disrupt the deployment.
  • Create and deploy pure packages. Exclusion lists automatically filter all captured resources and omit unnecessary system changes, which ensures the creation of pure packages (for example, PACE Suite has an editable exclusion list tailored to Windows 10).

Compatibility issues

Migrating critical applications from Windows XP to Windows 7 was a major challenge for enterprise IT and service providers. Though lots of Windows 7 applications are compatible with Windows 10, the best practice is to verify if mission critical software survives the upgrade. Moreover, testing is especially important for infrastructure apps.

Windows 10 adoption for the enterprise world is imminent, and we believe 2017 will be the year the majority of businesses will start or even complete the upgrade. If your migration project includes application repackaging, we invite you to try PACE Suite. PACE Suite doesn’t require any post-install configurations, has an easy user interface with helpful wizards, and allows installations of any number of virtual and physical machines. You can learn more about PACE Suite features here.

Be the first to comment

Types of Packages: Non-Virtual Packages – Practical Advice and Conclusions

Ever since the dawn of the consumer electronics and Windows OS, before virtualization has hit the mass-market, non-virtual packages were used to install software. It is worth mentioning though that non-virtual packages remain fairly popular and are nowadays widely used – as often as virtual packages.

Non-virtual packages can be grouped into three main categories, which we discussed in the previous blog posts:

According to the best practices, it is strongly advised to use Windows Installer (MSI) format for most application packaging needs.

  • Being more flexible in comparison to other formats, MSI is a perfect choice to perform complex operations with packages.
  • MSI allows using scripts to perform fine-tuning, therefore making it possible to deal with tasks of any complexity.
  • Since many .exe installers are rather limited in terms of configuration options, they can be repackaged to Windows Installer packages. Unfortunately, some packages can’t be repackaged, as they might be based on complex internal logic (e.g., installation of a system service or a driver). In such cases, it’s possible to use MSI format as a wrapper for an .EXE file. Custom Action is used to deploy .exe files while all additional configuration is performed using MSI. That results in a single .MSI file, containing all necessary installation logic and ready for deployment.
  • It should be noted, that Microsoft SCCM, one of the most popular deployment systems, is optimized for Windows Installer format providing a native support of .MSI packages. It ensures effective utilization of all features, offered by the Windows Installer technology.

In our next blog post, we’ll discuss existing approaches to virtual application packaging in Windows environment. Stay current!

About the Author

Dmitry Puzanov is an experienced IT specialist, a leader of Infopulse application packaging team and an analyst in the packaging sphere with 10+ years of experience in support engineering, networking, software installation development, and IT management.

Learn more about PACE Suite:

Be the first to comment

Types of Packages: Non-Virtual Packages – Scripted Installations

Last time, we talked about Executable Installers (.EXE). In this part of our blog, we’ll discuss an old, but still widely used approach to non-virtual application packaging – Scripted installations.

Scripted installation is one of the most archaic ways to install software. In a certain way, scripted installation is a father to many software packaging methods, as most modern installers are based on various script languages. The most widespread script languages in packaging are:

    • Batch Script (*.BAT and *.COM). Batch programming is very old-school! Batch script contains a set of system commands, which can also be executed using a MS-DOS emulator or Windows Command Prompt (cmd.exe). Batch-based packages contain a list of commands for copying files, applying an imported registry, managing system processes, services etc. The commands can be processed using basic conditions, loops, etc. During the installation, the files are installed to their destination paths, the registry is imported and some other auxiliary processes and activities are executed in the background. Interaction with the user is conducted via console screen (information is shown in text form during the installation process). Moreover, batch script can be used to install a set of “.EXE/.MSI” installers in any combination and to customize “.EXE” installations. In most cases Windows Installer packages do not require batch scripts due to advanced internal mechanisms. Nowadays the batch scripts are rarely used for application packaging needs.


    • VBScript is a way more advanced approach to scripted installations, based on Visual Basic. This programming language provides developers with almost endless opportunities and allows working with a system on a much deeper level, using WMI (Windows Management Instrumentation) and COM objects. With a help of VBScript, fully scripted packages can be built. VBS Wrappers perform sets of actions, including packages installations, additional customizations or system cleanups, etc. VBS is also commonly used in conjunction with .MSI Windows Installer, ensuring fine-tuning via MSI Custom Actions.


  • Windows PowerShell is the next generation command-line console and scripting language by Microsoft. Interest in PowerShell has been rapidly growing since the initial release in 2006. In fact, Microsoft was trying to make a sort of Linux’ terminal Bash and, apparently, they succeeded! Indeed, PowerShell has many means to manage the system and in the course of years, it has gone through a number of iterations. All recent Microsoft products for the server market have native support for this scripting language using specific PowerShell snippets. Most likely, you won’t find a standalone PowerShell package, however it’s widely used to fine tune other packages and as an installer wrapper. E.g., service is using OneGet protocol (based on NuGet) to implement repositories, similar to those of Linux. Packages for these repositories are wrapped in a PowerShell script and are installed to the user’s workstation with a help of this script. It is worth mentioning, that Microsoft OneGet is available as a pre-installed service in Windows 10 and is aimed at changing the approach to software deployment in Windows environment.

Some things just never get old. Being very close to low-level programming, script-based installations offer incredibly powerful and flexible customization capabilities.

Next time, we’ll summarize our knowledge about Non-Virtual application packaging and will come up with practical tips! Stay tuned for more blog posts on software packaging from our specialists!

About the Author

Dmitry Puzanov is an experienced IT specialist, a leader of Infopulse application packaging team and an analyst in the packaging sphere with 10+ years of experience in support engineering, networking, software installation development, and IT management.

Learn more about PACE Suite:

Be the first to comment

Types of Packages: Non-Virtual Packages – Executable Installers (.EXE)

In the previous article, we were talking about Microsoft Windows Installer. In this part of our blog, we’ll talk about the second largest type of non-virtual application packaging methods – Executable Installers (.EXE).

Executable installers (.EXE) represent the second largest type of installers. There are lots of .EXE installer types:

  • InstallShield Executable Installer is created with “Flexera AdminStudio”. This format supports customization by using a response file. It also supports ’silent’ installation mode, which requires no actions from the user. Customization of the installation file is limited, i.e., user can change only certain settings, which were specified by the manufacturer, while creating the installation.
  • InstallShield Executable Installer with wrapped MSI. Having the same origin and being mostly similar to the previous file type, this format does not offer many advanced configuration options as well. Customization options are available via public properties of the .MSI file wrapped into an .EXE file. Frequently, in software packaging factory practice, MSI file is simply extracted from .EXE and can be processed as a regular MSI installer. Naturally, in such cases specific features inherent to InstallShield MSI (specific properties, tables, custom actions) have to be taken into account.
  • NSIS (Nullsoft Scriptable Install System) is an open source project, supported by the dev community. An installation file is produced by compiling a script scenario. NSIS has its own set of free tools and add-ons, but requires developer skills to write a script. Installations support the ‘silent’ mode and can be customized within predefined by manufacturer settings.
  • InnoSetup Executable Installers are created with a freeware open source installer “Inno Setup” made by Jordan Russell. This script based installer supports the ‘silent’ mode and works with response files. Customization opportunities are predetermined by the manufacturer.
  • SFX Archivers (CAB/RAR/ZIP/7z etc.) are, by definition, self-extracting archives. A number of various installation customizations (UI and logics) is supported along with the ‘silent’ installation mode. It is possible to configure and alter the behavior of the self-extracting archive. If need be, the archive can be recreated with new files and registry settings. Having said that, it would be wrong to suppose that SFX archive is a standalone installer. It’s more of a supporting tool, which can unpack files to a certain location and execute a predetermined simple scenario. While it’s very easy to install such files, on contrary to prepare such installation is a rather time-consuming task. Unfortunately, advanced customization and fine-tuning are not available for such installations.
  • Wise Executable Installers are compiled .WSE scripts, primarily developed for a “WISE Package Studio” by Altiris Inc. (now part of Symantec). In order to create a WISE installer, first an installation script has to be written and then compiled. This installer type supports the ‘silent’ mode and can be customized, if allowed by the Vendor. Unfortunately, “WISE Package Studio” is no longer maintained and some modern OS features may not be fully supported. For instance, if you’re working in 64-bit OS, making the final package work as expected won’t be a walk in the park!

Of course, we could go on with this list forever, as there are many other custom-made installers, produced and supported by the manufacturers themselves. Whether to allow customization and include ‘silent’ mode support is completely up to the author of the installer. According to the generally accepted practice, these features nowadays are a must.

In the next blog post, we’ll discuss one more non-virtual application packaging method – the most archaic way to install software based on scripts. Stay tuned!

About the Author

Dmitry Puzanov is an experienced IT specialist, a leader of Infopulse application packaging team and an analyst in the packaging sphere with 10+ years of experience in support engineering, networking, software installation development, and IT management.

Learn more about PACE Suite:

Be the first to comment

Types of Packages: Non-Virtual Packages – Microsoft Windows Installer (MSI)

In the previous article, we discussed general information about application packaging methods and related target markets. Now, in this part of our blog, we’ll discuss in detail the non-virtual application packaging methods, namely Microsoft Windows Installer (MSI) format.

Microsoft knows a lot about doing things right. Wise people say, “Success is not a matter of chance, it is a matter of choice; it is not a thing to be waited for, it is a thing to be achieved”. That is exactly the case of the most popular platform that allows creating non-virtual packages. Initially, MSI was designed with a single purpose in mind – to install Microsoft Office 2000. It was only later on, upon consideration of the flexibility and convenience of Windows Installer, that the company decided to extend MSI support to the OS level. The most recent version of Windows Installer is 5.0, released along with Windows 7/Windows Server R2.


The installer consists of a set of tables forming a relational database. The tables describe the package structure and its properties. The Microsoft Windows Installer technology includes a number of installation file formats, each serving different purposes:

  • MSI. Microsoft Windows Installer Main Type includes the complete structure of tables and information summary, describing the installation.
  • MSP. Microsoft Patch carries changes to the Basic Type installer. Its main function is to update the previous installation with new information (files, registry settings, configuration (.INI) files, etc.). MSP can be installed separately, but only after the MSI with previous version of the product has been installed into the system.
  • MST. Microsoft Transform File modifies the Basic MSI. The key difference between MST and MSP is that MST can’t be installed separately from MSI. This format is extensively used in application packaging practice to customize Vendors’ .MSI files, ensuring the preservation of the initial .MSI logics, warranties and related liabilities. Normally, all additional settings and branding information are included into .MST Files.
  • MSM. Microsoft Merge Module is utilized to single out and integrate common components. It contains images of all tables, which have relevant information regarding the common components. MSM is used in various libraries from MS Redistributable Packages. Ready-made merge modules are supplied with Microsoft Visual Studio or can be downloaded from the alternative sources. Such modules contain accurate information regarding registration of a library in the system and are the best choice if a package contains common libraries.
  • MSU. Microsoft Update Standalone Package was first introduced with Windows Vista and is nowadays used by Microsoft to install Windows updates. This format, utilized solely by Windows update service, is frequently (and falsely) associated with Windows Update Installer. However, it would be wrong to associate MSU with MSI format. Microsoft Update format is based on a completely different technology. It can’t be called flexible or worthy for packaging practice and can’t be used in any other way than to install system updates. Why did we put MSU on the list then? The answer is simple: sometimes you may need to install update packages and for a number of reasons you might be looking for an alternative to the regular update service.

For more information on Windows Installer features and functions, please refer to the official Microsoft website.

In our next blog post, we’ll discuss another popular approach to non-virtual application packaging – Executable Installers.

About the Author

Dmitry Puzanov is an experienced IT specialist, a leader of Infopulse application packaging team and an analyst in the packaging sphere with 10+ years of experience in support engineering, networking, software installation development, and IT management.

Learn more about PACE Suite:

Be the first to comment
Showing 1 - 5 of 22 results

Top Contributors

Talk About Adobe Reader