Windows 10 Operating System Build Versions

[Giraldo Allain]

MicrosoftWindows is a computer operating system developed by Microsoft. It was first launched in 1985 as a graphical operating system built on MS-DOS. The initial version was followed by several subsequent releases, and by the early 1990s, the Windows line had split into two separate lines of releases: Windows 9x for consumers and Windows NT for businesses and enterprises. In the following years, several further variants of Windows would be released: Windows CE in 1996 for embedded systems; Pocket PC in 2000 (renamed to Windows Mobile in 2003 and Windows Phone in 2010) for personal digital assistants and, later, smartphones; Windows Holographic in 2016 for AR/VR headsets; and several other editions.

Windows MultiPoint Server was an operating system based on Windows Server. It was succeeded by the MultiPoint Services role in Windows Server 2016 and Windows Server version 1709. It was no longer being developed in Windows Server version 1803 and later versions.

In 2012 and 2013, Microsoft released versions of Windows specially designed to run on ARM-based tablets; these versions of Windows, named "Windows RT" and "Windows RT 8.1," were based on Windows 8 and Windows 8.1, respectively. Upon the release of Windows 10 in 2015, the ARM-specific version for large tablets was discontinued; large tablets (such as the Surface Pro 4) were only released with x86 processors and could run the full version of Windows 10. Windows 10 Mobile had the ability to be installed on smaller tablets (up to nine inches);[26] however, very few such tablets were released, and Windows 10 Mobile primarily ended up only running on smartphones until its discontinuation. In 2017, the full version of Windows 10 gained the ability to run on ARM, thus rendering a specific version of Windows for ARM-based tablets unnecessary.

* For applications that have been manifested for Windows 8.1 or Windows 10. Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). To manifest your applications for Windows 8.1 or Windows 10, refer to Targeting your application for Windows.

Identifying the current operating system is usually not the best way to determine whether a particular operating system feature is present. This is because the operating system may have had new features added in a redistributable DLL. Rather than using the Version API Helper functions to determine the operating system platform or version number, test for the presence of the feature itself.

If you must require a particular operating system, be sure to use it as a minimum supported version, rather than design the test for the one operating system. This way, your detection code will continue to work on future versions of Windows.

Note that a 32-bit application can detect whether it is running under WOW64 by calling the IsWow64Process function. It can obtain additional processor information by calling the GetNativeSystemInfo function.

There may be a number of additional considerations to take into account when determining if your source operating system will be supported by AWS Elastic Disaster Recovery. Ensure that you check the Additional Considerations section in conjunction with the below lists of supported operating systems.

There may be a number of additional considerations to take into account when determining if your source operating system will be supported by AWS Elastic Disaster Recovery. Ensure that you check the below considerations in conjunction with the above lists of supported operating systems.

A shutdown (from the OS menu or Windows CLI) of a Windows source server no longer triggers a rescan in AWS DRS once the source server is restarted. Hard reboots, disk changes, and crashes will still trigger a rescan.

Windows 2003 does not support TLS 1.2, as such, you cannot download the AWS Replication Agent installer directly by using the default browser. The file needs to be copied to the server using another transfer method.

The AWS Replication Agent and agent installer uses a separate installer file (AwsReplicationWindowsLegacyInstaller.exe) for Microsoft Windows 7, Microsoft Windows Server versions 2003, Microsoft Windows Server 2008, and Microsoft Windows Server 2008 R2 because these OSs are using older versions of software components that cannot be upgraded due to their end-of-life status.

Kernel versions earlier than 2.6.18-164 are not supported by AWS and AWS Elastic Disaster Recovery. Therefore, servers that run these kernel versions cannot be replicated by AWS Elastic Disaster Recovery.

A reboot of supported Linux servers no longer triggers a rescan in AWS DRS once the source server is restarted. Hard reboots, disk changes, and crashes will still trigger a rescan. Supported OSs include:

AWS requires that servers running Red Hat Enterprise Linux (RHEL) must have Cloud Access (BYOL) licenses in order to be recovered to AWS. Note that servers running RHEL Cloud Access Gold Images allow you to access AWS Red Hat Update Infrastructure (RHUI), Red Hat Satellite, or Red Hat Subscription Manager (RHSM). If you are using RHEL Cloud Access Gold Images, you will not be able to access RHUI upon failover to AWS unless you link your AWS account to your Red Hat account via the Red Hat portal, and select the Gold image AMI in the launch template.

You must select an AWS provided RHEL AMI in the Launch Template for servers running Red Hat Enterprise Linux (RHEL) Pay as You Go (PAYG) images. This will allow access to RHUI after failover. Note that usage of these images will incur EC2 charges for software and infrastructure per AWS Marketplace rates.

For SUSE Linux (SLES) 11 to work, you must install the xen drivers before installing the AWS Replication Agent. You must reboot the server after installing the xen drivers (before installing the AWS Replication Agent). Use the following command to install the drivers:

I have a customer with multiple sites, and 3 domain controllers. They also have a Microsoft volume license account so licensing is not an issue here. (they are a medical facility and thus under charity pricing and if any of you have not had experience with that let's just say pricing is disgustingly cheap next to free basically. I'm only saying this to eliminate a bunch of chaff responses of variations of make sure you got licensing)

The primary DC was also used as a fileserver and is running out of space. So my thought was to setup a new DC on Server 2019, (bare metal) migrate FSMO roles to it from the old primary, demote the old primary and then setup another new fileserver (hyperv) and move all the files and shares off the old DC then shut it down.

A question was brought up, wouldn't it be better to setup the new DC with Server 2016 that way all of the DC's are the same OS version? The target server I'm going to use is a Proliant DL380 Gen6 which I already installed 2019 on (HP only "supports" up to server 2008R2 on these but we have Server 2019 running perfectly on several others)

My feeling is if I'm going to put time into building a server to use 2019 that way we can get the longest amount of life out of the installation. Basically what it boils down to is Server 2022 is unable to run on any of the older CPUs so Proliants older than Gen10 are SOL - which is literally all of this customers servers - they range from Gen 6 to Gen 9)

I know Exchange 2016 can't run cannot run with anything newer than an AD Domain Functional level of 2016 so I was planning on installing the Server 2019 DC at Functional Level 2008R2 and then raising it later to 2016 level but not to 2019 domain/functional level.

Hello,

It is best to avoid mixing operating systems for DC - promoting even one triggers an Active Directory migration, and having older OSes put you at risk - expect security and compatibility issues. You also need to take admin tools into account (newer OS = newer admin tools).

Also, Active Directory migration isn't always straightforward - having on-premises Exchange will add prerequisites by example (and don't try to bypass - your Exchange infrastructure may explode).

My advice : do not try to go faster than you should.

Complete your file server migration first.

Make sure your DC own only AD and DNS roles and nothing else, and there is no other server with DNS role. Make sure you build them with Server Core.

Prepare a future Active Directory migration - check prerequisites (like DFSR), AD/DNS health and backup, enable optional features already available (like AD Recycle Bin), check new features available with newer OS and domain/forest levels.

Then, migrate your 2008 R2 to 2016. Enable new features and increase domain/forest levels (you won't need to do this on you reach 2016).

Then, trigger a global AD migration to 2022 using virtual machines if possible, or 2019 if you cant do better (end of support date for 2019 is slowly closing).

Just to be clear here, there is categorically no issue with running domain controllers built on differing operating systems beyond the single requirement around migrating from FRS to DFS-R, as @Harm_Veenstra already noted.

The functional level supportability matrices can be found in the following article (though I suspect you've already seen this.) Once you migrate from FRS to DFS-R, which you can (and should) do using your existing infrastructure, you can jump directly to Windows Server 2022.

Nothing is automatically triggered with respect to new functionality simply by using a newer operating system. The most you'll find (beyond your DFS-R task) are some cryptographic suite changes - which have taken place across all platforms purely as a generational exercise and have nothing specifically to do with domain controllers or the functional levels. And 2008 R2 isn't so old that it doesn't share a good portion of these suites meaning you will not run into issues on this front (unless someone's badly customised the existing suites via GPO - which is a very, very long shot.)

3a8082e126