Windows Server release information

Microsoft has updated its servicing model. The Semi-Annual Channel is a twice-per-year feature update release with 18-month servicing timelines for each release. This page is designed to help you determine the end of support date for the Semi-Annual Channel releases.

The Semi-Annual Channel provides opportunity for customers who are innovating quickly to take advantage of new operating system capabilities at a faster pace, both in applications — particularly those built on containers and microservices. For more information see the Comparison of servicing channels. Customers also have the option to continue using the Long-Term Servicing Channel releases, which continue to be released every 2-3 years. Each Long-Term Servicing Channel release is supported for 5 years of mainstream support and 5 years of extended support.

Windows Server current versions by servicing option

Windows Server release	Version	OS Build	Availability	Mainstream support end date	Extended support end date
Windows Server, version 20H2 (Semi-Annual Channel) (Datacenter Core, Standard Core)	20H2	19042.508.200927-1902	10/20/2020	05/10/2022	Review note
Windows Server, version 2004 (Semi-Annual Channel) (Datacenter Core, Standard Core)	2004	19041.264.200508-2205	05/27/2020	12/14/2021	Review note
Windows Server, version 1909 (Semi-Annual Channel) (Datacenter Core, Standard Core)	1909	18363.418.191007-0143	11/12/2019	05/11/2021	Review note
Windows Server, version 1903 (Semi-Annual Channel) (Datacenter Core, Standard Core)	1903	18362.30.190401-1528	5/21/2019	12/08/2020	Review note
Windows Server 2019 (Long-Term Servicing Channel) (Datacenter, Essentials, Standard)	1809	17763.107.1010129-1455	11/13/2018	01/09/2024	01/09/2029
Windows Server, version 1809 (Semi-Annual Channel) (Datacenter Core, Standard Core)	1809	17763.107.1010129-1455	11/13/2018	11/10/2020	Review note
Windows Server 2016 (Long-Term Servicing Channel)	1607	14393.0	10/15/2016	01/11/2022	01/11/2027

End of service for Windows Server, version 1809 has been delayed due to the ongoing public health crisis. For more information, see our Support article.

Windows Server, version 1803 and later are governed by the Modern Lifecycle Policy. See the Windows Lifecycle FAQ and Comparison of servicing channels for details regarding servicing requirements and other important information.

Конвертирование ознакомительной (Evaluation) версии Windows Server 2016/2019 в полную

Если для знакомства с возможностями серверной платформы Microsoft вы установили ознакомительную Windows Server 2019 или Windows Server 2016 StandardEvaluation или DatacenterEvaluation (после регистрации вы можете бесплатно скачать Windows Server 2019 on-premises Free Trial или Windows Server 2016 Evaluation здесь ), у вас есть 180 дней на тестирование ее возможностей. В течении этого времени вам доступен полный функционал Windows Server 2016/2019.

В любой момент вы можете вывести срок окончания льготного периода вашего Windows Server:

Slmgr /dli

Такое продление ознакомительного периода можно делать 5 раз. Таким образом максимальный срок использования Windows Server Free Trial можно продлить до 3 лет = 180 * 6 (однако по условиям использование Evaluation версий Microsoft вы не должны использовать ознакомительную версию в коммерческих целях – только тесты и ознакомление с функционалом).

По истечении срока пробного периода система начинает требовать активацию и выключаться через каждый час работы со следующим текстом в журнале событий системы:

На рабочем столе при этом отображается уведомление Windows Licenses is expired. Если вы умудрились запустить продуктивные задачи на ознакомительной версии Windows Server Evaluation, и хотите сконвертировать ее в полноценную редакцию Windows Server с сохранением данных без полной переустановки операционной системы, эта статья должна вам помочь.

До каких редакции можно обновить ознакомительную Windows Server?

Если открыть окно с вводом ключа продукта в Evaluation редакции Windows Server и попытаться указать KMS ключ или Retail/MAK ключ, появится предупреждение “ This edition cannot be upgraded ”, т.е. апгрейд данной редакции не возможен.

При попытке установить retail ключ с помощью утилиты slmgr (s lmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx ) появится ошибка:

Error: 0xC004F069. On a computer running Microsoft Windows non-core edition.

Но не все так печально :).

С помощью DISM нужно убедиться, что у вас используется именно ознакомительная версия Windows Server. Запустите команду строку с правами администратора и выполните:

DISM /online /Get-CurrentEdition

Как вы видите, в строке Current Edition указано, что текущая редакция — ServerStandartEval.

Теперь с помощью DISM выведем список редакций Windows Server, до которых можно обновить текущую Eval версию:

DISM /online /Get-TargetEditions

Т.е. текущая редакция ServerStandardEval может быть обновлена до следующих редакций Windows Server 2016 / Windows Server 2019: ServerDatacenter или ServerStandard.

Ограничения при апгрейде ознакомительной версии WindowsServer

Несколько ограничений метода конвертации ознакомительной редакции Windows Server, рассмотренного ниже:

• Можно выполнить конвертацию только полной GUI версии Windows Server. Методика не работает с версиями Server Core or Nano Server;
• Нельзя выполнить апгрейд редакции сервера с ролью контроллера домена Active Directory Domain Services. Его придется сначала понизить до рядового сервера;
• Нельзя перейти со старшей редакции на младшую. Т.е. апгрейд Windows Server Eval Datacenter до Windows Server Standard Full невозможен.

Windows Server 2016: преобразование Evaluation версии в полную

Для апгрейда ознакомительной версии Windows Server в полноценную нужно использовать общедоступный KMS (GVLK) ключ для Windows Server 2016. Преобразование выполняется через командную строку с помощью утилиты DISM. Например, чтобы выполнить апгрейд Eval редакции до Retail версии Windows Server 2016 Standard, используйте команду:

dism /online /set-edition:ServerStandard /productkey:WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY /accepteula

Если вместо публичного GVLK вы ключа в команде DISM вы укажите ваш собственный MAK/KMS ключ, появится ошибка:

Error 1168
The specified product key could not be validated.
Check that the specified product key is valid and that it matches the target edition.

DISM /online /Set-Edition:ServerDatacenter /ProductKey:CB7KF-BWN84-R7R2Y-793K2-8XDDG /AcceptEula

После применения команды (появится сообщение Command completed successfully) нужно перезагрузить сервер и убедится, что установлена полноценная версия Standard.

Если в вашей сети развернут KMS сервер, то для активация операционной системы на нем нужно выполнить команду:
slmgr /ipk WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY (это ключ для Windows Server Standart, для Datacenter используется другой ключ, он указн выше).
slmgr /ato

Если KMS сервера нет, вы можете указать ваш MAK или Retail ключ Windows Server и активировать ОС как обычно: через Интернет или по телефону.

Windows Server 2019: конвертирование ознакомительной версии в полноценную

Для преобразования Windows Server 2019 EVAL в полноценную версию нужно использовать GVLK (KMS) ключи для Windows Server 2019. В остальном процедура аналогичная.

Ковертировать Windows Server 2019 Evaluation в Windows Server 2019 Standard:

dism /online /set-edition:ServerStandard /productkey:N69G4-B89J2-4G8F4-WWYCC-J464C /accepteula

Ковертировать Windows Server 2019 Evaluation в Windows Server 2019 Datacenter:

dism /online /set-edition:ServerDatacenter /productkey:WMDGN-G9PQG-XVVXX-R3X43-63DFG /accepteula

Operating System Version

The Version API Helper functions are used to determine the version of the operating system that is currently running. For more information, see Getting the System Version.

The following table summarizes the most recent operating system version numbers.

Operating system	Version number
Windows 10	10.0*
Windows Server 2019	10.0*
Windows Server 2016	10.0*
Windows 8.1	6.3*
Windows Server 2012 R2	6.3*
Windows 8	6.2
Windows Server 2012	6.2
Windows 7	6.1
Windows Server 2008 R2	6.1
Windows Server 2008	6.0
Windows Vista	6.0
Windows Server 2003 R2	5.2
Windows Server 2003	5.2
Windows XP 64-Bit Edition	5.2
Windows XP	5.1
Windows 2000	5.0

* 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.

To determine the best way to test for a feature, refer to the documentation for the feature of interest. The following list discusses some common techniques for feature detection:

• You can test for the presence of the functions associated with a feature. To test for the presence of a function in a system DLL, call the LoadLibrary function to load the DLL. Then call the GetProcAddress function to determine whether the function of interest is present in the DLL. Use the pointer returned by GetProcAddress to call the function. Note that even if the function is present, it may be a stub that just returns an error code such as ERROR_CALL_NOT_IMPLEMENTED.
• You can determine the presence of some features by using the GetSystemMetrics function. For example, you can detect multiple display monitors by calling GetSystemMetrics(SM_CMONITORS).
• There are several versions of the redistributable DLLs that implement shell and common control features. For information about determining which versions are present on the system your application is running on, see the topic Shell and Common Controls Versions.

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.

How to: Determine which .NET Framework versions are installed

Users can install and run multiple versions of .NET Framework on their computers. When you develop or deploy your app, you might need to know which .NET Framework versions are installed on the user’s computer. The registry contains a list of the versions of .NET Framework installed on the computer.

This article is specific to .NET Framework. To determine which .NET Core and .NET 5+ SDKs and runtimes are installed, see How to check that .NET is already installed.

.NET Framework consists of two main components, which are versioned separately:

A set of assemblies, which are collections of types and resources that provide the functionality for your apps. .NET Framework and the assemblies share the same version number. For example, .NET Framework versions include 4.5, 4.6.1, and 4.7.2.

The common language runtime (CLR), which manages and executes your app’s code. A single CLR version typically supports multiple .NET Framework versions. For example, CLR version 4.0.30319.xxxxx where xxxxx is less than 42000, supports .NET Framework versions 4 through 4.5.2. CLR version greater than or equal to 4.0.30319.42000 supports .NET Framework versions starting with .NET Framework 4.6.

Community-maintained tools are available to help detect which .NET Framework versions are installed:

A .NET Framework 2.0 command-line tool.

A PowerShell 2.0 module.

For information about detecting the installed updates for each version of .NET Framework, see How to: Determine which .NET Framework updates are installed.

Determine which .NET implementation and version an app is running on

You can use the RuntimeInformation.FrameworkDescription property to query for which .NET implementation and version your app is running on. If the app is running on .NET Framework, the output will be similar to:

By comparison, if the app is running on .NET Core or .NET 5+, the output will be similar to:

Detect .NET Framework 4.5 and later versions

The version of .NET Framework (4.5 and later) installed on a machine is listed in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. If the Full subkey is missing, then .NET Framework 4.5 or above isn’t installed.

The NET Framework Setup subkey in the registry path does not begin with a period.

The Release REG_DWORD value in the registry represents the version of .NET Framework installed.

.NET Framework version	Value of Release
.NET Framework 4.5	All Windows operating systems: 378389
.NET Framework 4.5.1	On Windows 8.1 and Windows Server 2012 R2: 378675 On all other Windows operating systems: 378758
.NET Framework 4.5.2	All Windows operating systems: 379893
.NET Framework 4.6	On Windows 10: 393295 On all other Windows operating systems: 393297
.NET Framework 4.6.1	On Windows 10 November Update systems: 394254 On all other Windows operating systems (including Windows 10): 394271
.NET Framework 4.6.2	On Windows 10 Anniversary Update and Windows Server 2016: 394802 On all other Windows operating systems (including other Windows 10 operating systems): 394806
.NET Framework 4.7	On Windows 10 Creators Update: 460798 On all other Windows operating systems (including other Windows 10 operating systems): 460805
.NET Framework 4.7.1	On Windows 10 Fall Creators Update and Windows Server, version 1709: 461308 On all other Windows operating systems (including other Windows 10 operating systems): 461310
.NET Framework 4.7.2	On Windows 10 April 2018 Update and Windows Server, version 1803: 461808 On all Windows operating systems other than Windows 10 April 2018 Update and Windows Server, version 1803: 461814
.NET Framework 4.8	On Windows 10 May 2019 Update and Windows 10 November 2019 Update: 528040 On Windows 10 May 2020 Update and Windows 10 October 2020 Update: 528372 On all other Windows operating systems (including other Windows 10 operating systems): 528049

Minimum version

To determine whether a minimum version of .NET Framework is present, check for a Release REG_DWORD value that’s greater than or equal to the corresponding value listed in the following table. For example, if your application runs under .NET Framework 4.8 or a later version, test for a Release REG_DWORD value that’s greater than or equal to 528040.

.NET Framework version	Minimum value
.NET Framework 4.5	378389
.NET Framework 4.5.1	378675
.NET Framework 4.5.2	379893
.NET Framework 4.6	393295
.NET Framework 4.6.1	394254
.NET Framework 4.6.2	394802
.NET Framework 4.7	460798
.NET Framework 4.7.1	461308
.NET Framework 4.7.2	461808
.NET Framework 4.8	528040

Use Registry Editor

From the Start menu, choose Run, enter regedit, and then select OK.

(You must have administrative credentials to run regedit.)

In the Registry Editor, open the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. If the Full subkey isn’t present, then you don’t have .NET Framework 4.5 or later installed.

Check for a REG_DWORD entry named Release. If it exists, then you have .NET Framework 4.5 or later installed. Its value corresponds to a particular version of .NET Framework. In the following figure, for example, the value of the Release entry is 528040, which is the release key for .NET Framework 4.8.

Use PowerShell to check for a minimum version

Use PowerShell commands to check the value of the Release entry of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full subkey.

The following examples check the value of the Release entry to determine whether .NET Framework 4.6.2 or later is installed. This code returns True if it’s installed and False otherwise.

Query the registry using code

Use the RegistryKey.OpenBaseKey and RegistryKey.OpenSubKey methods to access the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full subkey in the Windows registry.

If the app you’re running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 64-bit registry is available in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ subkey. For example, the registry subkey for .NET Framework 4.5 is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full.

Check the Release REG_DWORD value to determine the installed version. To be forward-compatible, check for a value greater than or equal to the value listed in the .NET Framework version table.

The following example checks the value of the Release entry in the registry to find the versions of .NET Framework 4.5-4.8 that are installed:

The example displays output like the following:

This example follows the recommended practice for version checking:

• It checks whether the value of the Release entry is greater than or equal to the value of the known release keys.
• It checks in order from most recent version to earliest version.

Detect .NET Framework 1.0 through 4.0

Each version of .NET Framework from 1.1 to 4.0 is listed as a subkey at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP. The following table lists the path to each .NET Framework version. For most versions, there’s an Install REG_DWORD value of 1 to indicate this version is installed. In these subkeys, there’s also a Version REG_SZ value that contains a version string.

The NET Framework Setup subkey in the registry path does not begin with a period.

Framework Version	Registry Subkey	Value
1.0	HKLM\Software\Microsoft\.NETFramework\Policy\v1.0\3705	Install REG_SZ equals 1
1.1	HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322	Install REG_DWORD equals 1
2.0	HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727	Install REG_DWORD equals 1
3.0	HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup	InstallSuccess REG_DWORD equals 1
3.5	HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5	Install REG_DWORD equals 1
4.0 Client Profile	HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client	Install REG_DWORD equals 1
4.0 Full Profile	HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full	Install REG_DWORD equals 1

If the app you’re running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 64-bit registry is available in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ subkey. For example, the registry subkey for .NET Framework 3.5 is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.5.

Notice that the registry path to the .NET Framework 1.0 subkey is different from the others.

Use Registry Editor (older framework versions)

From the Start menu, choose Run, enter regedit, and then select OK.

You must have administrative credentials to run regedit.

Open the subkey that matches the version you want to check. Use the table in the Detect .NET Framework 1.0 through 4.0 section.

The following figure shows the subkey and its Version value for .NET Framework 3.5.

Query the registry using code (older framework versions)

Use the Microsoft.Win32.RegistryKey class to access the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP subkey in the Windows registry.

If the app you’re running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 64-bit registry is available in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ subkey. For example, the registry subkey for .NET Framework 3.5 is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.5.

The following example finds the versions of .NET Framework 1-4 that are installed:

The example displays output similar to the following:

Find CLR versions

The .NET Framework CLR installed with .NET Framework is versioned separately. There are two ways to detect the version of the .NET Framework CLR:

The Clrver.exe tool

Use the CLR Version tool (Clrver.exe) to determine which versions of the CLR are installed on a computer. Open Visual Studio Developer Command Prompt or Visual Studio Developer PowerShell and enter clrver .

The Environment class

For .NET Framework 4.5 and later versions, don’t use the Environment.Version property to detect the version of the CLR. Instead, query the registry as described in Detect .NET Framework 4.5 and later versions.

Query the Environment.Version property to retrieve a Version object.

The returned System.Version object identifies the version of the runtime that’s currently executing the code. It doesn’t return assembly versions or other versions of the runtime that may have been installed on the computer.

For .NET Framework versions 4, 4.5, 4.5.1, and 4.5.2, the string representation of the returned Version object has the form 4.0.30319.xxxxx, where xxxxx is less than 42000. For .NET Framework 4.6 and later versions, it has the form 4.0.30319.42000.

After you have the Version object, query it as follows:

For the major release identifier (for example, 4 for version 4.0), use the Version.Major property.

For the minor release identifier (for example, 0 for version 4.0), use the Version.Minor property.

For the entire version string (for example, 4.0.30319.18010), use the Version.ToString method. This method returns a single value that reflects the version of the runtime that’s executing the code. It doesn’t return assembly versions or other runtime versions that may be installed on the computer.

The following example uses the Environment.Version property to retrieve CLR version information:

The example displays output similar to the following: