Code Library: Windows Server 2016

Showing posts with label Windows Server 2016. Show all posts

Server management tools As infrastructure and deployments become more hybrid in nature, where we have workloads spread
across clouds, the management effort to control all these different areas increases exponentially. This
is obviously a bad thing and we want to be able to provide a more controlled way to manage
resources which might exist on-premises but also in Azure.

Server management tools (SMT) introduces a web-based GUI hosted in Azure and command-line
tools that can do this for your Windows Server 2016 estate. For instance, your administrators can
manage Nano Server or server core easily from this GUI without affecting the footprint of those
deployments.

The tool currently has the following capabilities
 View and change system configuration
 View performance across various resources and manage processes and services
 Manage devices attached to the server
 View event logs
 View the list of installed roles and features
 Use a Windows PowerShell console to manage and automate

Source of Information : Microsoft Introduction Windows Server 2016

System Center 2016 Just like Windows Server, System Center gets an updated edition, too. In this section, we detail what’s new for System Center 2016. The core focus of System Center 2016 is on hybrid management—how can we manage the cloud natively from System Center, but also how can we use the cloud to
extend the functionality of system center or manage the environment from the cloud. Microsoft
Operations Management Suite and Microsoft Intune are the management functions within the cloud that complement the System Center 2016 suite.

As you can imagine, a lot of what is new in System Center 2016 also focuses on ensuring that we can
support the new capabilities in Windows Server 2016. Also, System Center 2016 is designed to
truly facilitate the software-defined datacenter (SDDC) and gives you all the tools you require to
accomplish this.

Traditionally, System Center was geared toward managing your on-premises infrastructure. This
continued to evolve in the previous versions, and is yet even more of a focus in System Center 2016.
You can use System Center 2016 to manage your cloud environments, as well. For example, do you
want to know the health of your Office 365 Subscription? In System Center 2016, you now can gather this information.

Breakdown of some of the new features in System Center 2016 with respect to their general management areas:

Device management
Windows 10 deployment support
MDM enrollment with Microsoft Azure Active Directory
Access restriction based on device enrollment and policy

Provisioning
Support for Windows Server 2016 Technical Review Hyper-V features
Rolling cluster upgrades
Simplified networking
Shielded virtual machine (VM) provisioning
Guarded host management
VMWare vCenter 5.5 support

Monitoring
Nano Server
Windows storage
SMS-S support
MP catalog improvements
Performance improvements
Enhanced data visualization
Improved Linux support
Improved network support

Automation
Migration to the cloud
SCO integration packs and runbooks
SMA support native Windows PowerShell
Windows Management Framework 5.0
Windows PowerShell ISE plug-in support for SMA runbooks

Self-service
Improved usability and performance
HTML 5 self-service portal
New Microsoft Exchange connector

Data protection
Azure Express Route supported
Shielded VM support
Storage spices direct

Source of Information : Microsoft Introduction Windows Server 2016

Windows PowerShell script debugging Windows Server 2016 introduced several improvements for script debugging introduced for Windows PowerShell:

 Break All
 Remote editing
 Remote debugging
 Job debugging
 Runspace debugging
 Remote Desired State Configuration debugging

Break All
Break All is a very useful function to stop a script as it’s running so that we can dive into the debugger to find out how the script is running and what the current state of the variables and other elements are. Support has been included for both the Windows PowerShell console and the ISE.
To use the debugger in a console session, press Ctrl+Break In the Windows PowerShell ISE, you can press Ctrl+B or, on the menu, click Debug and then click Break All.

Remote editing
With the current Windows PowerShell ISE, you can open and directly edit a file in a remote Windows
PowerShell session. Using a new command called PSEdit, we can directly edit files locally and in
remote sessions. The following code shows a sample in action:
[Cloud01]: PS C:\> PSEdit C:\WinDemo\Get-ComputerInfo.ps1
When you execute PSEdit, it will open the file in the ISE where you can make changes and save them
to the remote machine and reexecute the code.

Remote debugging
Extending on to the capabilities of remote editing, you can now debug a script running in a remote
session with the ISE.

The Set-PsBreakpoint cmdlet sets the breakpoint in the code and then you use the Write-Debug
cmdlet to output some information for use in your scripts when you encounter a break point. This
drops you into the debugger at that point to perform some additional work and look at the available
information. When a script encounters a breakpoint in a remote session, it will display a message indicating it has done so. Not all remote sessions will support a remote debug session, but when you connect to the remote session using the Connect-PSSession cmdlet, you will see the output. If remote debug is available, you can connect to the session by using the Enter-PSSession cmdlet, which connects you directly to the debugger.

Job debugging
One useful function in Windows PowerShell is the ability to execute scripts as background jobs. These jobs can run without clogging up the main console screen, letting you proceed with additional tasks.

This was fine, but these jobs could sometimes be difficult to troubleshoot and could require a lot of
trial and error in order to develop robust scripts that could truly be run as jobs.

Now, with Server 2016, Windows PowerShell introduces the Debug-Job cmdlet, which gives you the
ability to debug these background jobs more effectively. To get to this break state, the same cmdlet Set-PSBreakPoint or Wait-Debugger is used to “pause” the script and enter the debugger. You can type these cmdlets into your script and then verify the state of the job so that you can verify if it has encountered the breakpoint and is ready to debug.

Runspace debugging
Runspaces were introduced to solve a few problems that background jobs had introduced, such as
resources issues and performance problems. Runspaces are different from jobs in that they generate a
new thread of execution for the environment which doesn’t come with the same overhead as a
background job.

Desired State Configuration
Windows PowerShell Desired State Configuration (DSC) is a hot topic nowadays. DSC is a new
configuration management platform with which administrators can use Windows PowerShell for
deploying and managing software services and also for managing the environment in which these
services run. Windows Server 2016 introduces several improvements to DSC, and in this chapter, we
dive into two of these enhancements: the new Local Configuration Manager and a new partial
configuration feature.

Source of Information : Microsoft Introduction Windows Server 2016

Windows PowerShell Classes Windows PowerShell Classes provides a new method to extend the management surfaces of Windows PowerShell for developers and IT professionals alike. Using PowerShell Classes, these audiences can create Windows PowerShell artifacts in a traditional manner using formal syntax and semantics from object-orientated programming.

For example, developers would be familiar with such constructs as classes or methods. Now Windows PowerShell makes it possible for you to define these natively within the language for future use.

Windows PowerShell Classes, although not a level 200 topic that this book mainly covers, is an important improvement in the journey of Windows PowerShell so that its appeal to wider audiences becomes more apparent.

Here are some other elements that Windows PowerShell Classes support:
 Define Desired State Configuration resources by using the native Windows PowerShell language
 Define custom types (i.e., classes, properties, and methods)
 Support debug types
 Generate and handle exceptions using formal methods

Now this might seem extremely advanced right now, but we include it today to ensure that you are aware of the evolution of Windows PowerShell and how it can become an underpinning technology
to line-of-business applications today.

Source of Information : Microsoft Introduction Windows Server 2016

Active Directory Domain Services - Active Directory Federation Services As we move forward in a cloud-focused world, being able to control your identity is becoming more
important. We need to think about how we can use our corporate identity to access applications that
we don’t technically own anymore. We also need to think about how we provide access to applications we own to other organizations in a secure and controlled manner without having a
cumbersome user-management process.

Active Directory Federation Services (AD FS) provides this ability so that you can connect to applications that are on-premises or in the cloud (Platform as a Service [PaaS] or SaaS) with your
corporate identity.

AD FS has been around for quite a while (since AD FS 2.0), and with Windows Server 2016, there are further enhancements to the technology to ensure that it meets the next level of demands from organizations in the cloud world. Here are some of the key improvement areas for AD FS:

 Multifactor authentication
Windows Server 2016 contains a built-in Azure MFA adapter to simplify the process of using Azure MFA as the primary provider for authentication. There is no longer a need to deploy an onpremises MFA server.

 Device registration for hybrid conditional access
You now can configure AD FS to recognize the device status. This means that you can manage the device and apply policies as necessary. This will ensure that the device stays compliant to corporate policy and reduce potential risks to corporate resources.

 Windows 10 and Microsoft Passport integration
Microsoft Passport and AD FS have been designed to integrate to provide a further seamless authentication experience for Windows 10 users.

 Lightweight Directory Access Protocol (LDAP) integration to secure non-AD directories Many organizations don’t rely on Active Directory for their identities. When this is the case, AD FS
will integrate into LDAP v3–compliant directories. This will allow further integration into the cloud
using those identity providers and the same enterprise experience when using Active Directory.

 Auditing improvements
Auditing in AD FS has been quite complicated in the past, with lots of verbose information that is
difficult to track. In Windows Server 2016, Microsoft has streamlined these improvements to prove
a more consistent auditing experience and provide easier methods to trace through the logs.

 SAML 2.0 improvements
SAML support has been improved in Windows Server 2016 with the inclusion of importing trusts
based on metadata that contains multiple entities. With this support, you can configure AD FS to
participate in confederations such as InCommon Federations as well as other implementations
conforming to eGov 2.0.

 Customized sign-in experience
In Windows Server 2016 you can customize messages, images, logos, and themes on a per
application basis, making it possible for multiorganizations to have one deployment rather than
multiple to suit the individual units. You can extend these customizations on a per–relying party
basis, as well.

 Simplified password management for federated Office 365 users
AD FS can now send password expiry claims to relying party trusts. The application users will be
notified of their expiring passwords and then have the ability to take action and change their
passwords.

 Configure access control policies without knowing the claim rules language
In Windows Server 2016, there are new access control policy templates which ease the
configuration of claims rules. These templates bring a simple UI-driven process to quickly and
securely create claims rules for the organization.

 Migration from previous versions of AD FS
The upgrade process for AD FS has been greatly simplified in Windows Server 2016. Now, all
you need to do is install a Windows Server 2016 AD FS instance into an existing farm, verify the
functionality, and then remove the previous versions. AD FS in Windows Server 2016 can “act” like
a previous version of AD FS.

Source of Information : Microsoft Introduction Windows Server 2016

Active Directory Domain Services - Microsoft Passport Authentication methods are moving at a faster pace than ever before. Think about it for a moment:
you sign in to your laptop and then open your browser to go to your favorite websites where you again sign in. In these instances, you are not always using your corporate credentials. If you hear of a
new service and want to access it, the chances are that you will be prompted to sign up and use
credentials from, for example, your public Microsoft account, Facebook, Google, and so on. The
traditional paradigm of using a dedicated identity authentication provider that you build as an
application developer is moving on and we are now using more “well-known” services like those just
mentioned.

Microsoft Passport is a new key-based authentication method that goes beyond passwords to mitigate traditional authentication attacks. A user enrolls for Microsoft Passport but must ensure that the authentication provider she uses supports Fast Identity Online (FIDO) authentication; thus, through a two-step process, the user sets up Microsoft Passport on her device and sets a gesture or PIN. This can then be used to authenticate the user via Microsoft Passport

During the setup, a certificate of asymmetric key–pair is stored on the device. The private key is stored within the TPM chip on the device. The private key never leaves the device during the authentication process. The public key is registered in Azure Active Directory and Windows Server Active Directory. The user account has a mapping between the public and private key, which helps to validate the user. Additional controls are implemented via One Time Passwords, Phonefactor, and so on.

Source of Information : Microsoft Introduction Windows Server 2016

Active Directory Domain Services - Azure Active Directory Join When enterprises begin to adopt the cloud and the work force becomes mobile, managing an estate
that rarely touches the corporate network can become troublesome. There are a variety of other
challenges that occur; for example, how do you give access to organizational resources on a noncorporate device. Whatever the challenge Azure Active Directory (Azure AD) Domain Join is
another feature in Windows Server 2016 that will enhance the overall experience for identify and offer new capabilities for both corporate and personal devices alike.

Here are some of the benefits that come with Azure AD today:
 Availability of modern settings
On any device connected to a Windows domain or joined to an Azure AD Tenant, you now can access with your corporate credentials settings such as the following:
 Roaming or personalization, accessibility settings, and credentials
 Backup and restore
 Access to the Windows Store with your corporate credentials
 Live tiles and notifications

 Access organizational resources
On any device that traditionally can’t be domain joined. Now, you can grant access to corporate
resources.

 Single sign-on (SSO)
Provide SSO capabilities to Microsoft Office 365, internal resources, Software as a Service (SaaS) solutions, and so on.

 Bring Your Own Device (BYOD) equipment
On personal devices where you need to access corporate resources you can now specify a work account from which you can access those resources and be influenced by new technologies like
Conditional Access.

 MDM integration
Provides the ability for the BYOD scenario to become corporate-controlled resources via an autoenroll solution to your Mobile Device Management (MDM) solution like Microsoft Intune.

 Kiosk Mode for multiple users
You can configure a device in kiosk mode so that many users can interact with a single modern app; for example, a sign in application at the reception area of an enterprise.

 Developer experience
Lets your developers build applications that can cater to business and personal uses on a single stack

 Imaging
Give further control to the end users to accept the corporate image or allow corporate policies to be configured during the first-run experience.

Although these are all great features, why should you suddenly begin to adopt Azure AD Join?
Actually, there can be a variety of reasons, depending on what type of organization you are in. For
example, if yours is a startup organization with a large mobile foot print, providing users with the
ability to use their own laptops or personal machines that can connect to Azure AD Join would save
time and effort for the roll-out of a corporate policy. This would even stand true for more mature
organizations in relation to new markets that they want to penetrate and the difficulty they might
have in sending machines from corporate to the remote offices. Another possibility would be around
educational institutions and cloud email solutions such as those offered as a part of Office 365. These
institutions can manage all users in Azure AD and provide access to cloud email and control access to
other resources like Microsoft SharePoint Online.

Source of Information : Microsoft Introduction Windows Server 2016

Active Directory Domain Services - Privileged Access Management The world of cyber threats becomes more complicated every day, and because it is such an invisible
threat in most cases, we need to apply security in layers on different levels to mitigate every feasible
possibility. PAM was introduced to help mitigate common credential theft threats like pass-the-hash, spear phishing, and so on. PAM requires that you deploy Microsoft Identify Manager (MIM).

Most Active Directory environments would like to believe that they are completely clean of malicious activity, but the truth is that we can’t be 100 percent sure. For this reason, one of the first things PAM implements is a new bastion forest where it can guarantee that it is free from malicious activity. A special type of trust is established called a PAM Trust. This bastion forest is provisioned by MIM during the initial deployment. Figure 4-6 shows the basic concept of the new forest and the PAM trust established.

PAM provides the ability to isolate the use of privileged accounts by storing them in this bastion forest and making it more difficult for attackers to gain privileged access. MIM is used to provide
methods for users to be able to securely request and obtain administrative privileges when they need
them. After being “approved” by MIM’s workflows, a shadow security principle is provisioned in the
bastion forest. These shadow security principals are “linked” via a reference that is stored in an Active Directory attribute that essentially points to a SID of a privileged group in the original forest.

Users can request the privileged access by the following methods:
 The MIM Services Web API
 A REST Endpoint
 Windows PowerShell (using the New-PAMRequest cmdlet)

These simple methods can be integrated into other tools like automation runbooks and ticketing
systems to provide further control on the overall process.

Earlier in this chapter, we mentioned the concepts and technology of JIT and JEA, PAM is a way of
implementing this for your environment. Like JIT and JEA, PAM provides time-bound privileges to the request account and, of course, link it to the privileged group that has the necessary permissions to perform the task.

You also can adjust the Kerberos ticket lifetime to ensure it has the lowest possible Time-to-Live (TTL) value. This way, if you sign in and receive a Kerberos ticket, its lifetime will be bound to the time remaining from the total amount of time PAM has granted you access to the privileged group.
PAM also comes with a variety of new monitoring features to provide greater insight with respect to
who requested access, what type of access was actually granted, and, more important, what activities
that person performed during the privileged-access assignment.

You can view this information MIM or in the Event Viewer, or if you already have System Center
Operations Manager 2012 provisioned and use the Audit Collection Services, you can create visualizations of the information. Other third-party tools and Operations Management Suite (OMS)
will be able to visualize the information in the future, as well.

Source of Information : Microsoft Introduction Windows Server 2016

Windows Server 2016 - A strategy for securing privileged access It has to be said that no matter how secure you can make an operating system or service, it is only as
secure as the weakest password. For example, suppose that you have the most sensitive data on earth
and you encrypt it by using the most sophisticated technology, but then you use a password like “Password01”; this utterly defeats the purpose of putting in place a battery of secure technologies.

Let’s look at another scenario. Walk around your office and count how many people have written their passwords on notes and stuck them on their keyboards or monitors. Then, observe how many people have pictures of their family or pets on their desk. When those people need to think of a password, what is the likelihood that it might be something personal based on the pictures?

Now, let’s consider a final scenario: the social engineering attack. With this particular form of attack— which is a leading cause of security breaks—the attacker calls someone, out of the blue, and pretends to be from IT, saying he needs to verify some account information. If the attacker is good at his job, the chances are high that the hapless victim will readily provide the information.

With those scenarios in mind, the attacker will gain access to something and potentially use that access to perform an escalated attack. But, what if the account were a privileged one in the first place.

Securing privileged access is not a single technology; it is a set of practices that an organization can
implement to become more secure. Although focused primarily on privileged access, it highlights the
need for any organization to implement and test all policies related to security and conduct the
necessary readiness to make people aware of potential areas of exposure.

No network to which users have access will ever be 100 percent secure, but to begin down the path of
securing privileged access to systems and networks, you must be diligent with regard to the following
basics:

 Updates Deploy updates to domain controllers within seven days of release.

 Remove users as local administrators Monitor and remove users from local administrators if they don’t need this access. Use Active Directory to control membership centrally, if required.

 Baseline security policies Deploy policies that will maintain a standard configuration for the
organization. Exceptions will exist, of course, based on applications and certain requirements, but
these should be challenged on a repeated basis to ensure that the system is as compliant as
possible.

 Antimalware programs Maintain regular updating and regular scans of the environment. Clean
and remove threats as quickly as possible.

 Log and analysis Capture security information, perform regular reviews, and identify anomalies
within the log set. Perform follow-up action on each detected item to ensure that it is an identified source and safe “risk.”

 Software inventory and deployment Controlling the software installed in an environment is paramount to ensure that end users don’t install malware into the environment. In the same
, it is important to know what software is out there and maintain an inventory so that you
are aware if the state of a system has changed.

With these basics covered, we can move into more details about the strategy that underpins securing
privileged access. Be aware that you will not achieve this strategy overnight, and this should be built
as a progressive implementation so that the organization’s practices can change and adapt to these
new principles.

As with most strategies, you need to establish short-, medium-, and long-term goals. The following
table describes the goals and the time frames you should use as well as the areas of focus for each
goal.

Source of Information : Microsoft Introduction Windows Server 2016

Windows Server 2016 Audit PNP Activity Found in the Detailed Tracking category, you can use the Audit PNP Activity subcategory to audit when plug-and-play detects an external device. Only Success audits are recorded for this category.

Additional changes have been made in Windows Server 2016 that expose more information to help
you identify and address threats quickly. The following table provides more information:

Kernel Default Audit Policy
In previous releases, the kernel depended on the LSA to retrieve information in some of its events. In Server 2016, the process creation events audit policy is automatically turned on until an actual audit policy is received from the LSA. This results in better auditing of services that might start before the LSA starts

Default process Security ACL (SACL) to LSASS.exe
A default process, SACL was added to LSASS.exe to log processes attempting to access LSASS.exe. The SACL is L"S:(AU;SAFA;0x0010;;;WD)". You can turn this on under Advanced Audit Policy Configuration|Object Access|Audit Kernel Object.

New fields in the sign-in event
The sign-in event ID 4624 has been updated to include more verbose information to make them easier to analyze. The following fields have been added to event 4624:

 MachineLogon String: yes or no
If the account that signed in to the PC is a computer account, this field will be yes; otherwise, the field is no.

 ElevatedToken String: yes or no
If the account that signed in to the PC is an administrative sign-in, this field will be yes; otherwise, the field is no. Additionally, if this is part of a split token, the linked login ID (LSAP_LOGON_SESSION) will also be shown.

 TargetOutboundUserName String and TargetOutboundUserDomain String
The user name and domain of the identity that was created by the LogonUser method for outbound traffic.

 VirtualAccount String: yes or no
If the account that signed in to the PC is a virtual account, this field will be yes; otherwise, the field is no.

 GroupMembership String
A list of all of the groups in the user’s token.

 RestrictedAdminMode String: yes or no

If the user signs in to the PC in restricted admin mode with Remote Desktop, this field will be yes.

New fields in the process creation event
The sign-in event ID 4688 has been updated to include more verbose information to make it easier to analyze. The following fields have been added to event 4688:

 TargetUserSid String
The SID of the target principal.

 TargetUserName String
The account name of the target user.

 TargetDomainName String
The domain of the target user.

 TargetLogonId String
The logon ID of the target user.

 ParentProcessName String
The name of the creator process.

 ParentProcessId String
A pointer to the actual parent process if it's different from the creator process.

Security Account Manager (SAM) events
New SAM events were added to cover SAM APIs that perform read/query operations. In previous versions of Windows, only write operations were audited. The new events are event ID 4798 and event ID 4799. The following
APIs are now audited:
SamrEnumerateGroupsInDomain
SamrEnumerateUsersInDomain
SamrEnumerateAliasesInDomain
SamrGetAliasMembership
SamrLookupNamesInDomain
SamrLookupIdsInDomain
SamrQueryInformationUser
SamrQueryInformationGroup
SamrQueryInformationUserAlias
SamrGetMembersInGroup
SamrGetMembersInAlias
SamrGetUserDomainPasswordInformation

Boot Configuration Database (BCD) events
Event ID 4826 has been added to track the following changes to the BCD:
DEP/NEX settings
Test signing
PCAT SB simulation
Debug
Boot debug
Integrity Services
Disable Winload debugging menu

PNP Events
Event ID 6416 has been added to track when an external device is detected through plug-and-play. One important scenario is if an external device that contains malware is inserted into a high-value machine that doesn’t expect this type of action, such as a domain controller.

Source of Information : Microsoft Introduction Windows Server 2016

Remote credential guard Remote credential guard provides protection against your credentials being stolen when you are remotely connected to a system via a remote desktop session.

When a user attempts to remote desktop to a remote host, the Kerberos request is redirected back to the originating host for authentication. The credential simply does not exist on the remote host any more. If a remote host (i.e., an end user’s computer or server) has malicious code running on it that can obtain credentials, remote credential guard will mitigate this because no credentials will be passed into the remote host.

There are some requirements for remote credential guard to operate:
 The user must be joined to the same Active Directory domain or a remote desktop server must be joined to a domain with a trust relationship to the client device’s domain.
 They must use Kerberos authentication.
 They must be running at least Windows 10, version 1607 or Windows Server 2016.
 The Remote Desktop classic Windows app is required. The Remote Desktop Universal Windows
Platform app doesn't support Remote Credential Guard.

To turn on remote credential guard, you can configure this via a group policy and widely deploy this
across your estate.

To configure this via group policy, open the Group Policy Management Console, and then go to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation. Next,
double-click Restrict Delegation To Remote Servers, and then select Require Remote Credential
Guard. Finally, click OK and run gpudpate /force to push the group policy out.

Source of Information : Microsoft Introduction Windows Server 2016

Enhanced Kernel Mode protection using Hypervisor Code Integrity The core functionality and protection of Device Guard begins at the hardware level. Devices that have processors equipped with SLAT technologies and virtualization extensions, such as Intel VT x and AMD V, will be able to take advantage of a Virtualization Based Security (VBS) environment that dramatically enhances Windows security by isolating critical Windows services from the operating system itself.

Device Guard uses VBS to isolate its Hypervisor Code Integrity (HVCI) service, which makes it possible for Device Guard to help protect kernel mode processes and drivers from vulnerability exploits and zero-day attacks. HVCI uses the processor’s functionality to force all software running in kernel mode to safely allocate memory. This means that after memory has been allocated, its state must be changed from writable to read-only or run-only. By forcing memory into these states, it helps to ensure that attacks are unable to inject malicious code into Kernel mode processes and drivers through techniques such as buffer overruns or heap spraying.

To deliver this level of security, Device Guard has the following hardware and software requirements:
 UEFI Secure Boot (optionally with a non-Microsoft UEFI CA removed from the UEFI database)
 Virtualization support turned on by default in the system firmware (BIOS):
 Virtualization extensions (for example, Intel VT-x and AMD RVI)
 SLAT (for example, Intel EPT and AMD RVI)
 IOMMU (for example, Intel VT-d, AMD-Vi
 UEFI BIOS configured to prevent an unauthorized user from disabling Device Guard–dependent hardware security features (for example, Secure Boot)
 Kernel-mode drivers signed and compatible with hypervisor-enforced code integrity

Source of Information : Microsoft Introduction Windows Server 2016

Shielded VMs Today, in most virtual environments there are many types of administrators who have access to VM
assets, such as storage. That includes virtualization administrators, storage administrators, network
administrators, backup administrators, just to name just a few. Many organizations including hosting
providers need a way to secure VMs—even from administrators—which is exactly what shielded VMs provides. Keep in mind that this protection from administrators is needed for a number of reasons.

Here are just a few:

 Phishing attacks
 Stolen administrator credentials
 Insider attacks

Shielded VMs provide protection for the data and state of the VM against inspection, theft, and tampering from administrator privileges. Shielded VMs work for Generation 2 VMs that provide the
necessary secure startup, UEFI firmware, and virtual Trusted Platform Module (vTPM) 2.0 support
required. Although the Microsoft Hyper-V hosts must be running Windows Server 2016, the guest OS in the VM can be Windows Server 2012 or above.

A new Host Guardian Service instance is deployed in the environment, which stores the keys required for an approved Hyper-V host that can prove its health to run shielded VMs.

A shielded VM provides the following benefits:
 BitLocker encrypted drives (utilizing its vTPM)
 A hardened VM worker process (VMWP) that encrypts live migration traffic in addition to its runtime state file, saved state, checkpoints, and even Hyper-V Replica files
 No console access in addition to blocking Windows PowerShell Direct, Guest File Copy Integration Components, and other services that provide possible paths from a user or process with
administrative privileges to the VM

How is this security possible? First, it’s important that the Hyper-V host has not been compromised
before the required keys to access VM resources are released from the Host Guardian Service (HGS).
This attestation can happen in one of two ways. The preferred way is by using the TPM 2.0 that is
present in the Hyper-V host. Using the TPM, the boot path of the server is assured, which guarantees
no malware or root kits are on the server that could compromise the security. The TPM secures communication to and from the HGS attestation service. For hosts that do not have a TPM 2.0, an
alternate Active Directory–based attestation is possible; however, this merely checks whether the host is part of a configured Active Directory group. Therefore, it does not provide the same levels of
assurance and protection from binary meddling and thus host administrator privileges for a
sophisticated attacker. However, the same shielded VM features are available.

After a host undergoes the attestation, it receives a health certificate from the attestation service on
the HGS that authorizes the host to get keys released from the key protection service that also runs
on the HGS. The keys are encrypted during transmission and can be decrypted only within a protected enclave that is new to Windows 10 and Windows Server 2016 (more on that later). These keys can then be used to decrypt the vTPM to make it possible for the VM to access its BitLocker-protected storage and start the VM. Therefore, only if a host is authorized and noncompromised will it be able to get the required key and turn on the VM’s access to the encrypted storage (not the administrator, though, as the virtual hard drive (VHD) remains encrypted on the drive).

At this point, it might be self-defeating: If I am an administrator on the Hyper-V and the keys are
released to the host to start the VM, I would be able to gain access to the memory of the host and
get the keys, thus nullifying the very security that should protect VMs from administrative privileges.
Fortunately, another new feature in Windows 10 and Windows Server 2016 prevents this from
happening. This feature is the protected enclave mentioned earlier, which is known as Virtual Secure
Mode (VSM). A number of components use this service, including Credential Guard. VSM is a secure execution environment in which secrets and keys are maintained and critical security processes run as Trustlets (small trusted processes) in a secure virtualized partition.

This is not a Hyper-V VM; rather, think of it like a small virtual safe that is protected by virtualization based on technologies such as Second Level Address Translation (SLAT) to prevent people from trying to directly access memory, I/O Memory Management Unit (IOMMU) to protect against Direct Memory Access (DMA) attacks, and so on. The Windows operating system, even the kernel, has no access to VSM. Only safe processes (Trustlets) that are Microsoft signed are allowed to cross the “bridge” to access VSM. A vTPM Trustlet is used for the vTPM of each VM, separate from the rest of the VM process, which runs in a new type of protected VM worker process. This means that there is no way to access the memory used to store these keys, even with complete kernel access. If I'm running with a debugger attached, for example, that would be flagged as part of the attestation process, the health check would fail, and the keys would not be released to the host. Remember I mentioned the keys from the key protection service are sent encrypted? It's the VSM that decrypts them, always keeping the decrypted key protected from the host OS.

When you put all of this together, you have the ability to create a secure VM environment that is
protected from any level of administrator (when using TPM 2.0 in the host) and will close a security
hole many environments cannot close today.

Source of Information : Microsoft Introduction Windows Server 2016

Windows Server 2016 container What is a container?
A container in its simplest form is exactly that—a container. It is an isolated environment in which you can run an application without fear of changes due to applications or configuration. Containers share key components (kernel, system drivers, and so on) that can reduce startup time and provide greater density than you can achieve with a VM.

The interesting thing about containers is the application itself. The application might have various
dependencies that it requires to run. These dependencies exist only within the container itself. This
means that something bad that happens to Application A and the binaries it depends on has no
impact on Application B and the binaries on which it depends. For example, in most environments, if
you delete the registry from Application A, the consequences are disastrous for both Application A
and Application B. However, with containers, Application A and Application B are each self-contained, and the change to the registry for Application A does not affect Application B.

Because all binaries and dependencies are hosted within the container, the application running in the
container is completely portable. Essentially, this means that you can deploy a container to any host
running the container manager software, and it will start and run without any modification. For
example, a developer can begin developing his application and deploy it into a Hyper-V Container
using Windows 10 Anniversary Edition. When he is ready to roll it out in production, it can be run on
Windows Server 2016, including Nano Server, in a public, private, or hybrid cloud. Containers are built on layers. The first layer is the base layer. This is the OS image on which all other layers will be built. This image is stored in an image repository so that you can reference it when necessary. The next layer (and sometimes the final layer) is the application framework layer that can be shared between all of your applications. For example, if your base layer is Windows Server Core, your
application framework layer could be .NET Framework and Internet Information Services (IIS). The
second layer can also be stored as an image, which, when called, also describes its dependency on the
base layer of Windows Server Core. Finally, the application layer is where the application itself is
stored, with references to the application framework layer and, in turn, to the base layer.

The base layer and the application layer can be referenced at any time by any other application
container you create. Each layer is considered read-only except the top layer of the “image” you are
deploying. For example, if you deploy a container that depends only on the Windows Server Core
image, this Windows Server Core layer is the top layer of the container and a sandbox is put in place
to store all the writes and changes made during runtime. You can then store the changes made as
another image for later reuse. The same applies if you deploy the application framework layer image;
this layer would have its own sandbox, and if you deploy your application to it, you can then save the
sandbox as a reusable image.

Basically, when you deploy a container to a host, the host determines whether it has the base layer. If not, it pulls the base layer from an image repository. Next, it repeats the process for the application framework layer and then creates the application container that you were originally trying to deploy. If
you then want to create another container with the same dependencies, you simply issue a command
to create the new application container, and it is provisioned almost immediately because all of the
dependencies are already in place. If you have an application container that depends on a different
application framework layer as well as on the original Windows Server Core base layer, you can simply pull the different application framework layer from an image store and start the new application container.

Source of Information : Microsoft Introduction Windows Server 2016

Nano Server Nano Server is an exciting new installation option for Windows Server 2016 that has an even smaller
footprint than the Server Core installation option.

Nano Server is a new, small-footprint, headless installation option for Windows Server 2016. It is a
deep refactoring of Windows Server that is optimized for the cloud. As such, Nano Server in Windows Server 2016 is ideal for the following scenarios:

 Compute Host for Hyper-V or part of a Windows Failover Cluster
 Container Host
 Storage Host for a Scale-Out File Server (SOFS)
 DNS server
 Web server running IIS
 Application Platform for apps that are built using cloud development patterns and run in a container and/or VM guest

Nano Server is fully headless; thus, it might require some changes to management and operations
procedures for organizations that aren’t fully managing their current server deployments remotely.

Windows Server customers have provided this feedback:

 Reboots have a negative impact on my business—why do I need to reboot because of a patch to a feature I never use?
 When a reboot is required, my servers need to be back in service as soon as possible.
 Large server images take a long time to deploy and consume a lot of network bandwidth.
 If the operating system consumes fewer resources, I can increase my virtual machine density.
 We can no longer afford the security risks of the "install everything everywhere" approach.

Nano Server addresses these problems by including just the functionality required for its proposed
use cases and nothing more. This minimizes the attack surface area, thus eliminating reboots and minimizing the footprint, which provides faster deployment and reboot time and frees up resources
for other uses.

Source of Information : Microsoft Introduction Windows Server 2016

Microservices When it came to applications built for the web, we generally moved away from traditional n-tier
architectures toward Services-Oriented Architecture (SOA). This was no easy task and put a lot of
customers off rewriting their applications. SOA breaks down an application into components, which
communicate with one another via some communication protocol.

It could be said that SOA is the forefather of microservices, given that microservices breaks down even further to smaller components that each live and run as an individual process and communicate with one another in a language-agnostic fashion.

Microservices foster more rapid development versus SOA. This is because the components that
dictate a microservices model are far smaller than SOA. If you need to make a change to a component in microservices, you can develop, update, and deploy rapidly without affecting the operation of the other components. Each component is technically an independent contractor, so each has its own way of doing things and separate way of communicating. Because all of these components share a single communication model, this makes it simpler to improve parts of an application built on microservices.

Service Fabric is a distributed systems platform that makes building microservices or translating your
application into microservices architecture easy to do, while also giving you the means to manage the
full lifecycle of an application. It is available both on-premises and in Azure as Azure Service Fabric.
You can write an application once and deploy it on-premises or to Azure with no API change using, all while using common development tools like Microsoft Visual Studio.

Service Fabric powers many Microsoft services today, including Azure SQL Database, Azure
DocumentDB, Cortana, Power BI, Intune, Azure Event Hubs, Azure IoT, Skype for Business, and many other core Azure services. All the learnings from running these solutions have been incorporated into the Service Fabric product and will ensure that if your applications need a highly reliable and scalable solution, this is your microservices platform of choice.

Source of Information : Microsoft Introduction Windows Server 2016

Modernizing traditional apps The cloud makes it possible for businesses to innovate quickly and deliver faster time-to-value with cloud-native applications and microservices architecture. But most businesses are grappling with how
to manage and update thousands of existing applications while planning how to move to this new world. What is needed is a solution that helps you invigorate existing applications and create new,
cloud-native applications. Windows Server 2016 can do both.

Windows Server helps you to secure and modernize existing enterprise server apps with little or no
code changes; package existing apps in containers to realize the benefit of a more agile DevOps model; and then deploy either on-premises, to any cloud, or in a hybrid model. Developers can create
cloud-ready, business-changing apps and services, whether on-premises or in any cloud, using technologies such as containers and the lightweight Nano Server installation option.

Windows Server 2016 can help you modernize your apps and innovate faster with a cloud-ready
application platform.

First, you can secure the fabric to protect virtual machines (VMs) and enhance existing apps immediately with Windows Server 2016, by taking advantage of enhanced security and management
features in the fabric. For example, you can use shielded VMs to help secure your critical applications to run only on trusted fabrics. You can limit administrator access to specific tasks by using Just Enough Administration (JEA) and specific time limits with Just-in-Time (JIT) administration.

Second, you can containerize existing apps and move your traditional applications into a modern DevOps environment with little or no code changes. You can gain benefits such as consistency across
development, test, and production by using the same tooling, which facilitates rapid deployments,
continuous integration, and continuous delivery, all with better security. You can use containers to
gain control and consistency by enabling apps that you can deploy on-premises, to any cloud, or in a
hybrid architecture across clouds. For an additional layer of isolation, you can deploy your app in a
Hyper-V Container, which packages the same container image in a Hyper-V Container, which uses the hypervisor to provide an additional level of isolation.

Third, you can build cloud-native and hybrid apps. Windows Server 2016 is suited to Agile methods
for building cloud-native applications with microservices architectures. With Nano Server’s
deployment model, you can build offline customized operating system (OS) images highly optimized
for your application, providing a fast-booting, tiny OS that achieves higher density while exposing a
reduced attack surface.

Microsoft wants you to create your best app, whether it’s written by using the Microsoft .Net Framework or open-source frameworks such as .Net Core and Node.JS. Using proven Microsoft Azure Service Fabric technology along with Windows Server 2016, you can build always-on, scalable, and distributed applications and run them in Azure, on-premises, or in a hybrid environment. You can combine the benefits of containers with Nano Server, Service Fabric, and the proven Windows Server platform to achieve business agility with cloud apps.

Ultimately, the choice will depend on each customer’s needs and the application being developed, but
Windows Server 2016 offers multiple options with which you can move forward into a cloud-ready
infrastructure with minimal investment.

Taking application proxies to the modern IT world A few years ago, our team had a big dilemma. We had two products in the market: Forefront Threat
Management Gateway and Forefront Unified Access Gateway. Both of these products had been around for many years and had been deployed by tens of thousands of customers. Both of them
had evolved since they were first introduced during the 1990s.

However, both products had similar issues: They were very complex products that were difficult to
deploy, troubleshoot, and maintain. This was partly because over the years they accumulated many
capabilities that became irrelevant. At the same time, they lacked or had limited support for modern technologies such as federation and OAuth2. On top of it all, they were expensive products that had their own licenses.

It was a tough decision, but we decided to start from a blank page, to examine all the functionalityof reverse proxy, to pick and choose only the technologies that matter today, and to implement them by using a fresh code base built on the most modern standards. A big part of this decisionwas that we wanted to embed the reverse proxy into Windows Server. We wanted to make it justlike any other role service available to install from Server Manager. For us, this meant adhering tothe strictest standards regarding code and management. Microsoft customers expect that allWindows Server role services are managed the same way, including in Windows PowerShell, the administrator UI, the remote administrator UI, performance counters, the System Center OperationsManager pack, event logs, and so on.

This is how Web Application Proxy was born in Windows Server 2012 R2. We made no compromise
on code security, management, and standardization. And, we were happy that customers got it. Companies were able to deploy and integrate Web Application Proxy into their infrastructure very
easily.

The downside of this approach is that we were not able to include all of the functionality we wanted
to have—functionality that would make it possible for all customers to move from Threat Management Gateway and Unified Access Gateway to the new solution. However, now that we
have built a solid foundation, it is easier to add more functionality to make Web Application Proxy
the obvious choice to publish on-premises resources such as Microsoft SharePoint, Lync, and Exchange to remote users. This version marks an important milestone in the journey we began quite a few years ago.

Now, it is time for us to begin another journey to bring remote access to the cloud era. We have
created Azure Active Directory Application Proxy as another tool for customers to publish applications in cloud-based solutions. Fortunately, Web Application Proxy in Windows Server and
Azure Active Directory Application Proxy share a lot of code. More than that, they share the same
concepts and perception of remote access and how to make it simple to deploy and easy to maintain.

Going forward, we will continue to develop both products. We plan to offer Microsoft customers a
choice with regard to which architecture to use. The cloud offers users a unique and highly efficient
way to implement remote access utilizing the rich functionality and robust security mechanisms of
Azure Active Directory, without the need to change their perimeter network. The same service that
takes care of 18 billion authentication requests per week handles your on-premises applications.

Source of Information : Microsoft Introduction Windows Server 2016

Windows Server 2016 Storage Spaces Direct Storage Spaces Direct enables service providers and enterprises to use industry standard servers with
internal drives to build highly available and scalable software defined storage. Using servers with internal drives decreases complexity, increases scalability, and enables use of storage devices that
were not previously possible, such as SATA solid state disks to lower cost of flash storage, or NVMe
solid state disks for better performance.

Storage Spaces Direct removes the need for a shared SAS fabric, simplifying deployment and configuration. Instead, it uses the network as a storage fabric, using SMB3 and SMB Direct (RDMA) for high-speed, low-latency CPU-efficient storage. To scale out, simply add more servers to increase
storage capacity and I/O performance. Following are some more features and characteristics of Storage Spaces Direct:

 Storage for Hyper-V and Microsoft Azure Stack The primary use cases for Storage Spaces Direct is as storage for Hyper-V VMs or as storage for Azure Stack.

 Hardware Storage Spaces Direct makes it possible to build highly available and scalable storage solutions using modern storage hardware like SATA SSD for lower cost and NVMe SSD for better performance and less CPU overhead. It can also use RDMA-enabled network infrastructure for low-latency storage with less CPU overhead than traditional Ethernet. Less CPU overhead means increased workload density.

 Prescriptive configurations Microsoft is working closely with its hardware partners to define and validate prescriptive server configurations for Storage Spaces Direct. Using these server configurations provides the best possible experience with Storage Spaces Direct with the full feature set and best performance.

 Storage Configurations You can use Storage Spaces Direct with various storage configurations. The most common configurations are:
 SSDs with traditional hard drives, where the SSDs are used as a read/write cache to accelerate I/O performance.
 All-flash configuration with NVMe SSDs and SATA SSDs for extremely high I/O performance.
 Three tiers of physical storage, NVMe SSDs, SATA SSDs, and traditional hard drives.

 Deployment Choice Storage Spaces Direct provides customers with a deployment choice, either as hyper-converged infrastructure or as converged infrastructure. In a hyperconverged infrastructure, compute and storage resources are provided by the same machines, simplifying scale and management. In a converged infrastructure, compute resources are separate from storage resources, allowing for increased scalability and independent scaling of compute and storage.

 Fault Tolerance Storage Spaces Direct is resilient to drive failures. When drives fail, degraded data is automatically reconstructed on the remaining drives. Storage Spaces Direct supports three fault domain types: a) server, b) chassis, and c) rack, and all data placement, data repair, and data rebalancing will adhere to the fault domain configuration.

 Accelerated Erasure Coding Storage Spaces Direct introduces hybrid volumes, which is in addition to the existing mirror and erasure coding volume types. Hybrid volumes mixes the best of mirror (performance) with the best of erasure coding (efficiency) into a single volume with automatic real-time storage tiering.

 Efficient VM check-points Storage Spaces Direct utilizes the new ReFSv2 file system, which when combined with Hyper-V can do very quick and efficient VM checkpoints with little overhead and storage I/O.

 Scalability Storage Spaces Direct can scale from 2 to 16 servers. You can add servers as needed, and data can be rebalanced to best utilize the additional resources. Microsoft and Intel demonstrated a 16 server Storage Spaces Direct deployment using all NVMe SSDs at IDF 2015.

 Health Service Storage Spaces Direct includes an intelligent built-in diagnostic engine that makes it possible for administrators with limited technical expertise to monitor and operate the system day to day.
 The Health Service actively monitors the underlying cluster, storage hardware, and software defined storage stack to detect problems and generate alerts that contain precise instructions for how to react.
 Performance and capacity information is aggregated to present a holistic, high-level view of available resources.
 Frequent tasks such as drive replacement and drive firmware updates are automated to reduce the burden on the administrator.

Source of Information : Microsoft Introduction Windows Server 2016

Storage Replica in Windows Server 2016 The following are some of the key things to know concerning Storage Replica as of the Windows
Server 2016 release:

 Network bandwidth and latency with fastest storage There are physical limitations to synchronous replication. Because Storage Replica implements an I/O filtering mechanism using logs and requiring network roundtrips, synchronous replication is likely to make application writes slower. By using low-latency, high-bandwidth networks as well as high-throughput drive subsystems for the logs, you can minimize performance overhead.

 The destination volume is not accessible while replicating When you configure replication, the destination volume will dismount and no longer be visible in any normal GUI tools or accessible to any writes by users until you remove replication, or the volume becomes the source due to failover. Block-level replication technologies are incompatible with allowing access to the destination’s mounted file system in a volume; NTFS and ReFS do not support users writing data to the volume
while blocks change underneath them.

 Different implementation of asynchronous replication The Microsoft implementation of asynchronous replication is different than most industry implementations of asynchronous replication that rely on snapshot-based replication, whereby periodic differential transfers move to the other node and merge. In contrast, Storage Replica asynchronous replication operates just like synchronous replication, except that it removes the requirement for a serialized synchronous acknowledgment from the destination. This means that Storage Replica theoretically has a lower RPO as it continuously replicates. However, this also means it relies on internal application consistency guarantees rather than using snapshots to force consistency in application files. Storage Replica guarantees crash consistency in all replication modes.

 Storage Replica is not Distributed File System Replication Volume-level block storage replication is not a good candidate for use in branch-office scenarios. Branch-office networks tend to be highly latent, highly utilized, and lower bandwidth, which makes synchronous replication impractical. A branch office often replicates data in a one-to-many with read-only destinations, such as for software distribution, and Storage Replica is not capable of this in the first release. When replicating data from a branch office to a main office, Storage Replica dismounts the destination volume to prevent direct access. It is important to note, nevertheless, that many customers use Distributed File System Replication (DFSR) as a DR solution even though it is often impractical for that scenario—DFSR cannot replicate open files and is designed to minimize bandwidth usage at the expense of performance, leading to large recovery-point deltas. Storage Replica might make it possible for you to retire DFSR from some of these types of DR duties.

 Storage Replica is not backup Some IT environments deploy replication systems as backup solutions due to their zero-data-loss options when compared to daily backups. Storage Replica replicates all changes to all blocks of data on the volume, regardless of the change type. If a user deletes all data from a volume, Storage Replica replicates the deletion instantly to the other volume, irrevocably removing the data from both servers.

 Storage Replica is not Hyper-V Replica or SQL AlwaysOn Storage Replica is a general purpose, storage-agnostic engine. By definition, it cannot tailor its behavior as ideally as application-level replication. This might lead to specific feature gaps that encourage you to deploy or remain on specific application replication technologies.

Source of Information : Microsoft Introduction Windows Server 2016

Code Library

Categories