Advanced Configurations for Windows 10

Generally speaking, past iterations of Windows allowed something of a free for all mentality in customizing images and Windows installations. It is worth noting that most of the techniques developed by IT professionals outside of Microsoft's walls were not truly supported by Microsoft. They however certainly achieved the goals of the IT professionals to customize the Windows installation for the required business use case. Usually, the solutions were stable (enough), and Microsoft provided best effort support when issues arose, so things were good.
As IT organizations in large enterprises matured, however, business folks became involved more in the IT process. ISO, Information Technology Infrastructure Library (ITIL), change review boards, procedures, and so on all came into the IT realm. At this point, the best effort and stable (enough) aspects of solutions became issues to address. One does not simply run global, enterprise-grade applications the world depends upon with kludged solutions hacked together from tips off various blogs and forums found around the internet.
To help IT organizations reduce support incidents, increase the stability of the solutions, and benefit the Windows platform, changes and recommendations started being made. In Windows XP, for example, it was common practice to swap hardware abstraction layers (HALs) based on CPU architecture so the organization could use a single image for deploying Windows. Microsoft never really supported this, but looking at the reasoning, the common issue was that Windows didn't handle this properly, so we hacked a solution to get around the issue. Therefore, making Windows not have the issue in the first place became a place to focus engineering resources on.
So came Windows 8.1 and then Windows 10--a conscious lock-down of the standard user areas of the operating system, isolation of the user experience, somewhat, to where they should be, to train users to not store things in C:\somepath but in the user profile for example, and also to train IT staff to image Windows in a reliable, repeatable method by creating the Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager (SCCM). One can cite many such efforts by Microsoft to direct or push users and IT staff in the direction of a more secure, stable, or even supported position.
General guidelines for a successful implementation of Windows 10 are as follows:

• Do not use the registry as a storage vehicle for large metadata
• Do not use the registry improperly when developing in-house applications
• Adhere to the least-rights concepts of Windows security

Virtual desktops

There is perhaps no greater of a deviation from the standard Microsoft vision of Windows than virtual desktops. For those unfamiliar with the topic, the concept is that an installation of Windows is contained in a virtual machine on a host, and the host then holds as many virtual machines as it can to increase density and cost savings for the infrastructure.
Brian Madden wrote a book discussing this triangle sort of problem called VDI Delusion. The crux of the issue is that Virtual Desktop Infrastructure (VDI) items such as virtual hosts, high-speed storage, network devices, expensive software licenses, and other technologies quickly add to a large bill. Most organizations tend to think VDI means cost savings; this could not be further from the truth in many instances. In my opinion, VDI projects that succeed are based on the concepts of control, user experience management, data centralization, or security concerns. The last is (somewhat) questionable in nature in terms of benefit.
No matter how secure the system is, what prevents the user from taking pictures with the ubiquitous cell phone? But that isn't to say due diligence should not be observed in building a well-planned VDI environment. Just make sure the goals and objectives of the project are clear and achievable.
VDI projects, like most IT projects, have some core fundamental infrastructure items that need to be in good working order for the project to succeed. These should go without saying, but just for clarity, we'll cover the items and what "good" looks like for each.

VDI infrastructure best practices

VDI projects require considerable underlying and complimentary infrastructure to work well.. The scale and scope of these projects into themselves is left to other books, but we can quickly cover them here for some background. It is important to also be able to speak about these subjects and interact with the team or teams managing the infrastructure on which a VDI project runs on top of.
The backend storage assigned to the project should be excellent. Ideally, it will be architected with the golden image on flash storage with differencing disks linked back to the golden image. The differencing disks would also reside in a flash memory pool. If this sounds expensive, it is because it is. High-speed 10 GB Ethernet or even fiber channel connectivity would be in play as well.
CPU considerations are generally not the bottleneck, but depending on use case very well can be a strong factor in performance. One consideration that often goes unthought of is NUMA spanning, where a virtual machine's CPUs are actually resident on multiple physical processor sockets on the host system. The communication from one core to another in the VM then is slow as it has to pass along the QuickPath Interconnect (QPI) bus. Quality hyper-visors will enable disallowing NUMA spanning for VMs.
Another consideration is whether users require GPU acceleration for viewing video (for example, stock traders watching Bloomberg), or what about engineers running AutoCAD? If so, the traditional blade server chassis used to achieve maximum density may not suffice. This expands the cost of the system as a whole, as density per host usually decreases in this scenario and the chassis with GPUs tend to be larger, generate more heat, and consume more power, all of which add to the final operating cost of the solution.
The user profile disks (UPDs) are another factor to consider as well as application virtualization or layering technologies. These increase the complexity of the image creation process as well as make determining the root cause of problematic issues such as blue screens a daunting task.
Application virtualization is a technique whereby the application is bubbled or otherwise contained as a unique entity unto itself. Now it still requires the OS to run and so forth. But it is an object, so to speak. Then, the application can be streamed into the image and launched at request time versus being baked into the master golden image. There are arguments of pros and cons for this that could make up a whole chapter or two. Sometimes this technology fits, while sometimes it appears silly and cumbersome.
Layering technologies such as Citrix Unidesk allows a similar approach as application virtualization. But instead of each app sort of streaming in, when the user logs on to the guest image, it is presented based on the profile of the user. What apps does the user need? Oh A, B, and C? Okay, let's provide the base OS layer, then layer on top the strata of those applications. This sounds odd at first but the technique is actually quite fast and efficient.
User profile disks are a method of bubbling the user data, the documents, downloads, desktop folders, settings, registry data, and so on of the user into a container. This is then merged at logon. Microsoft has a technology for this (UPD) that is native to Hyper-V, and similar concepts have existed for some time with Citrix and VMware.

VDI configuration considerations

With all this information in focus, how does a system administrator create the image for Windows 10 that will run in this VDI configuration?
ProjectVRC (http://www.projectvrc.com/) was a good source of information for a number of years. They published whitepaper studies of performance metrics of VDI in a variety of workloads and found web-based ads in browsers were a major cause of CPU consumption in VDI implementations and some other great nuggets of information. They seem to be silent lately but it's probably worth bookmarking them just in case.
Brian Madden (http://www.brianmadden.com/) is a good source of knowledge as well, with an excellent repository. Brain himself has left IT but the site still seems to be going strong. You can find a great variety of articles on VDI here.
Generally in Windows 7 and 8.x, administrators used vendor-provided scripts to configure the Windows image to make it ready to be a virtual machine. With Windows 10, that can still be the case but Microsoft is starting to (some would say finally) understand that VDI and remote desktop usage is a thing. Microsoft has partnered with Citrix to provide desktops for Windows 10 in Azure, and AWS has a similar offering as well.
With these types of configurations becoming more common, we can expect a streamlined guidance or profile from Microsoft on VDI configuration to be sure. It may even be that a new version of Windows 10 comes out that is cloud ready. It wouldn't surprise me.
Perhaps one of the often overlooked considerations for a VDI deployment is the ability to collect diagnostic data from the virtual guests. How are you going to collect a full memory dump if needed? Are you doing error reporting of user-mode applications? What about the performance impact of applications and monitoring software such as data loss prevention suites? These are things that ideally are thought through prior to a call with a Microsoft or other support engineer in an emergency.
In conclusion, the key point for a VDI solution is to spend the money to do it right. There are few magical registry tweaks that can fix a slow backend storage solution for your VDI users.

The Windows ICD

In the not-so-distant past, it was quite common place for an IT administrator to purchase a computer with a perfectly good Windows OS preinstalled and then bring it into the corporate environment by re-imaging with a corporate image. The reasons for this vary from organization to organization, but often contain the usual suspects of Original Equipment Manufacturer (OEM) installed cruft, trial applications, or even the wrong SKU of Windows. This is a rather inefficient process that needlessly throws out the whole operating system when only a small subset needs to be reconfigured.
With Windows 10, Microsoft is aiming to change this behavior through a technology known as provisioning packages. Provisioning packages are configuration bundles that can set core OS settings as well as install drivers or applications. There is, perhaps, no better indication of Microsoft's desire to end the re-imaging of new computers than the new name they have given the design tool: Windows Configuration Designer (WCD) (formerly Windows Image and Configuration Designer). WCD can be obtained in the 1703 release of the Windows 10 Assessment and Deployment Kit (ADK) as either a standalone install or as part of the new imaging and configuration design bundle that includes other imaging-centric utilities such as the User State Migration Tool (USMT) and Windows PE.
Upon launching the new WCD console, an IT administrator is presented with several wizards that are designed to help create provisioning packages for:

• Desktops
• Mobile devices
• Surface hubs
• Kiosks

These wizards will step through configuring everything from setting a naming scheme, upgrading to a higher OS SKU, enrolling in Active Directory (AD) or Azure AD, and uninstalling preinstalled applications as well as installing application packages. An advanced configuration interface is also available that reveals all configuration runtime options, but once a project has been converted to an advanced configuration, it cannot be turned back into a simple, wizard-based project.
Once a project has been properly configured, the IT administrator can export the project into a provisioning package that can be distributed and installed. The export process will allow the provisioning package to be secured through encryption and signing certificate, though it should be noted that only the provisioning package is encrypted and any passwords contained in the project file itself will remain in plain text.
To deploy a provisioning package created with installable client driver (ICD) to a desktop edition of Windows 10, the package can either be installed during initial setup of the device via USB disk, or post setup via USB, network share, or an enterprise endpoint management system. Post setup deployment can be initiated by navigating to the provisioning package and double-clicking or, in a more automated fashion, using the AddProvisioningPackage PowerShell cmdlet. A provisioning package can also be added to a mobile device using the Add or remove provisioning package wizard in the Accounts | Access work or school area of the Settings application or by dragging the provisioning package onto a mobile device connected via USB to a Windows PC.

Windows 10 Kiosk Mode

Windows 10 Kiosk Mode is a feature of Windows 10 designed for use in limited security or multi-user environments to restrict access to a single application. In a scenario such as an interactive directory in a building lobby, a device will need to provide the building directory functionality to many users without requiring the users to authenticate. It will also need to restrict users from accessing any applications outside of the directory application.
In order to accomplish this, Kiosk mode replaces Windows Explorer, the default shell, with an alternative application specified by the administrator. By replacing the default shell, access to the underlying Windows installation is removed and is limited to the specified application. When the replacement shell application is closed, the user session is ended, so there is no way to access the underlying operating system.
When specifying the Kiosk Mode application, an administrator must choose between two application technologies:

• Universal Windows Platform (UWP): Modern applications using UWP to run on any device that runs Windows 10, such as tablets or even an Xbox
• Classic Windows applications: Traditional applications written against to run only on PCs using legacy APIs such as Win32 or Component Object Model (COM)

Provisioning Kiosk Mode can be accomplished in a number of ways, depending on the type of application that is chosen as the kiosk app and the edition of Windows 10 being configured. Kiosk mode for UWP applications is available in Windows 10 Pro, Education, or Enterprise while classic Win32 apps are available only for Windows 10 Enterprise or Education.
Introduced in Windows 10 build 1607, the Provision kiosk devices wizard will allow an administrator to create a provisioning package that can be used to configure a Windows 10 device for Kiosk Mode without requiring it to be re-imaged. Using the wizard, an administrator can configure various settings covered in the ICD in the chapter as well as a local kiosk user account, auto-login settings, and either a UWP or classic application to act as the shell.
If a UWP application is to be used as the kiosk app, the configuration can be accomplished manually using the Settings application, or in a more automated fashion using a PowerShell script. Windows 10 Enterprise or Education also offers the ability to configure a UWP kiosk app using an Mobile device management (MDM) policy or provisioning package.
To configure a classic Windows app as a kiosk app, an administrator must use the Windows 10 feature Shell Launcher that will need to be installed using the programs and features wizard or Deployment Image Servicing and Management (DISM). Once enabled, the root\standardcimv2\embedded WMI namespace can be used to configure the default shell for a user or group as well as the action that should be performed when the shell application exits. These actions include relaunching the shell application, restarting the computer, and shutting the computer down.

AutoPilot mode

Windows AutoPilot is system management without the servers. Similar to Microsoft's InTune or SCCM, Windows AutoPilot can be used to manage devices. It requires Azure AD and some cloud-based services but the result is you can configure and tweak your devices and recover/reconfigure them quite easily without the infrastructure costs associated with a traditional SCCM multi-site deployment architecture.
At the time of writing this book, the current capabilities of AutoPilot are:

• Automatically join devices to Azure AD
• Auto-enroll devices into MDM services, such as Microsoft Intune
• Restrict the administrator account creation
• Create and auto-assign devices to configuration groups based on a device's profile
• Customize Out of Box Experience (OOBE) content specific to the organization

The key item OOBE is tweaking. This is a bit of work done by enterprises now with SCCM or MDT to tweak the installation of Windows on devices. But now it's cloud-based here with AutoPilot (with of course an Azure AD Premium subscription, whatever that cost may be).
In a way, this will, perhaps eventually, make deployment-specialized IT professionals worry about their long-term survivability and with good cause. Fewer Exchange Server administrators remain compared to 10 years ago. Similar too will be deployment engineers, I believe. Packaging apps and tweaking unattend.xml files will be going away I should think. Best to get prepared now.
As this is a somewhat new offering at the time of writing, little else can be said about it, other than be prepared for easy deployments versus more traditional ones that require a bit more planning and infrastructure. This is a good thing, unless you made a living off the old way, I guess.

The Set up School PCs application

Microsoft released an application recently, somewhat akin to the WCD, named Set up School PCs. This is unsurprisingly an application for teachers or school IT staff to set up machines for student use.
What is interesting is the feature set. Let's take a look:

Installation is a snap, right in the Windows Store. One interesting tidbit is this app has a strong tie-in with Azure AD. But we'll get to that:

The wizard walks you through the simple process of making a master USB image that can be used to manipulate the existing image on a Windows 10 device:

Here we go. Hey, this can be used without Azure AD, but you really want it to be fully functional. The real issue will appear later when you try to manage the devices centrally without Azure AD to help you, unfortunately:

This is basically creating a machine name variable for the administrator:

Pay attention here. The biggest single thing I see is Remove apps preinstalled by the device manufacturer. What a boon to, well, anyone. Anyone who has used a store-bought Windows device knows they come with an excess of software no one wants but everyone has, some of it difficult to uninstall properly without a removal kit made by the software vendor. Or a quiz at the end on why did you uninstall our bloatware?
Anyway, it's nice we can remove this for schools. How about giving the home user one too, Microsoft? Please?
From here, you simply follow the wizard and are rewarded with a template on a USB stick that can be used to configure your school machines properly for students. Yay!

Device lockdown

Windows 8 was the last Microsoft OS to deliver an embedded edition as a formal SKU. In Windows 10, the customization may be applied directly to a Windows 10 Enterprise (or Education) installation or image file. The customization available to modify the image is found in Windows features under the device lockdown area. Those who have crafted images for Windows Embedded in the past will recognize the options and be familiar with the capabilities already. Certainly, they are worth covering in this text for a clear understanding of what these capabilities are and aren't. These features are available only in Windows 10 Enterprise and Education editions, yet are visible on a Windows 10 Professional installation. They may or may not work properly though on Professional and likely violate license terms if they do; your mileage may vary:

Device Lockdown consists of:

• Custom Logon: Defined as enables customized logon experiences, which is a bit vague
• Keyboard Filter: Prevents unwanted keystrokes (enabling audit mode, avoiding auto logon, and so on)
• Shell Launcher: For launching your own custom shell instead of the default Windows one
• Unbranded Boot: Suppresses Windows elements that appear when Windows starts, resumes, or encounters errors
• Unified Write Filter: Installs services and tools to protects physical media from write operations

Note that checking these boxes enables the feature for configuration; additional work is needed to implement the feature properly. An overview of each is found next.

Custom Logon

Custom Logon can modify the logon screen to remove certain system components. Specific registry settings are:
AnimationDisabled: This disables the animation screen displayed during a new Windows logon, the annoying Hi, I'm organizing your files just like the last 3-4 times you've seen this after a new build is applied.
BrandingNeutral: This is a setting that can disable the power button, language button, ease of access, switch user, and so on.
HideAutoLogonUI: If you enable automatic sign-in for a device, this will hide or show the Windows Welcome Screen during the logon process.
NoLockScreen: Useful for kiosk and other devices, this setting will be set if the lockscreen is invoked when the machine is idle.
These settings give the enterprise administrator additional flexibility to tweak to their hearts' content.

Keyboard filter

This one is pretty straightforward. This filter is used to prevent keys such as PrtScrn and combinations such as Ctrl + Alt + Delete from doing their normal functions. For managed workstations or stations that may be in unknown peoples' hands (think kiosks at airports, ATMs, medical devices, and so on), this is a great way to lock them down to prevent tampering.

Shell Launcher

Shell Launcher is an interesting item in that Microsoft allows developers to create their own shells for Windows. The documentation on doing this for Windows 10 is somewhat incomplete at this time, but one can expect it follows similar guidelines as Windows Embedded, which is documented on MSDN and TechNet. This is also how we can specify Windows 10 to launch Citrix or VMWare launchers for thin clients. Interestingly enough, in build 1511, this was known as Embedded Shell Launcher and in newer builds as Custom Shell Launcher.
Typically, these need to know which users you want the custom shell for. This is only available to control via PowerShell at this time and is documented at https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/shell-launcher.
The concept here is that you want standard or kiosk accounts to log in using the custom shell but administrator accounts need not use it so they can perform administrative tasks if necessary.
For example, to make an internet browsing kiosk, you'd make a script to execute Internet Explorer to serve as our launch command:
start-process -wait -WindowStyle Maximized -FilePath 'c:\program files\internet
explorer\iexplore.exe' -ArgumentList 'https://insider.windows.com/'

Unbranded Boot

Unbranded Boot lets the system administrator customize items such as the boot loading screen, animations, and shutdown experiences as well. The primary use case is, naturally, device branding.
The specific registry keys are as follows:
DisableBootMenu: To prevent tampering, the administrator can disable F8 and F10 keys during startup
DisplayDisabled: If your system encounters an error, it displays a blank screen instead of the Microsoft image
HideAllBootUI: This hides all the Windows UI elements during boot (logo, scrolling status indicator, status messages, and so on)
HideBootLogo: This suppresses the Windows boot logo at boot
HideBootStatusIndicator: This setting suppresses the status indicator displayed during boot
HideBootStatusMessage: This, similar to HideAllBootUI, hides the boot status of the OS loading phase (applying Group Policy messages and so on)
CrashDumpEnabled: This setting has a few values that govern the size of a dump captured when the system encounters a stop condition.

Unified Write Filter

A Unified Write Filter is a filter driver that seals the drive in a non-write view and then keeps a differencing area in RAM of all the changes the user makes during the session. This area is known as the UWF overlay. This is a virtual storage area that looks at all the intended writes for the protected storage area. Instead of performing the write, it reads that disk sector from disk, then modifies it as the write was supposed to, and holds that change and caches it in memory (unless a page-file is in use; then it can make use of the page-file to extend the overlay area).
This is the biggest drawback of UWF. Typically, embedded devices do not have a preponderance of RAM installed (they are supposed to be cheaper than desktops, after all) and their storage is slow as well, so if the user does too much on the device, you run the risk of actually running out of RAM on the device.
To mitigate this, you can exclude areas of the storage from UWF protection (much like an antivirus). Administrators have to do this, and a restart of the device is required for them to take effect.
The same consideration is made for the Windows registry as the disk volume. And areas can be excluded there as well.
Applying updates to a UWF-protected volume requires some acrobatics. These are well documented at https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/service-uwf-protected-devices.

Summary

In this article, we touched upon many different topics relating to customizing and configuring the Windows image for enterprise use cases: point of sale, medical devices, kiosks in public areas, and virtualized desktops to name a few. Windows 10 can be customized in a variety of ways to meet the needs of a changing world. The good news primarily is that these modifications are coming more in the supported and standardized realm by Microsoft rather than random reghacks and tweaks that might work now and have unintended consequences later on.