Azure VMware Solution now Available

Move or extend on-premises VMware environments to Azure

Seamlessly move VMware-based workloads from your data centre to Azure and integrate your VMware environment with Azure. Keep managing your existing environments with the same VMware tools you already know while you modernise your applications with Azure native services. Azure VMware Solution is a Microsoft service, verified by VMware, that runs on Azure infrastructure.

You can read more here

Windows Autopilot – Self Deploying mode

This maybe a preview feature, but it has huge potential to change the way we manage Windows 10 devices in the enterprise.

Applies to: Windows 10, version 1809 or later

Windows Autopilot self-deploying mode enables a device to be deployed with little to no user interaction. For devices with an Ethernet connection, no user interaction is required; for devices connected via Wi-fi, no interaction is required after making the Wi-fi connection (choosing the language, locale, and keyboard, then making a network connection).

Self-deploying mode joins the device into Azure Active Directory, enrolls the device in Intune (or another MDM service) leveraging Azure AD for automatic MDM enrollment, and ensures that all policies, applications, certificates, and networking profiles are provisioned on the device, leveraging the enrollment status page to prevent access to the desktop until the device is fully provisioned.


Self-deploying mode does not support Active Directory Join or Hybrid Azure AD Join. All devices will be joined to Azure Active Directory.

Self-deploying mode is designed to deploy Windows 10 as a kiosk, digital signage device, or a shared device. When setting up a kiosk, you can leverage the new Kiosk Browser, an app built on Microsoft Edge that can be used to create a tailored, MDM-managed browsing experience. When combined with MDM policies to create a local account and configure it to automatically log on, the complete configuration of the device can be automated. Find out more about these options by reading simplifying kiosk management for IT with Windows 10. See Set up a kiosk or digital sign in Intune or other MDM service for additional details.


Self-deploying mode does not presently associate a user with the device (since no user ID or password is specified as part of the process). As a result, some Azure AD and Intune capabilities (such as BitLocker recovery, installation of apps from the Company Portal, or Conditional Access) may not be available to a user that signs into the device.

The user experience with Windows Autopilot self-deploying mode


Because self-deploying mode uses a device’s TPM 2.0 hardware to authenticate the device into an organization’s Azure AD tenant, devices without TPM 2.0 cannot be used with this mode. The devices must also support TPM device attestation. (All newly-manufactured Windows devices should meet these requirements.)


If you attempt a self-deploying mode deployment on a device that does not have support TPM 2.0 or on a virtual machine, the process will fail when verifying the device with an 0x800705B4 timeout error. (Hyper-V virtual TPMs are not supported.)

In order to display an organization-specific logo and organization name during the Autopilot process, Azure Active Directory Company Branding needs to be configured with the images and text that should be displayed. See Quickstart: Add company branding to your sign-in page in Azure AD for more details.

Step by step

In order to perform a self-deploying mode deployment using Windows Autopilot, the following preparation steps need to be completed:

  • Create an Autopilot profile for self-deploying mode with the desired settings. In Microsoft Intune, this mode is explicitly chosen when creating the profile. (Note that it is not possible to create a profile in the Microsoft Store for Business or Partner Center for self-deploying mode.)
  • If using Intune, create a device group in Azure Active Directory and assign the Autopilot profile to that group. Ensure that the profile has been assigned to the device before attempting to deploy that device.
  • Boot the device, connecting it to Wi-fi if required, then wait for the provisioning process to complete.


When performing a self-deploying mode deployment using Windows Autopilot, the following end-user experience should be observed:

  • Once connected to a network, the Autopilot profile will be downloaded.
  • If the Autopilot profile has been configured to automatically configure the language, locale, and keyboard layout, these OOBE screens should be skipped as long as Ethernet connectivity is available. Otherwise, manual steps are required:
    • If multiple languages are preinstalled in Windows 10, the user must pick a language.
    • The user must pick a locale and a keyboard layout, and optionally a second keyboard layout.
  • If connected via Ethernet, no network prompt is expected. If no Ethernet connection is available and Wi-fi is built in, the user needs to connect to a wireless network.
  • Windows 10 will check for critical OOBE updates, and if any are available they will be automatically installed (rebooting if required).
  • The device will join Azure Active Directory.
  • After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services).
  • The enrollment status page will be displayed.
  • Depending on the device settings deployed, the device will either:
    • Remain at the logon screen, where any member of the organization can log on by specifying their Azure AD credentials.
    • Automatically sign in as a local account, for devices configured as a kiosk or digital signage.

In case the observed results do not match these expectations, consult the Windows Autopilot Troubleshootingdocumentation.

Windows Autopilot – A brief overview

Windows Autopilot is a collection of technologies used to set up and pre-configure new devices, getting them ready for productive use. You can also use Windows Autopilot to reset, repurpose and recover devices.
This solution enables an IT department to achieve the above with little to no infrastructure to manage, with a process that’s easy and simple.

Windows Autopilot is designed to simplify all parts of the lifecycle of Windows devices, for both IT and end users, from initial deployment through the eventual end of life. Leveraging cloud-based services, it can reduce the overall costs for deploying, managing, and retiring devices by reducing the amount of time that IT needs to spend on these processes and the amount of infrastructure that they need to maintain, while ensuring ease of use for all types of end users.

When initially deploying new Windows devices, Windows Autopilot leverages the OEM-optimized version of Windows 10 that is preinstalled on the device, saving organizations the effort of having to maintain custom images as well as drivers for every model of device being used. Instead of re-imaging the device, that existing Windows 10 installation can be transformed into a “business-ready” state, applying settings and policies, installing apps, and even changing the edition of Windows 10 being used (e.g. from Windows 10 Pro to Windows 10 Enterprise, to support advanced features).

Once deployed, Windows 10 devices can be managed by tools such as Microsoft Intune, Windows Update for Business, System Center Configuration Manager, and other similar tools. Windows Autopilot can help with device re-purposing scenarios, leveraging Windows Autopilot Reset to quickly prepare a device for a new user, as well as in break/fix scenarios to enable a device to quickly be brought back to a business-ready state.

Windows Autopilot walkthrough

The following video shows the process of setting up Windows Autopilot:

Benefits of Windows Autopilot

Traditionally, IT pros spend a lot of time building and customizing images that will later be deployed to devices. Windows Autopilot introduces a new approach.

From the user’s perspective, it only takes a few simple operations to make their device ready to use.

From the IT pro’s perspective, the only interaction required from the end user is to connect to a network and to verify their credentials. Everything past that is automated.


Windows 10 version 1703 or higher is required to use Windows Autopilot. The following editions are supported:

  • Pro
  • Pro Education
  • Pro for Workstations
  • Enterprise
  • Education

See Windows Autopilot requirements for detailed information on configuration, network, and licensing requirements.

Windows Autopilot Scenarios

Windows Autopilot enables you to pre-register devices to your organization so that they will be fully configured with no additional intervention required by the user.

Windows Autopilot enables you to:

  • Automatically join devices to Azure Active Directory (Azure AD) or Active Directory (via Hybrid Azure AD Join). See Introduction to device management in Azure Active Directory for more information about the differences between these two join options.
  • Auto-enroll devices into MDM services, such as Microsoft Intune (Requires an Azure AD Premium subscription).
  • Restrict the Administrator account creation.
  • Create and auto-assign devices to configuration groups based on a device’s profile.
  • Customize OOBE content specific to the organization.

Windows 10 Branches are Dead, Long Live Windows 10 Channels

Overview of Windows as a service

The Windows 10 operating system introduces a new way to build, deploy, and service Windows: Windows as a service. Microsoft has reimagined each part of the process, to simplify the lives of IT pros and maintain a consistent Windows 10 experience for its customers. These improvements focus on maximizing customer involvement in Windows development, simplifying the deployment and servicing of Windows client computers, and leveling out the resources needed to deploy and maintain Windows over time.

Click the following Microsoft Mechanics video for an overview of the release model, particularly the Semi-Annual Channel.

YouTube video of Michael Niehouse explaining how the Semi-Annual Channel works


Prior to Windows 10, Microsoft released new versions of Windows every few years. This traditional deployment schedule imposed a training burden on users because the feature revisions were often significant. That schedule also meant waiting long periods without new features — a scenario that doesn’t work in today’s rapidly changing world, a world in which new security, management, and deployment capabilities are necessary to address challenges. Windows as a service will deliver smaller feature updates two times per year, around March and September, to help address these issues.

In the past, when Microsoft developed new versions of Windows, it typically released technical previews near the end of the process, when Windows was nearly ready to ship. With Windows 10, new features will be delivered to the Windows Insider community as soon as possible — during the development cycle, through a process called flighting — so that organizations can see exactly what Microsoft is developing and start their testing as soon as possible.

Microsoft also depends on receiving feedback from organizations throughout the development process so that it can make adjustments as quickly as possible rather than waiting until after release. For more information about the Windows Insider Program and how to sign up, see the section Windows Insider.

Of course Microsoft also performs extensive internal testing, with engineering teams installing new builds daily, and larger groups of employees installing builds frequently, all before those builds are ever released to the Windows Insider Program.


Deploying Windows 10 is simpler than with previous versions of Windows. When migrating from earlier versions of Windows, an easy in-place upgrade process can be used to automatically preserve all apps, settings, and data. And once running Windows 10, deployment of Windows 10 feature updates will be equally simple.

One of the biggest challenges for organizations when it comes to deploying a new version of Windows is compatibility testing. Whereas compatibility was previously a concern for organizations upgrading to a new version of Windows, Windows 10 is compatible with most hardware and software capable of running on Windows 7 or later. Because of this high level of compatibility, the app compatibility testing process can be greatly simplified.

Application compatibility

Application compatibility testing has historically been a burden when approaching a Windows deployment or upgrade. With Windows 10, application compatibility from the perspective of desktop applications, websites, and apps built on the Universal Windows Platform (UWP) has improved tremendously. Microsoft understands the challenges organizations experienced when they migrated from the Windows XP operating system to Windows 7 and has been working to make Windows 10 upgrades a much better experience.

Most Windows 7–compatible desktop applications will be compatible with Windows 10 straight out of the box. Windows 10 achieved such high compatibility because the changes in the existing Win32 application programming interfaces were minimal. Combined with valuable feedback via the Windows Insider Program and diagnostic data, this level of compatibility can be maintained through each feature update. As for websites, Windows 10 includes Internet Explorer 11 and its backward-compatibility modes for legacy websites. Finally, UWP apps follow a compatibility story similar to desktop applications, so most of them will be compatible with Windows 10.

For the most important business-critical applications, organizations should still perform testing on a regular basis to validate compatibility with new builds. For remaining applications, consider validating them as part of a pilot deployment process to reduce the time spent on compatibility testing. If it’s unclear whether an application is compatible with Windows 10, IT pros can either consult with the ISV or check the supported software directory at

Device compatibility

Device compatibility in Windows 10 is also very strong; new hardware is not needed for Windows 10 as any device capable of running Windows 7 or later can run Windows 10. In fact, the minimum hardware requirements to run Windows 10 are the same as those required for Windows 7. Most hardware drivers that functioned in Windows 8.1, Windows 8, or Windows 7 will continue to function in Windows 10.


Traditional Windows servicing has included several release types: major revisions (e.g., the Windows 8.1, Windows 8, and Windows 7 operating systems), service packs, and monthly updates. With Windows 10, there are two release types: feature updates that add new functionality twice per year, and quality updates that provide security and reliability fixes at least once a month.

With Windows 10, organizations will need to change the way they approach deploying updates. Servicing channels are the first way to separate users into deployment groups for feature and quality updates. With the introduction of servicing channels comes the concept of a deployment ring, which is simply a way to categorize the combination of a deployment group and a servicing channel to group devices for successive waves of deployment. For more information about developing a deployment strategy that leverages servicing channels and deployment rings, see Plan servicing strategy for Windows 10 updates.

For information about each servicing tool available for Windows 10, see Servicing tools.

To align with this new update delivery model, Windows 10 has three servicing channels, each of which provides different levels of flexibility over when these updates are delivered to client computers. For information about the servicing channels available in Windows 10, see Servicing channels.

Naming changes

As part of the alignment with Windows 10 and Office 365 ProPlus, we are adopting common terminology to make it as easy as possible to understand the servicing process. Going forward, these are the new terms we will be using:

  • Semi-Annual Channel – We will be referreing to Current Branch (CB) as “Semi-Annual Channel (Targeted)”, while Current Branch for Business (CBB) will simply be referred to as “Semi-Annual Channel”.
  • Long-Term Servicing Channel – The Long-Term Servicing Branch (LTSB) will be referred to as Long-Term Servicing Channel (LTSC).


For additional information, see the section about Servicing Channels.

You can also read this blog post, with details on this change.

Feature updates

With Windows 10, Microsoft will package new features into feature updates that can be deployed using existing management tools. Because feature updates are delivered more frequently than with previous Windows releases — twice per year, around March and September, rather than every 3–5 years — changes will be in bite-sized chunks rather than all at once and end user readiness time much shorter.


The feature update cadence has been aligned with Office 365 ProPlus updates. Starting with this falls’ update, both Windows and Office will deliver their major updates semi-annually, around March and September. See upcoming changes to Office 365 ProPlus update management for more information about changes to Office update management.

Quality updates

Monthly updates in previous Windows versions were often overwhelming because of the sheer number of updates available each month. Many organizations selectively chose which updates they wanted to install and which they didn’t, and this created countless scenarios in which organizations deployed essential security updates but picked only a subset of non-security fixes.

In Windows 10, rather than receiving several updates each month and trying to figure out which the organization needs, which ultimately causes platform fragmentation, administrators will see one cumulative monthly update that supersedes the previous month’s update, containing both security and non-security fixes. This approach makes patching simpler and ensures that customers’ devices are more closely aligned with the testing done at Microsoft, reducing unexpected issues resulting from patching. The left side of Figure 1 provides an example of Windows 7 devices in an enterprise and what their current patch level might look like. On the right is what Microsoft’s test environment PCs contain. This drastic difference is the basis for many compatibility issues and system anomalies related to Windows updates.

Figure 1

Comparison of patch environment in enterprise compared to test

Servicing channels

To align with the new method of delivering feature updates and quality updates in Windows 10, Microsoft introduced the concept of servicing channels to allow customers to designate how frequently their individual devices are updated. For example, an organization may have test devices that the IT department can update with new features as soon as possible, and then specialized devices that require a longer feature update cycle to ensure continuity.

With that in mind, Windows 10 offers 3 servicing channels. The Windows Insider Program provides organizations with the opportunity to test and provide feedback on features that will be shipped in the next feature update. The Semi-Annual Channel provides new functionality with twice-per-year feature update releases. Organizations can choose when to deploy updates from the Semi-Annual Channel. The Long Term Servicing Channel, which is designed to be used only for specialized devices (which typically don’t run Office) such as those that control medical equipment or ATM machines, receives new feature releases every two to three years. For details about the versions in each servicing channel, see Windows 10 release information.

The concept of servicing channels is new, but organizations can use the same management tools they used to manage updates and upgrades in previous versions of Windows. For more information about the servicing tool options for Windows 10 and their capabilities, see Servicing tools.


Servicing channels are not the only way to separate groups of devices when consuming updates. Each channel can contain subsets of devices, which staggers servicing even further. For information about the servicing strategy and ongoing deployment process for Windows 10, including the role of servicing channels, see Plan servicing strategy for Windows 10 updates.

Semi-Annual Channel

In the Semi-Annual servicing channel, feature updates are available as soon as Microsoft releases them. Windows 10, version 1511, had few servicing tool options to delay feature updates, limiting the use of the Semi-Annual servicing channel. Windows 10, version 1607 and onward, includes more servicing tools that can delay feature updates for up to 365 days. This servicing modal is ideal for pilot deployments and testing of Windows 10 feature updates and for users such as developers who need to work with the latest features immediately. Once the latest release went through pilot deployment and testing, you choose the timing at which it goes into broad deployment.

When Microsoft officially releases a feature update for Windows 10, it is made available to any PC not configured to defer feature updates so that those devices can immediately install it. Organizations that use Windows Server Update Services (WSUS), Microsoft System Center Configuration Manager, or Windows Update for Business, however, can defer feature updates to selective devices by withholding their approval and deployment. In this scenario, the content available for the Semi-Annual Channel will be available but not necessarily immediately mandatory, depending on the policy of the management system. For more details about Windows 10 servicing tools, see Servicing tools.

Organizations are expected to initiate targeted deployment on Semi-Annual Channel releases, while after about 4 months, we will announce broad deployment readiness, indicating that Microsoft, independent software vendors (ISVs), partners, and customers believe that the release is ready for broad deployment. Each feature update release will be supported and updated for 18 months from the time of its release


Organizations can electively delay feature updates into as many phases as they wish by using one of the servicing tools mentioned in the section Servicing tools.

Long-term Servicing Channel

Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.


Windows 10 Enterprise LTSB is a separate Long Term Servicing Channel version.

Long-term Servicing channel is not intended for deployment on most or all the PCs in an organization; it should be used only for special-purpose devices. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, typically used by an information worker, and therefore it is better suited for the Semi-Annual servicing channel.

Microsoft never publishes feature updates through Windows Update on devices that run Windows 10 Enterprise LTSB. Instead, it typically offers new LTSC releases every 2–3 years, and organizations can choose to install them as in-place upgrades or even skip releases over a 10-year life cycle.


Windows 10 LTSB will support the currently released silicon at the time of release of the LTSB. As future silicon generations are released, support will be created through future Windows 10 LTSB releases that customers can deploy for those systems. For more information, see Supporting the latest processor and chipsets on Windows in Lifecycle support policy FAQ – Windows Products.

The Long-term Servicing Channel is available only in the Windows 10 Enterprise LTSB edition. This build of Windows doesn’t contain many in-box applications, such as Microsoft Edge, Microsoft Store, Cortana (limited search capabilities remain available), Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock. Therefore, it’s important to remember that Microsoft has positioned the LTSC model primarily for specialized devices.


If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.

Windows Insider

For many IT pros, gaining visibility into feature updates early—before they’re available to the Semi-Annual Channel — can be both intriguing and valuable for future end user communications as well as provide the means to test for any issues on the next Semi-Annual Channel release. With Windows 10, feature flighting enables Windows Insiders to consume and deploy preproduction code to their test machines, gaining early visibility into the next build. Testing the early builds of Windows 10 helps both Microsoft and its customers because they have the opportunity to discover possible issues before the update is ever publicly available and can report it to Microsoft.

Microsoft recommends that all organizations have at least a few PCs enrolled in the Windows Insider Program and provide feedback on any issues they encounter. For information about the Windows Insider Program for Business, go to Windows Insider Program for Business.1


Microsoft recommends that all organizations have at least a few PCs enrolled in the Windows Insider Program, to include the Windows Insider Program in their deployment plans and to provide feedback on any issues they encounter to Microsoft via our Feedback Hub app.

The Windows Insider Program isn’t intended to replace Semi-Annual Channel deployments in an organization. Rather, it provides IT pros and other interested parties with pre-release Windows builds that they can test and ultimately provide feedback on to Microsoft.

Servicing tools

There are many tools with which IT pros can service Windows as a service. Each option has its pros and cons, ranging from capabilities and control to simplicity and low administrative requirements. The following are examples of the servicing tools available to manage Windows as a service updates:

  • Windows Update (stand-alone) provides limited control over feature updates, with IT pros manually configuring the device to be in the Semi-Annual Channel. Organizations can target which devices defer updates by selecting the Defer upgrades check box in Start\Settings\Update & Security\Advanced Options on a Windows 10 client.
  • Windows Update for Business is the second option for servicing Windows as a service. This servicing tool includes control over update deferment and provides centralized management using Group Policy. Windows Update for Business can be used to defer updates by up to 365 days, depending on the version. These deployment options are available to clients in the Semi-Annual Channel. In addition to being able to use Group Policy to manage Windows Update for Business, either option can be configured without requiring any on-premises infrastructure by using Intune.
  • Windows Server Update Services (WSUS) provides extensive control over Windows 10 updates and is natively available in the Windows Server operating system. In addition to the ability to defer updates, organizations can add an approval layer for updates and choose to deploy them to specific computers or groups of computers whenever ready.
  • System Center Configuration Manager provides the greatest control over servicing Windows as a service. IT pros can defer updates, approve them, and have multiple options for targeting deployments and managing bandwidth usage and deployment times.

With all these options, which an organization chooses depends on the resources, staff, and expertise its IT organization already has. For example, if IT already uses System Center Configuration Manager to manage Windows updates, it can continue to use it. Similarly, if IT is using WSUS, it can continue to use that. For a consolidated look at the benefits of each tool, see Table 1.

Table 1

Servicing tool Can updates be deferred? Ability to approve updates Peer-to-peer option Additional features
Windows Update Yes (manual) No Delivery Optimization None
Windows Update for Business Yes No Delivery Optimization Other Group Policy objects
WSUS Yes Yes BranchCache or Delivery Optimization Upstream/downstream server scalability
Configuration Manager Yes Yes BranchCache, Client Peer Cache Distribution points, multiple deployment options


Due to naming changes, older terms like CB,CBB and LTSB may still be displayed in some of our products.


Confused between Intune for Education and Full Intune? This post explains the differences

For many schools, regardless of size, device deployment poses significant challenges, as it is during deployment that group policies are set, data is secured, devices are readied, and essential applications are enabled. Historically, this task has taken a disproportionate amount of time. As a result, schools interested in using educational technology to improve student learning outcomes have turned to ways to manage those devices with less time and effort, so that more IT time can be spent in more strategic, directly supportive functions. Today, as the digital revolution rolls on, cloud-based deployment solutions are available to simplify this task. Read more about the challenges facing EDU IT and how cloud-based solutions like Intune for Education can help address them in the whitepaper The State of Modern Device Deployment in Education.
With the new and simple Intune for Education step-by-step Express Configuration wizard, Education IT selects a group for devices or users, also the specific apps that we wanted to be available, and key configuration settings from those most often used in schools. IT can use a USB drive to set up Windows 10 for each device and the enroll the device in Intune management via Azure AD. That is all they need to do and they can do it in less than an hour. Learn more about using the Intune for Education with the article What is Intune for Education?
If it’s a mixed device environment and/or more enterprise-grade policies are needed, they can move seamlessly to the Intune console and then back to Intune for Education for simplified Windows 10 device management. Ongoing management is also painless with a centralized console for updates and monitoring. Learn more about using full Intune with the Introduction to Intune article.
You can compare the different use cases with the article How is Intune for Education different from the full device management experience in Intune? Note: schools that are licensed for Intune for Education will also have access to the full Intune console.
With Azure AD identity as the backbone, user and device groups (i.e. schools, classes, grades) update automatically while providing insights to IT on usage patterns and any possible threats to the security of their users. Due to this common identity, all the devices and users that show up and are managed in Intune for Education will also be manageable in full Intune. This also means that you can leverage the new co-management capabilities with ConfigMgr in either Intune for Education or full Intune.
To find out more about Azure AD features in Intune for Education compared to other education offers, click on Learn what Azure Active Directory features come with Intune or Education and other plans at the top of the Intune for Education page. Note that customers can have Azure Premium and Azure AD EDU, with Office 365 or Intune for Education, assigned together or separately with no issues removing one or the other. You can also get your free 90-trial of Intune for Education (with full Intune) on this page too!

Introducing Windows Containers

Want to find out more about one of the most exciting features of Windows Server 2016, a game changer for a Microsoft Server OS, that could change the way we deliver Services and Web Apps.

Windows Containers

Containers are a way to wrap up an application into its own isolated box. For the application in its container, it has no knowledge of any other applications or processes that exist outside of its box. Everything the application depends on to run successfully also lives inside this container. Wherever the box may move, the application will always be satisfied because it is bundled up with everything it needs to run.

Imagine a kitchen. We package up all the appliances and furniture, the pots and pans, the dish soap and hand towels. This is our container

We can now take this container and drop it into whatever host apartment we want, and it will be the same kitchen. All we must do is connect electricity and water to it, and then we’re clear to start cooking (because we have all the appliances we need!)

In much the same way, containers are like this kitchen. There can be different kinds of rooms as well as many of the same kinds of rooms. What matters is that the containers come packaged up with everything they need.

Watch a short overview here: Windows-based containers: Modern app development with enterprise-grade control.

Container Fundamentals

Containers are an isolated, resource controlled, and portable runtime environment which runs on a host machine or virtual machine. An application or process which runs in a container is packaged with all the required dependencies and configuration files; It’s given the illusion that there are no other processes running outside of its container.

The container’s host provisions a set of resources for the container and the container will use only these resources. As far as the container knows, no other resources exist outside of what it has been given and therefore cannot touch resources which may have been provisioned for a neighboring container.

The following key concepts will be helpful as you begin creating and working with Windows Containers.

Container Host: Physical or Virtual computer system configured with the Windows Container feature. The container host will run one or more Windows Containers.

Container Image: As modifications are made to a containers file system or registry—such as with software installation—they are captured in a sandbox. In many cases you may want to capture this state such that new containers can be created that inherit these changes. That’s what an image is – once the container has stopped you can either discard that sandbox or you can convert it into a new container image. For example, let’s imagine that you have deployed a container from the Windows Server Core OS image. You then install MySQL into this container. Creating a new image from this container would act as a deployable version of the container. This image would only contain the changes made (MySQL), however it would work as a layer on top of the Container OS Image.

Sandbox: Once a container has been started, all write actions such as file system modifications, registry modifications or software installations are captured in this ‘sandbox’ layer.

Container OS Image: Containers are deployed from images. The container OS image is the first layer in potentially many image layers that make up a container. This image provides the operating system environment. A Container OS Image is immutable. That is, it cannot be modified.

Container Repository: Each time a container image is created, the container image and its dependencies are stored in a local repository. These images can be reused many times on the container host. The container images can also be stored in a public or private registry, such as DockerHub, so that they can be used across many different container hosts.

For someone familiar with virtual machines, containers may appear to be incredibly similar. A container runs an operating system, has a file system and can be accessed over a network just as if it was a physical or virtual computer system. However, the technology and concepts behind containers are vastly different from virtual machines.

Mark Russinovich, Microsoft Azure guru, has a great blog post which details the differences.

Windows Container Types

Windows Containers include two different container types, or runtimes.

Windows Server Containers – provide application isolation through process and namespace isolation technology. A Windows Server Container shares a kernel with the container host and all containers running on the host. These containers do not provide a hostile security boundary and should not be used to isolate untrusted code. Because of the shared kernel space, these containers require the same kernel version and configuration.

Hyper-V Isolation – expands on the isolation provided by Windows Server Containers by running each container in a highly optimized virtual machine. In this configuration, the kernel of the container host is not shared with other containers on the same host. These containers are designed for hostile multitenant hosting with the same security assurances of a virtual machine. Since these containers do not share the kernel with the host or other containers on the host, they can run kernels with different versions and configurations (with in supported versions) – for example all Windows containers on Windows 10 use Hyper-V isolation to utilize the Windows Server kernel version and configuration.

Running a container on Windows with or without Hyper-V Isolation is a runtime decision. You may elect to create the container with Hyper-V isolation initially and later at runtime choose to run it instead as a Windows Server container.

What is Docker?

As you read about containers, you’ll inevitably hear about Docker. Docker is the vessel by which container images are packaged and delivered. This automated process produces images (effectively templates) which may then be run anywhere—on premises, in the cloud, or on a personal machine—as a container.

Just like any other container, a Windows Server Container can be managed with Docker.

Containers for Developers

From a developer’s desktop, to a testing machine, to a set of production machines, a Docker image can be created that will deploy identically across any environment in seconds. This story has created a massive and growing ecosystem of applications packaged in Docker containers with DockerHub, the public containerized-application registry that Docker maintains, currently publishing more than 180,000 applications in the public community repository.

When you containerize an app, only the app and the components needed to run the app are combined into an “image”. Containers are then created from this image as you need them. You can also use an image as a baseline to create another image, making image creation even faster. Multiple containers can share the same image, which means containers start very quickly and use fewer resources. For example, you can use containers to spin up light-weight and portable app components – or ‘micro-services’ – for distributed apps and quickly scale each service separately.

Because the container has everything it needs to run your application, they are very portable and can run on any machine that is running Windows Server 2016. You can create and test containers locally, then deploy that same container image to your company’s private cloud, public cloud or service provider. The natural agility of Containers supports modern app development patterns in large scale, virtualized cloud environments.

With containers, developers can build an app in any language. These apps are completely portable and can run anywhere – laptop, desktop, server, private cloud, public cloud or service provider – without any code changes.

Containers help developers build and ship higher-quality applications, faster.

Containers for IT Professionals

IT Professionals can use containers to provide standardized environments for their development, QA, and production teams. They no longer have to worry about complex installation and configuration steps. By using containers, systems administrators abstract away differences in OS installations and underlying infrastructure.

Containers help admins create an infrastructure that is simpler to update and maintain.

Video Overview

Try Windows Server Containers

Ready to begin leveraging the awesome power of containers? Hit the jumps below to get a hands-on with deploying your very first container:
For users on Windows Server, go here – Windows Server Quick Start Introduction
For users on Windows 10, go here – Windows 10 Quick Start Introduction+

What’s new in version 1710 of System Center Configuration Manager

Update 1710 for System Center Configuration Manager current branch is available as an in-console update for previously installed sites that run version 1610, 1702, or 1706.

The following sections provide details about changes and new capabilities introduced in version 1710 of Configuration Manager.

Site infrastructure

Updates for Peer Cache

Beginning with this release, Peer Cache is no longer a pre-release feature. No other changes for Peer Cache are introduced with this release. For more information, see Peer Cache for Configuration Manager clients.

Cloud distribution point support for Azure Government Cloud

You can now use cloud-based distribution points in the Azure Government cloud.

Inventory default unit revision

As devices now include hard drives with sizes in the gigabyte (GB), terabyte (TB) and larger scales, this release changes the default unit (SMS_Units) used in many views from megabytes (MB) to GB. For example, the v_gs_LogicalDisk.FreeSpace value now reports GB units.

Client management

Co-management for Windows 10 devices

In the previous Windows 10 updates, you can already join a Windows 10 device to on-premises Active Directory (AD) and cloud-based Azure AD at the same time (hybrid Azure AD). Starting with Configuration Manager version 1710, co-management takes advantage of this improvement and enables you to concurrently manage Windows 10, version 1709 (also known as the Fall Creators Update) devices by using both Configuration Manager and Intune. It’s a solution that provides a bridge from traditional to modern management and gives you a path to make the transition using a phased approach. For details, see Co-management for Windows 10 devices.

Restart computers from the Configuration Manager console

Beginning with this release, you can use the Configuration Manager console to identify client devices that require a restart, and then use a client notification action to restart them.

See How to manage clients in System Center Configuration Manager

Application Management

Improvements for Run Scripts

This release brings several improvements to the Run Scripts feature, which lets you deploy PowerShell scripts to run on managed devices. This feature was first introduced in version 1706.

Improvements include:

  • Use Security Scopes to help control who can use Run Scripts
  • Real-time monitoring of the scripts you run
  • Parameters for the script display in Create Script Wizard, support validation, and are identified as mandatory or optional.

For more on using Run Scripts, see Create and run scripts.

New mobile application management policy settings

The following settings have been added to the mobile application management policy settings:

  • Disable contact sync: Prevents the app from saving data to the native Contacts app on the device.
  • Disable printing: Prevents the app from printing work or school data.

Software Center no longer distorts icons larger than 250×250

With this release, Software Center will no longer distort icons that are larger than 250×250. Software Center made such icons look blurry. You can now set an icon with a pixel dimensions of up to 512×512, and it displays without distortion.

To add an icon for your app in Software Center, see Create applications.

Operating system deployment


Beginning with the Windows 10, version 1709 (also known as the Fall Creators Update) release, Windows media includes multiple editions. When configuring a task sequence to use an operating system upgrade package or operating system image, be sure to select an edition that is supported for use by Configuration Manager.

Add child task sequences to a task sequence

You can add a new task sequence step that runs another task sequence, which creates a parent/child relationship between the task sequences. This allows you to create more modular task sequences that you can re-use.

To learn more about the child task sequence, see Child task sequence.

Software Center customization

You can add enterprise branding elements and specify the visibility of tabs on Software Center. You can add your Software Center specific company name, set a Software Center configuration color theme, set a company logo, and set the visible tabs for client devices.

For more information, see Plan for and configure application management in System Center Configuration Manager.

Software updates

Surface driver updates

Beginning with this release, managing Surface driver updates is no longer a pre-release feature.


Limit Windows 10 Enhanced telemetry to only send data relevant to Windows Analytics Device Health

You can now set the Windows 10 telemetry data collection level to Enhanced (Limited). This setting enables you to gain actionable insight about devices in your environment without devices reporting all of the data in the Enhanced telemetry level with Windows 10 version 1709 or later.

For more information, see How to configure client settings in System Center Configuration Manager.

Mobile device management

Actions for non-compliance

You can now configure a time-ordered sequence of actions that are applied to devices that fall out of compliance. For example, you can notify users of non-compliant devices via e-mail or mark those devices non-compliant. For details, see Set up actions for non-compliance.

Windows 10 ARM64 device support

Hybrid mobile device management (MDM) scenarios will be supported on ARM64 devices running Windows 10 when these devices are available.

These scenarios include:


Deploying .appxbundle applications built for multiple architectures may not work on these devices, and this scenario is not supported at this time.

Improved VPN Profile Experience in Configuration Manager Console

With this release, we’ve updated the VPN profile wizard and properties pages to display settings appropriate for the selected platform:

  • Each platform has its own workflow, meaning that new VPN profiles contain only the setting supported by the platform.
  • The Supported Platforms page now appears after the General page. You now choose the platform before setting property values.
  • When the platform is set to AndroidAndroid for Work, or Windows Phone 8.1, the Supported platforms page is not needed and is not displayed.
  • The Configuration Manager client-based workflow has been combined with the hybrid mobile device (MDM) client-based Windows 10 workflows; they support the same settings.
  • Each platform workflow includes just the settings appropriate for that workflow. For example, the Android workflow contains settings appropriate for Android; settings appropriate for iOS or Windows 10 Mobile no longer appear in the Android workflow.
  • The Automatic VPN page is obsolete and has been removed.

These changes apply to new VPN profiles.

To minimize compatibility risk, existing VPN profiles are unchanged. When you edit an existing profile, the settings appear as they did when the profile was created.

For more information, see VPN Profiles on mobile devices in System Center Configuration Manager.

Limited support for Cryptography: Next Generation (CNG) certificates

Configuration Manager has limited support for Cryptography: Next Generation (CNG) certificates. Configuration Manager clients can use PKI client authentication certificate with private key in CNG Key Storage Provider (KSP). With KSP support, Configuration Manager clients support hardware-based private key, such as TPM KSP for PKI client authentication certificates.

For more information, see CNG certificates overview.

Protect devices

Create and deploy Exploit Guard policies

You can create and deploy policies that manage all four components of Windows Defender Exploit Guard, including attack surface reduction, controlled folder access, exploit protection, and network protection.

Create and deploy Windows Defender Application Guard policy

You can create and deploy Windows Defender Application Guard policies by using the Configuration Manager endpoint protection.

Device Guard policy changes

The following three changes have been made in relation to Device Guard policies:

  • Device Guard policies have been renamed to Windows Defender Application Control policies. So, for example, the Create Device Guard policy wizard is now named Create Windows Defender Application Control policy wizard.
  • Devices using the Fall Creators Update for Windows version 1709 don’t require a restart to apply the Windows Defender Application Control policies. Restarting is still the default, but you can turn off restarts.
  • You can set devices to automatically run software trusted by the Intelligent Security Graph.

We’d like to welcome you to our new home on the web

Thanks for visiting, AT Computer Consultants Ltd are based in the North West of England and provide high quality technical training and consultancy services based around Microsoft System Center, Windows Azure, and Microsoft Office 365.

Whatever your needs, we can provide a total solution, working together with you from that initial spark of an idea, through it’s planning and to it’s realisation.

Founded in January 2003 by Tony Law and Alan Moss, both of whom have passion and a drive for all forms of technology, we have an outstanding reputation for customer service, and for a personal focus. The fact that the majority of business is generated by personal referrals from existing customers speaks volumes.

We have a wealth of experience working with  Academic Institutes, Public Sector, Defence and flagship training providers.