Ep. 01 - MSIX, App-V and AI: The Future of Application Management with Tim Mangan

Ep. 01 - MSIX, App-V and AI: The Future of Application Management with Tim Mangan

Show Video

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

Show Video

Other news

Miniature Hard Drives 2025-02-13 05:36
The Future of the Automotive Industry: Innovations, Technology, and Sustainability 2025-02-10 23:05
Just Delete The Fedora Flatpak Repo Already 2025-02-09 21:19