MacAdmins 2026: The Mac-Native Way to Deliver Windows Apps, Powered by Parallels Desktop

Thank you very much for being here. There are so many sessions to choose from. The fact that you picked this one means a lot to us. We'll try to make it worth your time. Let's get started. Today we are going to talk about something very new. In fact, it's so new that it's still being developed and coming later this year. But we are here to tell you about this and collect your thoughts and feedback so we can incorporate it into the product as it gets made. First, let us introduce ourselves. My name is Alex Patsay, and I'm a Director of Product Management at Parallels, responsible for several projects within the company. We are going to discuss one of those projects today. With me, my co-host is Lyuba Kulakova, and she drives the most critical aspects of this project. Lyuba, to you. Hi. Thank you, Alex. Hi, everyone. My name is Lyuba. I'm really glad to be here to connect with you because I work really closely with you as Mac admins to understand what are your challenges, what do you want to improve for virtualization on a Mac, and my goal right now is to simplify and improve the management of edge virtualization and management and delivery of Windows applications to a Mac. Today, we will start with what is Parallels Desktop Enterprise overall and what we've shipped over the past year. Then, we will shift to a real suite, moving away from delivering a full virtual machine image to deploying and provisioning only Windows applications to a user. We'll look at both admin experience and user experience. For the admins, we'll see how to deploy it, how to manage it, and so on. For the user experience, we'll see how seamless it is for them. Then, we will also cover a topic that mostly concerns you about how we lock down Windows and secure it as much as possible, and we'll close with the summary and open up for the discussion. As Alex mentioned, we are here for your feedback and input of where we're heading, and you can really help us to drive and strategize where we are going with this project. Before we go into specific features, let me show what Parallels Desktop Enterprise offers you as a Mac admin. The core problem they are solving is unmanaged on-device virtualization. If you have virtual machines that are unmanaged, you have no visibility, it's a security gap, inconsistent environment, compliance gap, or no visibility of what's happening in the virtual machine. And Parallels addresses this in four dimensions. First, it's access, so you can control who gets to run the virtualization and under what conditions. Then, provisioning. You can deploy templates and golden images to your users, so all the users start from the same baseline. You can also monitor how virtual machines are being used, what is the state of them, and what is in Windows inside, like updates and current versions. And of course, securing. You can encrypt virtual machines, you can keep Windows up to date using Mac MDMs, you can even enroll virtual machines into Intune and deploy to your users overall, so you have full control over Windows itself. And this all integrates with your existing MDM providers and identity providers, so it fits right into your workflow. Over the past year, we have pushed this control even further, and it's all driven by your feedback. Our golden images got a major upgrade starting from Azure integration. Now you can post your golden images in your Azure Blob Storage and connect your containers to Parallels Desktop Management Portal, so that the communication is done between Azure and Parallels Desktop. And when you set up a golden image, you can select the file directly from your Azure Storage, and then the user tries to create a virtual machine. They're offered to download virtual machine view provision to them, and our server generates a short-lived URL and provides it to Parallels Desktop. So, end-users don't see any authentication requests, they don't see any URLs, and the communication happens between Azure Blob Storage and Parallels Desktop. So, only Parallels Desktop with your license key can get this link, create a virtual machine from it, and users don't have to bother with anything about this, and your golden image stays secure. Another upgrade to golden images is declarative deployment. So, historically, to provide a golden image to users, you would build a full-blown virtual machine image. The declarative deployment is so much simpler because you just have a provisioning package with Intune enrollment token. You can upload it to our portal and say, Parallels Desktop, to download Windows directly from Microsoft. Then, when it is downloaded and virtual machine is being set up and installed, provisioning package is applied during the configuration. It's all automatic, so your users don't need to do anything, and they can just sign in to their online account and start working with Windows, with your controls and policies from Intune. You can also push policies from our management portal, and we got an upgrade to policies as well. Now, you can secure your virtual machines and control the capabilities of virtual machines by our policies. What I mean by that is you can control things like network access, clipboard sharing, application sharing between Windows and Mac, so you have full control over the configuration options for Windows virtual machine, Linux virtual machine, and macOS virtual machines. It is enforced by our policies, so you don't have to recreate virtual machines images and set up manually changes after the deployment. Once you set up in the management portal, it's being enforced in the end user's computer. Plus, you can change it on the fly, and it will be picked up, so no redeployment is needed. For example, you might have developers who need full flexibility and freedom to do whatever they like, but on the other hand, you might have finance department who don't need to copy-paste things or just have full isolated virtual machines. You can set up different policies to both of these users and control them remotely. Thank you, Lyuba. So, let's talk about something that is upcoming. You know Parallels Desktop, right, and what it does. It lets people run Windows applications and Windows on the Mac. What we want to talk about is an extension of what we have been doing for the last 20 years, and literally 20 years, the first version of Parallels Desktop was released in June, back in 2006, when Apple finally switched to Intel. But this time, we want to really focus on the app part of this. So, let's do a quick overview of what we think is the biggest shift in how Windows apps are delivered to Mac. Very quick overview of where things stand today. A business customer buys Parallels Desktop with a clear intention of running some Windows apps that are not available on Mac OS, and Parallels Desktop solves that. It enables you as an admin to deliver these Windows to Mac. But getting that into the user's hands, even with Parallels Desktop for Enterprise, it still requires several steps. We work on simplifying it, but still, it is a process. You have to prepare a virtual machine, or maybe set up a declarative deployment, install required applications in that virtual machine. Then you have to push all of this to your end users and make sure that everything is licensed. All of these steps cannot be driven through standard Mac and VM tools. You have to use multiple tools to achieve that. In most extreme cases, the workflow may look like this. An admin needs to prepare a mass deployment package to deliver Windows apps through MDM. You have to do a lot of manual steps. The audit mode, the script, the sysprep, the image. You have to manipulate the snapshots for VM. At the end, this process even may fail, and then you have to start over again. It doesn't have to be this way. For end users, this experience also looks like, hey, we are getting this Windows image, end up with the whole Windows on our desktop. It's fine for power users, like developers, the use case that Kripa mentioned, but you're handing the user a whole virtual machine. Along with it comes everything that Windows has, the file system, the settings, the desktops, alerts, updates. Not all of the users want or need that. Our grand vision is pretty simple. We want to let you admins focus on what you already know and care about, delivering apps to your end users using the tools that you already have. Perl's desktop will take care of the rest. In our case, what we want to do is how we want to solve this problem. Through Perl's Desktop Enterprise Management Portal, we want you to find an application that your users need. Then you will get a special Mac app that represents that Windows application. Then you push that Mac app through your Mac MDM and Perl does the rest. I promise it will make sense in a couple of minutes. But I want to touch on the user experience. As opposed to what I showed the users getting the full VM, we want to deliver the app. A user will not see any of the virtual machinery. They will not see Perl's desktop interface. They will not see Control Center. They will not see Windows Desktop, none of the internals of the virtual machine. They just open the app, they see the Windows app, and there's nothing else. That's the app-focused experience that we want to deliver. To give you a sense of how this works, let me start on a high-level overview of what's involved. I already mentioned that small Mac app, but where does it come from? It comes from Perl. We already know all of the Windows apps that people are running inside the virtual machine. We know what are the most popular apps. What we want to do is, Perl will build Mac apps that represent those popular Windows apps. We publish them on the Perl's Desktop Enterprise portal. Then, you as an admin, you grab one of those apps and you use your existing Mac MDM to deploy that application to your users. When the user launches that Mac app, Perl's Desktop will automatically create the environment, a virtual machine with Windows, install that Windows app, and then will launch it. There's no extra steps. The users will just see the application. With that, let's switch into the admin experience. Just to recap, as Alex mentioned, the new approach fundamentally shifts where the heavy lifting happens. Perl will take care of most of the things to set up the environment, to prepare Windows, to prepare virtual machine, and install the Windows application. What you get in return will be a clean, MDM-friendly file. I will show you how it looks like step-by-step. First, we will have a Windows app collection on our management portal. We'll post there most of the applications we know that are popular in Mac enterprise environments for Windows applications. We maintain this catalog. If you have any apps that are specific for your environment, it will be great to hear those so that we can populate this catalog and collection and provide it to you and potentially to other customers as well. Perl will handle the core installation logic, which executable to run for the specific application, where to put the and the main setup sequence. But what you can layer on top is your custom configuration, so things like pushing your organization identifier, suppressing license requests, or installing links to your server. You can add those to post-install scripts or install parameters and add to our management portal, and it will be stored on our backup. We also support different configurations for different user groups, so if you want to have a specific configuration for developers, you can put it here, create a configuration for a specific app, and deploy them to a developer user, or to test it before rolling out to all of the users. The configuration you've entered would be stored on our backend. It won't be included in the app package itself. This keeps things clean and simple for you and separates the configuration from the core installation. And to bring it all together, Parallels Management Portal generates an MDM profile that you can be able to download from our management portal, and this MDM profile will include a configuration ID by which Parallels Desktop will fetch this configuration and apply during the Windows app installation. It will be all silently, so again no user interactions, and again here you will have two files ready to be deployed by your Mac MDM, MDM configuration profile, and app package. With these two assets at hand, the process of delivery of a Windows application will look similar to how you deliver Mac applications right now. It will still require a prerequisite, Parallels Desktop to be installed and activated on the end-user's computer, so for the full deployment it will look like this. You push Parallels Desktop through JMP or any other MDM provider you have. You can force automatic activation of Parallels Desktop using MDM configuration profiles. It can be generated by iMazing, or if it is, JMP has already in their catalog of external application configuration profiles. Then, you would push configuration file for specific Windows app application to deliver the customized configuration, and this is the file you downloaded from our management portal. And lastly, you would provision a Windows application package through MDM policies, and most MDMs can detect if Parallels Desktop already installed or not, so you can target only those user groups and only those machines that have already all prerequisites met. And as you can see, the delivery of Windows applications has the same workflow as delivering a macOS application to your users. So, simple and for both end-users and for you as an admin. Let's talk about the end-user experience. So, as Libo mentioned, this stuff gets delivered after admin sets everything up in their management portal, and then MDM, it gets pushed in user's Mac. Whatever approach the admin has used, the app will either be available in the self-serve portal, or maybe it will directly be installed in the Mac, but the end result is the same, and the user gets an icon for a Mac app in their application folder, or maybe even in the doc. It will have the Parallels name in the parentheses for the name to identify that, hey, these apps are coming through Parallels, but all the users need to do is just double-click that icon, the same way they operate with any other Mac app. And as I mentioned earlier, the first time the app is launched, the execution environment needs to be set up. So, now the important prerequisite, as Libo mentioned, is the Parallels Desktop needs to be pre-installed, delivered through the same MDM as before. So, when this Mac app is launched by a user, it will check if Parallels Desktop is present, and then when it finds it, it will ask to perform the rest of the environment setup, if it hasn't been done yet. It will create a virtual machine, download and install a copy of Windows directly from Microsoft inside of that virtual machine, and then will download the installation file for that Windows application, and it will install it as a part of the process inside of that VM. So, all of this without any interactions from the user. Basically, this is what users will see. Just a progress bar for the application saying, hey, we need to set up some components, we're downloading stuff, and then we can run. So, depending on your internet connection, this may take some time. After all, we are downloading several gigs of Windows installation, we're downloading a couple of gigs probably for that Windows app installation. In my experience, when I was installing Power BI, it took me 12 minutes. That's the first setup. Your mileage, depending on the internet connection, may vary. Once the environment is set up and the app is installed, it just simply launches in the coherence mode. Now, those of you who haven't used it, just a reminder, it's a view mode within Parallels Desktop in which we try to hide Windows Desktop and let Windows apps run alongside your Mac as if they were a macOS native program. We are taking it a little bit further, so I'll talk about it later, but we removed the ability to turn off the coherence mode so users are always operating in this mode. In any case, when a user launches the app, as a result, they get the app running on the Mac, they don't see anything else. The majority of users likely will need just that one app, but if for some reason your users may need two or more apps, the process is exactly the same. You push another Mac package to their Mac. When they launch it, it will detect that the VM is already there, so there is no need to create another VM. It will just download the installer for that specific Windows application and install it into the same VM. The process will obviously be much faster. Users will interact with these apps exactly the same way as with all other apps, clicking the icon in the dock, or even using the command tab to switch between them. All of this with Windows hidden and locked. We will talk about the lockdown in a minute. The installed Parallels Desktop application, which is running in the background, will report back to the management portal and will show some relevant information about the apps that were deployed and installed, completing the scope of the functionality for admins in the management portal. But that's not everything in the scope of the app delivery process that we think will make admins happy. We are doing a pretty good job of hiding Windows from end-users, but we cannot hide it from you as admins, because you know that deep inside there are still Windows which you probably want to secure and update. We have some tools that we want to offer you as a part of the Parallels Desktop for Enterprise. The core idea, and Microsoft is probably hateless for this, but we want to reduce Windows to the point where it stops being a second OS. We hope it won't be a second endpoint that you need to manage. We want it to be locked down so tightly that it won't be so limited that it essentially becomes just a runtime for running Windows applications. The best analogy here would probably be a Rosetta that Apple used for running Intel apps on the Apple Silicon hardware. We want to deliver the same for Windows apps, something that quietly runs on your Mac, enabling Windows applications. With no Windows desktop exposed, maybe you will need some basic tools to audit that virtual machine. Over the next slides, we'll walk over what exactly goes into this lockdown of the VM, so you can judge for yourself. When we deliver a Windows app through Parallels app-based method, the users really need that app. They just need that app to run, not the whole operating system around. We harden, shrink, and hide a lot of stuff inside of the VM, which means that the admins will spend less time managing it. The numbers tell the story here. We remove 32 built-in apps from Windows. We strip 12 different Windows capabilities. We disable or set to manual more than 17 background services, and we do it across these four hardening levels. The performance, the bloat removal, the telemetry limitations. This work pays off in three major ways. First, we deliver a stronger security posture for Windows. We block the escape routes, like the Windows key shortcuts inside Windows. We block task manager, control panel. We hide the C drive from the users. We close the attack vectors like auto-run and unsupervised startup applications. And we shrink the effect surface by removing the components like Internet Explorer and WebView2. It means also a smaller VM footprint. We stop the constant background work, search index, super fetch, peer-to-peer updates, all of these background services that most of the users don't really need. In the end, we use less CPU, RAM, bandwidth, and disk space, and it all adds up across the fleet of Macs that you have. And third, it just lasts for admins to manage. There's simply far less Windows on your Mac to patch and monitor over time. The apps we remove, they don't sneak back, and the users get a clean, destruction-free experience, and they will only see the app. They will not see another alert saying, hey, compile it in the file explorer. How about using that? So smaller and more secure Windows, that's the idea behind the Windows lockdown. And the key thing for that is to understand that the detection and control, they already happen on the Mac host, not inside Windows. So three main levels. At the top, there's the macOS host, and it is the managed endpoint. Files, they live in macOS and accessed from Windows app through the shared folders functionality in Parallels Desktop. So your EDR system, they scan them at rest in macOS. And macOS privacy permissions, it still governs the access to camera, microphone, and USB device. And you still use the same macMDM to enforce the policies on the Mac. In the middle, Parallels Desktop is the control plane, and it decides exactly which macOS folders Windows app can access. It's a defined working set, not the whole file system. And every app that reaches that Windows only as a single package through our app delivery process. And at the bottom, you have Windows Runtime, that is a sealed execution environment. It runs just approved applications and runs in a net-only network. So no desktop, no shell, no browser, no email, no scripting, no inbound exposure. The exfiltration surface inside Windows is structurally very, very narrow. So the bottom line is that Windows will only ever see the files that Parallels grants access to, and the macOS stays the managed endpoint boundary in this. There's more exciting stuff, so I'll pass it to Lyuba. Even though we are doing a lot to lock down and reduce Windows footprint, you might still have some questions about activation, visibility, or updates. So let's touch a little bit on those. First, visibility. So when Windows runs as a hidden runtime rather than a managed endpoint, it's still there. You know that it's still there, and you might require some kind of visibility into the processes of Windows applications, what's happening there. So we will introduce a new feature on security tools collection. So we will have a collection of tools like Sysmon or NxLog for visibility, monitoring, reporting, and so on, that you can configure, install, and deploy along with Windows applications inside exactly the same virtual machines. These tools are designed to stay hidden, so we will keep it the same way for end-users. They won't have any UI or UI showing or something like this. They will be silently installed along with your Windows application and report to your system. To configure them, you will be able to upload configuration files or certificates, provide install parameters to our management portal, and again, we will store it on our backend, and when they are deployed to the users, Parallels Desktop will get the configuration and install these tools for the users. Next, activation. The plan is to provide you a way to provide us a mass activation key on the management portal, and we'll handle the automatic activation of Windows for you. So we'll push this mass activation key to Windows that have a Windows application delivery running, and you can see and manage the license key as you manage it right now in your Microsoft account. So our side is more on automating the activation of Windows. Important note here is that this is in plans, so it's not coming up in this fall yet, but it will be delivered a bit later. And last but not least is updates management for Windows. So we all know how Microsoft loves to update Windows and ships updates quite regularly with a lot of changes or security patches and so on. So you probably want to keep Windows always up to date, even for such cases where Windows is not shown, but it's still there. So our plan is to provide you three tiers, and it's staged. So at first, we will monitor when the applications are not used, and we'll push updates when it is idling. If there are no such time, we will move to notify and defer, meaning that we'll notify a user, hey, you have updates pending, please restart or do something. But they can still say, okay, later. And then the threshold is passed, we'll move to the stage where we will force updates. We'll still notify the user, hey, the updates will be installed. So we will, at the end, if all the thresholds are passed, we will close the application and restart the Windows to apply the updates. Here, again, no actions from the users, just to click, okay, now or later. If they do that, if we manage to update the Windows during the first seven days, they won't notice at all. And again, this one will be shifted with further updates. Thank you, Lyuba. So to pull all of this together, all of these pieces that we described, right, what we've shown you is a new way to deliver Windows apps, not by handing your users a whole virtual machine, but focusing on the application part, focusing on that single app that installs through an MDM that you already run. For the end-users, it's just an app, regular Mac app in a dock, right? The Windows space is hidden, the experience is very close to macOS native experience. They operate with the same keyboard shortcuts, they get to use the clipboard the same way they use in the Mac apps, etc., etc. And the part that matters a lot to your team is that because the Windows layer is sealed and locked down, macOS remains the managed endpoint. It's the similar model that you already trust for runtimes like WSL or containers, but it now applies to Windows applications. So that's the shift, right? If Windows is a runtime, not an endpoint, and users get to experience the Windows applications on their Mac, but not the Windows itself. And with that, this is what we have, so we can open up for any questions that you may have. Thank you very much. Oh, sorry, I can, I don't know. No, no, no, no, it's recording, yes. Um, so it will depend, uh, so we actually do plan to have a feature that will allow you to control that. If the application has a self-updating mechanism, you will be able to say, hey, I want this application to be able to self-update whenever the update comes out, or maybe actually lock it to a specific version, so it will stay until you say so. And in that case, if there's a new version of the app that comes out, you might need a new package, which we will create for that specific version of the app. Also, one note, our packages will be deploying the latest available version of Windows applications that are in LinkedIn or other repositories we will be using. So in the first version, we'll deploy the latest available for the same package. So actually, like, just a quick note, so I mentioned that we already see and know what kind of applications are popular when users are running Perl's desktop and have Windows installed, but it's always important for us to collect additional feedback. The way it works, so yes, we will define, I don't know, 40, 50, 100 apps that we will have in the collection that is available to our customers in the beginning, but you will be, you as an admin, you will be able to request additional apps, like let's say something that is not listed, but you need, right through the management portal, you will be to ask for that app, and we will create a package for it, and we will publish it on the management portal as well. In the future, we plan to work with MDM providers like Jamf, so these packages will be available in the MDM from the start, so you will be able to push them directly from MDM providers, but in the meantime, if you have an app that you have in mind and you want to make sure that it's available, when we launch it, you can scan the QR code and submit some ideas. Any other questions? That's a very good question and very relevant feedback for us. At this point, we, for the first version, we didn't plan any public APIs to manage the portal features or deploy these things, but we'll definitely, we are looking to having a public API, so just need to dig deeper into this stuff. Sure, but I wanted to quickly just add a note about the API, so we planned the API not just for this specific functionality. We want to cover all of the functionality in the management portal, so yes, you as an admin, you have your automations, you don't need to go and manually click stuff, so that's in our roadmap already. We have that. I cannot give you the exact timeline, but we have that down in our roadmap. Well, Steam is one of the most popular apps that is run through Perl's desktop, and a lot of content that comes through Steam, it also works, so yes, it works. We have a question here. You just wanted it to start, right? Can I? So, for this app delivery approach, you don't need the golden image. We will take care of everything. So, it's not using golden image that you have for the, what we want to do is to split this into like two modes in Perl's desk, right? So, users that need a VM, they get it through golden image. Users that need the app, they go through this app delivery process in which we will just push that Windows, cut it, pack it, and that's it. Yeah. Yeah. Thank you. We have one minute left, so we may have time for one more question. If not, we will finish early. Yes. The short answer is yes. The more expanded answer is the applications list is limited by domain, so by customer. So, if someone requests a custom app that is available only within their organization, we will be able to package it for them, provide them with the package that they can host in the same Azure blob storage that Lubom mentioned earlier, and it will be available only to the users of that specific organization. But we thought about this because that's what we see in a lot of stats, that people run some weird stuff that we've never heard before. So, that's really like custom apps that are only specific to some companies. Thank you very much. If you have any other questions, you can find us in the sponsors section or follow up with us later through many channels that we have. Thank you very much. Thank you.