Good morning, and welcome to Login Enterprise for Windows three sixty five. We’re gonna pause for just a moment and allow folks to join the webinar. Be back in about sixty seconds. Okay. Let’s go ahead and get started. My name is Michael Kent. I’m the chief product officer at LoginVSI. Today, I have forty five minutes with you, and we’re gonna be talking about Login Enterprise for Windows three sixty five. There is a giveaway that will be awarded after the webinar is complete. So if you are in attendance live and you participate in the polls, as we put those up, you will automatically be entered for a chance to win a pair of Apple AirPods that will be selected and and delivered after the webinar. A little bit of housekeeping. You do have some controls inside your interface. You will see that you can ask questions. I will probably save those till the end. Just be aware of that. You’ll be able to interact with polls as they get presented. And, of course, you’ll get a copy of this webinar for on demand view after the webinar is complete. And if you should need slides, you can contact your customer success representative, and they’d be happy to not only help you get access to any materials, but take a deeper dive after the webinar is complete. Okay. Today, we’re going to look at what changes and what stays the same, really, with a focus on what happens after you’re in Windows three sixty five. Why load testing really falls off should be obvious, but we’re gonna go into some things that are maybe a little bit less obvious. Really, your opportunity around Intune and some of the challenges you’ll have with it. Building a structured test program, we’ll go through that as well, and a live demo with the q and a at the end. We’ll start with our first poll. Where are you with Windows three sixty five today? Option a, evaluating, researching, not quite sure if it’s for you. Don’t know if your stack will translate well, piloting our proof of concept. We see a lot of our customers are piloting or running a POC, trying to understand, really what it means and what has to change operationally for them. Actively migrating from an on premise Citrix or VMware to a cloud based combination, are already live in production and off to the races. We have some evaluating. That’s great. Okay. Over half are evaluating of the folks on the call. I have a small percentage that are in the POC process. That’s great. And I do have a twenty five percent of you that have said that you’re in already in production with Windows three sixty five. So what we know is as you move over, the infrastructure goes away. Right? Traditionally, infrastructure was the hard part. We have to buy the machine. We have to prep the machine, wait for a budget cycle, go through procurement, have the machine shipped. That caused a lot of concern. We wanted to make sure that we had everything right and that we had the capacity and that we were paying attention to capacity as we filled that system up because we knew we were gonna have to take time to get the next system in, and that’s just procurement. Forget about budget and and everything else. So the infrastructure goes away. However, OS management stays. We have this new, as I like to call it, eventual consistency model for Intune. You might get it today. You might get it tomorrow. If your machine’s having some trouble connecting, you might get it next week. Right? And that goes for conditional access policies, compliance rules, AV updates, Windows patches, application changes, etcetera. Application packaging. Every app and update can affect performance. Right? We have all heard of the works on my machine. As it moves through and as it starts to climb with other applications and other environmental variables, especially distance, we wanna make sure that we understand the performance and the stability of that application. Microsoft is releasing patches at a breakneck pace. If we wanna make sure that we’re up to date with CVEs, we wanna make sure that we hit patch Tuesdays, etcetera. We need to make sure we have a a mechanism to deliver those that’s reliable and, to whatever degree, a bit foolproof. And then user profiles. Right? So we do make changes there. If we’re using FSLogix and we start to get busy, we have to acquire new SKUs or change out our, configurations for more spindles so we can get, you know, more capacity or more performance. You still own the end user experience. Right? Doesn’t matter that Microsoft delivers the infrastructure. They were still going to look to you to understand the delivery inside your organization. Application baselines really allow you to understand where it is and where it’s going. Validation sign off, they manage the infrastructure, but you still have to understand you’re layering your applications, kind of your unique fingerprint in that environment. They don’t have all your applications, and Microsoft’s very clear. We test what we know. We’re not going to test all the applications that you’ve collected over time. And then, of course, there’s the compliance and readiness. Do you have your security agents running? Are they doing their job? Etcetera. All of these are factors that you have to consider going forward. There still are three forces that really kind of cons encapsulate all of these changes. Image and app changes. Right? This is our our day to day bread and butter. Whether it’s an internal app or it’s an update in the PDF reader, these will happen at different times and different paces. So you have your volume of Microsoft updates. Then you have CVEs that come in ad hoc and in an emergency. Then you have app changes, which also can come in ad hoc and in an emergency. You have security agents. You have configuration changes. All of those that packaged up give you a very sporadic schedule of how you have to be able to deploy and react to business need, to security need, to, compliance needs. Intune policy and configuration is also a new vector that we have to pay attention to. Conditional access policies. Those are very just fun. Just plain fun. One switch, and you’re going left instead of right. How are we making sure that the pathway that our users are going into this infrastructure, this service in the cloud, are following the right pathway and that some new wrinkle hasn’t jumped up and gotten the way? And, of course, the platform updates, as I mentioned. We have to stay current. We’ve all seen the the news. Someone got abused by a vulnerability. We wanna make sure that doesn’t happen to us. I think that stat is four out of five hospitals have been hit with ransomware, some crazy number like that. There is a huge push to get everything as secure as possible as fast as possible. Not only is that the Microsoft platform updates even on their backside. I think, as we were deploying our connector, they updated the Windows app, you know, mid mid month, midstream. You’re gonna get this too. These are just different vectors in different areas where you have to pay attention to what’s happening and what’s going to force changes in your environment. Next pull. In your environment, what do you worry about the most? What keeps you up at night? Do we worry more about application performance, visibility, some of the complexities of Intune. I mean, we could start with the interface and then go to the policies and the configurations that it can deliver or just keeping up pace with the security paradigms that are out there. Alright. This is a little bit of a cheat code. If you’re already a customer of Login Enterprise, which you are, user experience is already top of mind. If you’ve come from traditional VDI, you understand the importance of user experience and not just monitoring RAM and CPU. Right? Those two things are are not automatically linked. So, of course, I I we have seventy five percent care about the user experience and app performance, which is great. And then Intune policy complexity, I was playing with it last night. It is frustrating. I can tell you that. I think I had to recreate my my app deployment four or five times because of a portal bug, you know, kind of thing. So there’s definitely some complexity. I think in addition, it’s Intune to me is like the new GPO. Right? You get so many branches that at some point, these policies collide, and knowing what you’re going to get at the endpoint after it’s all said and done is anyone’s guess. I’m sure that tooling will get better, but as it is right now, I could chew my fingernails off just, going through Intune configurations. Alright. Now we’re gonna address the elephant in the room, and that is load testing. We’re gonna start with some myths. Right? I bought a fixed price PC. Why do I need to load test? You’re absolutely right. You don’t need to load test. But the reality is that you still have to validate your apps, your launch, your performance. I only need to to corrupt the DLL to break your application, and all of that’s gonna hit at scale. So although it’s not load testing and the infrastructure is provided by Microsoft, and if you need more, you can get more with a swipe of a credit card. Or I’m now persistent VDI. I have my own system, my own kit, etcetera. Even within those SKUs, Right? I don’t know if you’ve ever used their lowest SKU, the the two two CPU, four gigs of RAM. I couldn’t use it for just about anything. You’ll get into a SKU. You’ll start layering on your applications, and you’ll realize you need a different SKU. Right? And that can ebb and flow to some degree based on your application stack or your image. Be aware of that. And then finally, of course, Microsoft manages the infrastructure, so I don’t need to test. Oh, boy. Right? It wasn’t a couple of months ago that there was an outage at Azure. Right? They do a great job. But at the end of the day, it’s infrastructure guys taking care of servers so that you don’t have to. The pain has moved to Microsoft Teams, and they’re well funded to handle those. But it doesn’t mean that there’s no failure. So, of course, you do need to test. And, as all these new updates roll out, you need to test even more. So load testing goes away because the infrastructure goes away. So, luckily, the platform is more than just load testing. Right? So we have this shared server user density mindset that goes away. We used to to load test before go live because we could control it, stress the infrastructure to make sure that, you know, we’re we’re trying to save every sliver of a percent so we could get more density inside that environment, validate the thresholds, and run those point of time assessments, and then release. If we’re lucky, we had a production environment and maybe a staging environment, which almost no one had. Our new risk is the change velocity. Right? Now things are coming faster. Applications are splintering and fragmenting. I have twenty apps in my stack, thirty apps in my stack. I have twenty agents in my stack, twelve to twenty. With all of these different components running on different schedules with different updates, that change velocity is a real challenge. What we wanna talk through is going through this continuous validation mindset. Like like, let’s set something up that helps us and make sure that we can catch these with hopefully some some minimal effort. Right? Baseline, what does it look like when when it’s healthy? And let’s roll those baselines forward so as we go through our changes, we can figure out if we’ve hit a roadblock. Continuous validation should become the new default. Right? When we have a change event, an Intune policy change, an image update, a patch, that should trigger this cycle. We’ll go through a little bit of that cycle later in the presentation. Our recommendation is continuous testing. Have some continuous tests running in different environments so that as these, changes come through the gates and have unintended consequences, you can answer the question, are we good to gate to the next phase? Talk a little bit more about that as well. Validating those application launch times, performance metrics, UX scores, it’s not always linear. Right? So we wanna have these rolling baselines in these comparisons because we can get a small performance bleed that accumulates over time. And then finally, catch those regressions so we get them before they hit our users and, of course, let teams know. This application, we can let it go. I know it’s a security change. I know it’s super important, but you’re going to hear people squawk. Right? This this change is gonna slow people down in our we we have evidence. It’s evidence based. It’s gonna slow them down twenty percent. What’s the message out to the users? You can do a lot of good just by setting the right expectations for your users saying, we know this is gonna be a tight fit, but it’s important for security of the company. It’s important for compliance, and it’s important for this. And you’ll find that your your end users, some of them are just always unreasonable. But a lot of your end users will understand, and that will cut down the backlash. Right? So we wanna move from this periodic testing concept where we have a nice defined gate where it goes from dev to test, the staging to production, because we have those systems involved, as we move to cloud, just a continuous validation strategy. That means that we have eyeballs on each of these different environments. And as we push a change, we expect to see a certain result. If we get the result, we can move it on to the next change. Maybe you’re doing ring deployments. So you send in a virtual user to ring zero even before you send in your users. Because if the virtual user can’t get through the stack, the workflow, what have you, without error, your users aren’t gonna be able to get through it either. Ring zero is good. Load your users, get any additional feedback. You go to ring one. Virtual user goes in first, right, and stays in there. So as you load up your ring one or your ring two or your ring three, you have the constant pulse of that ring. So as you load it up, you get to see, does my performance change? Am I having an issue that wasn’t there when it was one user, but is there now that we’re at ten or twenty? Yes. Windows three sixty five are individual PCs per user and unlimited infrastructure. But that doesn’t mean there isn’t a choke point somewhere in your application stack or your configuration coming back through a network link, common application gets slow, what have you. So there are always these scenarios that you wanna guard for as you move through your ring deployments even. Right? Understand, did I hit a choke point? Is the VPN coming back to the database causing a problem? These kind of things. The old way, big bang test before go live, that’s your your big performance test. It makes everyone feel good. Manual setup, onetime scripts, months between site test cycles because we were slow. We know we have to get faster. And then just doesn’t necessarily catch the drift, right, depending on how we do our comparisons and when we do our comparisons. Do we understand what our baseline looked like, and are we diffing against that baseline? If we move to this new way, this continuous automated validation, we’re always on. We’ll talk about that when we get into the demo. We test on schedule. So anything that comes through gets picked up in one of those cycles. Regression alerts. If I have a challenge, I get notified in ring zero before I go to ring one, ring one before I go to ring two, etcetera. Session quality scores over time. Right? How am I doing? Yeah. You know, the the CRM was working great. It’s starting to slow down. We can see it coming. What are we gonna do about it? And let’s get some preemptive, proactive remediation. And then, again, just catching issues before users report them. We all say this. And the truth is the larger your organization, the more users you have. The more users you have, the more likely a user will catch your error. Right? There’s always a trade off between constantly monitoring and the resources that monitoring takes away from your users. So we do a five minute interval or a fifteen minute interval. A user can always sneak in that window and catch an issue that your monitoring hasn’t picked up, but your continuous validation can pick up the details. It can get a much deeper read on that. I wouldn’t call it a root cause, but it can definitely help you diagnose to a much if your users or, like, my users and they report a problem, they say it’s bad. And when you say what’s bad, everything. All the time. My cat, you know, ran away. My Excel’s not working right, and getting quantitative data from some of these users can be a challenge. But if we have a automated validation system, it will give us the information we need when we need it, and that’s gold. Okay. Poll time. How would you describe your current end user experience testing? So we have help desk reactive. We fix it when it comes up. Manual test before changes. It’s our favorites. Not nothing like having to QA a a change at seven o’clock on a Friday or ten AM on a Saturday. Scheduled automation. Alright. We’re getting there. We have, some regular patch cycles. That’s great. And then fully automated. I have a robot for that. I could probably tell you who the fully automated folks are. We do have some customers that have just done an incredible, incredible job. But I have good news for everyone. If you are reactive, we can help you in a hurry. If you are manual, we can help you in a hurry, and we’ll show you some of that in the demo. If you’re scheduled, awesome. Right? Let’s talk. I’d love to see what you’re doing and even give you some ideas that I’ve collected from around the organization. And if you’re fully automated, then I need to buy you a coffee because that’s incredible. For those people that are looking for fully automated baby steps. Right? It’s we we have a way for you to build your your program. No one got there overnight. But Login Enterprise is a platform, has a public API, and we can show you how to go from zero to hero in very, very short time. That public API lets you interact. It lets you push data, pull data. And so as you get toward that fully automated goal, the platform’s already there for you. So the bulk are in the manual testing before changes, but it’s pretty close between reactive, manual changes, and scheduled automation. We we wanna get you into scheduled automation as fast as we can. Nobody needs that kinda, stress or gray hair, and we’ll show you a little bit about how we approach that in just a few slides. Okay. Now it’s gone to my, my favorite part, which is this thing that we call So Intune, we really can map its change events, whether they’re patch and update events, policy and config changes, or just application life cycle events. We can map those to use cases for the product. As long as we’re doing a a decent job of packaging the application and setting the version, you get a version in the registry every time you deploy that application. I do have at least one customer that they run and pay attention just to that version. So if that version should change on one of their evergreen images, they can trigger an automation either through Jenkins or or some CIC tool to go further, to do some, pardon me, to do some additional testing and validate that before they add it to a general catalog. That’s a great level of automation. But these are some of the things that you can do. We can also check if that version didn’t install correctly. Right? So there are a great number of ways that we can capture early in the cycle some of the problems that you could have in just packaging and deploying the applications. And then we go into does the application open. Did I deploy a version that has a DLL conflict and just crashes? Right? I’m gonna try to simulate that in the demo in just a little bit, but these are things that we can connect with with Intune. There’s even a way to package a test part of your Intune deployment. So if you have an application, you can actually package a test right after that application. Intune will only ever respond to you that the application installed or did not install correctly. You need to check. Just because the application installed doesn’t mean it opens, doesn’t mean it runs. And this is where you can connect the automation with Intune. Intune delivers a package. That’s great. Now let’s deliver a test. We can either loop the test and just leave the machine on, have a continuous, test running that always checks. Is the application good? Is the application good? And you can go through version one, version two, version three, and get a consistency of that check. And that’s pretty easy to set up in Login Enterprise. You can go further. You can have that first test say if the version is still one, I don’t need to do the check. I’ve already done the check. And in this way, you can have some forward operating theaters that allow you to have a machine that’s getting updates as soon as they come out, validating those updates within fifteen minutes, and you understand if that new CVE patch or what have you is ready for prime time, and you can pull it through the rest of your cycle. That sets us up for smoke testing, of course. Does it can I log in? Yeah. I made a policy change. Can I log in to this desktop? I increased my back end for FSLogix. Is my profile still there? These kind of things. Application testing. Again, I’ve revved the version from one to one dot one. Is everything still working? It’ll also pick up the accidentals as I like to call them. And that is well, I didn’t mean for the config file to change, but somehow it changed. So the application version was the same, but something affected a downstream dependency. Maybe your virus scanner stole it. Right? Saw it as, you know, a new policy update on your virus scanner, and all of a sudden that executable is now marked as bad. Your application didn’t change, but something changed. And with continuous validation, you can catch that change. And then, what I recommend, we try to get you to as fast as possible if you’re not already there, and that is automated UAT. Right? So I spent twenty or so years in IT operations infrastructure. And getting folks to getting my application team to test their application changes after the change was made was like herding cats. We actually, have a customer that that monitors logins to their applications to see if when they send the word out to the app team to check their application is was working properly, if they actually even log in to the system and do the check. And it’s, like, twenty percent or some really, really low number like that. Automating the UAT is a process. You go to your stakeholder. You say, I’m gonna run this test. Every time you make a change, you have to make sure it’s the right test. And they say, yeah. More of this, less of this, then great. I’m going to capture this. And this is what I’m gonna run every time, and I’m gonna send you the report. If you don’t, stop it and the report is green, it’s gonna gate on to the next step. Right? We all have the same pressure. Right? Application teams, oh, the infrastructure teams are so slow. They’re taking too much time, etcetera, etcetera. Right? Remember how a lot of the app developers work. They make a change to an application. They push it via a commit to their repository, and they check a task done. Right? And they’re on to their next thing. How it goes through the rest of your cycle and your system? If business comes looking for that application update, the developer’s gonna point at you. Right? So let’s automate as much as we can. Let’s accelerate as much as we can, without putting our infrastructure in danger, our service lines in danger. New for the product as of six five. So if you’re not on six five, we would we want you to get there. We have productized the Windows three sixty five connector. You’ll see that here in just a moment or two. We know before it was a pain in the butt. Custom scripts to connect, manual, TOTP MFA configurations, recode every time Microsoft decided to move a button, change a button, what have you, and really because it’s that code, some real specialized knowledge. Right? If you weren’t good with C Sharp or with JavaScript, it was really rigmarole to to get there. Now with the new connector, easy setup. I’ll show you what that looks like. Unified across your instances. So now I can make a test and just point it at different things. Right? I can copy my test very easily. My connector is part of the launcher. So, again, we’ve reduced the overhead dramatically. Automatically supports your TOTP as long as you configure the components, and you’ll see that in a minute, and really more IT guided as opposed to specialized engineer. We also have done a great deal of updates in six five to our script recorder. If you’ve used it in the past and it left you wanting, we would ask you to take a look at it again, faster, finds more things, more intuitive in the UI. A great deal of work has been put in, and we’re still working on it. So give us give it a spin, and tell us what else you need. Right? So point and click, it will record the clicks. And we actually get two or three different pieces of information. So I get a full x path, and I get the old way of doing it so we can pick and choose which one we wanna use depending on the application. We do capture those inputs and give you the ability to expand the step and change your wait times. Well, I wanna wait a little bit more for this one. You can do it globally for your entire application script. You can do it per step if you want, and then, of course, replay it immediately. We have a run and record that we’ve had last couple of versions that will run it to where you last left off, leave the application open, and allow you to continue your recording and expand your script as you go. We want it to be easier for you to get in. We have a new knowledge worker twenty five. If you have an older appliance, you probably don’t have the new knowledge worker, but we keep up to date with the knowledge worker and its changes. We’re trying to make it easier for you to get started quickly and be effective quickly. So can always start with knowledge worker and get a great deal of coverage. And then as we have access to apps that are common across our customers, we add those to our docs website. You’ll see community workloads menu item, and that will list all of the different applications that we’ve captured that you’re welcome to download, put into your appliance, and and start running with. What’s your most likely step after today? For those people that are just getting started, do you have a full pilot or evaluation project that you’re going through? Are we gonna explore more of Windows three sixty five with Login Enterprise? Are we gonna build out a test program? Are we just gonna talk to our leadership and get some sponsorship? The features and the capabilities that we’ve talked about today are in the product. As long as you can get to six five, you already have them. They’re there for you when you need them. So there’s no additional licensing that’s required. It’s all built in. Okay. Twenty eight percent are gonna start an evaluation. Awesome. Forty two percent are gonna build out their program. That’s our next section. And then twenty eight percent are also gonna talk to their leadership. Always a good place to start. Right? Give you some time and some space to to make things better. The way that we look at it, just a very simple maturity model. As we discovered in the poll, some folks are still reactive. No real structured testing. Maybe just dipping a toe into Windows three sixty five, really trying to look at how you can apply some of these concepts and technologies. A lot of people start there. We we have a lot of customers that have started there, and our goal is to get you as close to to level four as fast as possible. We’re gonna talk about that a little bit, but it’s an interesting eighty twenty approach that that we generally talk through. You’ll get a lot of bang for a little buck if if we do this right. Manual validation, that’s just no fun. You know? Jeez. I gave the script to Jeremy. He kinda did okay, but, you know, then I gave it to Billy, and Billy didn’t do it the same as Jeremy. And so I can’t really compare the results. It’s, it’s why we and it’s it’s no one’s fault. Distraction. I’m tired. I don’t have time. I have an old version of the of the test steps. There’s all kinds of reasons why that manual validation falls apart, kinda breaks down over time. No one reason, but it’s the reason why we automate. Scheduled automation, again, let’s get some of these, routines in place. Even even at a small level, it will pay huge dividends. And then finally, kind of continuous change where anything that comes through the pipe is well covered by a multifactored, multistep program. So how do we go about doing that? Define your app portfolio is number one. But here, I would say, take your most problematic apps. Take your top five noisy apps, whatever those apps are. Most complicated, most often changed, the ones that people see every day or complain about the most. And here again, I would say, Do your eighty twenty. What I have found is across a large section of customers. If I take your top ten applications and we start making them better from the top down, somewhere, sometimes it’s after three, sometimes it’s after five, sometimes it’s after ten, you get a huge amount of relief just by better coverage, better congruency of that application, and then you can make your decision. What’s the cost benefit analysis to doing more? Now I do have customers that want every app in all the time, and I applaud that. But that is a that is a commitment and an effort. And if we wanna get value from this platform quick, you can usually get it in your top ten apps. Just be aware. Establish your baselines. We always kinda wanna know where we start. We measure. We make a fix. We measure again. And that’s how we can demonstrate improvement. Mapping your changes, I don’t know that you wanna map everything in Intune, but I think you have to map by group or by category. What are my policy updates? What are my application updates, and how am I going to handle those? Again, even if you start with some of the more problematic ones or the ones that are harder to find, it’s harder to find conditional access policies, what happened, when they went wrong. Pick those noisy scenarios inside of Intune, and let’s get those under wraps first. Automating your triggers, again, I’m gonna suggest that you start with just continuous validation. Can we automate later? Sure. But start with your continuous validation because that’s going to cover a big chunk of what could possibly happen. I used to tell this joke. Don’t tell it so much anymore because network guys get mad at me. I’d say nothing ever changes, and it’s never the network guy’s fault. Because when I was in operations, I would go home on a Friday, everything was perfect. And I’d wake up in Saturday with with, my phone blowing up, and someone decided to rewire a closet. Right? And all of a sudden, you know, the network guys are like, well, you know, everything’s perfect. What are you talking about? You know, we didn’t have a problem, and you had to prove that your application was suffering from congestion or something else. Right? So nothing ever changes, and it’s never the network guy’s fault. And then finally, let’s act on alerts and not tickets. We wanna catch them before our end users catch them. The bigger your organization is, the harder that is. But I do have, customers that said, if you can give me an extra two hours, I can usually solve most issues. So that’s what they wanted. They wanted a four AM check so that when their users came in at six AM, they had two additional hours to find and fix a problem, before it impacted their staff. Should look something like this. When you’re or when you’re building your program, you’re gonna get your critical app inventory, define your baselines, map those events, and scope. You’ll deploy your connector. You’ll run your first tests. Maybe you’ll record some of those tests with ScriptRecord. Maybe you already have them. You’re gonna baseline across your your cloud PCs, regions, as well as SKUs, and then validate and premigrate any data. You’ll go through your your migration process. Right? So if you’re moving into Windows three sixty five, you get a steady state of what it is, what we would call, zero. No one has you’re you’re in planning. You do your validation. These SKUs look like the right SKUs. When you get to build stage one where, you know, greenfield, no one’s moved in yet, Now I wanna know, that those configurations I have my baselines in place. So as I load up that environment, I can understand how fast I can move. That’s an that’s an important criteria in migration as well. How fast can I move before things settle back down and adjustments need to be made? Again, we’d love to think that once it goes to Windows three sixty five, there’s no other dependencies, but there are dependencies. There are dependencies on on premise data. There’s gonna be dependencies on different applications and how those can move and change. You’re gonna wanna know how fast you can move, not just whether it’s safe to move, but how fast you can move. And then, of course, the operate phase where you’re really post migration validation. I have a system in place. I’ve tested my tests. Right? I validated that my mechanisms to catch regressions actually catch regressions, and now we can move faster in there. This is about the time that if we load up those security agents and we load up those enterprise applications that we that are specific to us that Microsoft can’t test for us, we understand that we get our skew right. Right? So I had to move to four by sixteen just because some of the applications I use would absolutely dog. Then I turned on Copilot, and I had to skip my skew up again because the load on the image itself was just punishing to anything I was trying to do. And then we expand that that coverage. Once we have that model, we expand that model across the rest of the catalog. If I were to give you a thirty days, let’s go. Looking at week one, you should be able to get LE configured against your tenant and run three to five apps. Week two, we could map some of those change triggers and and be specific. Week three, we can start expanding that coverage. Again, I’m still going eighty twenty, set some regression thresholds, and make sure my regressions catch what I want it to catch. And then we get to week, four. I would like to see one completely automated cycle. Alright. Hopefully, we are ready for a demo. Here we go. I’ll go ahead and share my screen. Alright. What you’re looking at is MyLogin Enterprise demo lab. I have configured a continuous test. I’m going to walk through the configuration backwards and build forward. So let me talk you through the moving pieces. And, apparently, I only have to keep resharing my screen. Okay. This is my launcher, and my launcher is running, as you can see, the Windows three sixty five connector. Connector logs in. This green tree background, this is my actual cloud PC. And on my cloud PC, you’ll see login enterprise startup here in a moment, I have a regression app. This is an app that I built that I can monkey around with to force different failure scenarios. So I can set a switch on it that says, as soon as you open crash. And I can set a switch on it that says, delay the start time of this app by ten seconds. Right? And there’s a few other thing. I can make it spike a CPU and just a little fun that I’m having with this application I use. You may have problematic apps that you’re already aware of. I had to make one. So here, I’m gonna run a test, and then we’ll walk backwards through the configuration. Here’s my application. You see that I have it in a healthy state, and I just do a simple open close. That’s your smoke test. Open close. I’m good, and I can go back to my dashboard and see that I have clean runs. This runs continuously. So if I go in and I make a change, I’ll see it. So let’s talk about how we got there. So to configure this connector is only a few steps. First step, accounts. I took my account. We add some custom fields. This is the name of the desktop when I log in to my Windows three sixty five. That’s the tile that I see. That’s the name I put. This is my TOTP code. I went into my user account. I added authenticator. I said the other authenticator, and it says scan the QR. I said, I can’t scan the QR code. It gave me a number. That’s the number we put in here. When it authenticates, I get both a TOTP authentication, and I get a little pop up on my phone. I just don’t have to deal with the one on my phone. I’m doing this with my account to get, a demo up in a hurry. Ideally, you would isolate some test accounts, but they can still have MFA, and they can still go through the same process. These are the configurations, the the preconditions, if you will, a user account with a secure custom and, your desktop name. From there, I can go in and make my continuous test. I go to my connector. I use my Windows three sixty five connector. Yes. My cloud PC name is in, field one, and, yes, my TOTP secret is in secure custom one. We are ready to go. In my actions, I’ve just pulled my regression app. Nothing nothing too crazy. And in my test settings, I run every five minutes, and that’s my continuous validation. Any actions I want, I can record. I can put into this continuous validation, and it will just loop. I designate my cloud PC as ring zero. A different cloud PC is ring one. A different cloud PC is ring two. However, I want to group those. And inside Intune, as I deploy my application, I target my different groups. Ring zero, I deploy the application to ring zero. I have a test that’s already ready to catch it and validate whether it works or not. There’s one other thing that you can do that I do in all of my tests. This is available in six five and ready to go today. I also make an application test. I actually make two. These are exactly the same as my continuous test, same actions, same connector. The only difference is is this is a one shot. So if I wanna send it to ring zero and I’m not ready to do a full loop of the validation cycle, I can still use an app test to catch it. The app test up here with the Windows three sixty five connector does exactly the same login process that the continuous does, but it only does it one time. The next test I have in here is my diagnostic. Now this does not actually do the connection. And the way I use that is I’ll go into my continuous test. I’m just gonna pause this. And inside of my actual cloud PC, your test gives you this little piece of information here. This allows you to run just the application portion of the test. So I can copy this little hyperlink here, login p I, and I can run it inside my cloud PC without having to deal with the login. Maybe this is your smoke test. Maybe this is your diagnostic. A user calls in and says, you deployed an application to me and something broke. Well, I can run the same test with my end user that I ran for my ring zero, my ring one, and my ring two deployment. They log in. Call me up, Joe. Let me look at your PC. I now have a diagnostic I can run. And by running that, it just goes through your application cycle. Skips the login part, but it does produce a report. And with that report, you can see, did you meet the workflow criteria? Are your timings correct? Did your application function, and did it perform within the tolerances you set for your test? Collecting these will allow you to get through that testing cycle that we talked about. Smoke testing, automated UAT testing. So to me gotta find my mouse here. This is my automated UAT test. When I run this test, I get a report, and that report is in PDF form. And I know that it has been tested per the specification. I use the deployment rings and a continuous test to make sure that that stays good as it works its way through my process out to my production’s edge. This is a combination of things I use in logging enterprise today with Windows three sixty five to great effect. The last thing that we have is we do have an SLA report. And the SLA report on the backside will actually show you how you’re running. So not only do you catch it in the rings and you catch your regressions, but you can also report upward that we’re delivering this application into Windows three sixty five at, hundred percent no latency and eighty six percent or better, application success. Right? All of your metrics are here, and it’s easy for you to report. They say eighty six is not great. We gotta make that better. You know from the diagnostic what will make that better. App start time for here is is a bit high. It’s approaching our tolerance a little too closely. We either have to change the tolerance or go back to the application team and ask them why their application is so slow. Right? Evidence based work, and we don’t have to explain why why these things are are happening. It’s not my fault. I didn’t write the application. I just need to make sure that the onus is put where the onus is due. And, hopefully, that makes sense. Okay. Let’s get back to the presentation. Why log in enterprise for Windows three sixty five? You saw I put my regression on a five minute cycle. Every five minutes, I’m gonna do a check and make sure what I thought was good is still good. Hundred percent coverage. We should be able to cover anything you’re pushing through Intune. It does hit that cloud PC. We have a way to test it if we know about it. And then, again, just accelerate that issue detection. I’d love to catch you early in your cycle. But even if you went straight to your Windows three sixty five in production and hit this, you’re gonna find your issues a whole lot faster. And then with that concept of a desktop connector, you can do that for continuous. You can do it for application test. You will understand a little bit deeper as to what happened, why it’s off. Catch your continuous automated testing, baseline your performance, capture Intune changes, and we do it from as you saw with the connector, I log in the same way your users log in, and that’s the the benefit of Login Enterprise as a platform. Okay. If you need to know more, pull out your phone. You can start scanning some QR codes. Again, this deck will be sent as part of the follow-up. If you want more information, we can go into a deeper dive and a customized demo for exactly what you’re trying to do. Talk to your customer success representative. Tell them what you wanna do with it, and they’ll put the resources together to give you something very specific to your scenario. And I wanna thank you. As I mentioned, you will have, we have a couple minutes. I’ll go through a couple of questions. We have a POC going on Windows. I already use Login Enterprise. We’re looking to modernize our testing approach. Whom should I reach out to? Best, answer is start with your customer serve success representative. They’ll pull a team together that will, focus in on exactly what you’re trying to do and build a plan. And then we also wanna include regression testing for applications installed on cloud PCs, Simple tests such as opening Outlook, sending, receiving mails. Yes. Most of this, of course, it’s all part of continuous validation. Again, talk to customer success because when you start talking about sending or receiving email, we have to have a a sender and a receiver, and we wanna talk about what that looks like particularly. But if it’s not interactive like that, we already have the knowledge worker twenty five you should check out. If you already have it, great. Use it. If you don’t have it, download it, put it on your appliance. It covers the OfficeSuite. It covers Edge. We even have, some three d modifiers if you’re doing GPUs and whatnot. Definitely talk to your your CS representative because they are gonna drive this forward for you. They will put together the resources and put those resources in your path to make you successful. Folks, thank you very much for your time. Reach out to anyone on the on the login BSI side via support services or customer success, and we’d love to engage and further the conversation. Bye all.
