MICHAEL NIEHAUS: So, welcome
to managing Windows devices with Microsoft Endpoint Manager. My name is Mike Niehaus. I'm a Principal Program Manager on the Windows Autopilot team. MIZANUR RAHMAN: I am is an Mizanur Rahman, Senior Program Manager at
Windows Autopilot team. MIKE NIEHAUS: So as part of this session, we want to talk about
managing Windows 10 devices, whether on-prem or in the cloud, key features that we have available for managing devices from the cloud, how we can do this remotely, how we can provision devices
using Windows Autopilot, and how we can provision
those devices remotely. With that, let's jump in. All of this, including Windows Autopilot, Intune, Configuration Manager, all of these are part of the Microsoft Endpoint Manager product. They provide together comprehensive
management capabilities for all your physical
and virtual endpoints. This includes the initial
provisioning of those endpoints, as well as the continued
management of them. We're going to focus in this
session on Windows devices, talking about the capabilities
in Microsoft Endpoint Manager that cover the entire lifecycle
of the Windows device. Key capabilities include
deployment and management of apps, application and security policies, management of security and
conditional access checks, configuration of the OS
and app-related settings, installation of Windows 10
feature and quality updates, and configuration of VPN
and Wi-Fi connections. When we look at this
as part of a continuum, we can see that there's
two ends of the spectrum. You can have an entirely
on-premises infrastructure or you could move entirely to the cloud. It's up to you. A lot of customers have
people working remotely. While many are transitioning
to a more hybrid workforce, where some days they're in the office and other days they're at home. So having management purely on premises really isn't sufficient anymore. So we are seeing customers shift toward a co-management environment
with Config Manager and Intune working together to manage a device, even when it's not connected
to the corporate network. In some cases, they may go all the way to a cloud native environment and eliminate all
on-premises infrastructure from managing those Windows
10 devices all together. Azure Active Directory Join. Having devices joined
to your cloud tenant, instead of requiring them to connect back to your on-premises Active Directory is a key capability as we
shift more towards the cloud. It was designed from the start for devices that are only
connected to the internet, avoiding many of the
complexities of Active Directory that often require VPN
connectivity for ongoing use. If you haven't tried out Azure AD Join, there's no time like the present. Of course you can use Use Hybrid
Azure AD Join if you must. That takes an Active
Directory joined device with all of its complexities, registers into your cloud tenant to enable additional functionality, such as authenticating to cloud resources, including Intune, OneDrive,
Outlook, et cetera, but it is still at its core an
Active Directory Join Device. It still needs connectivity
to the corporate network. It still needs to be able to talk to Active Directory domain controllers. We'll talk about all
of these scenarios more as we dig deeper. First, let's dig deeper into each of the
cloud-based feature areas, starting with Win32 apps. With the availability of the
Intune management extensions, the ability to install
Win32 apps of any kind was made available in Intune. Since then, a number of
additional enhancements have been added, including specifying that the app requires a reboot, either immediately or when convenient, based on the return code from that app. You can specify dependencies, so any apps that need
to be installed first before this app is installed. You can monitor and track these Win32 apps as part of the Windows Autopilot
enrollment status page. You can do peer-to-peer content sharing or server-based caching
using delivery optimization,- and the Microsoft Connected Cache. So all of these provide a
good set of capabilities for delivering Win32 apps. Soon we'll also be adding the ability to leverage supersedence to make it easier to manage app updates. Security is obviously a
major concern as well, to make it as simple as possible, to adopt recommended security settings for Windows 10 and Microsoft Edge. Security baselines have been implemented that you can leverage as is, or tweak for your specific requirements. Either way, you know that you're starting from a set of industry-based
recommendations that are kept up to date as
Windows and Edge are updated. While many settings are
available natively in Windows via MDM, and that list grows
with each Windows 10 release, there are thousands more
that exists via group policy. The Administrative
Templates feature in Intune add support for all of these, so that these GPO settings can be configured directly from the cloud, leveraging the same ADMX
policy definition files that have been used for years
with the Group Policy editor. In fact, we just added
another 646 settings that weren't previously available, leveraging that GPO engine
to configure those settings directly on the devices. Soon, as administrative templates feature will also support adding
your own ADMX files too, whether using the ones
provided by a third party ISP, or ones that you've authored yourself. We're also working on a
simplified authoring experience for all Windows policy settings, which should help make individual settings much easier to find, and make it easier to create your administrative profile templates to configure your devices. When it comes to updating Windows, one of the biggest enhancements that you might not have noticed is the ability to explicitly target Windows 10 feature updates
to groups of devices. No need to worry about
deferral periods anymore. You just create groups for
your initial validation rings and your staged broad rollout, and Intune will take care of the rest. This is done through coordination between Intune and a
component of Windows Update called the Deployment Scheduling Service. Intune can tell it exactly when a particular feature
update should be deployed. So that gives you complete control over the feature update
deployment process. For those who need to be
able to easily connect from home or through
other remote locations back into the corporate
network using Always On VPN, it was always challenging
to define VPN profiles, if you were doing machine tunnels, because there was no easy way
to do that through Intune. Since that's required for
hybrid Azure AD Join scenarios where you want to enable a remote device to connect back into
the corporate network, we've made sure that we
can do this more easily. So you can go into Intune,
create a VPN profile, specify that it's a machine tunnel, specify all the needed IKEv2 settings for that connection profile, and even the device
certificate that should be used for authenticating the device
to the Always On VPN server. So all of that gets bundled up into a simple VPN device
Configuration profile. Co-management has been around for a while, and it's continuing to be
enhanced to make it easier to deploy and configure. We're working on adding an additional co-management profile and Intune that lets you specify whether
Intune or Config Manager should control who is authoritative for the different co-management workloads. We're also going to simplify the Config Manager agent
installation process for scenarios where we start from Intune and then deploy the Config Manager agent. for example, an Autopilot scenario. Notice too that you can
specify a task sequence that should be automatically executed when the Config Manager agent installs via the provisionts parameter. Using this setting, you can do all of your Windows configuration tasks via a Config Manager task sequence, and integrate that task sequence into the Windows Autopilot
enrollment status page, blocking access to the desktop until the task sequence has
completed its configuration, making sure Windows is secure
and customized as desired before the user can access the desktop. So those are some of
the key building blocks for managing Windows 10
devices from the cloud using either Intune by itself or Intune plus Config
Manager via co-management. Naturally, these same building blocks are used as part of the new
device provisioning process, which we call Windows Autopilot. For more on Windows Autopilot, let me hand it over to my teammate, Miz. MIZANUR RAHMAN: Thank you, Michael. Hello, everyone. Now let's talk about Windows Autopilot. For the next few minutes, I'll walk you through
some of the new features that we have released recently and also give you a sneak peek to some of the awesome upcoming features. But before I start, for anyone who doesn't
know what Autopilot is, let me give you a quick
intro on Windows Autopilot. So what is Windows Autopilot? We have this traditional way
of deploying Windows devices which requires organization
to build a custom image by gathering everything you need, like apps, drivers, policies, and settings into a single image and
deploy them into a device. Overall, that process takes
a lot of time and effort for IT and organization,
which turns into cost. To overcome this, we have this
more than deployment solution that helps organization on IT to deploy an unboxed shrinkwrapped
device to their end user. When the end user or
employee of the organization powers on the device, they have this simple
device setup experience with very minimal decision-making steps. During this provisioning,
the device implements all required apps and policies from Microsoft Endpoint
Manager to the power of cloud. So, in summary, Windows Autopilot is the cloud-based solution that simplifies device deployment and device setup experiences or OOBE by reducing the overall time and cost for the organization to deploy
and manage Win 10 devices. You can always learn more
about Windows Autopilot at aka.ms/windowsAutopilot. Now let me start with some of the features we have recently released with our goal to simplify the device deployment and management experiences. First, let's talk about
Autopilot user driven mode for a hybrid Azure AD Join. In this deployment method,
you can deploy devices to join Azure AD remotely
and enroll in Intune MDM. Recently, we have released this feature where you can deploy over a VPN feature. With Windows 1903 and above, you can now use Always On VPN or any other third party
VPN client you have that have support log on
integration or auto connection, similar thing what Michael
was going over earlier. Next one is Windows Autopilot
white glove deployment. In this process, the white
glove partners of the IT staff can pre-provision a Win 10
device to be fully configured and business-ready for an
organization or the users. Currently, this is in a
preview and we are targeting for general availability
this calendar year 2020. The next one we have is
Autopilot self deployment mode. With this deployment method,
the device would deploy without the need of any user credentials, automatically join as
your AD and MDM enroll. Currently, this is also in preview, and we are targeting for
a general availability same calendar year 2020. But we have not stopped there. We took Autopilot to its next phase and bought Autopilot deployment
to Windows Holographic OS. With Windows Holographic 2004 and above, you can deploy HoloLens devices with Windows Autopilot
cell deployment mode. Soon we'll be launching two
other new features in this area, Wi-Fi support during Autopilot
deployment for HoloLens and Autopilot Tenant lock
for HoloLens 2 devices. The next feature I would like to call it is Windows Autopilot update. This is the capability where
we can do fixes, bug fixes, or a feature update to an Autopilot client with using Windows Update. With this capability, you do
not need to update your OS or image to get the latest
fix or the features. Very soon, we'll be
publishing an Autopilot update through this channel. Now if we look at some other enhancements we have done in in this area
are enrollment status page, for example, which we also call it ESP, which allows you to track apps, policies, certificates, et cetera, to
be deployed during deployment. Recently, we have enabled
device-level targeting for ESP. Also soon, you'll be able
to monitor task sequence for co-management during ESP. Michael referenced about
that a few slides earlier. The next set of features
we are a lot investing on is called the deployment
reporting and monitoring. In that area, we have tons
of enhancement going on. We have recently released Windows Autopilot deployment
report in Endpoint Manager, which is currently in preview, and we're making tons of
improvement in that reporting space to provide you more
accurate deployment results and empower you to troubleshoot any issues during deployment. Very soon, you'll be
able to see ESP duration broken down at devices
and user targeted level, and app installation status. Policies, status tracking is also part of our roadmap to supporting
the deployment report. In addition to it, we're also working on a client side diagnostic view and troubleshooting capability, which would allow you
to see deployment issues with a very simple and organized
view on a Win 10 client. And finally, we have the DFCI
Management Endpoint Manager. For your Autopilot deployed devices, DFCI will allow you to manage
device firmware settings with the Endpoint Manager. Currently, this is only
available with Surface devices, but we are actively
working with other OEMs to make it available for their devices. General availability, it's
targeted calendar year '20, and we also have plans to support some additional capabilities on the firmware management area. Now I'll give you a sneak peek about a couple of upcoming Autopilot features. But first, let's look at a little bit more on the Autopilot client side
diagnostic and telemetry. If you have deployed devices
using Windows Autopilot, you must have seen an error like this. Sometimes some error doesn't provide much clarity on the issues and we tend to ask you to do a Shift + F10 and run diagnostics script
and look at the logs. Even there, sometimes it
could be too many log files that it might be confusing
to know what to look at. We are working to solve
this problem for you, and make it simple enough to diagnose and troubleshoot
deployment on Win 10 client. When you run into an
error like this during ESP or any other point during OOBE, you will have an option on
the left side of the screen called View Diagnostic. And when you click on
it, it will launch a view which will provide you details
about the deployment issues and many other important information related to the deployment. Not only here. For any error cases only, but you can launch this diagnostic view from any point of your device
setup process during OOBE. we just press Ctrl + Alt + D, and it will launch the
diagnostic view for you. Here's another example
where this diagnosed view will be very helpful,
which is a technician flow of the Windows Autopilot
white glove deployment. And again, as I mentioned,
it's not only here. Anywhere you launch, you can
have this diagnostic view at your fingertips. Just pressing CTRL + ALT + D, and it will launch the
diagnostic view for you. Now let's look at when you click on that. What happens when you click
on the View Diagnostic? So when you click on the View Diagnostic, what's going to happen is
you're going to be seeing three categories of information. During this process,
your device will collect a lot of the log information
on behalf of you, and you'll be landing
on this center pivot, which is called a Deployment Info, which would be the middle one, and it will provide you an
organized and visualized in a much user friendly
and subcategorize form. On the right, you have apps and policies, which would show you
apps and policy status. And finally, on the left, you
have the configuration info, which it provided details about some of the device information about Autopilot profile information and other deployment-related
configuration. We'll go over a little bit, a few slides down about this more. The goal of this feature is to empower you to be able to diagnose and troubleshoot deployment issues when needed. Now, let me give you a
sneak peek to this flow on what it might look like. Now, I would like to caution that we're actively
building this feature now. So I'm going to show
you is a click-through on the user interactions. But again, because it's a
product we're developing, there are a few things
which might change in the UI when this final product releases. So if you look at this error
during ESP for example, and you have this View Diagnostics show up when there's an error happening. Now when you click on it, the device will run the process behind you to collect all the required logs and present them into
three categories fee. The deployment Info tab
will be the center one, and that's where you're going to land. And the devices
information are going to be categorized into multiple categories. For example, the connectivity check, what happened during the Autopilot flow, what happened during
the enrollment status, and also Windows security. You can also change this
view to a timeline view from the Top. So if you click on it, the
timeline view will represent all the events into sequence of event from the beginning of the OOBE. On the right, you have
the apps installation and policy status. It's going to give you the time it took and the installation status or any error related to apps or policies. On the left, you have
the Configuration Info, which will show you
information about the devices, and device you have, and also
about the Autopilot profile it collected from the cloud, the MDM, the ADJ
enrollment status with IDs, and various other important information which will help you to troubleshoot. When you want to export the log, you can do so by clicking
on the Export log and selecting your choice of your folder where you want to save the log. When done, you'll be back
to the diagnostic view and you can close your view
and return to the OOBE step where you originally started it from. I would like to iterate that this is illustration purpose only, but the actual product UI may vary. We are very excited about this feature, and I hope you all are too. But now I'm going to go
shift gears a little bit to a new Autopilot
feature and capabilities that we have recently
released in a private preview and soon is going to
be generally available in this calendar year. And that feature is Windows Autopilot for HoloLens 2 devices. As adoption of HoloLens 2 is increasing with our various industries
and business segments, we have found that deploying
this type of devices at scale is very challenging, time consuming, and end of the day could turn into costly. Imagine an IT admin putting
on a HoloLens device calibrating the device and moving through the
decision-making step doing OOBE, such as user ID and password, to join the device into the tenant. Now repeat that process for many devices they need to deploy in their organization. Yes, it is painful. To simplify the steps
for organization and IT, we have built this Autopilot
for HoloLens device. Windows Autopilot for HoloLens with Microsoft Endpoint Manager simplifies the deployment, streamlines the devices
security and management, driving significant cost and time savings for your organization. As part of this modern deployment story, we'll look and redesign a lot of the Windows
Holographic OS device setup flow to give IT an end user a simple and personalized provisioning flow. To deploy HoloLens 2
devices with Autopilot, first, your organization must meet Windows Autopilot licensing
and networking requirements. Second, you would need to register your Windows Autopilot HoloLens devices. Your HoloLens devices
must have version Windows, the Holographic OS 2004 or above. If you don't have it, you can
update your HoloLens 2 devices using the Advanced Recovery Companion app which you can download
from the Microsoft Store. Now on the registration phase of it, as I said, you can actually
register these devices very similar to your PC. Your partners or your reseller can register these devices
using PKID or device tuple. HoloLens have the
similar capability as PC. Or you can also self-serve
and register themselves by using HardwareHash using
Microsoft Endpoint Manager. Now, after that, when
you're done registering, the next step would be
for you to configure an SL deployment mode profile and assign it to your
HoloLens devices group. And during the configuration, you can select the customized
language, which is available, and region that is supported
by HoloLens 2 device. You can also set your device
name for those devices, so that it changes the device name before the device joins Azure AD. You need to configure an ESP
also for your HoloLens devices. And finally, when you're done, you can connect that device
to the internet and deploy. Now what I'm going to show you a video of what this provisioning
flow would look like after all this configuration is done, and your organization
IT connects this device to the internet and deploys. We actually deployed
these HoloLens devices remotely at our home. After the device is powered
on and got connected, the HoloLens device will
connect to the internet and get Autopilot profile. After collecting our power profile, you'll see that the company
branding page will show up, which is a signature image for Windows Autopilot
self deployment mode. Behind the scene, the device has skipped a bunch of OOBE pages and already set up various configuration set by the IT admin. During this period, the device
would set up device name and do a reboot to apply the device name. Post reboot, you'll be seeing
an enrollment status page. At the first step, the
device will be completing [indistinct] station, join
Azure AD, and enroll to MDM. Post enrollment, you'll start
applying policies, certs, and installing apps to the devices that is targeted by your
IT admin or organization and through the Microsoft
Endpoint Manager. When done, the device will automatically reboot one more time and then
land the user sign in screen. Now the device is ready and secured for an employee of that
organization to sign in and use. And you can see there are multiple methods of signing in within HoloLens device. Now if you see the overall experience, this deployment was
such a simple deployment with absolutely zero
touch from an IT admin. IT admin can deploy multiple of these
devices at the same time, without needing to putting
this device over their head. Obviously, they will need a USB-C to an Ethernet adapter dongle to be connected to the device. Now, we have also solved that problem too. So, during the provisioning,
as I explained, the device have done all the steps. But then when the device is ready for an employee or a
first time user to use, what happens during that flow? So here Nicole, an employee
of that organization, as a first time, user picks
up any HoloLens devices which was provisioned
by doing this Autopilot. She takes it on, puts it on, and then sign on with her own credentials and other auth methods which
is supported by the device. Goes to her own user personalization, learns about various gestures, and finally landing to the start menu. it's simple, end user-focused, and zero complexity UI setup experience. So, Autopilot itself
deployment for HoloLens 2 is currently available in private preview with partners or reseller support in registering these
devices, similar way as PC. HoloLens 2 devices soon will
be shipping with PKID barcode outside of the box for
partners like reseller to register these devices
easily for their customers. This feature would soon
be in public preview and finally generally available
by end of calendar 2020. Now, there are two new features
I would like to call out what's coming out next. So first is Wi-Fi support. Remember I mentioned that
you would need a USB-C dongle to connect this device to the internet. This is the one. If you need to kind of deploy
this device over Wi-Fi, you have this support now, So it is currently under
the insiders build. So with this new update, you can actually have a Wi-Fi support during Autopilot provisioning flow. And then the next feature we have is called a full tenant lockdown for Autopilot deployed devices. This only happens after the first time the device gets enrolled, and you set up a policy
using an OMA-URI settings. After first enrollment,
any future reset or reimage would require a mandatory network and the device must be deployed with Autopilot to the same tenant. In addition, there will be no local or Azure AD Join using PPK to prevent any escape hatch
during the device setup process. So this makes sure that an
organization-enrolled devices must stay enrolled to the same tenant. And there is no escape
hash during the setup for a user to bypass that. That Windows Autopilot HoloLens. Now, there's another thing
about the remote provisioning. We have looked into so many
options to provision a device. And during the times like this, if we have to remote provision a device, your Azure AD is your best
option to deploy these devices for your organization. But if you're not there yet, alternatively, you can
do hybrid Azure AD Join with skipping connectivity check. With Windows 1903 and above, we have now, You can always use Always On VPN or any other third party
VPN to get your connection. But pretty much wherever you are, you can do this
provisioning of your devices in a much simpler and a cost-effective way through Microsoft Endpoint Manager. That's the end of Autopilot. We are very much end of our presentation. There are some few key takeaways I would like to mention towards the end. Wherever you are in your
cloud management story, whether you are still thinking
about to move to the Intune, or you have started with co-management, or you are completely on the cloud, use Microsoft Endpoint Manager. It is truly your hub to
unify security, apps, access, compliance, and end user experience across your entire technology state. And because it can leverage
Microsoft's powerful data set, it is also intelligent, delivering analytics and signals to keep you ahead of the change, so that you can keep your costs down and keep your organization
running smoothly to whatever the future brings. And we believe partners
are key to the success and Endpoint Manager is
also the integration point for the ecosystem. We also mentioned that there's so many other learning sessions in this Ignite, and this is just the beginning. You will find these and
more at our video hub at aka.ms/microsoftignite2020/mem. If you have missed Brad
Anderson's live session or any other here, please make
sure you catch them as well. Now we have dozens of
demos and step-by-step, as I mentioned earlier, I mean from Windows
Autopilot to Virtual Desktop, from Endpoint Security
Management to Microsoft Tunnel, or to Endpoint analytics
and Universal Print. To access those, visit
aka.ms/microsoftignite2020/mem. We will see you there. Thank you.
