Course Transcript

1.

Hi, we are going to talk about the Windows application story. There are so many different ways in which we can deliver applications to Windows 10 and to our Windows 10 users, and we are going to explore those different avenues, those different channels for delivering the applications. And there are some significant changes here. So for instance, we now have a single Windows store, and yet we have different ways in which we can access Windows store applications and deliver those into our organization. So you might be a company that does not use much in terms of Windows store apps. This might change your mind and you might be able to leverage the Windows store more often. Then we also have some concerns about application compatibility, so we are going to address those and talk about techniques and different application delivering methods like Azure RemoteApps, or running your application in a cloud, or running it locally, or virtualizing it with App-V. So we are going to talk about the changes in the application story with Windows 10 and the variety of different technologies that help us address some of the problems with managing applications in an IT organization. So everything from delivering them, and supporting them and then the compatibility. So, let's have a look at the Windows10 application story.

Back to top

1.

There is more to delivering an application to the desktop than next, next and the install wizard. At the end of this topic, you're going to have a pretty good understanding as to the different choices around application delivery in Windows 10 – the conventional methods and some more unconventional methods. So how do you get your applications? Now this is an important question. After all, we don't install Windows just for the sake of Windows. We install Windows so that we can use it for two main reasons. Number one – we use it to work with our digital data and get stuff done. And then number two – we use Windows to run applications to help us work with our data and get stuff done, right and oh yes, watch stuff, watch – you know – Netflix, Game of Thrones, whatever, so work and play, apps and data. Otherwise, I mean, what is the point to Windows, right? So this question is important as it relates to the immediate reasons we use Windows.

So here's a quick outline of the different ways in which we have applications delivered to Windows. We have traditional methods. We've got good old-fashioned installation, virtualization methods, presentation methods, and connection methods. Now what I want to do is go through and break into each one of these and talk about the details and really kind of look at what options are available to an organization when it comes to delivering users the applications they need so they can get stuff done. Now we might also rely on some virtualization technology to deliver applications. And there's a couple of ways in which we might do this. Now remember the key word behind virtualization is abstraction. By that, what we're doing is we're taking some steps away from what has traditionally been our approach and we're abstracting it, creating kind of a new reality from virtualization. So now we want, of course, to deliver an application. But we're going to virtualize that application, so it's less of this and kind of more like this. Meaning we're going to take the application and put it in its own container, and it's not going to actually have an interdependency on some of the same parts of the operating system. There is still a dependency with these virtualized apps to the OS, but not the same kind of dependency. In other words, they kind of run inside their own container writing to files, writing to the registry that belongs to them. So we virtualize those components as opposed to actually using the real registry that belongs to the operating system.

So this gives us several key advantages. The actual deployments are far faster. They can actually be available offline, so you can deliver this application over the network in a streaming approach or cache them on the machine. So, if the network is not available, the applications still execute. This does require a client, and we call this application virtualization – App-V. Now you might also have additional licensing requirement. So, with virtualizing our applications like this, there is an infrastructure, there is an agent, and so there is also a licensing requirement that might come into play. All right, now one of the benefits to this is side-by-side compatibility. So earlier when I was describing kind of traditional installation, how that lends itself to compatibility problems with App-V because they run in separate containers, you can have more than one of these running side by side – could be the same app, but different versions. There is no conflict because they're not actually talking to the operating system registry, but they're talking to a virtualized registry. So they're kind of fooled a little bit. We're lying to the application giving it a registry that it thinks it's writing to. So these two apps – like two version of access – can run side by side without interfering with each other, which is great. And then what you have is potentially easier application life cycle. So there is a better updating model with these types of applications as well. So I would suggest to you that the downside to this is going to be the infrastructure and the licensing aspect. So it may not be an option for everybody, but it's well worth investigating as an alternative to the traditional installation model.

Back to top

1.

Now here's the other virtualization option for delivering an application and that's to run the application in its own dedicated virtual machine. This gives it its own full operating system where it's going to be installed in kind of perhaps the traditional way, could also be an App-V installed inside of a virtual machine. Nevertheless, we've got a dedicated environment for that app. This is useful if the application is kind of landlocked to a specific OS – doesn't support Windows 10, only works with, say, Windows 7 or only works with Windows XP or maybe it's a Linux-specific application so it requires the Linux operating system where you can create a virtual machine for that application. Now that's an entire OS for the VM. So there's a bit more overhead to this. And don't overlook the fact that you're running not one OS now. Now you're running two or three operating systems. So, for every virtual machine you're running, you've just added additional administrative overhead in terms of updating them, keeping them patched, and supporting them. So this might be beneficial for testing. It might be beneficial for trying out new products, might be good for developers especially if the developer needs to kind of test their platform or their application against multiple platforms. But, for application compatibility, it's useful. But, if you have an alternative, that might be preferred because of the additional overhead and complexity that running the app in a VM requires.

All right, the next one on our list is presentation. And, with presentation, we're using RDP – the Remote Desktop Protocol. So we're not installing it on the user's machine either in a traditional sense or in an isolated container like App-V or into a virtual machine running on the user's machine, no. This is actually a network-connected application. So the application is installed on a host – Remote Desktop host – and the user is using a Remote Desktop client to connect to that host and access that application. And so it's being presented or projected to them from over the network.

Now there are advantages to this – the advantages similar to what we have with some of these virtualization technologies in terms of compatibility, the fact that you can run more than one type of application, one installed on the user's machine and then the user can access a noncompatible application through the Remote Desktop window side by side. And that's because, right, the application is not actually installed on the user's machine. So there are situations where this can help with OS compatibility. That's what I am trying to get out there. The downside to this is you have additional licensing that might be required, subscriptions if it's in the cloud, some additional infrastructure if it's on-premise with licensing. So there are some requirements in order to host the application over here. Another benefit to this is you can have a wide variety of different user devices accessing the application using Remote Desktop including customer- or employee-owned devices, right. So BYOD scenarios work well with this because we're not installing the app on to the user's own personal device. And so, when it comes to accessing or delivering the application, we don't necessarily have to install it on to the user's device. There are other ways to deliver the application, say, over the network, like in the case of using RDP.

Now here's another network-based way of delivering an application and that is again the users connecting to it. But what is different about this approach versus the RDP approach is this one is using like a web browser or maybe a specially designed client that's installed on the user devices. If it's a web-based application, this makes it a whole lot easy to do, compatibility is less of an issue. We just want to make sure that the browser can support the application and the user needs to have appropriate credentials. There is a wide scenario support here for the client machines. They can be personally owned or maybe corporate owned. And, depending on the infrastructure, we could support other types of scenarios like Single Sign-On and maybe even multi-factor authentication. But the downside, like Remote Desktop is, it may require an infrastructure on the server side to support those client connections. And then, if the application itself has an agent that requires deployment or requires certificates installed on the user devices for authentication, well, then there's that added overhead along those lines. So, as you can see here, we've got a range of different ways in which we can install and deliver applications. We can bring the application to the user and install it in the traditional way. We can go through and abstract the way that it installs. Or we can put the application out there on the network and provide a couple of different ways in which the user can actually reach out to the app and connect to it.

Back to top

1.

Okay, you may have heard this somewhere already or you may have heard it from me from, you know, a previous video but Windows 10 supports two types of apps. It supports what are called desktop apps or Win32 apps. And it also supports what are called Windows apps or universal apps. These Windows apps are designed on the new universal Windows app platform. They're delivered typically from the Windows Store. They really got their start in Windows 8 and have since kind of evolved. Now our focus here is on desktop apps. And I talk about the universal app platform in an entirely different set of videos. But here we want to talk about those desktop apps, again, they're called Win32 apps and they're really your traditional Windows App Model. Now when I say traditional, you might think of that as another word for legacy but legacy suggests deprecated – that's really not what we're talking about here. These desktop apps may not be the latest application model for Windows 10 and yet they're very, very significant. They have present day significance and that's because some people think there are over 16 million of these different applications out there. And for you, you might have some line-of-business apps that fall into this desktop app category, so you might call them arterial apps. They are the lifeblood of your business. So legacy – that does not apply.

So now, in this section, what I want to talk to you about is desktop apps and how we can install those into Windows 10. Now for you old-timers that are watching this, you might actually be surprised with me in this next section. And I say old-timers because some of you are real familiar with kind of how apps are installed onto the system but I want to show you some new installation methods that go beyond kind of the traditional next, next, finish. So it's my hope – at the end of these next few slides, well, you might even be using PowerShell to actually install these applications. So let me show you what I mean – bear with me and look at this. Over here on the left, we've got different origins for the application. Over here, we've got the Windows Installer service that can take the installation files for the application or we might have another installer and it could apply that to our system. And that means we have files being copied, different parts of the operating system. There is also an important step where it gets written into the registry, gets registered as part of the operating system here. Now the good news is this – this process that we're describing here, the Windows Installer process, well, that still applies to Windows 10. And the reason that's good news is because there are millions of applications that support this process and those traditional Windows applications, many of them will still run on Windows 10 but there is more.

Now Windows 10 supports installing Win32 apps in other ways besides using and relying on Windows Installer. For instance, Windows 10 can use App-V packages. It can use an App-V infrastructure. The administrator can take App-V packages and deliver it to the client machine via that infrastructure. So let's say you have a line-of-business application, you don't want to deliver it the traditional way but take advantage of the benefits of App-V. Well, you can sequence an application and deliver it through your App-V infrastructure. And what that does is that runs the application in kind of an isolated container on the client machine in what Microsoft likes to call a sandbox. Now there's more, you can actually upload your line-of-business applications to the Windows Store and have it delivered the same way that those universal apps or those new Windows apps are delivered.

Now the way that that works is similar to an App-V package. You take your line-of-business application and it's going to basically be put inside a similar type of container or package and it gets delivered here to the machine. So, for example, now the Windows Store can also do this. You can actually take your line-of-business application, put it inside of a package similar to App-V and deliver it to the client machine via the Windows Store, just like those universal apps or Windows apps are actually delivered to these client devices. So, for example, you could take like Adobe Photoshop – that's a Win32 application that can actually be installed to the client machine from the Windows Store. Now when it's actually deployed down there, it's not installed in the traditional way, it's running similar to App-V in its own kind of virtualization container. Now what that means for us is that the Windows Store isn't just for those Windows 8, Windows 10 universal apps. The Windows Store has been expanded to become like a retail super store. It's like those super Walmarts, which no longer just sells clothes but also sells clothes, auto parts, and groceries. In other words, the Windows Store offers, in terms of applications, more than just Fruit Ninja. Now some organizations might decide to move their app to the cloud – that's another option. We call that Software as a Service, so couple of examples of this. You might have your users connecting to Office 365, or you could take your line-of-business applications and actually store them up here in Azure RemoteApp. So the client is connecting to it using Remote Desktop Protocol, and the application is hosted in Azure services.

Then there is this fourth and final option I want to mention and that's called OneGet, which is a package manager built into Windows 10. What that means is Windows 10 has built into it a Linux-style package manager, which means that you can actually browse, search, and install application packages that are in web-based repositories much like the way Linux does that. OneGet is new, and it's going to allow you to use PowerShell to install applications in new ways. Okay, so let's step back for a moment. Now the main point here is you and I have additional ways to deliver traditional desktop apps beyond the next, next, finish. I know many of you probably have some additional questions about how each one of these work, and what I want to do is ask you to keep watching because this is just an overview. I am seeking to answer those questions.

Back to top

1.

OneGet – well, what is OneGet? Well, to answer that question, let me tell you a story. C Linux user compile code instead of using install.exe. C Linux user compile code again and again. C Linux user angry at compiling code. C Linux user use a package manager instead and download the application from a repository. C Linux user never need to update the app and compile it again. C Linux user dance with glee. C Windows user clicking next, next, and next again. C Windows user jealous at Linux user. C Windows user get Windows 10 and is now happy because it has a Linux-style package manager. Okay, that was a cute story. Basically Jason, you're telling me there's a package manager in Windows 10 – now that's a whole lot like Linux. Yes, it is. It's called OneGet. OneGet is a PowerShell module designed to apply packages much in the same way that Linux has been doing for years. Now the benefits of OneGet are these – number one, you'll have simpler installs; number two, simpler uninstalls; number three, the ability to search the web and search web-based repositories for these packaged applications; and then number four, a more seamless update model.

Now, in case you don't get OneGet, here's another look at it. OneGet is a unifying system for software installation. Well, what does that mean? Well, let me tell you more of the story here, right. OneGet is related to what is called NuGet. And NuGet was something developed back in 2010 by some developers to help them with accessing libraries. Essentially, these developers wanted to mimic what was going on in the Linux world in terms of package managers and how those were making their lives easier. So then along comes what is called chocolatey.org, this web site, which is a repository for Windows apps. It's kind of a funny name, right. So you've got chocolatey.org. And then you've got NuGet, chocolate NuGet. And what turned out to be kind of a small project actually expanded and became quite popular. So you might even go to chocolatey.org right now and check it out. You can see what I am talking about. Now Microsoft designed OneGet to work with Chocolatey that's actually built into Windows 10. And that means you can use PowerShell to search chocolatey.org or other types of web-based repositories and then you can download those applications and those application packages and install them with the help of PowerShell. Now you can expect OneGet to actually grow in capability and support these additional repositories in the future. You might think of OneGet as a unifying system meaning simply this – it's a universal package manager like one package manager to rule them all.

[OneGet allows the admins to manage software repositories, search and filter software repositories, and install and uninstall packages with PowerShell.]

Back to top

1.

Now, in this section, we're going to take a look at App-V and we're going to talk a little bit more about how application virtualization works. Now to understand application virtualization, I want to begin with an idea. I want you to think of your computer in layers, okay. So let me actually draw this out. So we've got one layer here at the bottom and that's our hardware. Up above that, our operating system. What is the next layer? That's our application layer. And then you could say up above that – this is our user data and our user settings there. So I want you to think here about your computer in layers. Now the historical computer, the historical PC, the mythic system of the 1990s – really tightly integrated all of these layers together. A single operating system married to a single set of hardware, applications entwined with that operating system, user data and settings on top of that.

Now I've tried to come up with a metaphor for what this model is – haven't been very clever – so forgive me if this is a little weird. But imagine a train that's a single car, that's the engine, that is the caboose and the cargo – all in a single car. Now I have a friend who works for the railroad, who will probably tell me that's a pretty dumb idea because it's not very efficient. And he might even check the contents of my drink if I suggested it to him. And that's because the current train is far more modular. The modular nature of present day trains makes it actually far more effective because, well, we can have multiple cars, not just one car. And those cars can be switched out for different types of cargo. And then we're able to actually support or integrate with other types of shipping systems like containers. And so that makes the current modern day train far more effective than if it was all collapsed into a single car.

Now what I hope I am saying to you is obvious in regards to the historical PC because that historical PC been all in one single car is very inefficient. Now I remember back in the Windows 7 days, a Microsoft representative came to the organization I was working with at that time, and they gave us a presentation about MDOP and App-V. And in that presentation, they explained that one of the things that they're trying to do is decouple these layers from each other and making them more independent – more like those train cars that I was just describing. So now, if you want to transform the PC and decouple these layers from each other – transforming it from a single car into what looks more like the modern train – well, then what you would use is virtualization. Virtualization is the keyword my friends. If you want, for example, more than one operating system to share the hardware, well, then you're going to put it into a virtual machine. If you want to decouple the OS from a physical hard drive, well, you create a virtual hard disk instead. If you want user data and settings to be able to roam, well, then you're going to virtualize it by using user state virtualization. And, if you want the added agility and portability that comes with roaming applications and delivering those applications independent of the operating system, putting your applications in their own train car, well, that's where you virtualize the application layer as well. That's where App-V comes in.

Now when a user double-clicks the icon for an App-V application, it doesn't execute in the traditional way. And that's because it's not been installed into the system the traditional way, instead that application can be streamed from over the network or perhaps it's loaded inside the local cache, and then the application executes and runs inside of an isolated environment. And this environment Microsoft likes to refer to as sandboxing. Now the next question you might be asking yourself in regards to App-V is why. Well, there are several reasons why you want to consider App-V because it decouples that application layer from the operating system. And that translates into several benefits.

[App-V deploys applications to end users in a nontraditional way. In App-V, the applications are transformed into streamed packages for faster deployment and isolated execution.]

Let me give you some examples. Number one – it lowers the total cost of ownership. Now you want to evaluate this for yourself of course but App-V can lower the TCO or Total Cost of Ownership around things like deployment and support, especially if it's part of a larger solution. That is, you take App-V and you mix it with VDI or you mix it with System Center deployments or you mix it with Virtual Machine Manager deployments. So you can use App-V for server apps as well or you mix it with other types of virtualization like user state virtualization. So when it's part of a larger solution, you start even getting and gaining other types of reduction in your total cost of ownership but there are other benefits as well. Let me give you some other examples of this. Number two is it's customizable and by that I mean, you're not waiting on the vendor to create a certain file type for you – you can actually sequence and create your own App-V packages. So this works with line-of-business apps – that's pretty neat. One of the reasons why that's beneficial is because number three – it lowers application conflicts. So application virtualization can help improve address compatibility issues that you might have. You can run these apps in these isolated environments. And, if these apps normally would conflict with each other, well, they wouldn't because they're in these isolated containers. So you can have like different versions of access on the same machine. And, of course, it's also going to be great for testing and for migration scenarios as well.

Now there are some other benefits as well. So another one would be the update model. I really like this aspect of App-V, and that is App-V packages are centrally stored. And so when the app bits change, you actually update them on that central storage, and then just the differencing comes down to the client machines. So when they go to execute the app, you're not waiting for the traditional kind of updating process, instead just the differencing bits are downloaded. So the updating model works really well for line-of-business apps that don't necessarily have their own kind of updating model built into it, and it also reduces some of the time it takes and the complexity around updating these applications. And one final benefit I want to mention. And that is the installations of these App-V packages – overall they're faster than the traditional installation method. So when you combine these different benefits, well, that takes us back to the first benefit I mentioned, and that's the fact that it reduces the total cost of ownership – that's the why behind App-V.

Back to top

1.

All right, here's a diagram that makes you happy. And that is, it shows me the before and after – what happens before an application becomes sequenced and gets packaged with App-V technology. So, before that happens, the application is writing directly to the registry, it's writing to the file system. Well, what we can do is we can turn around and sequence that application, put it inside of its App-V container. And what that does is that creates this little App-V bubble. So the application now is not writing directly to the registry. It can still perform read operations for other parts of the operating system. So there's still a relationship between the OS and an App-V application. But write operations are done actually to its own virtualized registry here and in its own kind of isolated data here. So, by isolating the application and giving it its own registry and its own folder and storage location, it's really happy. It thinks it's interacting with the system in the same way, but it's actually not. It's put inside this virtual container. This is how we're able to accomplish the compatibility we're talking about. This is also how we're able to accomplish some of the other benefits around App-V.

So here's a look at how App-V applications are installed. Over here, we have our line-of-business application that gets sequenced. That sequencing procedure results in a package that can then be delivered by the App-V infrastructure. And that can also include integration with System Center. The user double-clicks on the application and the bits are streamed to it. In fact, the user can start using the application even before the streaming is complete. That's how fast the install is. If something goes wrong with the application later on, one technique you can employ to fix it is just simply delete the application from the cache. So, in that stream down there, the App-V client maintains a copy of it in its cache. Now alternatively, you could actually – if you wanted to – build a stand-alone installation for that App-V package as well.

[To troubleshoot an installation, check the Windows Installation logs. To manage the cache, use the App-V client MMC.]

Back to top

1.

The next thing I want to talk about is deploying Office 365 to Windows 10. Now we have a question, what is Office 365? Well, it's likely many of you know what Office 365 is and maybe you can share a little bit of information with your neighbor who is asking or look at this list right here. Office 365 is the office you love, but it's stored in the cloud. There are also additional tools and cloud-based services that are available up in the cloud. This is subscription based. Now that doesn't mean you're running it from the cloud per se. There are offline plans, you can have it cached. Actually there are different plans for our different-sized organizations. So it's pretty diverse in terms of the deployment options and the way which Office 365 can be used and what products are included with Office 365 – pretty cool stuff. Now the next thing I want to look at is deploying apps using Intune. Intune is Microsoft's mobile device management solution and it has an app deployment feature that supports Windows 10 as well as other non-Microsoft devices.

[Office 365 is a collection of cloud-based productivity services such as e-mail and word processing.]

Now this gives us a list of some of the features or characteristics of Intune providing our applications for us. One of the key things here is the diverse style or types of applications that Intune supports. So it will actually install or deploy Windows 10 native applications, so as universal apps as well as those Win32 or Windows Installer apps. So, if you have an MSI file that supports silent installation, Intune can deliver that to devices for you. You also have support for Android and support for Apple packages as well. So non-Microsoft apps can be delivered. Now you can then install these applications by requiring them to be installed, and you can uninstall them. You can actually advertise them and make them more optional so that the user can pull them down if you want them to. Now there are some specifics depending on the type of package or the type of application. So there are some differences between an Android and an Apple application package for instance. Quick example of this is iOS requires now that you're member of their developer program before you can actually deploy their IPA files – so those types of things. That's not the case with Android. But there are some differences you want to look into in terms of supporting non-Microsoft apps. Now apps can be published to the company portal where they can be downloaded. So there is integration with the private store. It also supports sideloading, so out-of-Windows Store application models and then using external links, using a link to an application in the Windows Store is also supported in Microsoft Intune. Now Intune supports sideloading that is deploying the applications outside of the Windows Store. Here are the requirements. These are pretty obvious. You're going to need an Intune subscription, you're going to need bandwidth, and you're going to need space.

Now what this slide does is it reminds me that if I want to deploy an app package for Android or if I want to deploy a Windows Phone package, I definitely need to make sure that my authority is set to Intune, and this is a setting that's in the Intune administration portal – just one of the requirements I want to pay attention to. Now there is an installation type called deep links. And this allows me to reference an application that might be in the store. So I can deploy a policy that says, "I want this user to install this application" and reference a deep link to that application's origin in the company store or in Windows Store. Now this is the process of using Intune to deploy applications. First thing we want to do is make sure we meet the requirements, we have support in Intune for that particular application type. We need to create the appropriate group – users group or device group. Those are going to be the targets of our deployment. And a lot of it depends on how we're actually going to do the install. So there are a couple of ways in which we might perform the application – the application installation action, if you will. So we can require an install for certain users – a targeted user group. We can also make devices, enforce them, and require them to install the application. Then we can make an application available and that's just for users. That's where we're using like the company portal and we're advertising the application and the user can manually select the app and have it installed. Now, before they can even do either of these, we have to make sure that the application of course is published and we've deployed it. And then, once it's installed, we can use Intune to monitor and manage the application.

[There are five steps involved in Intune app deployment. In the first step, verify the app support in Intune. In the second step, create groups for targeting. In the third step, publish the app in Intune. In the fourth step, deploy the app. In the last step, monitor the app.]

Back to top

1.

So now we're going to talk about Azure RemoteApp. Well, I'm going to show you how to configure it, tell you what it is, why you would want to use it. Now Azure RemoteApp is a way to truly access Win32 applications from anywhere – so from your office, from your home, in a box, with a fox, on a train, right – anywhere. Now Brad Anderson of Microsoft puts it this way – he says that Azure RemoteApp is a way for users to be productive using the devices they love. In other words, you can use Azure RemoteApp as part of your mobile device strategy offering Windows-based applications, your line-of-business apps, those Win32 apps, whatever. You can offer those apps to your users even if they're not running Windows – pretty cool. So what exactly is Azure RemoteApp? Azure RemoteApp is a Remote Desktop service. It's where we're hosting our applications on Windows Servers in Azure and connecting to it using Remote Desktop. So your applications are published, they're centrally managed, and they're protected. Now that means at the same time, users can then access these applications from anywhere as if the applications are running locally. And they can do this from any type of device – from Windows, from Mac, from iOS, from Android.

Now let's think of some of the other benefits here too. Because it's in the cloud, there is less infrastructure. So there's potential cost reduction, there is support for legacy applications, and think of the fact that you also get to enjoy the elastic nature of the cloud. That means when you have busy time, say, like during the holiday season or maybe you have a tax season or maybe you have a busy time during the week, well, then the application can actually scale. And then, when you have less connections and it's less busy, then the application can shrink. So that's one of the benefits of using the cloud is the elastic nature. Now there is also some security here. Security is a huge benefit because you're not actually storing data on the client's devices. Instead, you're able to store the data in a secure centralized location in the cloud or maybe on-premises and not on the user's devices. That makes RemoteApp inherently more secure than many of the other strategies from mobile applications. So, when you take all of this together and the ways in which RemoteApp addresses a lot of common pin points around mobile devices and access to our line-of-business apps, well, RemoteApp addresses a lot of those concerns, does it very effectively, does it securely. And so that makes RemoteApp a really attractive, powerful option as part of your mobile device strategy.

[There are different features of Azure RemoteApp. It is scalable and easy to use. It deploys Office, Win32, and LOB applications. It is a centralized storage and data stays off the devices.]

So let's talk a little bit about RemoteApp requirements, okay. So we need to have an Azure subscription because we're using Azure. We need to have a client app and an image. There is reliance here in RDP. So we require an Internet connection. And we want to make sure that RDP communications are not inhibited by a firewall. We also want to make sure that we have an authentication identity model that's going to work for us. So that might mean using Azure Active Directory accounts or it might mean creating an integration – hybrid solution as it's called – between our on-premise Active Directory and our Azure services. So there are a ways of doing that. And then you might have some other application requirements that might apply. So, for instance, one of the things you have to be aware of is that your application has to be able to run in Windows Server. So, if you're going to deliver via RemoteApp, it needs to run in Windows Server, which in many cases if it's a Windows app, it should work in either context. But you'll have to test that to determine whether or not it's going to actually be compatible. Another thing you have to be aware of here is that the application needs to support multiple users. So it has to be multiuser aware, which means does your application supports switching users, like that feature of Fast User Switching. So that's something you have to kind of factor in there. So those are a couple of issues that are easy to test, right. You can just install it on Windows Server 2012 and then check to make sure it's got multisession capability and make sure the application is going to work properly. Another thing I should point out is you want to kind of evaluate the resources that you're going to need. And that's going to affect kind of like how you built it out there in Azure. It's pretty straightforward though and pretty simple. And then one other final thought here when we're talking about app requirements is that Windows Store apps are not supported. So this is really a solution designed for your Win32 apps, your desktop apps. That's the primary target for this solution.

Back to top

1.

So let's have a look now at how Azure RemoteApp works. So as you can see here, we've got our RDP connection and our clients with a variety of different devices over here. They need to have an RDP client which...you know, all the major operating systems – we've got support for an RDP client for them. They're going to connect to the published applications over here, and these are actually generated from what are called templates. So Microsoft has some prebuilt templates here – some basic ones. Now one you can try, and there is one for Office 365. Those are kind of read-only templates, so they're prebuilt and designed for delivering Office but they are not one that you can actually make any edits to. So, if you have a line-of-business app that you want to upload, you create a custom template and upload it there. And then those are going to be hosted in Azure serverces – that's kind of server and services put together there. And so technically, that's a Remote Desktop Session Host that's taking care of that for us. So this is very similar to the Remote Desktop kind of infrastructure that was available and still is available for an on-premise type of solution.

So, if you have Remote Desktop servers, you have VDI type of configuration, you got your Remote Desktop Gateway server, you have your licensing server, you got that whole infrastructure. Well, then this is a very similar type of approach but you're eliminating some of the need behind actually maintaining those servers and the infrastructure, and it's all being done for us here in Azure. So it's very similar type of idea. It's only in the cloud. And it's kind of a progression, right. So went from Remote Desktop to VDI to on-premise kind of solution there, and then we're up here now using our Remote Desktop in the cloud. All right, so this is a basic idea of how the relationship with these connections works. One thing I do want to point out here is that when you build your custom templates, you want to make sure that you're not storing data inside the templates in the published application themselves. So Microsoft highly recommends that your application data is stored outside of the template. I mean there are security reasons for that and also it affects scalability. Because remember, this application can be scaled out across multiple session hosts if there is a network demand for it. So to avoid affecting that in a negative way, well, make sure you've got your data set up in an external location.

Now you might have several other steps that you have to configure to facilitate user access depending on your identity options. So you've got two different identity options here. Azure Active Directory is going to be the one we use with standalone but then you can extend it and synchronize really with your on-premise solution. And there is a couple of ways in which that can be done. You can synchronize your passwords here. So another important part to this beyond what you have in terms of kind of your basic connection is the fact that in a hybrid configuration, we have to extend our identity services using Azure Active Directory sync and then connecting to our on-premise environment.

All right, here are some basic steps in configuring Azure RemoteApp. This is really kind of an overview. There are specific steps or additional steps you might need to take depending on the specifics of your implementation. But to give you a general idea, of course, we need to have an Azure subscription. So you might have one already, Office 365, maybe even an MSDN allowance, or even vested in Azure and other services. If not, you can, you know, just use the trial and check this out. If you're doing an on-premise integration, so a hybrid deployment, then you might need to configure Azure Connect and directory sync there. Then what you do is you create a collection. You go into the portal, and you select RemoteApp and quick create and go in and create a collection. This actually is like less than ten clicks, so you set that up. Then from there, we're going to publish our RemoteApps from our images. So we remember we've got two different types of images. The prebuilt ones – there are like three of those at present. And then custom ones, which you might want to create. And then you configure user access. Now when you go to configure user access, there might be some additional steps there like, for instance, if you have Azure Active Directory Premium, you might want to enable multifactor authentication, you might also want to configure conditional access policies. So there might be some additional steps around there.

Now there are several steps around configuring on-premise Active Directory to support Azure RemoteApp. So the idea here is we need to have full access on-premise network, so there is going to need to be a physical connection and a creation of a virtual network there in Azure. In this way, users can log on with their corporate credentials and basically create a federation with Azure Active Directory and your on-premise Active Directory. So they can use domain credentials to access Azure RemoteApp. That's part of the experience. Now a couple of important things here. You want to make sure DNS can resolve, you know, domain controllers. You want to make sure that you have proper name routing. So between Azure and your on-premise environment, there is what is called a domain suffix. In Active Directory, we call them user principal name suffixes that you have proper name routing. You may need to configure UPN suffixes. And then configuring these last two here relating to configuring the synchronization between Azure Active Directory and your on-premise Active Directory. And so you can create and use what is called Azure AD Connect or DirSync is what it used to be called. And there is a couple of ways you can do this. You can do this with federation server or without, depending on really where you want the authentication to occur. And then you can also enable or not enable password synchronization. So some of that has to do with security implications. Like, for instance, you may not want to store password hashes on the cloud. So you might use federation service to make sure your on-premise servers are doing the authentication or you can do password synchronization, so Azure Active Directory will authenticate the users there. So there are a couple of different ways you can approach that in regards to setting up federating your two different identity services there.

[The steps involved in the AD DS configuration for Azure RemoteApp are configuring UPN suffixes, configuring service account, and enabling Azure AD connect.]

And then another category of configuration for RemoteApp is the client side. So making sure that the devices have the client, user can use RemoteApp client then to connect to, you know, the applications that we are hosting now in the cloud. And there might be some additional client configurations and tuning that you want to do like, for instance, device redirection where you take advantage of some of the hardware available on a local device.

[The steps involved in the client configuration for Azure RemoteApp are downloading the client and configuring the device redirection.]

Back to top

1.

Now let's talk about managing applications on a local Windows 10 device. And this also includes troubleshooting those applications. Now, before we get into how we're going to manage our applications on Windows 10, I want to have a look at some key terms and that's applications, services, and processes. So one of the things you'll see in Task Manager, for instance – if you open up Task Manager – is you'll see a list of processes. A process is an executable that sends in threads to the processor. These threads are the actual smallest unit of execution. So it's the threads that the processor is executing, and it's threads that the operating system is scheduling for execution in the processor. Now where do these threads come from? They come from services or they come from applications. Processes, I should say, run in the background. Applications on the other hand, these are typically tied to a user logon session. So a user logs on, executes Word – that's an application, that's a process generating threads as part of that user session. Services, on the other hand, those are running in the background, whether a user is logged on or not. So, now that you have a basic understanding of these key terms, you'll be able to go into Task Manager and recognize the fact that applications show up in the Applications tab. But there is a process, you know, a lot of executables that are running then those are processes and those can include services as well as applications.

So how do I manage my applications, troubleshoot them, configure them in Windows 10? And this includes, of course, services as well. Well, there are three main ways we can do this. We can use, you know, Settings in Control Panel. There is a policy method, and then there are some command line tools. Now, starting with the settings approach, there are couple of things we can do in the settings app. And that is, we can control maybe startup settings. In the Control Panel, we can control maybe which programs are the default and might control things like privacy settings. Task Manager even gives us some controls related to our applications. Let me show you. The local policy is another place where I can go and configure settings that have an impact on my applications and have an impact on my Windows 10 system. And of course there is the command line, right – PowerShell and the classic CMD console. Let's have a look at ways in which we can use the command line to manage my applications.

Okay, let's talk about managing apps in the enterprise. So how do I manage applications and services in the enterprise? That is, how do I support applications and services on Windows 10 devices in the business environment? Well, I'm glad you asked. Basically, we have some of the same management tools you've seen me talk about in other videos. We have the ability to manage Windows 10 application settings through Group Policy. So these are similar settings to local policy, only we can distribute them from Active Directory domain controllers. We also have the ability to apply different device policies and application policies through mobile device management, through System Center. And it's entirely likely that some of you have a third-party management suite that you use. So, in a typical enterprise, these are the different ways in which we manage applications and services on our client machines.

Back to top

1.

We're going to talk about AppCompat now. AppCompat is short for application compatibility. This is an important subject. If you're moving to a new operating system, you want to ensure your applications can run so that you can, of course, maintain your mission and continue to do stuff that you need to do and, you know, make money, be productive, and all that. So, in this next section, we're going to talk about common problems with application compatibility, some things to watch out for, as well as some fixes to consider. So let's get started. Now here's a question that you don't want to hear your users say nor do you want to hear your boss say – why does my application not work, or why doesn't their application not work? Of course, when you're moving to a new platform like Windows 10, you want to ensure the applications are going to work properly because those applications are tied to the mission of the business or tied to, you know, being productive and doing stuff.

Now there are several reasons why applications may not work – a lot of reasons. And there are four categories here. This is just some examples, this is not an exhaustive list. Well, let's take for instance security features. Windows 10 is the most secure operating system for Microsoft yet. And so there are some internal security features that, you know, the application may not get along with. Let's say, for instance, if the application requires the user to be an administrator, well, that may not fit with our current policies or what we want to change our policies to be. So that could be a potential compatibility challenge or maybe user account control or some other internal feature in Windows 10 that affects the application running.

Now there are also changes in terms of folder locations. Now some of these changes are things that have been around or are part of Windows 7. So, if you've got an XP app, this list actually becomes really important. If the application worked under Windows 7, it's likely it's going to work fine on Windows 10 because the profile location and the program files location, those are on the same place in Windows 10 as it were with Windows 7 and Windows 8. Nonetheless, a lot of it comes down to the age of the application and how it expects the operating system to behave if you will or how they relate to each other. Now the application might be a web-based application – a lot of business applications are. And, because now in Windows 10 we have Internet Explorer 11 and Microsoft Edge, there can certainly be some compatibility issues here that we want to review. Then there can be just a hard version check. With version checking what we mean is the application says, "What version are you in?" And Windows 10 says, "Well, I'm version 6 point whatever." And then it says, "Why? I was only made for XP version 5.1, I'm not going to run." So those types of version checking can actually affect the application. Now thankfully, some of these are really easy to fix and some of them are a bit more complicated. Nevertheless, Microsoft has a few tools that can help you with addressing compatibility problems. And there are some other techniques I'm going to share with you in regards to addressing compatibility problems.

Back to top

1.

Now this slide describes some of the procedures and some of the options you have in regards to fixing compatibility issues. So let's get started with this first one here. One of the first things you want to do is inventory and analyze your environment. This means gathering information about your existing applications, and then taking the time to kind of go through the list of apps that determine which ones do you want to actually address, which ones are mission critical. Oftentimes, you might go through the inventory process and discover some of the applications don't merit the effort it would take to get them ready and running on Windows 10. Sometimes, it might result in you standardizing on a certain type of application. So, for instance, let's say you go and you do an inventory and find out there are six different media players that are out there. So then organizationally you can decide if you are going to try to get all six of them to work on Windows 10, or you're going to standardize and say, "Well, we're only going to support this particular media application." So one of the important aspects of this is this particular step – inventorying and analyzing your applications gives you the opportunity to really kind of reduce the effort around fixing compatibility issues. This is one of the most important steps right here. Now, once you actually identify which applications I really need to work on Windows 10, the ones you want to put some effort to, then you have some options here. So, for instance, you might actually look at the vendor's web site and discover that there is a patch available that will make it and help it run on Windows 10. You might need to upgrade the application. You might actually need to consider sunsetting the application. Maybe that application has been superseded by another process or another application. So there are those options there.

Then you might opt for compatibility mode. This is another remediation option. And here what you're doing is using the Program Compatibility Troubleshooter, sometimes called the PCA, so Program Compatibility Assistant is a name it used in the past, anyway. Now this thing is a wizard that's built into Windows 10. You can invoke this. It will look in and examine the execution end of application. It will make some recommendations in terms of making some fixes, like it can address and help you identify if it requires an administrator or if it's doing a hard version check – it can help you get around a couple of those types of things.

[For fixing compatibility issues, patch the application, upgrade the application, retire the application, and then replace the application.]

Now another option is to actually shim or fix the app. Now fixing the source code – that can be probably a great route to go if the resources are available, if the application developers are available, so you can just fix the code. So whatever particular compatibility issue that it's, you know, stumbling on, well, you can get that obstacle out of the way. Alternatively, you can shim it. And by shimming it, what we're talking about is redirecting whatever is happening. So instead of the application removing the obstacle, well, then you're having the application walk around it. So let me give you an example of that. Actually that's what this Program Compatibility Assistant does to some extent. It uses some basic built-in shims.

Now Microsoft has got hundreds of shims that you can actually use basically from the Application Compatibility Toolkit. So there is a download that includes a lot more shims than what comes in the OS, and you can bring them to bear to help your application run. So here's the example I want to give you. Let's say, for instance, you have an application that checks the version. And it was written specifically for, oh gosh, like Windows 98, right. Some 9x operating system – it's kind of a DOS mentality. So you want that application to run on Windows 10 because, you know, it's really important, it's your daughter's, you know, typing game, right or something like that. So it's mission critical. I only say that because I had to get one of these to work for my daughter. Anyway, so you've got this 9x application, you needed to get it to work on Windows 10. One of the things you can do is shim it by a shim when the application requests the version from Windows 10. Windows 10 will use the shim instead and lie to it and say, "I am Windows 98, wink, wink." Now the application doesn't know any different. It sees the fact that it passed the version checking, continues to run. And at that point, the application might work fine. It may have just been running into that hard version check and failing itself because it didn't see what it wanted to see. So shims can be very useful in getting the application, manipulating the application, and getting it to run on your operating system. And we're talking here, of course, of Windows 10.

Now as I said earlier, there are hundreds of these shims. There's a database of these. You can download these from the Application Compatibility Toolkit and use several of them if you need to. These are found in the Compatibility Administrator Tool. So you got shims or you can fix the source code. And then that brings us to this last option here and that's virtualization. Virtualization allows me to give the application an environment it can succeed in. This might mean isolating it in an App-V container for many other applications, or it might mean giving it an entirely different dedicated environment through a virtual machine. That's a lot of overhead when we give it its own operating system and it adds to my management but that might be my only option. So these are the different options available to me when it comes to addressing application compatibility. I can move onto another app, I can use some of the built-in compatibility tools, I can download compatibility tools who try to use shimming, or I might actually need to virtualize the application. It starts though by first assessing my current environment and identifying those applications that I need to make sure run on Windows 10. So don't forget – this requires a testing and validation process. And by the way, the Application Compatibility Toolkit can help me with that as well.

So what is the Application Compatibility Toolkit? Well, the Application Compatibility Toolkit comes with ADK – the Assessment and Deployment Kit. Well, it's a kit, so it's a collection of different tools that can help me address compatibility problems in my environment. So, for instance, it has got tools like the Compatibility Administrator and the compatibility database that gives me shims. I also have a tool in there that allows me to inventory my environment, so I can deploy what is called a data collector out across multiple machines. Then they report back into my Compatibility Manager, and I can look into this database to see, "Oh look, I've got so many instances of this application and so many of these." And then the other aspect of this is Microsoft allows me to interact with a community of other Application Compatibility Toolkit users. And, if they are reporting that application doesn't work, well, then I can actually pull that information down, and it helps me kind of identify which apps will work or not work. Now that saves me a little bit of my own testing. But I'm still going to do my own testing. So I do my own testing. And then I discover. Well, I think the problem is X, Y, and Z. So then I can use the toolkit here in the database to record that information. And then I come up with a solution or a developer comes up with a solution. And so then we use the database and record an act that we've found a solution. So it becomes a warehouse of compatibility information as well as a set of tools to help me fix compatibility problems.

Back to top

1.

Now, in this section, I want to talk about the different application models that can be found in Windows. Basically, there are two models – three depending on how you're counting this. So, at the end of this, I hope you have a better understanding as to the reasons why we have multiple application models and the advantages that Windows 10 brings in its new unified application model. Now we all know the world is changing, right. And in fact, we could probably say, "One thing is for sure, and that is things always change." And, as for Windows applications, this is one of the areas, I would say, has not changed with this much frequency. I mean we've used these EXE files for decades – for a long period of time – but that also is experiencing a change. And really the changes started around Windows 8. Windows 10 is right in the center of a lot of these changes around Windows applications.

Now, back in 2011, Microsoft had three distinct platforms for applications. There is the desktop of course – Windows desktop. There is also though the Xbox and Windows Phone. And so we had separate platforms, we had separate stores for these. Now, if you've been following the Windows 10 story, you know that one of the big changes in Windows 10 is that there is a convergence going on – a convergence of code. Now these three platforms have some things in common. They share, for instance, some of the same type of code, they share the same kernel, they also now share the same store. Now this is significant for several different reasons. I'm going to explain more on that later on. But, for now, I want to point out to you that the application model in Windows 10 is the primary beneficiary of this convergence that's happening here. That is to say, Windows 10 now has a unified application model. And it's supported across all of the different types of devices here. Not only is the world of IT changing, but as you can see here with Windows 10, the world of applications are changing. So in short, consider it this way, Windows 10 has now got a core operating system ‒ the one application store and one application platform.

Back to top

1.

So next thing I want to look at is Windows 10 application model. And, if you haven't seen the Windows block diagram here, you're in for a real treat. I mean, this has got some serious cool factor going on. This is right up there with like robots and legos and donuts. Well, maybe not quite that tall, but anyway it's a fundamental depiction of Windows operating system. And, if this is the first time you've seen this, I want you to pay careful attention to this because this will help you think differently about Windows. It's made me a better troubleshooter because I understand much better how the components relate to each other. So let me break some of this down for you. I want to start over here, we've got Ring 0 and then we've got Ring 3. Now we have other words for these two different parts of the operating system. We also refer to as Ring 0 as kernel mode and Ring 3 as user mode. So the kernel mode down here or Ring 0 has a lot to do with where our operating system, our core functions of the OS are going to run. These are important services down here that we need to keep protected. If there is a problem with one of these services down here, then there are several things that are at risk ‒ the entire operating system stability is potentially at risk, security might be at risk, and any dependent applications are at risk. So this runs here in a different privileged area of memory as Ring 0. And we've got not just a kernel, but other services the kernel relies on, like for instance, the I/O stack – the input/output stack ‒ that runs down here as part of the kernel service. And then those stacks, these kernel, or executive services, as they sometimes are called as well, they need access to the hardware. So we have got kernel-mode drivers down here to facilitate communicating with that hardware.

Now, if something goes wrong with one of these drivers, something goes wrong down below this line, that's where you get those blue screens of death. This is critical errors occur down here when and if they occur. Now let's talk a little bit now about the user mode. The user mode is where you and I spend a lot of time interacting with Windows. This is where we've got subsystems and we've got API services and applications that are enabling us to use the system, right. And so communication between these two occurs, but it's protected communication, facilitated communication through what are called APIs and also called subsystems. Like, for instance, if you open up Task Manager, the Win32 subsystem is a real common one that supports applications and you may not have recognized it as the Win32 subsystem. But maybe you've opened up Task Manager and you've seen CSRSS – Client/Server Run-time Subsystem. Well, that's an example of one of the subsystems to operate at user mode that facilitates communication with some of the kernel services down below. All right, now one of the things I want to point out to you here in user mode is that our applications and services run up here. And, if there is a hang like an application is not responding or a service fails, we don't get a blue screen of death. So one of the important things about this block diagram is it demonstrates the inherent stability in Windows. The fact that we have this line and we abstract between Ring 0 and Ring 3, right. We have this division between the two in terms of execution, well, that brings and creates for Windows a great deal more stability than other Windows systems in the past, like Windows 95. Windows 95 did not have this line. This is really kind of an NT architecture that Windows 10 continues with because it's inherently more stable. Errors up here don't affect the running of the operating system that's occurring down here.

Now another thing I want to point out to you is that we've got user-mode services and we have applications. So a quick note. There is a difference between an application and its services. Well, what do you think of in terms of applications and services? I mean we've got both services and applications listed right here, what is the distinction between those? Well, the way I think of the differences between applications and services is applications are tied to the user logon session and services are those things, which are running even in the background even after a user logs off. So think of it this way, user logs on, they execute an application, execute word, and then they log off. Well, what happens to that application? What happens to word? Well, it gets terminated. But what about those services that are running in the background? Well, those services continue to run because they're running in a separate session. And so that's the difference between, I think, applications and services. They might both be operating up here in user mode and they might even be running in the background. But, if it's something that's associated with that user logon session and it's terminated, well, then I think it's better to call an application. Now that might be useful. I think it's not a definitive description of the two. You might have others who kind of describe the differences between the two another way – foreground versus background or something like that. I mean the reality is when a user logs on, there might be some services that are executed and dependent specifically on that user account. So I think the definition can get a little fuzzy. But that's I think helpful for me when I think of the difference between application and service – one being tied to a user session and one being tied more to the system. All right,

so going further into this, I want to explore this idea of APIs here, right. So we have this term called APIs – application programming interfaces. So let's talk a little bit about what these are – application programming interfaces – the key emphasis is there on the prefix inter. The word inter means going between something. So like internetworking protocols – a protocol that goes between networks ‒ or you have intersect or interstate, right. Interstate is a highway that goes between different states or an interface card – a network interface card is a physical card that goes between the computer and the network media. So it's something that kind of brings two things together and allows them to interact with each other. So we've got application programming interface ‒ well, these are APIs ‒ and what they allow and facilitate is they allow applications to take advantage of certain functions of the operating system communicating through these application programming interfaces.

One of the key things about the new application model that I am getting to here is this guy right over here, WinRT versus this one over here kind of classic desktop model over here. So one of things, I want to highlight for you is that starting with Windows 8 and continuing into Windows 10, Microsoft has been developing a set of APIs that support a new application model. This new application model is built on WinRT. The WinRT stands for Windows Runtime. This was something that was developed around Windows 8. Microsoft has continued to enhance it and really evolve it. That's probably the best word for it is it's been an API system that's evolved. And it's evolved to support now a whole new set of applications that actually interact with the operating system in a different way than traditional applications. We do have in Windows 10, support for the other application model and one of the distinguishing points here is that it's sitting on top of another set of APIs. These are traditional APIs and this is what we might call Win32 applications or desktop apps, that's one of the words that Microsoft uses for it. So this is kind of a classic application environment. So now looking at this, you get an idea of how these different components relate to each other. And not only that, I want to highlight for you that when it comes to an application model what we're really talking about is we have applications that are written to run on Windows – it's the same Windows 10 kernel – but what makes them different is they're leveraging and using different APIs.

Back to top

1.

So what is wrong with the classic Windows app model? Now this question really is implied based on the fact that we have two sets of APIs, right. We have two application models. And so that begs the question. Well, there must be something wrong with the classic Win32 apps if Microsoft went to great effort to create these WinRT APIs and create this universal app model. So why do they go to the effort to create a new application model when we have this other application model that's been in use for decades? Well, the reasons are very simple – inconsistency. I mean think about it, if you've supported Windows for any length of time, you've experienced installing, uninstalling Windows applications on the desktop; then you can probably see with me and agree with me that there is a great deal of inconsistency with the experience. There's inconsistency and how these applications look and feel and are used, inconsistency in terms of how they install, how they get uninstalled, or how you configure them. Now that inconsistency – you could say, well, that's part of the freedom of working on the Windows environment and being able to create applications, you know, uniquely and creatively.

But the downside to that is we're talking a lot of these inconsistencies having the impact on the way that they're supported, their lifecycle, the kind of problems that you can experience. For instance, it gets really complicated with these Win32 applications in terms of uninstalling them. Microsoft has created some standards over the years, but we're talking on the early days, just like raw EXEs and processes and then all those ways in which an app could be installed. And then organizations have to come up with their own installers, they all don't do it the same way and so the impact is compatibility and interoperability with the OS. So, when you go to uninstall it, it's not really fully cleanly uninstalled. Then you have the fact that these applications are sometimes written now with the best practice in mind in terms of security. So some of these apps are like wanting to write to System32 or wanting to write to secure parts of the registry and wanting to write to the root of the C drive, come on. So we have these Wild Wild West type of experience with these Win32 apps because there's not the same kind of prescribed and enforced rules that you get, say, with applications that are stored in application stores. So a lot of application stores or application models – not just Microsoft – but other vendors they have curation, so they have specific rules in which the applications are required to follow in order to properly interact with the operating system. And the benefit, when you have standards in place, translates for the user to experience a consistent and good experience. When you have inconsistency, then you create the risk of users having bad experiences or having complicated and difficult to install and expensive support scenarios. So these are the primary reasons Microsoft is moving away from a classic app model.

Back to top

1.

So, after 20 years or so of using the Win32 applications and discovering its tendency to lead to certain types of problems, Microsoft decided they wanted to change the application model to make it more modern, more secure, more resilient, more stable, standardize it, right ‒ keyword, standardize it, and that started in Windows 8. So, in Windows 8, Microsoft introduced some new APIs. The thing with these APIs, though, is they adopted a lot of great features that Microsoft wanted to continue moving forward, but they were device specific. So you had APIs that were designed for the desktop and laptop tablet and then you had those APIs, which were designed for the phone.

Now that brings us up to date to Windows 10. And what Windows 10 does is it takes these new APIs as WinRT APIs and enhances them and converges them, so this creates a new kind of API model called the universal Windows apps. So this is what I said when I said, "There are two app models maybe three." By three, we're talking about Windows desktop – Win32, right, from Windows 7 and before. And then there is Windows 8, which started introducing the new WinRT APIs. And that kind of evolved into what we have now our third. And that's our converged API or the Universal Windows Platform.

So, as you can see here, they took many other kind of PC-specific APIs and then the phone-specific APIs and made sure that those could be shared among both of those devices. So they want repeating APIs. Now that being said, the WinRT API spaces like shared among different devices and form factors, something like 80% to 90% of the APIs are common between these different types of devices. However there's still going to be a need for having unique kinds of interactions on these devices. I mean a phone is still different than a desktop, which is different than the HoloLens, which is different than the big, you know, Surface Pro type of TV. So because there are still some unique experiences that the devices themselves bring, then there is going to be some diversity in certain aspects of what those devices can provide. So different diversity in terms of the applications leveraging what the form factor provides. But nevertheless, there is a great deal of code in APIs that's shared. So an application designed for the phone will work on the desktop and will work in other types of form factors as well, as a result of the fact that they have these shared APIs. And that really is, at the heart of, one of the key benefits of the Windows 10 API story. Now, the Universal App itself, it brings with it a bunch of important benefits that overcome a lot of the problems with Win32 apps. And that's another important thing that we're going to look at.

All right, so one final look here, comparing these different application models. This is just another look, really, what I've already been talking to you about just in a chart kind of form. So down here, we see the older Windows 7 and Windows Phone kind of approach where you have very different APIs – supporting the problematic Win32 applications. Windows 8 comes along and introduces WinRT APIs, but notice that those APIs don't actually work on Windows Mobile. They're really designed just for a desktops and tablets and such. And so a big and important part of this whole Windows 10 story is the convergence of those APIs and the fact that universal apps work on Windows and Windows Mobile. So this is just a review, really, of what we've already been talking about that gives you a kind of another look at it in a comparative chart.

Back to top

1.

So now what I want to do is explore the characteristics of universal apps. And so it's my hope that at the end of this section, you'll have a better understanding as to why universal apps are better than the classic Win32 apps. So let's have a look at this. Now, for starters, I want to talk about some of the key features behind, you know, universal apps. Why they're so significantly better than the Win32 apps. So let's talk about some of these key features. Now I'm want to walk through each one of these. We'll do one at a time here, so stay with me if you will. First off, I want to talk about the Adaptive UI feature, and that's the fact that universal apps in Windows 10 can adapt to the different types of form factors. And this is significant, if you're going to have a universal platform that's going to run an application across multiple types of devices – all of these different form factors – then it needs to be able to respond to the change in screen real estate and maybe perhaps other aspects of that device. So having an Adaptive UI is an important part of what makes the Universal Windows App Platform important. And that's written into it, way that the application can adapt and respond or react if it's being used on a different type of device.

With that being said, natural input is an important part of this approach. So what Microsoft has done here is they have universally indicated how they want the Back button to be used, for instance, so that's kind of written into the platform. They have written rules around how it should interact and how it should respond in terms of touch. And then important application controls like the hamburger menu on the top left-hand corner and then the way we close it, and the way that it runs in Windows period. Now this is an important kind of iteration in terms of the development in Windows 10 compared to Windows 8. So let me give you a quick background with this. When the first WinRT apps hit stores in Windows 8, right, so you started using Windows 8, you launch an application there. One of the things that they used to cheer about is the fact that they got rid of a lot of the Chrome. This is Microsoft's terminology. They would say Chrome, no Chrome, immersive experience, and so you would launch this application and it would just come up, right, and it would just take away the whole screen and that was because Microsoft's heart was in the right place. I mean they wanted it, so that the application was center staged, that a lot of that controls, status bars, the task bars, the menu bars, all the bars hoping we used to do, right, in classic Windows, in an XP, and in all the different applications that would run. A lot of these applications would run in the window loaded with all these bars and they wanted to get rid of that, they called back Chrome and they wanted to make the content of the application the central focus.

However, one of the things that they risked doing is they lost some of the intuitive aspects of working inside of a Window that has very visible controls. So some of the feedback people gave them in regards to Windows 8 is, "Hey, this immersive experience is a neat idea, but I don't know how to close the application. I mean, I don't even know how to close it." And so you had all these videos, right, that's being done by pundits and bloggers and other YouTubers out there showing their parents trying to use Windows 8 and trying to find where things are at. And it was, you know, difficult for them because the controls were no longer visible, and you would have to swipe to the left or to close the application there was no x any longer, instead you had to hold in the center top of the screen and pull it down. Now on touch that actually works really well. It's very intuitive. On a Windows 8 device, touch – just swipe the app down, beautiful, just goes away. However, on desktop, where lot of people use Windows systems trying to close one of these immersive full screen applications prove to be, you know, an enormous hurdle and a point of frustration, too difficult. And, for me, I actually spend five or six times trying to press and hold and drag, long enough with my mouse, just to get the window to close when Windows 8 was first released. Okay, that's a long back story to why natural input makes this include with Windows 10, the whole fact that they have gone back to the Window environment. They have gone back to allowing some Chrome to leak in because users need to know naturally where to close that window. And so I think that's a really good step. Microsoft is still kind of buried some of the menus. There's less Chrome in Windows 10, but there's still some visible places you can go ‒ in order to actually interact with the application, all right ‒ I really like that myself.

Then this one right here, reusing existing code. Now this one really has to do with the fact that when you write an application and design it for the desktop that same application and its code could be used in other places as well, on the Xbox, potentially used on the Surface Hub – which is the big conference room type of computer with multiple touch kind of thing ‒ and potentially even in these more interesting form factors. So for instance, the HoloLens down here and maybe in some cases IOT – the Internet of Things. So Skype, for instance, being able to use Skype and being able to reuse Skype and experience Skype in a consistent, yet at the same time device-specific way across all of these devices the Universal Windows App Platform facilitates that and is intending to make it easier for developers to do that. You're not rewriting code and there's not enough of a distinction here to make it difficult to adapt your application to the different form factors. So I think that's a good plus and a good move.

Now we've got power management. Now this is an interesting thing about the way universal apps work and this was a big deal with Windows 8 as well. So, when the WinRT APIs came out, it actually interacts with the system in a different way. So the whole idea of background tasking and how much power that it uses, Microsoft had a very specific model and recommendations and ways in which the application should interact with the system with a power saving consciousness. And what I mean by that is these universal apps have a new state, they go into suspend mode, right. Suspend mode means when the application is not in use, it actually goes into a low-cycle mode called suspend mode where it's not demanding these much resources. We've all had those applications on our laptops and on our phones that when it goes into the background it may not be actively in use, but it's sucking the life out of the battery. It's got this vampire feature to it. Well, power management in Universal Windows App Platform is meant to address that specific power saving states and specific application lifecycle states that have to do with execution cycles in specific ways of doing execution in the background, foreground, or even being idle that saves power. So these are well-defined as far as the platform is concerned. So developers when they're writing the application they can take advantage of that power management feature. Universal navigation that really, kind of, fit into what I was talking about earlier when I mentioned a natural input, just kind of defining with the Back button does for all the different types of applications.

And then last but not least on this guy secure framework. Now a secure framework this is another important part of the difference between this application model versus a previous application model. And secure framework one of the things they have done is they run these universal apps in kind of separate containers. So there is an additional boundary of protection. There is also additional security here in regards to the way that application actually interacts with the device. So, if you've used Windows 8 before or if you've been using Windows 10, you might have an application prompt to you and say, "Hey, this application wants to use your camera or this application wants to know your location, yes or no." So written into the platform is this opt in security model where the application can't just assume or presume that those resources and those aspects of the device have potential privacy or security implications, well, they aren't just free to use for anybody, it's an opt-in type of model. So the actual execution model is more secure. They run in a sandboxed environment and the way that it interacts with devices is also more secure. Now this is just the beginning, there are many other aspects to the Universal Apps Platform I want to talk to you about.

Back to top

1.

All right, here's a look at some additional features that are part of Universal Windows App Platform. Let's start with this one right here, connected experiences. Now what Microsoft means by that is that this platform supports some unique experiences because we have this transcendent model, right, that allows us to interact with an application across multiple devices. So connected experiences mean you can take advantage of that reality with features like geocaching and roaming data. Then we've got isolated storage. And with isolated storage the applications interact with the system differently than a Win32 does – specifically I'm talking about the user profile. So Win32 applications will store data in user profiles and sometimes that data will be in a shared user profile. Whereas these applications are actually in a per user, per device kind of storage. So another user logging in, well, they're going to have to install the application themselves because the app might be present, the bits might be buried in the directories there, but it's not visible to other users who login to the system. So it's a per user, per device kind of licensing scheme. So for me, when I actually download one of these apps from the Windows Store, I can quickly go to my other device and download it on my other device and so it's per device, and yet my licensing allows me to actually have it downloaded on more than one device. And that's another benefit to this model. That brings us to this appx install & uninstall.

Now this is one of the big changes from Win32 because with Win32 we would have a loose file type of approach or we have MSI file type of approach, and it would be very inconsistent. Here we've got a very consistent kind of rigid model in which these applications are deployed and that uses are an extension of particular file format called appx. And so these files are installed as appx packages, and uninstalled very easily. So the difference here is you have to see it to believe it there is no or very little friction. It's just right-click – uninstall and it's gone, or right-click – install and it begins to install. There is no next, next, next, next, next, finish going on, no advanced versus standard installs or any of that kind of stuff, so this is a convenient way. And the other implication to this is the updating model is simplified here as well.

Then that gives me removable storage install. Now this is new with Windows 10. Up to this point many of these things that we've been talking about are also true with Windows 8, enhanced in 10 – this is new in 10. And removable storage allows me to install an application in a removable like an SD card, right. So instead of having my applications run from the local drive, I can actually have them installed on a removable drive instead and there is a way of actually moving them through the settings app. And then, last but not least, here that I want to talk about is One Store. Now Microsoft mentions that we don't have an Xbox store and a Phone Store and a Windows Store. Then we have One Store, now. One Windows Store for all those different devices and that's true. Accessing the store though, well, there's a different ways in which we're accessing store. Microsoft says, "It's One Store, but there's multiple storefronts so we'll give into that later on." One of the other key benefit of the fact that we have One Store is the fact that I can actually use or access that store from any of these types of devices, and I can see what applications I've downloaded, which ones I've installed on which device. So I can manage that through that One Store or Windows Store interface. So that's a look at some of these Universal Windows App Platform features that make it distinct from Win32 applications.

Now we've talked about many of the different Universal Windows App Platform features that make it distinct from Win32 applications. One of those that we talked about was connected experiences. And by connected experiences, we're talking about a couple of different things, like geofencing and roaming data. So let's talk a little bit about geofencing here. Give you a basic idea here this is like location-aware software that goes beyond just like mapping and GPS kind of services, but actually can do things based on location. And the Universal Application Platform supports these kinds of experiences. So this is kind of cool. So quick example of this. I can take my phone, and I can say, "Cortana, next time I am in the grocery store, remind me that I need to buy eggs, right." And so the next time I walk into my local grocery store, Cortana reminds me, pings me, and says, "Hey, you need to buy eggs," that's one example. But there are other examples. So it could be security examples, like the users phone would beyond them and they're walking to an unauthorized location of the building and then that phone sends an alert that says, maybe compliance and maybe auditing purposes or maybe the truck driver scenario. So automatic monitoring with a dispatcher or maybe the ability to walk into a retail store. And the retail store is able to say, "Hey, we've got a customer who has our application is in our store, let's send them the daily special, right." So they can send them the daily special right there where they are at. They get dinged, "Hey, welcome so and so, today we've got 25% off, you know, on red shirts or something." You get the basic idea.

So this creates a whole new category of application experiences because of the geosensing that are built in to a lot of these devices now. Okay, so imagine this. Imagine you're on your phone and you're watching a video and you hit pause, what happens here with roaming data is that place where you pause the video can be stored up into the cloud. So, when you walk up to your laptop or your tablet and you resume that same application, it has some additional intelligence from the cloud, indicating what video you're watching and where you paused it, giving you the opportunity to pick up right where you left off. So one of the great things about this idea of roaming data is it creates for the user this transcendent experiences. They go from device to device, you know, assuming they have the same application installed in all those devices. And so that's where Microsoft talks about new experiences or mobile computing – not being about the device that is mobile – but being about the experience that's mobile. And I am really excited about that. So new in Windows 10 is the fact that you could install Windows applications based on the Universal Application Platform. You can install these apps on to external media on removable media like an SD card. And so what I want do now is show you how to do that, how you can move your applications off of the disk on to removable media.

Now I love food, I love going to restaurants, if I go sit down in a brand new restaurant like a new Chinese restaurant or something there are certain items you expect to see on the menu, right. You expect to see egg flower soup or something like that. Well, that's the case when it comes to a new operating system. Any new operating system when you sit down in front of it, you expect to see built-in applications and that's the case with Windows 10. So what I want to do now is do kind of a showcase and tour some of the built-in applications that come with Windows 10. Keep in mind friends, that these are based on the Universal Windows App model, so many of the characteristics and benefits to the WinRT APIs and the Universal App model will see those demonstrated in these built-in applications.

[The built-in applications in Windows 10 are Photos, Groove Music, Maps, People, Movies and TV, Mail and Calendar, and OneDrive.]

Back to top

1.

The next thing I want to talk to you about is the Windows Store. Now no conversation about the new application model in Windows 10 would be complete without also talking about the changes they made to the Windows Store. Quick background with this. When Windows 8 was released and the new WinRT APIs were introduced and the new metro style applications that were built on the APIs were released, well, the Windows Store was also introduced. And it was the primary way in which devices received these new WinRT metro style applications. So in Windows 8, we have the store and we have WinRT. In Windows 10, it's not much different. In Windows 10, we have an enhanced or evolved WinRT API, we have this Universal App Platform that's progressed and evolved and improved and so has the Windows Store. So what I want to do now is look at the features in the Windows Store, the new features and some of the older features as well. And these features here are in support of the Universal App Platform, kind of a hand and glove kind of relationship. So what is the Windows Store? Well, the Windows Store is a couple of things. The Windows Store is a Universal Windows Application. So it's an app in and of itself that's built into Windows 10 that supports accessing a service. So it's not only an application, but the Windows Store is also a service.

All right, so there's new things in the Windows Store. The Windows Store – like it was with Windows 8 – is the primary source for applications to be installed or delivered universal apps. One of the new features here is we're not talking just universal apps or Windows app or format. There's also support here for desktop applications that can be uploaded to Windows Store and delivered that way. Windows Store is also a place where applications can be promoted. Think of it is kind of a market place. This is where applications can be bought and sold and where applications can be advertised. And so this is a place where you can search and browse and find the application that you need. You can find applications in variety of different categories, applications for like for games, applications for your device. For instance, I have a printer that has an application that's a Windows Store app and I can download and use that printer-based app. So you get, kind of, a purchasing experience that the Windows Store provides. The other thing to know about the Windows Store is it has some telemetry information in there. So you can see that these applications have stars next to them. They're rated. And the reason for that is Microsoft allows the community to provide feedback so that consumers can have confidence in downloading an application. They have some visibility into the quality of the actual application that's part of the curation. Another word for this is kind of moderation. Microsoft has specific store policies that these applications have to adhere to and that includes content and whether or not it adheres to the specific standard of the universal platform and then the security requirements. So apps are promoted here, apps can be delivered here, apps can also be updated and serviced from here.

Now the Windows Store is also part of the unification store in Windows 10 and that's because we've gone from having multiple stores to just One Store. And you probably heard me talk about this in another video, because back earlier 2011 or so there were multiple stores – one for the Xbox and phone and PC and so forth and those have been unified into a single store. So Microsoft says, "One Store – new opportunities." And so what we see here is kind of a description of how that One Store works. And really, what it's pointing to is the fact that we've got One Store for developers to upload their applications to and that is able to reach out across multiple different devices. So you've got a range of different Windows 10 devices that can consume a single source for all those different applications. Another important thing that you can get from this slide here is that they have increased or improved the discovery of applications. So we got the single catalog here of these applications that's categorized, really, so you've got applications for games, you've got music, you got videos, and then these are searchable. And they're searchable from within the store, but they can also be discovered from outside the store. So for instance, you can discover applications through Cortana, you can discover these applications through Bing. So there are search enhancements along those lines as well. The other benefit to this is from the developer's standpoint and that is they're able to leverage existing code. So the application developer isn't rewriting the application or confirming the application in three different ways or three different stores, instead what they are able to do is upload that application and they are able to use that same code to have and advertise it basically to multiple device families over here.

Now another new development with the Windows Store is the fact that it's still One Store that's part of the unification story, but Microsoft has multiple ways in which you can interact with that store or multiple surfaces or entrances. So this is going to allow for more flexible deployment to understand why this is significant. Consider the Windows Store back with Windows 8. Windows 8 had a Windows Store, of course, but your only way to interact with it was online, the only way to purchase it was purchase applications with a credit card. If you want to deploy an application from outside of the store, then there was a procedure, but it was challenging and difficult to use and required a special developer certificate. All of that to say that many businesses found working with the Windows Store are trying to deliver applications from the store, not conducive for corporations or for businesses. Acquiring licenses, acquiring the applications, distributing those apps, well, the Windows Store prove to be kind of more for consumers. So what Microsoft wanted to do was change that in Windows 10. They changed that by unifying the store, so we got One Store across multiple devices, but then enabling, basically, flexible ways in which the applications can be accessed and deployed.

So there's good news here, really, because you don't have just the public online store, you have a private store and a Business Store. In addition there is multiple ways in which you can acquire or purchase these applications. Now the way I need to think of this, like a coffee shop. I come from the Pacific Northwest, where we have a lot of different coffee shops. They might all be owned actually by the same company, like Starbucks or Dutch Brothers, or what have you, but the stores themselves can vary. They can distribute the products in different ways, different formats. So for instance, you might have a coffee store that's collocated with another business. You might have a coffee store that's stand-alone and sit down, and then another one that's a drive through. The point I am trying to make is you've got essentially one product here that you're selling across these different distribution, and so that's essentially what we have here with the Windows Store. So one of my Microsoft's goals here is with the Windows Store to reach more users on more devices and to also simplify the way that businesses interact with it. So by creating One Store with multiple conduits or multiple services, they get one step closer to that goal.

[Microsoft provides multiple ways to interact with Windows Store in order to make it easier for the organizations to acquire and license applications for their users.]

Now the Windows Store also comes with security, as we would hope and expect. We've got the protection that comes from digital signature, so the applications aren't tampered with or altered and they're protected there in the Windows Store and we can verify their origin. There is opt-in device access, which means if there's an application that you install that wants to leverage or use your camera, you can let it or not let it, so there's opt-in device access in that regard. Privacy settings can be changed. You go into the settings app and control how much information you want that application to share. I mean managing this Windows Store application, there's a couple of ways in which it can be managed; we've got Group Policy, we've got MDM support. And then restricting the applications can be done in a couple of different ways. Couple of examples here, you can restrict the application with AppLocker or perhaps isolate the application, based on what it's trying to do in and say, "Hey I don't want this application on the Internet, but I want to permit it on the intranet." So you can restrict it using what is called network isolation rules and the Windows advanced firewall.

Back to top

1.

The Windows Store is One Store, but it has multiple services to enable flexible access to support business situations as well. What we're going to do here is we're going to look at the different store services and compare and contrast them. The first store surface we want to explore and examine is the public store. So let's take a closer, deeper look into this. Remember, you can think of this as a kind of a franchised service, right. So you would have One Store, but multiple storefronts or multiple kind of store formats. Now the primary surface, the main way to access the Windows Store is through the public store, or what you might just call the Windows Store. Here consumers and business users both can get in there and access and install these applications – both the pay for applications and the free ones – because there's free ones in there as well. Now typically, user is going to login with the Microsoft account. They can pay with the credit card or gift card or they can use PayPal or some other mobile payment option. And they can also discover and find and download desktop apps. So another important enhancement to the Windows Store is that desktop apps can also be delivered from the Windows Store.

Now, quick side note, I want to mention about desktop apps. Delivering and installing desktop as through the Windows Store, the way that Microsoft does that is that actually uses App-V technology – so application virtualization. So the applications are packaged as App-V apps. They're stored in the Windows Store and they're delivered using that same type of technology, so they run on kind of an isolated sandbox container. Some of the Adobe apps can be delivered that way as opposed to doing the click, click, next, next, finish, kind of installation. So that's something that's new and interesting. Now this is very, very useful in terms of accessing a lot of different types of applications from a variety of different devices. On the other hand, business users may not have a credit card or they may not have a Microsoft account, so there are other distribution methods we want to talk about.

Now the next store surface I want to talk about is the private store. Now the private store is also known as the company portal and that could be enabled with the help of Intune. Now for those of you who don't know Intune, Intune is Microsoft's MDM solution – mobile device management solution – helps you manage your Windows 10 devices, as well as some other devices. Anyway, company portal here, the company portal allows you to directly assign Windows Store applications to your devices. And it can also help you customize what users see. So you can actually filter out certain apps in app categories. Let's say we don't want our users playing games, well, you can filter out games from the company portal, but still allow users to download those productivity apps or even line-of-business apps.

Last but not least is the Business Store. Now remember, in the past with Windows 8, the Windows Store required a Microsoft account, required an Internet connection, had limited purchasing options. And businesses found the Windows Store and Windows 8 are not very functional, difficult to use. So Microsoft developed the Business Store in Windows 10. And the whole idea with the Business Store is it's kind of, like, a layer of software that sits on top of the Windows, but one Windows Store catalog and this layer is the specially designed for enterprises and for IT administrators, like you and I. Now, like the public Windows Store, organizations will have access to the same applications because it's sitting on top of the regular Windows Store, so free applications and paid applications, those will all be accessible there. But get this, these applications can also be acquired in bulk. So that means that organizations can have some app license management. So licenses can be reclaimed or reused or reassigned, if you will, the kind of license tools that you would expect for an organization when you have users coming and going and they want to distribute an application to new employees or that kind of dynamic. So that's all built in to the Windows Store.

The other benefit to this is payment methods are more diverse than your public storefront. So this includes support for invoices now, so that's a pretty good news. Another bit of good news here is you don't actually have to have a Microsoft account. The Business Store supports other identities, work identities, Microsoft calls them Azure Active Directory. Now, if you have Office 365, you already have Azure Active Directory, so the Business Store is actually already available to you. Now the next thing I want to mention is the Business Store also supports multiple deployment methods. So users can actually deploy apps directly from the Business Store or they can use the private store to access the applications or install the applications into an image from the Business Store, download them, install them into the image. And then you don't actually need an Internet connection.

Back to top

1.

All right, time to explore now how the Business Store works, more detail. First off, I want to mention it's a free to use web site, okay. Free to use web site for businesses, schools, and other agencies. Remember, the Business Store is, kind of, a layer software that sits on top of the Windows Store. So we still accessing the applications inside the Windows Store, but we got this Business Store on top of it, so that Business Store adds additional flexibility. Whole point is to make it easier for you and I and for our purchasing departments to be able to access these applications. Now let's talk about distribution for a moment. There is two different ways in which we can interact with the Business Store and distribute application packages. We can either do it the online way or the offline way. So let's talk about the online method. Now the online method has some key advantages to it. And for instance, the Windows Store will track our licensing for us. So that can be a pro – a benefit to that – but it limits flexibility in terms of distribution. Okay, so this is an online approach. Now the other thing here is it requires an Azure Active Directory account and will deploying up packages from the Windows Store. Now couple of examples in which we might actually do this.

This means that we can, basically, link the applications, we can use the private store – the company portal, we can directly assign them with the help of MDM. So these are our deployment options. Offline alternatively, gives us added flexibility and that we can actually deploy the applications outside of using the Windows Store, we instead download them and deploy them using our infrastructure. This also means we don't need Azure AD you might need the account to set it up initially, but the users don't need Azure AD, so doesn't rely on that. We do have to keep track of our licenses. Now we got, instead, new options for distributions. So we can do manual installation, or we can do sideloading, we can basically take our packages and install them or embed them into our images. But some of you prefer the traditional approach of baking in your applications into your images that supported in the offline scenario. So thanks to the Business Store, we've got additional options in terms of deployment. And we have a couple of factors to think about whether its online here where we're using the Windows Store – an Azure AD account – or going offline where we're required to do our own tracking, but we have the ability to actually include it in our images.

[The online business store gets automatically updated through Windows update. In online business store, the packages are deployed by Windows store. The offline business store gets updated through Windows update. In offline business store, the packages are deployed using internal infrastructure.]

All right, so here's a look at the Business Store licensing models. We have the online licensing model and offline licensing. Now online licensing is enforced by your Windows Store Services and therefore have to have an Internet connection and, like we mentioned in the previous slide, you're going to need Azure Active Directory identities. This is really kind of the default model, as you might expect. May not be ideal for every business though, especially if you've got like closed firewalls. So applications can be licensed in an offline approach, which you may call a wall garden type of environment. And, in that case, what we're doing is we've got restricted Internet services so we need offline type of licensing. So this requires an organization to really, kind of, opt in to the licensing agreements and then do their own tracking, do their own kind of enforcement. Now you can have help with like MDM and System Center Configuration Manager. So for instance, you can download licenses to SCCM and have those cached on SCCM, and then push those licenses via SCCM to the client machines themselves. So two different licensing models – we got the online licensing model with its specific requirements and the offline model if those requirements don't apply.

All right, let's take a much closer look. Double-click into this whole online application model. Now couple of key take aways some of these we talked about previously, but a couple of key take aways here and that is this approach remember requires an Azure Active Directory user account, right. So the user must sign in to Windows with an Azure AD account or Azure AD-aware application. The other thing here is this requires store services to be enabled. You don't necessarily need the store UI, but you do need store services, so those can actually be separated now, something to keep in mind.

The other point about this model, like you see here, is that this is actually the deep link topology, the management server piece here is optional, so there's a couple of approaches here. Let me go through these with you. First off, the private store approach. So you have the admin or purchaser, login to the Business Store ‒ this is web based, remember. They log in there and they purchase the application for the users, the user then connects to the company portal – the private store and then that application is available there. So then this is kind of an opt-in the user can download that application, and install the application. Then there's direct assignment. What direct assignment simply means is that the administrator after they purchase the apps sends an e-mail to the client. In the e-mail there will be a link and then they can install the application that way. And then third and lastly here is the deep link approach. The deep link approach integrates with your management server. And in this case, what happens the purchasing takes place here in the Business Store of the application, but then that data is synchronized with the management server and then the administrator creates a policy over here, deploying the application using a URL – deep link, and the URLs pointing to that application in the Windows Store. And so then that policy is distributed to the client, the client then acts on that policy, goes to the Business Store, downloads the license, downloads the application. So these are the three different approaches here when it comes to online application distribution.

Now look at the offline application distribution and this approach we don't have Azure Active Directory as a requirement, you can use domain accounts, local accounts, and the other big take away here is it puts the organization into a position of having more control. More control of the version of the application, requires more control of the licensing, more control of the installation, and where we're going to store the application content. Okay, so this is the offline approach. So a couple of key take aways here. It's a flexible deployment model. We have the acquisition of the purchase in the Business Store here by the administrator. Then this is synchronized to our management server. This could be stored or replicated, if you will, to a content server. So on a file share, if you like, Windows Store Services are not required for this either. So that's another thing to point out because we're delivering the applications locally through our own management servers. So management server can then send the license to the client with a policy to install the application or the application could be downloaded with the help of PowerShell, and it can do the install for us or we can include the application in our images. So this gives us kind of an out-of-band deployment options outside of using the Windows Store Service and Azure Active Directory.

Back to top

1.

All right, let's talk about line-of-business applications and how these relate to the Windows Store. Now line-of-business application, remember, is an application that you might be creating in-house for your business or it might be an application that's specific to your industry, but it's important to, you know, your business. So these line-of-business applications they can actually be written, published, and uploaded to the Windows Store and take advantage of Windows Store services just like other applications can. So what are some of those benefits? Well, you have support for online and offline distribution, so those line-of-business apps can be published to the public store and accessible on purchase through the public store. They can also go through this other distribution channel that we talked about earlier – the business store – and then filtered out to the private store. And then from a developer standpoint, having it in the Windows Store means they're not having to host it. And Windows Store services can provide me telemetry information. They can help me in terms of updating the application. So there's benefit from the standpoint of the developer of the ISV having their LOB application in the Windows Store. Another thing I want to point out here is sideloading. Some organizations are concerned that sideloading an application requires that they turn on sideloading in Windows 10. And, if it's enabled, then that will open up the gates if you will for anything to be sideloaded into the Windows 10 device. Sideloading is installing the application outside of the Windows Store, in case you're not familiar with that term. So there's an alternative here. The alternative is the developer can actually publish their application directly into the organization's inventory. There's another track here for line-of-business applications to go straight to an organization's private store. So this allows organizations to actually get that application without having to enable sideloading.

Back to top

1.

Up next I want to talk to you about the nitty-gritty of installing Windows Store apps. So big question here, how do I install these universal apps, or also known as Windows apps or Windows Store apps? I want to take an aside right here. And that aside has to do with what we call these things. So there has been some confusion about the name of these different applications. I am referring to them here as universal apps, but one of the reasons I include this here in parenthesis is because they go officially by the name Windows apps and are often called Store apps. And there's a story behind this. Back, when these applications were first released with Windows 8, Microsoft had a couple of names for these. They used to call them Windows RT apps or WinRT apps, but then they were going by the name metro and that was kind of the standard name that they were going to adopt and use going forward. And the word metro is tied to kind of an aesthetic – an art school in Europe that Microsoft used as part of their inspiration and their design for Windows 8 and this metro style. So they called them metro apps, but the problem is that was in a conflict with another business organization, so they were required to actually change the name from metro to something else. So that just open the doors there for more confusion because then they started calling the apps modern apps, Windows Store apps, then they were also called packaged apps in another location. And so they have come along here to Windows 10 and we've got these additional names on top of all of this universal apps. And then Microsoft has particular article where they say the official name for these things are Windows apps.

So technically, we've got Windows apps and we've got desktop apps ‒ those are the two kinds of apps that Windows 10 supports. But the reason I am including universal apps is because there is an important point of clarification here. Universal apps are really the apps designed and written for the universal application platform as compared to those legacy desktop apps. All right, so that's a quick aside as to with this whole naming issue, and what we call these things. You'll see documentation and Microsoft itself is not consistent with how they refer to these things. Sometimes they call them Store apps, or in fact, I can show you in Windows 10 where it's called Windows Store apps. And then in Windows 10, where it's also called packaged apps, so they are not consistent either in their naming. Nevertheless, as long as, you and I understand the difference we're in good shape. So back to my original question here, how do we install these modern, metro, packaged, universal, Store Apps?

So deploying applications are online and offline. You can also use a lot of the old tools that you had before as well as using the stored surfaces. So we have online approaches here, public store, private store, and the business store. Applications that are line-of-business apps could be uploaded to the cloud and you can distribute them through the business store. We talked about that in a previous video. Another thing you can do is you've got offline approaches, so out-of-store approaches. So this means you can preinstall apps into your images, you can inject them the same way that you would do with desktop images, and use a lot of familiar tools like DISM, like PowerShell now has a new noun called AppxVolume to help you with that. So this allows you to actually deploy applications in familiar ways and new ways. You have support for deep links, so creating application policy in Intune and then linking to the Windows Store and having them download the application that way; installing the application with direct assignment via e-mail. So a lot of different options in terms of installing your applications.

Now the way these applications are installed are different than your standard desktop apps. Your standard desktop apps are, you know, loose files, cabinet files, or MSI files, right, they're installed. Here we're talking about applying the files as packages. And that requires that in Windows 10, we have a Package Manager and that's all built in, that's part of the universal app platform is the actual packaging or file format of these applications. They're in what's called an appxformat. So these appx packages are stored on this machine. And it supports Single Instance Storage, which means if multiple users are using the device and they install the same application, well, it's installed per user, but it's not stored per user, which means that, you know, if I install an application and then you log into my device, you won't see my app. If you install the same app, well, it's not going to double or triple or bloat the device with additional bits, because the bits are already there, so that's all actually configured. So it's optimized in terms of storage usage at the same time it has a per user installation. So that's a quick look at the way those applications, the Windows Store apps are installed.

Now the Windows Store application has an appx file format. So what I want to do now is talk a little bit more about these appx packages. The appx package itself, well, it's kind of like a ZIP file. It's a container. And inside the appx package, there are several components. First off we've got, you know, your assets. These are the different files, images, and other important parts that belong to the application. But then we have metadata, in the package itself, describing the application to the operating system and that would be like AppXManifest file here. Now every asset and every file actually gets hashed for security purposes and as part of the appx package project. So that is what is stored in the block map and then this gets digitally signed to ensure that this data is protected and this is really your appx package.

[The AppX package includes Assets such as files and images; AppXManifest.xml; BlockMap; and Signatures.]

Back to top

1.

All right, the next topic I want to look at in regards to Windows Store applications is sideloading. Now you might be asking yourself, well, what exactly is sideloading? Well, I am glad you asked. Sideloading is basically installing an appx package, but doing that outside of the Windows Store. And this gives us some added flexibility, but the way that this worked in Windows 8 was, well, difficult and cumbersome. There are some changes in Windows 10 in the way we do sideloading. So let's do a comparison between Windows 8 and Windows 10 and sideloading. So, in Windows 8, you have to have a special developer license. The device had to be Enterprise Edition 8.1. They changed that so it supported Pro, but nevertheless, you had some limitations and you had to have a certain sideload key and such. In Windows 10, now there's a simple switch that allows you to go into developer mode. There's also support for sideloading – both to online image or to an offline image. Sideloading isn't just done with PowerShell, but you can do with PowerShell. You can also sideload with mobile device management. You can sideload with Intune, for example, and Configuration Manager, so you've got more options than you had in the past.

All right, so how do I sideload in Windows 10? It's really easy, in my Settings application, there's a couple of features or settings that you can change right here. So you can turn on sideload application or you can go into developer mode. Now developer mode what that, basically, does is it's designed for developers, it gives you additional debugging options, you can install loose files, you do phone tethering, that kind of thing. Sideload apps is all you need, though, to sideload your application. So, if you're an enterprise or organization, you want to sideload for your app distribution. This is a setting you can enable, you can do this either in settings, or you can use policy to set this. One of the things you should know is that the appx package still needs to be digitally signed and that app certainly needs to be trusted.

[The UPDATE & SECURITY page of Windows 10 is open. On the left of the page is the navigation pane, and on the right is the content pane. In the navigation pane, there are different options and the For developers option is selected by default. The content pane contains the Use developer features section, and the section contains three radio buttons: Don't use developer features, Sideload apps, and Developer mode. The Don't use developer features radio button is selected by default.]

Back to top

1.

All right, next in our lineup is how to manage Windows apps. And this is I think a natural follow-up to our conversation in previous videos and previous topics where we talked about installing apps. Now that they're installed, well, let's talk now about managing those applications. So we're looking at here, how do I manage universal apps in an enterprise? So these are those Windows Store type of apps built on the universal app platform. Once we have those installed and out there across multiple devices, well, we really are looking for a centralized way to manage those applications. Now Microsoft's goal was to allow organizations, you know, rich capabilities to manage the apps, much like they made changes for the deployment of the applications with the business store and that company portal or the private store. Well, we have similar type of investments in terms of the management space. This includes integration with policies and MDM solutions. It also includes familiar tools like Scripting, PowerShell, and DISM support. Now the idea here is we want to be able to support universal applications across multiple devices. So we don't have support for just PCs here, we're able to use things like MDM solutions to support these applications, regardless of what device that they're sitting on whether or not it's a Windows Store app or a line-of-business app. And so these solutions here give us those tools that you would want in an organization that's just big as an enterprise.

Now, for example, here's some new app management policies that are available. And these are just an example of some of the policy-based controls that an organization, an enterprise can use to control universal apps. For instance, we can control how those applications store their data, whether or not we want to include an enable shared-user app data. SD cards – this is related to removable media, so moving an application off the local hard disk and storing it on a removable media. Well, that's a new feature in Windows 10. And, of course, we've got policies to support that new feature and then sideloading settings as well. Now all of the application management policies are available to me, I have others, but this gives you a quick idea of some of the newer features that there are policy settings behind these new features.

[The new app management policies are data sharing, SD cards, and sideloading. The data sharing policy allows the user to enable the shared user app data. The SD cards policy allows the user to disable apps and app data on other media. The sideloading policy allows the user to enable the installation of all trusted apps and to enable the developer mode.]

Okay, let's talk for a moment about restricting applications. And really what we're talking about is restricting devices, right. We want to minimize the number of applications that a particular device can run or, maybe, we want to create a list of applications that are permitted to run. Well, that's technology that's available to us through AppLocker and through Device Guard. We can create an AppLocker policy for Enterprise Edition machines or Windows 10 education machines and say, "Here's a list of applications that are permitted to run." We can further restrict it including the boot environment protected in with Code Integrity services using Device Guard, which is a very powerful security feature that's new in Windows 10. So, between these two, we can take an enterprise class machine and really restrict those applications. Also available to us is MDM policy. So, with the help of Intune and Configuration Manager, we have some other settings and even Group Policy to some extent can help us in terms of restricting applications on Windows 10 devices. Now we got to keep these applications healthy, right. So what are my hygiene options and updating options? Well, they're not much different than, you know, what I have available to me in terms of the operating system. I have automatic update, I can control that, I can turn that off if I want to. I can also turn it on or off on a per-app basis, which is new in Windows 10.

Back to top

1.

Let's talk about one of my favorite things. It's probably one of your favorite things as well and that's browsing the web. Now browsing the web in Windows 10 isn't like it used to be. Now we've got Microsoft Edge. What is Microsoft Edge? Well, Microsoft Edge is Microsoft's new web browser. Now this is kind of peculiar. Don't we already have a web browser called Internet Explorer? Well, we do still have Internet Explorer in Windows 10, but we also have a new browser called Microsoft Edge. Of course, this begs a question, right. Why do we have Microsoft Edge? I mean, why a new web browser? You see, Microsoft shipped their very first web browser Internet Explorer about 20 years ago. And, during those years, Microsoft sought to adapt the latest emerging web technologies. But, as they developed Internet Explorer with the latest web technologies, they always had to maintain a strong foot on backward compatibility. You see the challenge of Microsoft is expressed about Internet Explorer is that it has proven for them to be more and more difficult to keep a compatible browser that supports all of the different line of business applications in organizational investments and dependencies while at the same time creating a web browser that secure and has adapted to the latest in terms of web technologies. Because, guys, the web and the way we develop web pages is dramatically different today than it was 10 years ago and then it was, you know, 20 years ago.

So, from Microsoft, they have this added complexity of being a very popular web browser. But, for businesses – and some of these businesses have created line of business apps – that only works with certain versions of Internet Explorer, specific versions. And unlike Microsoft, these businesses will continue their mission using these legacy web technologies. But Microsoft – on the other hand – is caught between a rock and a hard place and that they need to provide, of course, compatibility so these businesses can do what they need to do and their line of business apps can continue to run. But, at the same time, Microsoft wants to produce a web browser that's innovative, that is adaptable, that is up to date in terms of kind of adopting modern web technologies. All of that to say, that's why we have a new web browser.

Now this slide really summarizes the reasons why Microsoft developed Edge and has a lot to do with this point right here. And that is they developed Edge to support new and emerging web technologies like HTML5 and they had a lot to do with the fact that Internet Explorer continues to suffer – as far as performance and security is concerned – because it needed to retain all of that backward compatibility because of the investments their customers have in terms of line of business applications. So the solution was let's leave the past and fork the code. That doesn't mean they've left their customers in the dust. In fact, they still have Internet Explorer with rich backward compatibility to support those investments that their customers have made. And yet, they want to support other customers who really are hankering for exploring the web using HTML5 and modern web technologies. So, for those types of customers, we've got the modern web with Microsoft Edge.

Microsoft Edge has some other features as well that might be of interest to you. For instance, it has a modularized construction making it easier to update light-weight built on Microsoft's universal Windows platform. A big thing these days are extensions and plugins. And so their support for that as well as a built-in PDF reader improves security, of course. So this is a big category especially today. So Internet Explorer has some security features in it, but Microsoft Edge goes a next step. It is a much harder browser than previous browsers. And then we've got compatibility and interoperability. So what this allows me to do is if I encounter a web site that really would be better served in Internet Explorer, I can quickly switch to IE11 as opposed to just staying in Edge. So there is a kind of a bridge between the two that's meant to make it really easy for the user to experience both browsers and get the most out of the web site they're trying to visit.

Back to top

1.

For those of you who use Internet Explorer in your business, well, you're going to want to pay attention to this because Windows 10 has built-in compatibility features to support those line of business applications that are based on the web. Now I like this particular slide because what it does for me is it shows me with each operating system release, the compatibility and dependency of certain Internet Explorer web browsers. And various organizations used IE, of courses, as the foundation for their line of business applications in their Internet sites. But as new operating systems released, backward compatibility became more and more of a concern because, well, if you built your application back here, and then you were trying to render that application in a newer web browser, you could lose some functionality and they wouldn't necessarily render quite the same. So, as time progressed, Microsoft also introduced various compatibility features into these different versions in Internet Explorer – like IE8 has this compatibility view. Now nevertheless, one of the things I want to point out is that IE11 here is supported by Windows 7, Windows 8.1, as well as Windows 10. IE11 also has compatibility features for these other versions of Internet Explorer.

So why use Internet Explorer 11 if we have Microsoft Edge? Well, IE11 like previous versions of Internet Explorer was designed to support some of the latest and greatest in terms of web technologies, but also recognize the need for backward compatibility. You see, a lot of organizations even today still create web sites for specific versions of IE, instead of adopting modern standards. Now it's hard I would say for old habits to die, right, it's not the same. Well, it's true and that's why we have Internet Explorer 11. So for some companies, this would be actually an important factor to moving forward and adopting Windows 10. Imagine for a moment, an organization that created an application that will work in IE11 and supports the compatibility features there. And so, if they're looking at moving to Windows 10 and it doesn't work in Microsoft Edge, well then, they've got to fall back, they have IE11 available to them. And so that's one of the key reasons why you would want to consider using IE11.

[IE11 supports modern web standards. It has improved performance and security features.]

All right, here is a list of some common problem areas just really addressing basically the misalignment between web browser and web site. And that can include a misalignment in terms of functionality. A misunderstanding is in the case of user agent strings between the browser and what the web site can provide. And so with this lack of functionality or lack of interoperability, the miscommunication between the web site and the web browser that all translates into the web page being misrendered or the web site providing code to the web browser that's less than ideal, text sitting on top of text frames out of order, functionality lost, can't even use the web site at all in worst case situations. So, on those situations, we really need compatibility. And that's where IE11 steps in.

[The common problem areas are caching and prerendering, deprecated functions, binaries and ActiveX controls, and user agent strings.]

Now IE11 has a lot of enhancements in and of itself in terms of performance and supporting the latest in terms of standards. But in Windows 10, it's still included for primarily for backward compatibility. You see, when it comes to the latest and greatest that's where Edge comes in. For backward compatibility, we have IE11 to Enterprise Mode site list and Document Mode. And these are features that allow us to identify web sites that need to be special handled, especially within our organization. So one of the things you can do is create a list of applications that are running in web sites and tell IE11 and even Edge, how to respond to that. So, for instance, let me give you an example. Let's say, if you have a particular line of business application, and it really requires kind of Internet Explorer's proprietary legacy type of approach. So, when that web sites encountered, your users then can even be using Microsoft Edge, but when they encounter it because of Enterprise Mode site list, then Internet Explorer 11 automatically will open instead and render the site for them. That ability – that detection ability – can be managed centrally, your organization can maintain that list and enable that list using a handful of central tools including things like Group Policy and a tool called Enterprise Mode List Manager. And the reason this is so important is because this again could be one of the primary factors to help companies adopt the new Windows 10 operating system. While at the same time, enabling users to continue to use those legacy web sites and those legacy applications.

Back to top

1.

Hi again, I have a challenge for you. Imagine you want to enable sideloading so you can install an Appx package without using the Windows Store. Now there's a couple of ways of doing that. One, of course, is going into Settings and turning on one of these options right here. You do Sideload apps or Developer mode. But my challenge to you is what are the other places to go where you can configure sideloading? Think about that with me for a moment. Feel free to pause the recording as you think about it and when you're ready, hit resume, and we'll finish the discussion.

[The Settings window is open. In the window, the UPDATE & SECURITY page is open. On the left of the page is the navigation pane, and on the right is the content pane. In the navigation pane, there are different options and the For developers option is selected by default. The content pane contains the Use developer features section, and the section contains three radio buttons: Don't use developer features, Sideload apps, and Developer mode. The Don't use developer features radio button is selected by default. The presenter opens the Run dialog box. The dialog box contains Open text field, and three buttons: OK, Cancel, and Browse. The entry in the Open text field is gpedit.msc. The presenter clicks the OK button, and the Local Group Policy Editor window appears. The top of the window contains four menus: File, Action, View, and Help. The toolbar below the menu bar contains different buttons such as Back, Forward, and Show/Hide Console Tree.]

Are you ready? Great. So the challenge out there is how do I enable sideloading going into the Settings environment? Well, there's a couple of different ways. First off, you may have thought of this option and that's to use gpedit.msc to use local policy. So this is certainly one way of doing it. So let's bring it up. And we go into Administrative Templates. Under Computer Configuration, go to Windows Components and there's a category called App Package Deployment right here. And this is where we can enable sideloading – allowing other trusted apps to install. Okay, so that's method one. What are some other methods? Well, you also may have thought of maybe a registry hack or PowerShell, and both of those also work as well. So you can see those listed here. In this TechNet article, there's a registry path that you can enable, which is essentially what that policy setting does – it enables that. And then you can also change that registry entry through PowerShell. So either using policy or making a change to the registry. Those are the other methods to configure and enable sideloading on a Windows 10 machine.

[The Local Group Policy Editor window is split into two sections. The left section contains expandable nodes, which further contain different folders. The right section shows the page of the selected folder. The presenter selects the App Package Deployment folder in the left section, and the App Package Deployment page opens in the right section. The page contains Setting section, which further contains different options. The presenter opens the Internet Explorer browser. In the browser, the Microsoft web site is open. The web page contains two ways to enable the device, using regedit and using PowerShell. There are four steps to enable the device using regedit. In the first step, open the command prompt with administrative privileges. In the seconds step, run regedit. In the third step, set the value of DWord to 1: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowAllTrustedApps. In the last step, set the value of DWORD to 1: HKLM\SOFTWAREVYlicrosoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense. There are three steps to enable the device using PowerShell. In the first step, run Windows PowerShell with administrator privileges. In the second step, run the following command: PS C:\WINDOWS \system32> reg add "HKEY_ LOCAL MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" \t REG DWORD /f /v "AllowDevelopmentWithoutDevLicense" /d "1". In the last step, run the following command: PS C:\WINDOWS\system32> reg add "HKEY LOCAL MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /t REG DWORD /f /v "AllowAllTrustedApps" /d "1".]

Back to top