The Application Packaging Experts Roundtable discussed a wide range of topics surrounding application packaging, management, and deployment. The speakers included the product manager at Flexera for security products, including Admin Studio and Software Vulnerability Manager, as well as a guest speaker from SparkleFlow.

The guest speaker, Ronald, has been in IT since 1991 and has worked extensively in application packaging, even starting a company dedicated to this area. He discussed the development of SparkleFlow, a management tool designed to streamline the application packaging process. Ronald highlighted the need for more efficient and structured practices in this field, pointing out common inefficiencies in many projects such as lack of documentation and structure.

Furthermore, the roundtable included a discussion about the evolution of online communities dedicated to application packaging. The history of the website AppDeploy was discussed, highlighting its role as a resource for sharing packaging tools and solutions, and how it evolved into IT Ninja under the acquisition of KACE and subsequently Dell.

The roundtable concluded with Ronald’s proposal to reboot a similar platform to AppDeploy, acknowledging the change in times and the saturation of information on social media websites. The new platform would integrate with SparkleFlow and other resources to provide a comprehensive resource for application packagers. The integration with the WinGet repository and the development of an API with artificial intelligence were also discussed as future enhancements for the platform.

The participants delve into the future of application packaging. The speaker, Ronald, shares his journey as an admin, starting with setup access and the wise install master, and how he thought that silent installs using the Microsoft Installer (MSI) technique would mark the end of packaging. However, that didn’t happen, and then other technologies like Softgrid and AppV also didn’t mark the end of packaging as he expected. He notes that MSIX is the current trend, but admits he’s unsure where things are going. Ronald believes that the focus has shifted from technical solutions to management, with much of the administration work revolving around application availability. Despite the evolution of technology, he believes there will always be a need for management, even if everything shifts to a cloud platform. However, he notes that there’s still a lot of legacy technology that many applications are based on, which may slow the transition.

The conversation then turns to the role of packaging in on-premises versus cloud applications, with the consensus being that on-premises enterprise applications are here to stay for a long time due to various reasons, even though cloud computing technology has improved significantly.

The participants also discuss the role of Powershell and the Powershell deploy toolkit in application packaging. The toolkit provides a consistent and customizable way to wrap applications in a script, which makes application management and logging easier, especially for those who don’t have strong Powershell skills.

The benefits of the app deploy toolkit, such as its user interface and the ability to shut down apps, restart machines, warn users, and brand and customize applications. The participants agree that the toolkit provides a great use case for learning scripting, as application deployment often presents complex problems that require creative solutions.

The speakers are discussing the complexities involved in deploying software packages, specifically focusing on the advantages of using the App Deploy Toolkit. This toolkit simplifies the process by consolidating all the steps into a single file, allowing for pre-install configurations and conditional scripting to stop installations if necessary conditions aren’t met. This reduces the potential for application misbehavior and subsequent support cases.

A common challenge discussed is managing MSI (Microsoft Installer) packages. Traditionally, if an application was already an MSI, it was not recommended to repackage it, even though repackaging could help to introduce all customizations into the software. Nowadays, with the PowerShell Deploy Toolkit, it doesn’t matter what type of package it is, the toolkit provides a consistent way to inject any customizations.

One of the customers shared their experience of using the wrapping functionality of Admin Studio. They had a script that would call various packages and based on certain conditions being satisfied on a machine, a specific package would be installed.

The conversation then shifts to MSIX, a packaging format from Microsoft aimed at Windows 10 apps. The speakers highlight that while MSIX has some limitations, especially with legacy applications and complex dependencies, it is being improved continuously. However, the adoption of MSIX is slow, even from Microsoft itself.

The speakers point out that a successful transition to MSIX, from the user’s perspective, would mean installing and using an application without knowing it’s an MSIX package. But this is not what the professionals want – they want MSIX to be a requirement, much like Windows Installer was in its early days.

A promising development mentioned is App Attach, which allows for the sideloading of applications into a Windows Virtual Machine image instantly. This is helpful for VDI (Virtual Desktop Infrastructure) use cases where it’s undesirable to have all applications in a static VDI session that needs constant updating.

They mention that even though MSIX has been around for five years and has seen significant improvements, it’s still seen as a container and may not be suitable for all applications, especially those that are resource-intensive.

Interactions with the operating system, or something like that, present some limitations. These limitations might continue indefinitely. At some point, as an independent software vendor (ISV) or an enterprise, you might have to step back and evaluate whether you’re okay with what MSIX offers, and then decide to convert at least a set of applications to MSIX.

As you mentioned, there are many benefits to MSIX. One of the major ones is deployments. With the containerization aspect of MSIX, you can circumvent the legacy issues of conflicts and compatibility. This ensures your application will be deployed successfully, and most importantly, uninstalled without problems.

Uninstallation is one of the best things about MSIX. If you’re okay with these benefits, then you can consider which of the applications in your portfolio are simple enough to move to MSIX. For example, Notepad++ or 7-Zip are typically used across enterprises and could be good candidates to start transitioning to MSIX.

Managing applications becomes easier with MSIX, and it also simplifies updating to the latest versions. However, the real-world benefits of MSIX updates haven’t been fully realized yet. Many vendors have automatic updates, which we as admins often have to figure out how to turn off. With MSIX, the source for that package could be the vendor’s website. They update to the new version, and you, with a policy, can decide whether this application automatically updates or not. Moreover, it updates side by side, eliminating the need to restart the application.

If you’re hosting your own source from the MSIX package, you can update your source and then decide how it rolls out. It’s smoother, more efficient, and it provides consistency for this update capability. Currently, it’s quite ad hoc, and we often do a rip and replace, installing over the top and hoping it works okay.

However, the all-or-nothing approach for MSIX is probably its biggest hindrance. If you plan to be all Windows Installer and repackage everything to Windows Installer, keep in mind that this isn’t Windows Installer. These days, people generally understand that if it’s a good command line, they’re going to wrap it in the PowerShell Deploy Toolkit. If it doesn’t play well, they’re going to repackage it and then wrap it in the PowerShell Toolkit for consistency.

For MSIX adoption, it’s really about adding it to the top. If it works with MSIX easily out of the box, great. But if you want everything MSIX or you’re not going to do MSIX, you may never get there.

In terms of errors, we’ve been searching for errors in MSIX, the newest and most interesting technology. We have a section on the website which handles most errors. If people encounter new errors that aren’t listed, we like to be informed. People can also become contributors to the website.

Finally, a viewer mentioned their main issue with MSIX is the requirement for signing. Managing hundreds of AppV packages right now is a nightmare, let alone trying to manage certificates for all applications. This has been one of the biggest pain points for adoption. We should dive into this topic in a future roundtable, as it might be less intimidating if you look at it a certain way.

For troubleshooting, the first step is using the Event Viewer. Unfortunately, it seems that some system administrator courses are not teaching this basic tool anymore. However, the Event Viewer is an important first step in troubleshooting.

The final section of this conversation deals primarily with using MSIX packaging and the challenges associated with runtime errors. The participants discuss the benefits of Microsoft’s “fix-up” system, which helps diagnose and rectify these errors. A part of this system is the “trace” fix-up, which can be used during testing to identify any runtime errors. The speakers also mention the usefulness of tools like the MSIX editor in Admin Studio, which simplifies the process.

They also touch on the trend of organizations migrating SCCM deployments to InTune win32 installs with the help of Admin Studio. This transition is being automated, making it easier for companies to manage their applications.

The conversation then shifts to the size of endpoint management teams in medium-sized companies. While the number of devices is one factor to consider, other factors like the number of applications under management and the degree of automation also come into play. They suggest that a team of four to seven people might be typical for a medium to large enterprise, but the composition of the team is equally important.

The session ends with an invitation for participants to join their community and engage in discussions about future topics. The next session is scheduled for June 6th. They express their gratitude for the participation and valuable inputs provided during the session.