MSIX Packaging Fundamentals Q&A Webinar Summary
On December 2nd of 2020, MSIX Packaging Fundamentals book authors Tim Mangan, Bogdan Mitrache, and Kevin Kaminski answered a series of questions within the MSIX Packaging Fundamentals Q&A live webinar.
All of those questions, together with the answers addressed by the authors, are presented here.
Tim replied: “I think it's going to take a while for
that to happen. I remember being on the Microsoft campus in 2001
when they announced .NET and it still took another six years
before developers really largely releasing products in that new
type of technology. It takes a while for that whole group to move
over from what they have been doing to what they're going to do in
the future. Particularly if they have to redo everything in the
process.
Initially, with MSIX there was a lot of that --
even though Microsoft made a good story about how we could take
the existing apps and bring them over. The PSF(Package Support
Framework) wasn't quite up to snuff and that's been a work in
progress and it's improving but it's still got a ways to go but it
really required developers to go in and make some changes and
about a year ago Microsoft announced some changes for developers
that they're still in the process of releasing so this is all the
.NET Core three stuff that ideally is coming out by the end of
this year in a release format and that's really the signal that
gives developers a chance to say okay I can base a product on this
and that's a set of changes. That, at least in theory, allows them
to do a much better job of mixing and matching old and new style
programmings all within the same package. Now, exactly how great
that is on day one it may be like a lot of the other stuff we've
seen. With MSIX where it's going to be some good basic
capabilities but there's still going to be the need to have some
more things added so whether they're going to jump on board and
we'll start seeing a lot of products come out in this way next
year or if it's going to be the following year we don't really
know yet but you know something that's going to come is going to
take time and it's even when the capabilities are all fully there
it's probably still going to take another you know five years for
the vast majority of applications to be released by ISVs into this
format but clearly is something that's coming everything Microsoft
is doing that is new for the programmers is in the newer
interfaces that will require them to go this route.”
Bogdan replied: "Let me start with addressing the
elephant in the room.
Even though Windows 10 comes with a
lot of built-in apps packaged as MSIX, everybody wants to see more
MSIX apps delivered by Microsoft, and the number one app everyone
wants to see is Office. But let's be honest, Office is not a
simple elephant, it's a freaking mammoth, folks, so for those of
you that have used the App-v version, I'm sure you remember it
took a while for Microsoft to deliver it as an App-v package -
it's not something easy, but we know they are working hard to make
it happen. They've learned a lot from the previous experiences
with application packaging and deployment, and we need to give
them time and feedback to properly build the MSIX engine without
forcing them to take shortcuts and give us custom actions or
something wilder like we have for MSI's.
If you want to
see a detailed list of what's on the MSIX roadmap and even add
your own suggestions, we recommend going to the link. There you'll
find the list with the most requested improvements where you can
upvote them and also the backlog of the MSIX team from Microsoft.
So, there's no simple answer to what they should improve
short term and long term. If you go to the Office package,
obviously, once we'll have Office as an MSIX, we need to make sure
that all the Office add-ins work properly, and that's probably the
biggest challenge that Microsoft has right now with packaging it
as an MSIX.
There are other app communication challenges
that the MSIX team is facing, so we're pretty confident that we'll
see major improvements in this chapter in the following years.
It's been only two years, I think since MSIX was
officially announced, and already the platform is a long way ahead
in adoption and capabilities. "
Bogdan replied: "This is a classic challenge that's
hitting us every time we need to get out of our comfort zone. By
us, I don't mean us as Advanced Installer, just us, as normal
people, when you need to learn something new. Even at Advanced
Installer, we had similar talks about our involvement in
development resources for MSIX.
Some colleagues believed
that we were investing way too much development time into MSIX
with very few people using it. Two years ago, a fourth of our team
was investing their full time on this, and even now, when we have
even more resources on this, the MSI is still the main package
delivered by our customers.
You have to start from
somewhere; if you start, this will allow your packaging team and
your deployment team to familiarize themselves with the technology
stack, discover the most common problems, and establish mitigation
protocols.
Every organization has a small set of
non-critical applications that can be easily converted to MSIX and
another set that requires a little bit more work to get things
going.
Obviously, you should start with the easy one -
this way, you learn to tooling, and then you also upgrade your
skills along the way.
If you look back on deploying MSI's
or App-v packages like ten or twenty years ago, it wasn't that
straightforward as it is today.
All this technology also
started in a hybrid adoption model, so you were still using the
old script way of packaging, unzipping applications. Then you
started easily packaging MSI's or repackaging all your
applications and so on.
Any new technology requires a
gradual adoption, and we must be patient with MSIX, too, but keep
in mind this MSIX is here to stay. This is the future of
application packaging, as stated by Microsoft. They are investing
a lot in its development over the last two years.
As I
said, they've been delivering major improvements, and they
continue to do so. It's very important that, while you are
starting to use MSIX, you will have problems or questions just
like the ones that you're sharing with us today.
Remember
- always share these questions on the MSIX community at the
techcommunity.microsoft.com/msix.
This is the best way
for MSIX to evolve - where you, as an end-user, come in with real
questions or scenarios, and Microsoft, together with partners, can
learn from your experience and improve the technology.
Otherwise, they would be just guessing from Microsoft's product
management teams and not that much involvement in the development.
But I'm sure that you guys have a lot of questions and a lot of
scenarios that need to be covered, and so far, the engagement of
the end-users and those community forums has been great. We've
received a lot of good feedback to improve the tools and
Microsoft's platform.
Tim replied: “MSIX uses a very similar format to the
UWP format, it's also very similar to the App-v format in all
cases. What we have is a basic zip compression with an internal
manifest file. Unlike the traditional MSI style of installs, the
installation doesn't necessarily drop things into various system
registry locations and certain file locations. Still, the manifest
is really the piece that defines how this application gets
instantiated when you install it, how it gets integrated with the
user in the operating system.
So all of them share that
common style of doing it. This is the modern way of installing.
The difference between the technologies is really what's in that
manifest. And all of the manifests are built on a basic app x core
in terms of the schema that's available. But App-v has an
extension to the schema that is quite broad and covers a lot of
different integrations, and MSIX has a today smaller integration
set. It's a different set of extensions of how you describe the
way that the application interfaces. And when MSIX first started
came out a couple of years ago, that extension was a little bit
smaller. Still, every six months, Microsoft is coming out with
more and more extension schema to enhance the capabilities of how
these applications integrate the idea.
As we start
looking at things like RDMS, and you talk about App-v, one of the
big reasons that customers use App-v in a multi-user scenario or
VDI scenario is to get that really fast publishing time. MSIX has
something that's called "MSIX AppAttach," which is Microsoft's
solution to do the same type of thing with the MSIX packages.
So that's something that I think I saw yesterday; maybe
it wasn't even released. It's getting awfully close to actually
being released and what's getting released is the Azure
implementation of that. We expect other vendors to be doing their
own implementations of an app attached for those that aren't
hosting up in Azure, but that's really kind of the future
direction there as well.”
Kevin replied: “With modification packages, it's a
bit of a mess right now. One of the things you got to look at is
if you want to take a store app and apply a modification package,
the management tools don't really do it for you like with SCCM.
You would have to add that in manually, which would mean
you'd have to go to the MS Store, get an offline install of the
app, and then put it into SCCM with your modification package. But
then, it also comes down to what you want to do with your
modification package. So, if you're just making some settings
modifications, probably is not a big deal, but the big thing is
looking at the file system because if the vendor did not package
the MSIX package as a VFS package, then the modifications to the
file system may not work out so well.
Microsoft may need
to fix, but this comes down to how the package was actually built
by the vendor.
The management tools should be better at
dealing with the modification packages, but it doesn't seem to be
fully mature yet. I think the management tools have come a long
way and provide a lot of the functionality you need, but I think
there are some rough edges we still need to look at. “
Kevin replied:" So this is a tough one because
ideally everything's going through the MS Store, and we're going
to have applications that are going through a vetting process with
Microsoft as they go into the store - and that's a trusted model
for delivering your software.
The biggest issue with the
Microsoft Store I find is that if a vendor makes a release
available, there are some delays in getting it through the store
ecosystem. The other piece you have to look at is, if they sell
their app through the Microsoft Store, the software vendor is
taking about a thirty percent commission of their software that
goes to Microsoft.
Now Microsoft is just not simply
cutting a check like they are providing a service with the Windows
Store, but if it's a ten-dollar app, thirty percent it might not
be a big deal.
It's gonna come down to where the ISV
feels comfortable because you have the app installer method that I
included in the book, and I'm really wondering how many software
vendors are going to say: "No, forget everything! I'm going to
manage my software releases", and it's going to be done with the
app installer".
I'm not sure if enterprise shops would
really accept that, but I could see software vendors wanting to
use that distribution method for their application. Otherwise, we
could see a lot of MSIX packages being handed over for
distribution with Configuration Manager or Intune.
Those
methods may be the path of least resistance for some vendors.
I deal with iOS and Android, and I can't believe the
number of small developers that hand me applications as a file and
say: "Please, go deploy this". I have to educate them on how they
integrate with the store for those platforms to get their
applications properly distributed. Windows is unique because, with
Windows, an MSIX package is basically deployable. I know there's
some stuff with signing and all that, that you have to consider,
but for the most part, it's deployable.
Bogdan replied:" Integrating with Shell Extension
was always a challenge for virtualized applications, and MSIX is
no exception as we can all see. Obviously, we don't know when
Microsoft will provide us with a solution; even when they provide
us with a date, that's usually not the real one. So far, we
haven't seen any updates on this one.
We know for sure
that this is a topic well-known to them, and they are working hard
to provide us some solutions.
So far from our tests,
we've seen that we can only define a shell context menu, and by
context menu, we refer to a menu that has as a target an EXE
application. So, that's defined in the package manifest of your
MSIX package. It didn't work out in any of our tests when we tried
to define a shell extension where the target is a dll. You can
read more about this experiment on advanced installer dot com
slash msix context menu . But, so far, this capability is a
missing feature that we've all been hitting into it."
Tim replied: "To be clear in terms of the context menus,
what Microsoft has in there is support for file type-specific
context menus. If you right-click on a .zip file, the context menu
for that works in the shell extension. What doesn't work is the
wild card - so that you can right-click on any file, which is
probably the most important shell extension on the context menu
for an app like 7-zip, and that's what's missing, and that's what
they have to add in and. Given how they build MSIX, it turns out
to be one of the more difficult things for them to change, even
though it is like a three-character change in a schema. It's still
going to end up involving thousands of people over a long period
of time for them to fix that."
Bogdan replied: ”So, first of all, just to make it
clear for everyone because we've seen this confusion in some other
questions. PSFTooling is a separate tool built by Tim and is not
part of the Advanced Installer or its functionality for the Packet
Support Framework integration.
Now, back to the script
support from Advanced Installer. At the moment, you cannot add
scripts automatically when converting an MSI or EXE to the MSIX
package. After the conversion, you need to open the Advanced
Installer project, go to the AppCompat view and manually add the
script using our user interface.
We'd love to learn more,
to understand why you want to automatically add, probably the same
script, I assume, or some slightly modified script. So, please
email me at the bogdan advanced installer that's my first name at
advancedinstaller.com with more details - why you need to do this,
and we will gladly evaluate it.
Tim replied”: PSFTooling is a separate thing that I do,
and it is a tool that you would use if you were doing your
packaging using the Microsoft MSIX Packaging Tool. If you're using
Advanced Installer, they have equivalent functionality to do
things of bringing in the packet support framework.”
Tim replied: ”It eventually might be possible if
anyone has worked with PSFTooling for a while. You've seen a
constant update to it where we really start out with some really
raw capabilities that are individual, and we've been kind of
consolidating them and trying to automate that.
Quite
frankly, in the future, I don't look at PSFTooling as the way that
I would want to do that automation process. If you take a look at
some of my tooling for App-v, I have a tool called "TMEdit", and
TMEdit has an automated method - so there's a GUI method, which is
what 99 percent of the people using TMEdit use. They use the GUI
piece of that to post-process edit the package.
What I'm
looking forward to in MSIX is going to that type of thing within
the background; there's also an automatable way. So, there's a
command-line prompt that you can feed in an XML file, and it'll
just automatically figure out what needs to get added into your
package and put in the PSF components and configure them for you.
That's probably more likely what we'll see, but it's
going to take quite a bit of time before I get there.”
Kevin replied: “If you're doing any sort of manual installation, you're basically stuck with elevating somehow. Technically, if you're building a fresh OS, you could use a provisioning package, but you're basically an administrator at that point. You're probably looking at using a management system like Intune or SCCM to auto elevate for those packages that need to be installed that way. By default, you know it will install per user on Configuration Manager and that you have to specifically tell it to install per machine if you want it for all users.”
Bogdan replied: "Of course we can. We've provided
the free book, so the URL is simple. First of all, you can find
the section - which is called "Predefined fix-up" in the book.
There you'll find listed all the fixed apps available for the
Package Support Framework at the moment. There are also a few
paragraphs about each of them to understand how it works and how
you can apply them. A similar list is on advanced installer.com
package support framework introduction. It's an article I wrote
like six months ago, which explains the Package Support Framework
and summarizes the fix-ups list. Now, this list is precise to a
certain level, so we have the fix ups that Microsoft has added by
default in their GitHub repository. Tim actually added I think,
two more fix-ups, one for registering, one for environment
variables on that list. Depending on the packaging tool that
you're using, there might be additional fix-ups automatically
included just when you're doing the packaging. For example, with
Advanced Installer, we automatically detect that you have
additional command-lines or a working directory that needs to be
set for your main application and the other stuff like that or
migrating app data, but that's a different topic. The official
list of fix-ups, as I said, is in the book. Maybe Tim wants to add
more details on his predefined fix-ups."
Tim replied: "Microsoft hasn't really talked publicly at
all about what they're going to do with the PSF. Quite frankly,
what I've seen is that they did the initial development, and
they've really then just dumped it on the community. So I'm the
one that's done most of the work most recently, and I've been
pretty active in adding additional fix-ups as we need them. Right
now, I'm actually putting that work a little bit on pause because
I think we're at a spot where it's probably more important to get
more towards, making the process easier rather than getting more
types of fix-ups. So once we figured out how to make it easier,
then we'll go back, and we'll start retaking a look at it: What
are the other types of fixes that we need to create to be able to
get more and more app compatibility."
Bogdan replied:
"Well, I think we have a solution for the easy part, but we'll
keep it for the next webinar since that's not the topic but just a
spoiler for the folks that are live here. In general, it doesn't
matter what tool you're using; you shouldn't say:" Hey, maybe this
tool doesn't have the latest version of fix-ups". If you know how
to use Visual Studio, you can always clone the repository from
GitHub, build the available solution, and get the DLLs generated
as output, and add them as fix up with whatever tool you're using:
MSIX Packaging Tool, Advanced Installer, Install Shield or any
other tool that you're using to build your MSIX packages."
Tim replied: “The answer is not really. The documentation for the format on config.json is included in the GitHub repository. Now, you don't need to be a developer to understand this part of it. It's really in the READMEs associated with the Package Support Framework up on GitHub. In the READMEs, it shows you the various configurations. So there's a basic overall configuration, and for each of the fix-ups, they have specific configurations. Now, quite possibly Bogdan just wrote down a little note that we should have an article that describes this on my website, and who knows, maybe they'll do something like that for you in the future.”
Bogdan replied: "It depends on the packaging tool.
As I said previously, you can have a shell context menu only for a
specific file type association that you define. You cannot have
generic wildcard ones like 7zips in this case. But if you have
like a generic file association, let's say you're repackaging the
Edge, since we still don't have an MSIX package for Edge, and you
want to associate HTML files with opening with Edge, you can have
the packaging tool to detect this association at conversion time.
For example, Advanced Installer has a high-level conversion of
elements like file type associations or any other constructs that
need to end up in in the package manifest. From what I know, the
MSIX team from Microsoft was working on the smartening up of the
MSIX Packaging Tool to recognize this type of manifest package
resources.
In some cases, you need to manually edit the
manifest and tweak it. In the particular case for 7-zip, as Tim
said, you cannot have a Shell Extension. But in cases where you
know that you have a specific file type association for an
application and the packaging tool that you're using hasn't
detected that you need to manually add that by directly editing
the manifest - if that tool doesn't provide you with a user
interface, or if you are using Advanced Installer by clicking two
buttons. And it also gets synced automatically between MSI and
MSIX build.
If you have an existing project where you
were already building an MSI for that application when you
duplicate that build to create an MSIX, everything is converted
into the corresponding package manifest entries, so you don't have
to manually create them."
Bogdan replied: “First, this is a very good question and I'll add some context for those that don't understand Dan's question completely: when you digitally sign an MSIX package, Microsoft imposes a strict requirement for the publisher of the package to match the public share listed under a certificate, and the publisher of the package is written down in the package manifest. So if you have a set of packages already built, the chances are that they have a different publisher. Is it either matching the publisher of the test certificate used by somebody from the packaging team or matching the publisher from an outsider independent software vendor. What Dan wants now is to automatically update this publisher to match his enterprise certificate, I assume. One solution is just as you said, Dan - you extract the packages, you create a small script that just replaces that line in the manifest, and adds your certificate publisher then, you can use makeappx to basically re-bundle back the MSIX package and then resign it with sign tool. Otherwise, at the moment, it depends on the packaging tools. Now, for example, Advanced Installer has a command-line interface only to edit MSIX projects. So, we have an MSIX editor with a UI that allows you to edit but that doesn't have a command-line interface at the moment, so you cannot launch it from the command-line and set publisher name. If you have a project for the MSIX package, in the case where you are editing an existing project that you're maintaining, you can just run command-line tools command lines from Advanced Installer to just set whatever variable you want from the package and we have a command for the publisher name and then you just execute the build command and it builds the MSIX with the new publisher name. What we do if you use the UI, you'll see that we automatically detect that a new certificate is being set for the project and we try to sync it automatically. I don't think the Microsoft PackagingTool - MSIX Packaging Tool does this but I expect that other vendors will be doing this synchronization in the past because from what we've seen, especially for new people trying out MSIX, this is the top of the list mistake that they do. They forgot to sync the publisher from the certificate with the one from manifest and you can't even install the package and that it's just annoying.”
Kevin replied: “It's coming back to using management
tools and user targeting. That way it does create a bit of an
issue for manual installs that we have to deal with because if the
package requires elevation and your user isn't elevated, what can
you do the interesting thing. I haven't personally tested. What
would be really interesting is to see how the app installer
handles this. I'm assuming it would not elevate the user or the
install but you know that's something I am not 100% certain on, to
be honest.”
Tim replied: “It does, and it does elevate on them, so
you have to have credentials to do it so.”
Tim replied: “Not necessarily correct so when you have some software running inside the container it can start processes that live outside the container and it can run inside the container. So as long as you properly configure the config.json you can also have the intercepts applied to those executables. I do that all the time.“
Tim replied: “Yes that is the direction Microsoft
wants you to go - there's no doubt about that. Is it still too
early though. We are not at a point where we have the ability to
take all of our app packages and turn them into successful MSIX
packages. We can get a lot of applications that we can work well
on. My latest internal testing is showing me that about 60% of the
enterprise app we can get working into MSIX in. What I call full
fidelity mode meaning the same feature set complete feature set
that you would have had natively there's still a whole set that
you can't do so if you're thinking about an entire migration
project we're going to take everything we have and move it over to
MSIX. I'm telling enterprises you're not going to be successful on
that project today you're going to get a lot of good stuff that
works and I would recommend you start that process. Because you
are going to have to learn how to deal with MSIX not just how to
get it packaged. There's all the operational stuff on the back
end. How does your help desk support these apps? You need to start
getting that experience with the simple apps first while the
technology evolves and you can do the other pieces later on as we
get more capabilities.”
Kevin replied: “Yeah maybe I should finally chime in with
a piece I was going to sneak in with Microsoft managed devices.
This is kind of hitting organizations in weird ways because
Windows 10s mode has been viewed as largely a joke but the fact of
the matter is it's an extremely stable secure well-performing
platform if you can get there. But the big thing is - is getting
your apps onto that device. Now it's very strict - so you're
either going to use VDI and remote the apps into the device or
you're going to figure out how to package these apps as MSIX apps.
And it's funny to watch because if you look at it from a technical
point of view customers just turn their noses up at the whole idea
of what you're proposing. But you start looking at Microsoft
managed services - now I'm not trying to sell Microsoft managed
devices because you can do something very similar yourself - but
you know you look at how they're selling the hardware, the
software, the support - everything for a low low price. A manager
looks at that low low price and he goes hey I want that and so
then all of a sudden there's this motivation to make some tough
technical decisions about what you do with your apps. So when it
comes to - are you ready for migration - I guess I should address
the question which would be yeah you should be prepared for this.
Like it could flip on you pretty fast. I’m not saying you could go
Microsoft-managed devices or Intune or modern desktop overnight
but all of a sudden a business unit or a user group all of a
sudden flips over because they're a good candidate. Now you have
to support all that, so I agree with Tim that you have to be
prepared; this is something that could sneak in and yelvason have
to be an expert.”
Tim replied: “I guess I didn't answer the first part of
that question about migrating the app packages over from a batch
conversion. I mean, there is a command-line interface the
Microsoft Packaging Tool can convert things over Advanced
Installer has the ability to convert things over but that
conversion is a pretty basic conversion in general. You're still
going to have to do a lot of hand massaging particularly if the
app would end up needing things like the packet support framework.
So it's not just a quick flip of the switch and suddenly your
package works as an MSIX package but there are tools there to
help.”
Bogdan replied: “Everything that's custom made can be a black hole. At a certain point, Microsoft is striving very hard not to get to that point, especially to stay very far away from where custom actions ended up being for the MSI. And even in that context, everything that is launched by the PSF runs in the container content context. So it's fairly secure because it's contained inside your application and shouldn't have access to information from other applications on your system. If you elevate your applications, so somehow you allow your users to elevate your application from the PSF launcher, then probably they could do a lot more damage with some black box script in there, but if you just keep it clean to a script that handles a license file or some id configuration, something that you need to be handled by the scripts, there shouldn't be any black box. It's a partial script, it's visible in the package so it's very easy to inspect what's in there and it should be pretty safe as long as you don't push this too much. I see this because PSF scripts are practically intended to be used mostly by IT Pro, so we don't expect, we don't have an official answer from Microsoft but we don't expect to see applications published in the Microsoft Store that use PSF. It doesn't make any sense because PSF is intended for applications that are no longer maintained, no longer under active development, so if you are an ISV who does active development then you just fix the app itself and make it work nicely inside MSIX container. So it's also related a little bit to self-control, I could say here, and if you impose the right standards in your packaging team, there shouldn't be any problems with this.”
Bogdan replied: “ I assume that there are others like Robin that are confusing and believe that the output generated by Tim or by Advanced Installer or by other packaging tool is different. And that's not the case. So the PSF framework is a standard that is employed by all the packaging tools. What's different is that some tools could provide additional fix ups but they all leverage this same architecture, they all connect to the PSF launcher in the same way, so if you write a PSF fix up, all and you just want to add that in a package built with Advanced Installer or the Packaging Tool and the PSF tooling from Tim, it should work in the same way as long as you correctly configure the config json. So there is no difference in that. The only difference is in how easy the tool makes it for you to realize what fix up your application needs and how easy it is to add that fix up into the package. Once you start using it, I assume that you probably haven't added any PSF fix ups at the moment, Robin, once you start adding a fix up into your package you'll see that that's the difficult part to understand “hey I need a fire direction, is it failing to load my DLL from a relative directory “ or something else like that. That's where different tools treat this differently and. We'll have a separate webinar probably at the beginning of the next year where we'll show you some cool improvements that we have for the PSF support in Advanced Installer.”
Tim replied: “Microsoft has talked about that
feature. They've used different names for it each time I've heard
them talk about it and it's something we expect to see in the
future I’m hoping the near future. There clearly isn't any support
for that, that I can find in the h2 release of the OS this year,
so we'll be taking another year out, and of course then whenever
you actually deploy that version of the OS as well. So they still
have some work to do to get that out to us, but there is that idea
that we'd be able to have multiple independent packages all joined
together to run inside the same container. We even heard Microsoft
on stage at Ignite talk about it in a way, where they said you
could just take all your MSIX packages a user if you wanted to, so
they are definitely working on that we just don't know when.”
Kevin replied: ”Yeah, that's an interesting comment
considering connection groups were a little bit touchy depending
on how much you strung together.”
Kevin replied: “This is a lot like App-V. Basically, you can interact with the locally installed applications where it falls apart is when the locally installed application needs to access a resource like a file or a registry key that's inside the MSIX package. That integration doesn't work so well, so it depends on what you need to accomplish. I’ve seen applications do all sorts of ways of interacting with, like Adobe readers. Most of them are smart and they just hand over a file but I’ve actually had an app that actually looks for the adobe reader com object and checks the document across that way, forcing you to have Adobe reader installed locally. So well actually no later versions of App-V you could expose that comm interface but anyway that's a bit of a rabbit hole. The thing is that it's probably going to be a reality for making some of this stuff work because I don't know what mixtures we're gonna see on the device of locally installed apps and MSIX apps. Ideally, everything would be MSIX and they would be talking to each other in modern ways but there's just so much baggage with old apps that we have to deal with. I don't know, it depends on the industry and the job function like some of the worst integration scenarios I saw were in the oil and gas companies because they had engineers that were using like four to five applications that talked to each other but weren't all from the same vendor and you had to package that up with that App-v that that that that made for some interesting situations.”
Tim replied: “We're really kind of going to the
basics which we kind of skipped, we sort of assumed everyone
understands the basics but from a basic standpoint, you know why
MSIX and I think we should kind of address that a little bit. It's
very clear to me that MSIX, in the long run, is going to be a
better way to be deploying applications. If you look at the whole
evolution of the computer industry, you know we really started out
with these single-user computers, and we did have no separation
between what a user could do and what was protected for the
system. Over time, we had to evolve that and separate out the
kernel from the user, and then add multi-user in it and separate
the users from each other. This is really just part of that next
level of evolution, of isolating down at that app-level and making
sure that our systems are secure and that we can update and we
don't have to throw away the entire image every year and a half
just to get decent performance out of our system, so that's the
entire goal out of all of this in the long run - to make our
systems better and we have to go through a little bit of pain to
get there. I think it's really going to be worth it in the long
run. From a business today, what I'm telling my customers is:
‘Look, MSIX is the future, the app development world is my mind,
definitely gonna go there’. Eventually, it's gonna take them some
time to really get there, but they're gonna get there and you're
gonna end up dealing with MSIX. I don't think you can just totally
ignore it, but if I gotta deploy out a thousand new applications
next month I'm not gonna pick MSIX as a way to do it - that it's
gonna be a little more work, and some of them aren't gonna work. I
view App-V as the technology that can probably do most of those
applications today, and it can't do all of them. There isn't any
single technology that can not even the MSI, so you have to end up
with a mixture of these things in your environment.”
Kevin replied: “My personal opinion is Windows is slowly
evolving to be a phone OS, and that means you have MDM, you have S
mode, you have MSIX applications. Basically, you want to make this
thing as stable and rebuildable as possible, and you know, you
just see how Microsoft's trying to shed legacy components. It's
going to be a long journey because Win32 APIs are going to be very
hard to kill off, but Microsoft's moving that way. When we can get
a proper S mode device with modern apps it's a very different
experience with Windows than we have today. I wish I had my own
data but Microsoft with their users that are using modern devices
they're saying that they're getting a lot of positive feedback
from the user experience. This will be interesting to see because
ultimately, you need to get the apps on there to have a happy
user. Right now, it's a very small group of people that you can
focus on this modern vision but it will grow and it will generate
demand for modern apps.”
Bogdan replied: “Definitely and maintaining Windows 10 as
a service practically with a bi-annual updates model it would be a
challenge if you wouldn't start adopting a modern packaging and
deployment framework around it because as Tim said you don't want
to do imaging all day long.”
Bogdan replied: “We have to mention that these are
separate tools, so Tim has its own tool, Advanced Installer has
its own licensing system agreement. For Advanced Installer you can
simply go to Advanced
Installer Purchase and you'll see all the editions
available there and the pricing, and it starts from 499 and it
depends on the features that you need. For TimEdit I really don't
know at the moment to be honest but I think you can email him and
he has more details on that.”
Tim replied: “It's also directly there online, you can
purchase it online so go to tmurgent.com
for that one.”
Bogdan replied: “What I can tell for sure is that
Microsoft wants to keep MSIX apps in running user mode only, most
of the cases. So besides some exceptions like the MSIX Packaging
Tool, which requires elevations and other special tools dedicated
to IT Pro, their idea is that they don't want the MSIX container
to install machine level resources. We've seen not the best,
perfect hack with the solution they provided for services now, in
the latest updates, I think it was six months ago, but we don't
expect to see something similar with drivers. We don't have any
signals from them but from the initial announcements they had in
the first year of MSIX, there was a clear, strong message from
Microsoft saying that drivers should be deployed through the
Microsoft Store and not as part of an installation package.”
Tim replied: “Microsoft's answer with drivers right now
just doesn't really work, so they're assuming you could trigger
it. The idea is you could have it marked inside the package and
say hey, I need this driver, but you have to deploy that driver
through the Microsoft Store or potentially a WSUS server. Although
I'm not quite sure that that ladder actually has support for it in
there today, which means the driver store is really missing, and I
think it's something that Microsoft has to continue to try to
address going forward. As far as the overall extensions within the
product, clearly, we don't have everything that App-V has today,
but we also have some things that aren't there in App-V. We don't
necessarily trigger those things with traditional exe based,
dot-net framework-based apps, but these are the things that
developers are wanna add for the future and that's where we'll get
extensions that do things that we really can't do in App-v today.”
Tim replied: “Yeah, I am planning, so for those who don't know, I have a site m6conf.com where I post the MSIX report card, and I've done this for the last two Januaries up there. It provides an overview and includes a lot of testing of normal enterprise applications, so I think I had 60 in it last year. My current testbed has, I think, 65 or 66 in it. I did do some preliminary testing this summer, working with the 2004 os, and I can tell you that's where I saw some much better numbers. I was getting up to almost 60 percent compatibility. I am planning to do that work again. I am behind schedule; I should have already started it, so it might not hit January, but at some point this winter, I do intend to have another version of that report card out.”
Bogdan replied: “My idea is that, first of all,
because you're running as a containerized application, this
changes everything. As Tim said in the past, with MSI or even
before MSI, the application was having access to all the resources
from the system, and that made it easier for the development team
from Office to create a package, and I can bet that in the first
edition of the MSI where they lacked a lot of support for native
integration with the system, they basically added a bunch of
scripts and custom actions because they could do that. Now there's
no longer the case for that, so they need to play the clean game
from the beginning, and that's why it's so hard to get the Office
suite inside the MSIX package, especially the Office add-ins.”
Tim replied: “Fortunately, I am an MVP, so I'm sometimes
subject to seeing some things that I can't talk about, but in this
case, I've actually actively avoided talking to the Office team
whatsoever, so I can speak openly to what I think. Office is not
just a single thing, it's a whole series of products. If you just
take a look at the way little things like the ribbon got added to
Office, it didn't just hit all of Office, it hit one product and
then hit another, and then hit another. I think when it comes to
MSIX, Microsoft is faced with the same sort of thing. They have
completely independent teams that have to do this work. Quite
frankly, given the way that Office components integrate together
themselves, they probably need that equivalent of the connection
group, so it can all run in a single container when it happens. So
we may end up seeing parts of Office come out in MSIX but not all
of it, and it will be a little more limited initially, but over
time clearly, if Microsoft wants the industry to move to MSIX,
their platform product Office has got to get released in an MSIX
format.”
Kevin replied: “It is, you have to eat your dog food, and
it's funny because with s mode right now they're faking the modern
Office bits, so they really need to complete that vision.”
Kevin replied: “That would be a bad one, I think. I
don't know, I've never tried Internet Explorer 11, but no, you
need an external target - that's not even supported in MSIX.”
Tim replied: “Right, there's really no way to do that,
and I don't see any appetite in Microsoft to try to make that
work.”
Tim replied: “Quite frankly, you have your choice
there. With App-V, I have a tendency to keep dependencies inside
the package so that everything is all in one place. I know Kevin
has, even under App-V, a very different attitude towards that, and
I think folks that are deploying through Configuration Manager
tend to feel more that way; you want to separate out dependencies
and manage them separately. With MSIX, we again could go either
way. MSIX does have a nice way inside the package to reference
dependencies that are also MSIX things as well, so we can make use
of that capability, and that's one of those things that we haven't
done a lot with yet, but I think as we get more and more things
under MSIX, we're going to want to do that. Ultimately with MSIX,
if I put that same dependency in more than one package due to the
single instance storage nature of MSIX, we're not really bogging
down our systems, there's really only going to be one version of
that component put down on the system.”
Kevin replied: “That's true. I was wondering about the
dependency packages because, right now, it seems people are using
it for run times and stuff like that but lacking my packaging
expertise with it, what was the potential for the dependency
packages? Could I say, make an Oracle client an entire dependency
package?”
Tim replied: “You could, the issue becomes really, quite
frankly, the tool support to make it easy for you to put that in.
You'd also have to make sure you're still going to need to deploy
that dependency through a Configuration Manager or an Intune as
well, so you're still going to have to manage that process. It's
not going to automatically happen but the package install would
require that piece to be in place.”
Kevin replied: “Okay, I was just unclear if the
dependencies had to be obtained from Microsoft or if we could
actually build our own.”
Bogdan replied: “There are very few ones you can obtain
from Microsoft like the Visual C++, register bootables...”
Bogdan replied: “First of all, because when you're
packaging the app, you end up with a containerized app, you should
be very careful with apps that communicate with each other by
sharing files for the registry - that will be the problem number
one and, especially with older apps where developers weren't using
inter-process communication or other ways of communicating with
the apps, because now you have app services and Microsoft
recommends that you update your code to leverage these frameworks.
So sharing interrupt communication using shared files or
registry is one thing, and another one is drivers. Anyway,
probably you'll have some apps that try to install machine level
resources like drivers or services - it was recently added support
for services.
You need to be careful with what version of
Windows 10 the clients are running inside because the latest
features supported by MSIX like services or some improvements,
such as improvements to the shell extensions, will not be backward
compatible with all the versions of MSIX.
Very few
features that Microsoft introduced work backward compatible with
the first version of Windows 10 that supported MSIX. So, assuming
that you will need one or two more years to get up to date, the
timeline is like, I think, 18 months; you cannot be on an older
version of Windows 10 that's 18months older. So it takes between
one to two years to get there. Make sure that when you're trying
to use the latest features from an MSIX platform, you have the
Windows 10 up to date for the entire department where you plan to
deploy those apps.”
Tim replied: “If you're doing repackaging for a customer,
most of the customers that are going to use an external packaging
company are going to be these larger enterprises that have a lot
of the older legacy applications. That's my experience, and those
are the ones that you're going to have the most problems with. So
you're going to have to manage that process with the customer to
make sure they understand. You're not going to be able to do
everything, the technology is just not ready to do all of their
apps. but we can do some of them if you really want us to do that,
you're going to have to really focus on that testing and you're
going to need to work with the customer to find out what level of
that, what I call application fidelity do they need. Do they need
every single feature to work exactly the way they worked before,
or can they live without this shell extension that's not going to
work here? So I normally look at smaller, more agile companies
that are not risk-averse as being better candidates for that, than
a larger company that has lots of things like change control
boards that get involved. Those are the companies that are going
to have applications that are going to pass that smell test and
are going to need more time before MSIX is ready for them.”
Tim replied: “AppAttach is about rapidly taking the
MSIX packages and making them available particularly for instances
where the user is logging in or getting deployed upon login, so it
speeds up that process. It basically involves converting the MSIX
package format into a slightly different format, but it's still
running inside the container, so there is no difference. It's just
how does it get down there and it acts a little bit more like a
layering solution, or from those from APPV may be looking a little
bit more like the shared content store mode, so that the actual
bits don't have to come down to the virtual machine that you're
running the application on. It just redirects remotely in the
background to get access to the bits as it needs it.“
Kevin replied: “Hopefully, they'll create more demand for
MSIX packages to be put into VDI. I know VDI folks are excited
about it, but again we need apps.“
Kevin replied: ”AppAttach would not use Intune for
management; it would be separate from it.“
Tim replied: “It would be technically possible even
though they don't necessarily have an interface today, would be my
guess, as long as we're talking about Intune for VMs running
inside the data center.“
Kevin replied: “So that's the thing now, you can run VDI
(Virtual Desktop Infrastructure) managed with Intune, which I
think is kind of a cool idea, just from the fact that your VDI
servers become zero trust entities, which means that if one of
them got compromised you can't just leap across to the next Citrix
server from there - it limits your lateral movement. Anyway,
because of that, you're joined to Azure AD (Active Directory),
your authentication is a little bit different, but I think you're
okay with AppAttach. You would probably have to manage AppAttach
not through Group Policy - they are putting something in the GUI
for WVD, but I’m not sure how that works. Our book's Group Policy
method would definitely not work with Intune managed devices
unless they had a hybrid identity and were actually joined to
Active Directory.“
Bogdan replied: “From what I know that's the case.
Before this, it was only insider previews, so I think that was the
first public release.”
Tim replied: “There's a dependency on there in the
PowerShell interface for sure, as well as I believe, the
underlying app installer. So while maybe the app installer piece
on previous OS’s, I think that PowerShell end of it for the new
option they added, is a requirement that you really can only get
once you get to that version of the OS.”
Bogdan replied: “We know that we, at Advanced
Installer, extended the Microsoft fix app that allows the windows
host to basically load HTML files. We had a customer that
contained HTML files inside his package with documentation and
those were practically not found by the external process of his
browser or his default browser, so we needed to create a
redirection for that so the HTML files could be loaded. In this
case, if it's just a link to an external browser. Have you tested
that Tim?”
Tim replied: ”That's just really using the launcher to
use the PSF launcher to do a shell-style launch. So then you have
to have it tied, and then, even if it was a web page that was
within the package itself, you can construct it in a way. That
pretty much should work. Certainly, there are going to be some
cases of things that people want to put in there that aren't going
to work, but generic simple things, absolutely that's going to
work.”
Kevin replied: “Isn't containerization still kind of
considered app virtualization, or are we split?”
Tim replied: “I consider it app virtualization, yes.”
Bogdan replied: “And the developers that need to fix the
app consider it virtualization too so..”
Kevin replied: “I guess also Robin asked about app attach
on non - WVD (Windows Virtual Desktop), and I think it works
without WVD if you use the group policy method.”
Tim replied: “The WVD that Microsoft is doing is really
the management piece on top of that. There are quite a few
well-known script methods to be able to do that yourself locally,
and you can be sure that vendors who've announced support for MSIX
such as Citrix and VMware are doing their own management interface
on top of that as well but still using that basic app attached
style of capability.”
Subscribe to Our Newsletter
Sign up for free and be the first to receive the latest news, videos, exclusive How-Tos, and guides from Advanced Installer.