Bob (00:07) Hello and welcome to the App Management Experts podcast, where we discuss the latest news, developments, and ideas within the application management space, often inviting industry experts to join the discussions. This podcast is for digital workplace managers, application managers, IT professionals, or anyone with a focus on applications in the enterprise. I'm your host, Bob Kelly, and I'm joined by my colleague, Kiren Mantagi Between us, we have multiple decades of experience in application and desktop management and spoken to over 100 enterprise customers about the related challenges. We'll lean on
that experience in these sessions to foster interesting discussions, and we're glad you're here to join us. Now, on to today's episode. Bob (00:57) Okay, let's get started. This is first episode of the App Management Experts Roundtable. I'm your host, Bob Kelly, and I've got my friend and colleague, Kiran here with me. And in this session, or this series rather, we're gonna be doing talks just about technology, packaging, app management, trends, new things happening in the market, and hopefully bringing some interesting guests from time to time.
And I'm very happy to have with us for our initial series here, Tim Mangan. Tim, great to have you. Can you please do a quick intro for us? Tim Mangan (01:36) I'm Tim Mangan from TMurgent Technologies and I'm kind of the AppV and MSIX guy. Bob (01:43) Yeah, that's a good way to put it. You've written a number of interesting books. I had the pleasure of a foreword on a
recent one that I thought was really cool. It's a book on application, how applications work. Tim, I think you have a unique perspective, Tim, because you kind of have a developer background, but you're also like an IT pro. And I don't think a lot of people have both of those perspectives. I'm sure it comes from your, you know, the AppV the, you know, focus that you had. Tim Mangan (02:20) Yeah, I basically lived the way I put it. I've lived the last 25 years sort of in between the application and the operating system. That's a very narrow space there.
Bob (02:29) Yeah, yeah, that's what made that book so interesting too, because it was a lot of very developer heavy topics, but written for an admin audience. And so I find it pretty enlightening. Kiran Mantagi (02:30) Thank It's an interesting perspective because when you look at something from a developer point of view, it is engineering. And when you look at something from an IT pro point of view, it becomes reverse engineering. So you have to think back and forth. And it's difficult to get both of those perspectives. So it's great to have somebody like Tim on the call today. Thanks for joining us, Tim.
Bob (03:02) Yeah, for sure. MSIX, obviously a topic that you've been knee deep in for a long time and we've had our hands in it for quite some time as well. it seems like the momentum is kicking up. Thanks largely in part to your own efforts. then, so we said, you know, let's talk about it. Let's see where we are, what we're hearing from customers and from the market, what you're hearing in classes that you're teaching, in places that you're speaking. then the App-V news kind of dropped very recently on top of all this, which really ties things in.
Well, first, maybe a quick summary of where things stand for anybody that's not caught up. Tim Mangan (03:52) Well, for those that may not know, App-V has been around forever. We built the original platform in 2000. Microsoft acquired and renamed it as App-V. And they've been basically giving it away to enterprises for years and years. And it's been on its death rows for a long time. Microsoft has been saying that they're going to deprecate it, it's going to go away, there's no guarantee it's going to go beyond an X period, and finally they got settled on April, 2026 as being the last day that they would provide any security support. And it sounded very much like that was it. That was
the final and that customers needed to get off of App-V before that time. And then on the first week of December, they suddenly changed course a little bit. And, the way that I have been referring to people is sort of like, App-V has been on death row. And the governor came in at the last minute and, put the execution on stay. it's not a commutation of sentence. It's just, it's on stay. we believe
that because App V is part of server 2025 next year that now that comes with a five year, plus a five plus five policy there. that App V should probably be around for a while. But the real driving force for the decision appears to be for Azure AVD, Azure Virtual Desktops. And that's the main reason that that decision got made was that AVD needs apps and they were seeing customers were struggling getting enough of their apps working in MSIX, which is the only way to get them into AVD at that point. So they need to be able to expand that. And so they...
They took out all the deprecation notices. They're supporting App-V as part of that service now, as well as some other formats. They also announced at the same time. So they're really trying to make a big play to get AVD to be able to get more volume and more customers in there. And I believe that that's what's driven
that answer. And it makes me a little nervous for those that aren't on AVD. So it's not... Everything that the customer wants are going to be no new features, no big fixes out there. It's security updates only for App-V going forward. And I think over time, we're going to see that you need to kind of move off of App-V, but the pressure's off. Bob (06:35) Hmm. Yeah, it's
interesting way to play it. Microsoft's part. would, because they're not saying that MSIX is not a replacement for App-V anymore. They're just taking their foot off the gas, I guess, and saying no rush, which is a odd approach. Kiran Mantagi (06:54) that was my question. think you kind of answered Tim, that I was wondering if they are keeping it alive, then maybe they would keep adding enhancements or improvements, but it's clear they're not going to. Now that makes me think with so many technology improvements, there is a new version
of .NET Framework, a lot of other things. So as in how you go in the future and you build apps on these modern technologies, how do you think they would be compatible for App-V? I know it's good today, but as we go in the future, we are talking about next five years. Tim Mangan (07:24) It's, it, well, well, you know, it's good today, but I've already started to see, some of the newer applications out there and there starts to be challenges in getting them, properly deployed through App-V. So over time that high level, you know, that, that I normally see high level of compatibility for applications of App-V that's going to start to drop down.
Kiran Mantagi (07:45) So that should be like a warning for enterprises who are in the middle between MSIX and App-V and they're at a point where they want to decide, with this announcement, do I want to continue with App-V or should I move to MSIX? What do you think would be the right path for them? Tim Mangan (08:04) Yeah. Well, my take is that you should be starting that motion, that, you eventually are going to need to make that move. You're gonna eventually we'll hit that tipping point and we're getting better with MSIX every year. If App-V starts to drop down, we're going to reach that point. I reached a point in October, which was before Microsoft made this announcement that said that I think MSIX is now ready to be your first choice going forward that an enterprise can.
Kiran Mantagi (08:18) Mm. Tim Mangan (08:32) very easily make that decision. I want to go MSIX first. And then for those that don't work, I'll have to do something else with those applications. With this announcement, I think I don't really change that. I think MSIX is ready for that. And I think if you're ready to
be making those moves, then you should be doing that. If maybe you have other things that you have to do this year, like maybe complete that Windows 10 to Windows 11 migration. Well, yeah, you probably should be focusing on that first, but eventually, yeah, you're going to want to kind of go there. see Bob has put up the chart that I
provided. This is showing how I measure the application compatibility, right, between the two technologies. And this is what I usually, whenever I show numbers like this, I like to explain this is my high fidelity model, which says that what you see there in green, Kiran Mantagi (09:03) Yeah. Thank Tim Mangan (09:27) is something that if you deployed the native application from that EXE or MSI installer and you gave the end user this package, could they tell the difference? And if the answer is no, then we give it that green color. And that may be a little different than numbers you hear from the vendors directly that are supporting these technologies. Usually it's more of a smoke test. Hey, if I launch the app and it works, it's compatible.
There's often little things that may be very important to the user that are missing in that application. So, this, that high Fidelity battle and traditional number for, for App V quite frankly, it was 98%. this is a number there was from my report card that I produce each year in January report card for MSIX. and, the number dropped down this year, but it actually dropped down in part because of what I just mentioned that we're starting to see a little bit of. Kiran Mantagi (10:12) Thanks.
Tim Mangan (10:24) a rot in there with some of the newer apps. But quite frankly, I added a whole bunch of applications into the mix this year. And I only gave AppV one shot. I didn't try to troubleshoot any of them. So the number dropped down to 91%. It's probably more like 95%, I think would have been the realistic number if I'd spent the time. And then we had the 82 % for MSIX. Again, this was last January. My preliminary numbers for next year's report, I ran last month. And it looks like we'll be at 90 % with MSIX this year. So we're continuing to move that bar forward each year as we move along.
Bob (10:59) Your testing is an interesting thing to maybe touch on for a second, because you're not just taking 10 random applications. You've found things that you know will be difficult to stress the system, as well as some things that can work. So how representative of a typical environment, with the feedback that you've gotten, is this fair or are you the test pretty hard? Tim Mangan (11:25) Yeah. So, the, I'm making the test pretty hard. I is the full criteria of what people would want. I mean, you you've got, the 115 apps in this year's test set right now. I don't know if I'm going to add any more before the end of the year, but right now that's it. But you know,
it's got, two or three versions of AutoCAD in there. you know, it's got SolidWorks It's got, TechSmiths Snagit program, is just a nightmare in itself, right? So, you know, lot of apps that I have seen from my work and training customers on how to do the packaging. So the, a good sample of the apps that they have, as well as some custom things that I made myself applications specifically to test.
Kiran Mantagi (11:59) and Tim Mangan (12:20) different parts of the technology so we would know that this particular area is working or not. Bob (12:25) Yeah, because a lot of times the applications that people are trying to package and deploy in the enterprise are in-house applications that are no longer really being supported or old legacy applications that may not have licenses for, or they've gone end of life, but they're still being used. Those are the nightmare packages, right? But for the most part, new applications, if you're getting the latest version of something to get the most secure version and it's available and supported, then... your success rate on both parts should be relatively high. Tim Mangan (12:57) Yeah. Bob (12:58) Yeah, we're really at well, you know, the podcast here is really meant to be more technology focused and not product, but at Juriba we are working on kind of automation as a challenge and coming up with ways to automate everything that is automatable when it comes to the whole packaging process. And that includes testing. And of course, for
MSIX that has to include PSF because it's just needed so frequently. Here's another kind of slide that I think you shared that helps illustrate this. Tim Mangan (13:38) Yeah. So, you know, as I look at the applications, there are some applications that are just, they're good apps, you know, you can package them up, every way to Sunday and they're going to be fine. and, then, then there are these applications and these numbers here are specifically from my testing with, MSIX and where we need the PSF. and, you know, we can take a look at what's in that application.
and understand what is going to be needed in terms of the PSF to be able to get that application to work inside the MSIX container. And that can be automated. So we can just look at it and say, OK, yep, here are the things that we need to do. And that covers about 70 % of the applications out there that I see. That we can just take a look at it, and they're fit for some type of automation so that someone can say, I need this application or I need this new version and you can very rapidly get an app and it's going to be good. Right. we got that next set where we really need some human input into that. Someone needs to look at it, troubleshoot it and say, okay. That didn't work. with just the straight up default fixes from the PSF,
we need to do something special here and we have things that we can do there and that can get us to that 90 % number today. and then, you know, beyond that it's, you know, there's Bob (14:38) Mm. Tim Mangan (15:01) There's, there's nobody, I don't think they can get those apps to work right now. And that's something that'll, you know, we're
going to continue to shrink that number down, but you know, that is where the technology is. Bob (15:12) And hopefully you're just lucky enough not to have too many of those needs Superman quality apps. Yeah, this, this lines up pretty well with the numbers that we've been seeing around automation. Cause you know, everybody says automate packaging. That's kind of crazy. But if you're also automating the testing for it and getting some high fidelity results back, then you can be confident that you have successfully automated something without a terrible amount of work. And with all the Tim Mangan (15:15) Yeah. Yeah.
Bob (15:40) Command line support today and like I said, the more modern new applications doing things the way we would hope they would more frequently. We do get, it looks like about 70 % of applications can be hands off automated. So this aligns with that. And our message too isn't that we can automate everything. We're trying to automate everything, but we know it's a goal that we'll never get to. And so there is always gonna be a need for packaging expertise and people that can sit down and get into this. Tim Mangan (15:58) Yeah. Bob (16:10) understanding this necessary.
Tim Mangan (16:11) What I love about the approach that, Juriba is taking is, you know, mean, view much of your work as being sort of upstream from the work that I do of actually, worrying about getting the package created and you're reducing, you're helping the enterprise reduce all of the friction that takes place to get to the point that someone's actually doing a package so that as things change and you want to move. It doesn't take six months to get to the point that there's a packager actually taking a look at a package. You can do that rapidly. And for the ones that you can automate, great. Now you've really sped up the services that you're providing the end customers within your organization of these applications, helping them modernize and get moving faster, getting rid of the security vulnerabilities that may exist in some of these apps. then...
IT can really focus on, okay, here are the ones that really need some help. Bob (17:09) Exactly. And where we're zooming in now is articulating those that need expertise, why we think that's the case. even more helps. So when they sit down to work on something, they've got a good starting point. Tim Mangan (17:26) And I really feel like some of that lines up with the company you were open and talked about the, application book that I wrote and understanding that. And that's part of what I've been trying to do with the packages is use that as a, packaging as an opportunity to pull out the information that someone who needs to do that UAT test can really understand, well, what should be involved in that test for this app? Right. What
should I be looking for and understanding what the application intended initially when it installed. is part of that information. Kiran Mantagi (17:56) You said you put applications like AutoCAD and SOLIDWORKS through your testing, and you're able to get MSIX successfully. That seems very positive. I'm in there. Okay. Okay, they're in the mix. All right. Sure. I was coming to a point of PSF fix-ups. I was trying to understand from you how often have you seen that a PSF fix-up is required to make an MSIX work to meet your UAT or your tests Tim Mangan (18:05) No, I did not say that part. I said that they were in the mix. They're in that bright yellow column.
Bob (18:12) Yeah. Kiran Mantagi (18:26) and MSIX work to meet your UAT or your tests? And two, second part of that question is, I know there are a few that are released by Microsoft within that library and I know you contributed a few. So I'm curious to know which are those common ones that you found during your testing. These are the ones that are commonly found PSF fix-ups by these apps? Tim Mangan (18:54) Well, there's...
The numbers I have aren't exactly the question you asked, because what you asked is what needs the PSF. Instead, what I have a tendency to do is to look for any possible reason that I could use the PSF to fix something in this application, and I add it to it. So I'm adding the PSF into the vast majority of these applications. Now, within the MSIX framework, particularly as the... Kiran Mantagi (19:17) you Tim Mangan (19:22) AppX Manifest itself has expanded over the years. There are sometimes newer options. To give you an example of that,
we have a fix-up called the dynamic library fix-up. Because of some of the things that MSIX does, sometimes the application can't find its own DLLs because it's a different kind of environment. And so the dynamic library fix-up, which is part of the PSF, attempts to solve that problem. And if the problem exists, it solves it for... Kiran Mantagi (19:32) Thank Tim Mangan (19:50) 98 % of applications that are out there, but there are a few applications we've found that make calls to load those DLLs in a very unusual way. And the fix up doesn't trap those because they don't call through the normal mechanism to load the DLL in. And so we have to fix those problems another way. There is another feature that Microsoft has added called the Loader Search Order.
Kiran Mantagi (20:09) Thank Tim Mangan (20:19) which is an entry in the manifest that says, here's some additional folders that you should look for DLLs in. That's a different way of solving the problem. My solution has been traditionally to recognize I probably need it and add that dynamic DLL fix up in it. But now I'm also doing loader search order. I could possibly always do it with loader search order, except that Microsoft put a limit to only five directories in that list. Kiran Mantagi (20:37) Hmm.
Bob (20:47) Thank Tim Mangan (20:48) And there's a lot of applications that have more than five. So we kind of need both. And so my default tends to be I put the PSF in if I think I might possibly need it because it's probably not going to hurt. and then fall back to these other methods, as I need them. Kiran Mantagi (20:58) Hmm.
Bob (21:03) And that's your general approach too, right? To look and see, okay, there is an INI file, an XML file. These might need to be written to, there's, you know. Tim Mangan (21:12) Yeah, they might. And maybe they're not going to be written to, but I, if I see them in there, say, yep, I'm going to add the, the file-based fix up so that if the app wants to write to it, it will be able to, because that's what it's used to being able to do. Kiran Mantagi (21:23) Now, the one specifically, the dynamic library fix up seems very technical for somebody who comes from an IT pro background that seems like a very developer skill to identify those things. I know your tool does a great job simplifying
all of that, but what would be your suggestion or your guidance for somebody who tries to... look for issues in MSIX, runtime issues, and then figure out, hey, these are the ones that I want to apply versus your approach where let me apply everything upfront and ensure what I get is a good one? Tim Mangan (22:01) Yeah, so that kind of goes back to the way that we originally figured out these applications, right? And so we would start out, for example, looking at applications that need some help for the registry. And so you would containerize the application, you'd test it, you'd run process monitor against that, and you'd see that there are instances where the application is trying to gain Kiran Mantagi (22:15) Mm-hmm.
Tim Mangan (22:27) read-write access or maybe full access is the term that you'd see in there. And they get an access denied. And they're trying to do something which under HKEY local or sorry, HKEY current user, they're trying to open up something to get at a key and they're getting access denied. And that would never happen natively. So that's the kind of thing that we'd look for and then say, okay, we need the registry fix up on this one because it has that particular type of problem. Kiran Mantagi (22:32) Yeah.
and you identify such, I know there is trace fix up, so do you think that would be helpful to identify such things? Because all of that could be possibly in the logs, in the event logs where I may not be able to easily identify that, this is related to this app's this call. Tim Mangan (23:12) Yeah. So, so, what Kiran's referring to there is we have a piece of the PSF that's called the trace fix up, which is something that we would inject into the package for the purpose of doing monitoring. and in the early days with the MSIX, that is how we did all of our debugging. use that, because it's actually tracing exactly what the application
asked for and exactly what the application got back. Something like process monitor. Kiran Mantagi (23:20) Hmm. Tim Mangan (23:42) is running at a lower layer of their operating system, which means the MSIX container has already made changes to what the application asked for, or maybe even prevented that request from even getting down to the level of process monitor so we would miss some things.
Over time, we've gotten better at understanding what we need to know, and we don't use the trace fix-up very often anymore. It's still there, and that would be a way to get started. Kiran Mantagi (24:07) Okay. Tim Mangan (24:12) There's even a little GUI monitor piece we put in there to give you a process monitor like look at that. And it is nice that it's very close to the application. But I think at this point, I usually, if I needed to bug, I'm just going straight to
process monitor and seeing what's there. And it does take a little experience to get used to doing that. There's often much more to look at than it would have been with the native application. Kiran Mantagi (24:27) Okay. Correct. That'd be a lot. Tim Mangan (24:38) but that seems to be the most effective way to be able to do that job these days. Kiran Mantagi (24:43) Yeah.
Bob (24:43) Knowing that your MSIX package works is a tricky one. You mentioned some people's tests might just do a smoke where it's launching the application, make sure it runs. A lot of these things that are fix up related may not occur until you're stressing the application, do something with it, which really drives more need for functional testing or user acceptance testing than normal. Do you think it becomes necessary to functionally test everything or you know because I mean that's really going to slow things down if that's the the guidance for MSIX Tim Mangan (25:20) It all needs to get tested eventually. It's a question of where you want to spend that effort, right? Well, what I've been trying to do is kind of get that information out there. Like on this form here, there's that view report button. And if they click on that, it'll show them, okay, this application had four shortcuts. And here's what
they were. It has some file associations. There is a shell extension for a context menu. There is... a drag and drop handler shell extension. And that's where a user would be taking a file and dropping it somewhere. And that's associated with this particular file type. And that at least provides the information. OK, so maybe in my smoke test, I want to make sure that I've got the shortcuts I want. I mean, that's pretty standard that anyone would be doing. I'm going to launch
some things and see if it comes up. Well, I got these file associations. Maybe I ought to find one of those files and make sure that I can open it from the file and that that works. and then, the drag and drop handler. Well, maybe I just leave that to the end user because probably very few use it, but hopefully whoever my application expert is that goes through the process of approving this application. When I finished my packaging, they'll run that test if they think it's important. but every organization is going to have to figure out where they want to put, that effort. Right. But, but eventually you want to make sure that the things are being tested.
Bob (26:42) Yeah. Tim Mangan (26:46) before the application hits a lot of end users and you have one of those IT fires you have to put out. Bob (26:54) Yeah, I agree. I think it used to be there was a lot of upfront testing, right? We'd identify and correct problems before any testing was even done. And that took a lot of time. And as Windows compatibility got better and better, it made less and less sense to do that upfront work. And so this could be a similar situation. There might be some applications that lend themselves to trouble that you're going to give extra attention to.
but the majority are okay. And so to wait until deployment testing to see if the application's working might make more sense than ahead of that, because you're already gonna do that deployment test and launch it and do some work. Tim Mangan (27:33) Yeah, and that's part of what just going to one of these package formats is. I whether we're talking about AppV or MSIX or even some of the others, know, the danger that we always had with MSI repackaging was the fact that you could take that package and drop it on the system and it could break something else on the system. And we kind of eliminate that by going to these new, more modern formats, which is really a good thing. And taking out that level of risk.
Kiran Mantagi (27:53) you I'm gonna... Tim Mangan (28:01) and allowing us to focus on what's important to the end user. Bob (28:06) Yeah, for sure. think the automation bit that we can use your tool, and we do with our integration, we use that command line to apply all the fix ups that make sense. And then we throw it to a smoke test because that's what we can automate right now. And then you kind of get your, this looks good. You can, you can put it through a UAT, you can deploy it to pilot and check it out there, but yeah, it needs that extra.
sanity check before it goes out to the masses. But the ability to use AI for this type of thing seems very close. So I don't know if you saw, but we recently posted a demo where we've got an AI agent doing a repackaging job. So it takes FileZilla, I think it is, we tell it, install the application. Don't put it... Kiran Mantagi (28:52) you Bob (29:04) No, put a shortcut on the desktop and don't launch it at the end. So that's like the instruction or the prompt. And it
goes through and you can see what it's thinking at the bottom of the video. It's basically, it does a screenshot, it interprets it, and then it sends back to our client, click in these coordinates to check this box or to press this button. And so it goes through the whole install. And that use case is very simple because the installation wizard is very simple to understand. But I can see in the very near future, you should be able to say,
functionally test this application. And just like you would look at an application and know the things it does pretty intuitively, to be able to play around with it, you wouldn't necessarily need to be an expert on the application to identify a problem with it. So I think we'll get there pretty soon, like maybe sooner than people were expecting. But that would certainly be a great way to solve the problem of functional testing at mass, because we're trying to help. Tim Mangan (30:07) So does that mean your packager needs to learn prompt engineering skills? Bob (30:12) prompt engineering. I love that term, prompt engineer. Now, actually, the hope is that we cover that. But for UAT testing, we're still kind of brainstorming the right way to go about it. We have
a capability right now where we suggest command lines to packagers. If you're not a packager, we have a simpler interface that doesn't show this complexity. But if you're a packager, you can see Kiran Mantagi (30:15) you Bob (30:40) Here are the command lines that might work, where they came from, success rates if they've been smoke tested. So we can really help you pick the right command line for install and uninstall. I could see
us getting to a similar place with prompts. So maybe for this application, these three or four prompts make sense to make part of your test, and you could have those recommended to you. Tim Mangan (31:05) So when you're talking with your customers, you hearing them? How do they react to the idea of using AI for this? Bob (31:13) A lot of people didn't trust it because, I mean, for running through an installation, there's some security concern that you're giving AI control of the system. But this is a test system in a test environment. It's just running this application. It's not doing anything of consequence. And of course,
you can see it. We have a complete log of everything that happens, and you can control it. So it's not too risky there, but I think a lot of people's initial, feeling about AI is skepticism because they've gone to ChatGPT and said, what's the command line for this? And they've gotten some hallucinated, completely made up thing that doesn't work. So actually the way we've implemented it for command line suggestions is we have our own rich knowledge base as the most, you know, likely best source of information. Then we also, so there could be multiple good entries there. Then we do a programmatic analysis and say, okay, programmatically, these are the command lines that seem appropriate.
Because some of might be customizations and you may or may not want them. So there could be a number to select from. But the AI suggestion, we've actually demoted to the bottom of that recommendation list because And it's definitely better than nothing when you can't get much, but you generally wouldn't want to rely on it at this stage. But some systems are better than others. Ours is set up in a way that we can leverage multiple systems. And we're seeing some AI service providers are good for this and others for that. Tim Mangan (32:58) for a while people were really concerned about the harvesting aspect of that. I didn't hear
you mention that as a concern at all. Are we kind of over that? Bob (33:07) I think it depends on what you're asking. You know, you're, if you're working on a sensitive presentation, you're giving it a lot of information about your company and your product in your direction. That is concerning. but I see it getting used quite a bit. There was a lot of warnings early on. Don't, don't ask sensitive questions. Don't use it. because there, there is concern that you could be training it on things you don't want public, but Tim Mangan (33:09) Okay.
Yeah. Bob (33:34) Knowing that, there's been a lot of security put into these systems. So you have control if you trust the vendor you're working with. But for command line stuff and running installers and testing applications, that's not proprietary or sensitive information.
Kiran Mantagi (33:50) Thank Tim Mangan (33:50) One of things that I, you know, it's talking with, with customers is like, how much trust are you going to give to how many companies? You know, I mean, you you, you, got to trust Microsoft because you really don't have a choice. Right. And, and, and maybe you're on another cloud provider, so you got to be trusting them, but every one of these applications that you're putting on your systems, you've got some type of trust relationship with that vendor. And, how do you actually deal with it? And I think for a long, long time, we've just been walking around with blinders on it. It's like, yeah, okay, fine. It's just, that's not a problem.
Bob (34:31) Mm-hmm. Tim Mangan (34:32) So security is everybody's job. And we do have these relationships, we need to recognize them and we need to manage them the best we can. Bob (34:39) Yeah, yeah, that's why I see a lot of policy around, you know, use of AI for that reason. And Microsoft's obviously in a good position
with Copilot being built in and them having their own security. But then there was a lot of concern about that feature they had where they're basically screenshotting your screen for text and storing it in a readable way. That was a cause for alarm. They had to put the brakes on that one. Kiran Mantagi (34:41) you Tim Mangan (35:00) Yeah. Bob (35:09) There's definitely concern. And that's the good thing. There's a lot of people
that are concerned speaking up. So I think everybody can kind of go in. Tim Mangan (35:19) Well, we kind of saw a little of this with, as we started moving in the cloud, the whole data sovereignty thing, right? That, I got to make sure that I know where my data is in terms of geographic boundaries and all that. And spent a lot of energy and time and money just making sure that that was in place and then immediately go out and then buy a company that's not within that geography and well, What do you do now? I guess we really didn't need to do all that. Right.
Kiran Mantagi (35:51) So. Bob (35:52) Yeah. So we haven't come up on a lot of companies that still have App-V. think given your focus, you'd be exposed to the majority of them. What's your hearing from people that are on App-V? They've obviously been thinking about the MSIX move and are now maybe less concerned. Tim Mangan (36:14) Yeah. Well, the, of the customers
that I've been dealing with, have been in that migration mode, but I know that there's a lot of customers out there that weren't yet in that migration mode. And so they weren't talking to me. so it's, it'll be interesting to see, how much those folks engage and how aggressive they want to be moving forward. again, my advice is they, they, can't ignore it. The problems are going to be there eventually. Yeah. Bob (36:45) Yeah, enterprises move slow, right? It's just like a Windows EOL or anything. Everybody, there's way too many people waiting till the last minute or past that last minute.
Tim Mangan (36:55) Yep. Kiran Mantagi (36:55) Have you seen any new vendors coming up with their products in the MSIX format? I know that there are really few, but in recent year or two, have you seen anyone? Tim Mangan (37:04) there are a number of that are out there and it may not what, what I'm actually seeing is, you know, it's not the products you already have that are coming out in that format. It's it's new stuff. Microsoft has actually done a surprisingly large amount of stuff within their own portfolio for the small stuff that you don't even notice that's there. Right. I mean, the big one they did was teams. the new outlook is in that format.
Kiran Mantagi (37:14) you Tim Mangan (37:32) But I mean, the new outlook is one that quite frankly, they did so much else at the same time that that is something like I tell my wife, don't turn on the new outlook. You're going to hate it. You know, stay with the old one, because you're just, there's some loss of functionality to happen because it was really a total rewrite to make it more, cloud friendly. But, gosh, I don't want to use that in a disconnected mode. you know, that's, that's horrible. And, know, she'll, she'll go to the. Bob (37:43) Yeah. Tim Mangan (38:02) to the library with her laptop to do work and suddenly all her documents are gone. That's not a good thing. Bob (38:09) That was really the hope though, right? That the vendors like this, biggest advantage over app V was this is an ISV ready format that we want.
Tim Mangan (38:24) Yeah. And, they are the, anything that the vendor is doing that they're writing as a new application today. they're no longer writing. Well, they are some, but they're largely not writing in a .NET framework or the old win 32
stuff. They're writing in .NET six, seven, eight, nine now. And those are natively a package format. also have an unpackaged form, but given the fact that they wrote it in those. it's inherently packageable. even if the vendor didn't actually come out in the MSIX format, that is something that is so easy to package up because it's already built to run in that package. And some of the compatibility things that we have to fight with with the PSF shouldn't apply anywhere near as often with that type of software.
And those are the ones that I'm worried about for things like AppV going forward, that AppV won't be able to handle some of those as well. Bob (39:12) Yeah. Kiran Mantagi (39:16) Hmm. Bob (39:19) Okay. Well, there should be some pressure that MSIX has an advantage to encourage that movement sooner, but so maybe it'll be that way intentionally as a... Tim Mangan (39:30) Yeah, and what Microsoft's been doing with the operating system is, from a security perspective, something that they've needed to do. Like we talked about shell extensions earlier,
Shell extensions traditionally ran inside the Explorer process that ran your desktop. So any vendor that dropped down a shell extension, that was loaded into that memory space and it was active. And that's a big security spot right there. And so they've been... quietly behind the scenes in the new versions of the operating system, splitting these things out. So things like preview hosts have their own process. Some of those other shell extensions end up in some of those massive numbers of SVC hosts you see in the task lists these days. I Windows 7, you had maybe a dozen of those. Now, just logging in, you probably have 30 of them on your system. And that's that separation to try to improve the security posture of the operating system.
Kiran Mantagi (40:19) Yeah. Tim Mangan (40:29) And these package formats for MSIX are taking advantage of that and applying things in a way that you get that type of separation. Whereas MSI and App-V are continuing to do these things the old ways and you're not getting that improved security posture as a result. Bob (40:49) I remember early on that was one of the benefits of MSIX that they were pushing is on Windows 11, while you can still run other applications. If they were packaged with MSIX on Windows 11, that they would be inherently
more secure. So people do care about that, but the complexity, the unfamiliarity of the format, like people expect to see a setup.exe, right? Which have you seen like bootstrapped because You'd see that a lot of times in the beginning before people knew what MSI was, it would be a setup.exe with the MSI inside so that people got what they expected. I haven't seen anybody do that with MSIX, have you? Kind of a bootstrapped MSIX? Tim Mangan (41:35) no, I don't think I've, I've, I've seen anybody do anything like that. Yeah. I'm sorry. There is an accept. There is an exception.
There was one, the guy who writes notepad plus plus he, I think he's already taken this out, but he had a version where the context menu was actually an MSIX package. Bob (41:39) Yeah. Yeah. mean, Store, think, has more. Yeah. Kiran Mantagi (41:50) you Bob (41:50) yeah.
Tim Mangan (42:01) so that you installed the native application and it installed an MSIX context menu to get it. That was weird. Bob (42:08) Wow. Okay. still that's the thing right you look at enough applications you'll find the the weird things still happening. Yeah.
Tim Mangan (42:16) Somebody does something weird. Kiran Mantagi (42:19) You said it that version is discontinued now or is it still there on there? Tim Mangan (42:22) He took it out in the next version, I think, yeah. Kiran Mantagi (42:25) There are lot of Tim Mangan (42:27) It definitely caused me a headache in trying to repackage that as an MSIX app because I had an MSIX app in it. Kiran Mantagi (42:33) Already, yeah.
So there are definitely a lot of positive things happening in the direction of MSIX, but when we have conversation with our customers, with enterprises, I still see they're very skeptical about moving to MSIX. They still, we've hardly spoken to anybody who say we have MSIX packages in production. They're mostly, we are testing, it's in dev or QA, staging, whatever. So what do you see are like common reasons that enterprises have not to move to MSIX? One thing that we hear is, we want to see more vendors coming out with MSIX, so we have more confidence on the package format. But beyond that, with respect to, these are some
limitations in MSIX which is stopping me because these functionalities are part of my core packages like MSI or EXE, and those are not supported by MSIX. I know they are doing better. mean, when they started, they didn't add support for drivers. I think in some way they brought it. they're also continuously making some improvements. But at this point,
do you think about such limitations which are holding back enterprises? Tim Mangan (43:44) I think it's something that I think as we've improved our capabilities, it's something that they probably need to go back and look at. I think there are a lot of companies that went and looked at it in the early days that, wow, this is really hard. But I've worked with some customers that started in the early days and they've had tremendous success. know, customer in Portugal, 700. Kiran Mantagi (43:58) That's true. Tim Mangan (44:12) applications and they're almost completely in MSIX now because they've been working at it. They got the easy ones first and they had to learn a bit on how to deal with the hard ones. But once they got that under their belt,
they were able to be very successful in their ability to deploy those things out in production. Kiran Mantagi (44:32) Excellent. Bob (44:33) What I see is it's kind of an all or nothing wish, right? Like, I can't have everything in MSIX, I don't want to go there, and that just doesn't make any sense. Tim Mangan (44:37) Yeah, and there is no format that can do them all Yeah, yeah. There is no single format that's going to fit for all of your applications and in all of the different ways that you want to deploy those applications. You know, even the ubiquitous MSI, you know, it does not work in the non-persistent VDI or the RDS world very well. So you're going
to have to end up with a mixture of ways that you deploy these applications and you try to find the best fit. You're probably going to end up somehow with a first choice. This is what I'm going to do. Kiran Mantagi (44:59) Yeah. Tim Mangan (45:12) If I got a brand new app and I don't know anything about it, I'm going to go with this path first. And when I run into resistance, then I'll go to another path. Bob (45:21) If you try the MSIX and it works easily, then you're done. And if not, you've got your full back. Tim Mangan (45:27) Yeah. And, and that's the approach that
I would recommend, but I know that there's a lot of customers out there that they're, not going to go that route first. They're going to go with something else first, and maybe they'll end up backing in MSIX when they can't get it to work any other way. Bob (45:41) Yeah, change is hard. And, think marketing wise referring to it as a modern package format, you know, modernization was like, yeah, I want that. Yeah.
But there are some benefits to MSIX that you don't hear touted very much. mean, obviously app attach is a powerful use case that's gotten it some good attention. The clean install and uninstall. Tim Mangan (45:52) Yeah. Yeah. That's, that's free, right? That's free, right? I get modern for free. Bob (46:11) It is a benefit, but it's almost frustratingly a benefit. Like that shouldn't be that big a deal. But there
are some good things around application updates. It's a single instance store. You don't have to shut the application down. There should never be a need to reboot or anything. You can install it in place. You can install just the files needed, just the parts of the files needed. So it's very efficient. But I really don't hear anybody talking about updates. Is that kind of a...
Tim Mangan (46:17) You Bob (46:40) something that you dive into in your class, how to update and control the updates. Tim Mangan (46:44) Yeah, we do. But particularly as we're talking about things like applications with plugins. And I think the story there with MSIX is just so fantastic because you package up the plugin for that application. And now when the application changes, you don't have to touch that plugin package. And that's really cool. With App V, we had to worry about that stuff. But here we don't. You just bring in the new version and the plugin, unless there is a compatibility change that the vendor made in that.
Bob (47:00) Hmm. Tim Mangan (47:14) that app and that version and they had to throw away all the plugins. So that plugin is just gonna work without you touching it. You just update the app and boom, it's gone. You don't have to worry about it.
Bob (47:22) And modification package too is another interesting one, Because for an MSI, every time you get a new MSI, you need to create a new transform for that thing. Kiran Mantagi (47:24) Hmm. Tim Mangan (47:34) And then, and then this becomes your, your transform it's, it's, and as well as the container for your pre-configuration for the app. So this is where your settings to disable the auto updater, example, something enterprises typically want to do. you know, that would be, you can contain that in that modification package and now the new vendor package can just come on down and you don't have to change any of that stuff. and that's, that's really cool. I don't see enterprises.
Bob (47:43) Mm-hmm. Tim Mangan (48:04) leveraging that piece as much as they probably should be going forward. Kiran Mantagi (48:09) One such benefit is signatures as well. Well, it depends on how you see it. It offers great security,
but we have generally seen IT pros are not very used to signing something. They might not have that knowledge, so it might look like an overhead step for them. So yeah. Tim Mangan (48:27) It's a big blocker for folks to get in MSIX. And it's really one of those silly ones because once you spend a day to get over that problem, it's no longer an issue. It's just like,
something that happens in the process and yeah, right. We have a certificate there. Kiran Mantagi (48:42) considering all these works, it looks like if you're taking that approach, moving or migrating towards MSIX and you want to look at automation, then you want all of this to be part of your automation workflow, signing upfront PSFs. So that might make or reduce your time to get the package ready than thinking about, let me first create MSIX. Now let me try to figure out what PSFs are required, which might take ridiculous amount of time.
and lot of skill. So you might rather want to take the approach that you take, Tim, that I want to first apply the fix-ups and let the package work and be reactive if something fails. You think that would be a good approach for us? Tim Mangan (49:21) Yeah. I think that's a great
approach. I think it's kind of turning the packaging process for that 70 % of apps that we talked about as being just sort of an automatic thing. thinks, I want a package, and then boom, I've got a package. does it look like this is in the 70 %? Great. Let's move on. Kiran Mantagi (49:32) Hmm. Tim Mangan (49:48) And then, well, when it's not, then, okay, now I need to bring in an expert within my organization that knows how to deal with the problem packages. And yeah, you got to spend a little time getting that person trained up so that they can be effective at it. but,
but over time they'll be as effective as that, as they can for any type of packaging. Bob (49:56) right. And that mindset, think, is a game changer too, because it's very common for enterprises to only manage certain applications. They don't try to create and test a
package for everything only if it's on at least 10 machines or only if it's by this set of vendors. And so they're consciously taking, we're going to close our eyes and not look in this direction at what could be hundreds of applications that fall into that. Kiran Mantagi (50:22) Thanks Bob (50:33) that criteria. So to look at an inventory and see, okay, there are 200 applications that we probably should get under management, but we don't have the resources. If you can take this more automated approach and only focus on the 30 % that are necessary, then hopefully that existing team could actually take on a lot more because they're not wasting their time with all the simple. Tim Mangan (50:58) Yeah.
And I think it's becoming more more important for organizations to take that type of approach because of the benefit we see, we didn't talk about with MSIX is that isolation piece. And we get it with AppV as well. But not all of the packaging formats have that. And that isolation piece is really important because all of these applications are being built on frameworks that themselves even if the vendor is absolutely perfect in every line of code that they write, they're based on these frameworks that themselves have CVEs every single month. And so by getting this isolation that comes in,
it's not a perfect solution. remember in the early days of Appy back in softricity, Bob (51:34) you Enough. Yeah. Tim Mangan (51:48) our marketing guy wanted to refer and said, we called the epi the bubble. He wanted to refer to as the condom. And we said, no, no, no, no, no, no, no. we said no for other reasons. the idea that we're providing protection is not the point. The idea though, is that if you are running inside that isolation, the odds of worse things happening because that app did get attacked.
Bob (51:55) you you Tim Mangan (52:14) because of that vulnerability that's maybe in the app, maybe it's in the dependency that they build into the app. The odds of that getting exposure beyond the container itself is reduced. And so you're better off than just putting those things out completely unmanaged and hoping that nothing bad ever happens. Bob (52:34) Exactly.
All right, Tim, I think we're up on our time, but this was a great conversation. Thanks again for joining us. I hope we can have you back again sometime in the future. Kiran Mantagi (52:39) you Tim Mangan (52:44) Great, was very enjoyable being here. Good talking with you guys.
Kiran Mantagi (52:49) Thank you, Tim. Thanks for joining us. Bob (52:56) Thank you for listening to this latest episode of the App Management Experts podcast. To hear more, subscribe on YouTube, Spotify, or at juriba.com I also encourage you to follow Juriba on LinkedIn to keep up with other recordings and articles we're publishing. See you next time.
2025-01-23 20:10