COM Clients and Servers

A critical aspect of COM is how clients and servers interact. A COM client is whatever code or object gets a pointer to a COM server and uses its services by calling the methods of its interfaces. A COM server is any object that provides services to clients; these services are in the form of COM interface implementations that can be called by any client that is able to get a pointer to one of the interfaces on the server object.

There are two main types of servers, in-process and out-of-process. In-process servers are implemented in a dynamic linked library (DLL), and out-of-process servers are implemented in an executable file (EXE). Out-of-process servers can reside either on the local computer or on a remote computer. In addition, COM provides a mechanism that allows an in-process server (a DLL) to run in a surrogate EXE process to gain the advantage of being able to run the process on a remote computer. For more information, see DLL Surrogates.

The COM programming model and constructs have now been extended so that COM clients and servers can work together across the network, not just within a given computer. This enables existing applications to interact with new applications and with each other across networks with proper administration, and new applications can be written to take advantage of networking features.

COM client applications do not need to be aware of how server objects are packaged, whether they are packaged as in-process objects (in DLLs) or as local or remote objects (in EXEs). Distributed COM further allows objects to be packaged as service applications, synchronizing COM with the rich administrative and system-integration capabilities of Windows.

Throughout this documentation the acronym COM is used in preference to DCOM. This is because DCOM is not separate;it is just COM with a longer wire. In cases where what is being described is specifically a remote operation, the term distributed COM is used.

COM is designed to make it possible to add the support for location transparency that extends across a network. It allows applications written for single computers to run across a network and provides features that extend these capabilities and add to the security necessary in a network. (For more information, see Security in COM.)

COM specifies a mechanism by which the class code can be used by many different applications.

For more information, see the following topics:

Службы Windows Server Update Services (WSUS) Windows Server Update Services (WSUS)

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Службы Windows Server Update Services (WSUS) позволяют ИТ-администраторам развертывать новейшие обновления продуктов Майкрософт. Windows Server Update Services (WSUS) enables information technology administrators to deploy the latest Microsoft product updates. Службы WSUS позволяют в полной мере управлять процессом распределения обновлений, выпущенных через Центр обновления Майкрософт, среди компьютеров в сети. You can use WSUS to fully manage the distribution of updates that are released through Microsoft Update to computers on your network. В данном разделе представлен обзор этой роли сервера и дополнительные сведения о том, как развертывать и обслуживать WSUS. This topic provides an overview of this server role and more information about how to deploy and maintain WSUS.

Описание роли сервера WSUS WSUS Server role description

Сервер WSUS предоставляет возможности для управления обновлениями и их распространения через консоль управления. A WSUS server provides features that you can use to manage and distribute updates through a management console. Сервер служб WSUS может также быть источником обновлений для других серверов WSUS в организации. A WSUS server can also be the update source for other WSUS servers within the organization. Сервер WSUS, действующий как источник обновлений, называется вышестоящим сервером. The WSUS server that acts as an update source is called an upstream server. В реализации служб WSUS хотя бы один сервер WSUS в сети должен иметь возможность подключаться к Центру обновления Майкрософт для получения информации о доступных обновлениях. In a WSUS implementation, at least one WSUS server on your network must be able to connect to Microsoft Update to get available update information. Учитывая вопросы безопасности и конфигурации сети, администратор может самостоятельно определить количество дополнительных серверов, напрямую подключенных к Центру обновления Майкрософт. As an administrator, you can determine — based on network security and configuration — how many other WSUS servers connect directly to Microsoft Update.

Практическое применение Practical applications

Управление обновлениями — это процесс управления развертыванием и обслуживанием промежуточных выпусков программного обеспечения в рабочей среде. Update management is the process of controlling the deployment and maintenance of interim software releases into production environments. Это помогает поддерживать производительность, преодолевать уязвимости и обеспечивать стабильность рабочей среды. It helps you maintain operational efficiency, overcome security vulnerabilities, and maintain the stability of your production environment. Если организация не может устанавливать и поддерживать известный уровень доверия в своих операционных системах и прикладном программном обеспечении, то у нее может появиться ряд уязвимостей, что в случае взлома способно привести к потере дохода и интеллектуальной собственности. If your organization cannot determine and maintain a known level of trust within its operating systems and application software, it might have a number of security vulnerabilities that, if exploited, could lead to a loss of revenue and intellectual property. Чтобы минимизировать данную угрозу, необходимо правильно настроить системы, использовать последние версии программного обеспечения и установить рекомендуемые обновления ПО. Minimizing this threat requires you to have properly configured systems, use the latest software, and install the recommended software updates.

Основными сценариями, в которых WSUS повышает эффективность вашего бизнеса, являются: The core scenarios where WSUS adds value to your business are:

Централизованное управление обновлениями Centralized update management

Автоматизация управления обновлениями Update management automation

Новые и измененные функции New and changed functionality

Обновление с любой версии Windows Server, поддерживающей WSUS 3.2, до Windows Server 2012 R2 требует предварительного удаления WSUS 3.2. Upgrade from any version of Windows Server that supports WSUS 3.2 to Windows Server 2012 R2 requires that you first uninstall WSUS 3.2.

В Windows Server 2012 обновление с любой версии Windows Server с установленными службами WSUS 3.2 блокируется в процессе установки, если будет обнаружена служба WSUS 3.2. In Windows Server 2012, upgrading from any version of Windows Server with WSUS 3.2 installed is blocked during the installation process if WSUS 3.2 is detected. В этом случае вам будет предложено сначала удалить службы обновления Windows Server, а затем повторно обновить сервер. In that case, you will be prompted to first uninstall Windows Server Update Services prior to upgrading your server.

Но после изменений, внесенных в текущем выпуске Windows Server и Windows Server 2012 R2, установка не блокируется при обновлении с любой версии Windows Server и WSUS 3.2. However, because of changes in this release of Windows Server and Windows Server 2012 R2, when upgrading from any version of Windows Server and WSUS 3.2, the installation is not blocked. Если перед выполнением обновления Windows Server или Windows Server 2012 R2 не будут удалены службы WSUS 3.2, то задачи WSUS после установки будут завершаться ошибкой. Failure to uninstall WSUS 3.2 prior to performing a Windows Server 2012 R2 upgrade will cause the post installation tasks for WSUS in Windows Server 2012 R2 to fail. Известен только один метод решения такой проблемы — отформатировать жесткий диск и повторно установить Windows Server. In this case, the only known corrective measure is to format the hard drive and reinstall Windows Server.

Службы Windows Server Update Services представляют собой встроенную роль сервера со следующими дополнительными возможностями. Windows Server Update Services is a built-in server role that includes the following enhancements:

Может быть добавлена и удалена с помощью диспетчера серверов Can be added and removed by using the Server Manager

Включает командлеты Windows PowerShell для управления наиболее важными задачами администрирования в службах WSUS Includes Windows PowerShell cmdlets to manage the most important administrative tasks in WSUS

Добавляет возможность использования хэширования SHA256 для дополнительной безопасности Adds SHA256 hash capability for additional security

Обеспечивает разделение клиента и сервера, благодаря чему версии агента Центра обновления Windows (WUA) могут поставляться независимо от WSUS Provides client and server separation: versions of the Windows Update Agent (WUA) can ship independently of WSUS

Использование Windows PowerShell для управления WSUS Using Windows PowerShell to manage WSUS

Системным администраторам для автоматизации работы необходим охват с помощью автоматизации командной строки. For system administrators to automate their operations, they need coverage through command-line automation. Основной целью является облегчение администрирования WSUS, позволяя системным администраторам автоматизировать их ежедневный труд. The main goal is to facilitate WSUS administration by allowing system administrators to automate their day-to-day operations.

Какой эффект дает это изменение? What value does this change add?

Пропуская основные операции WSUS через Windows PowerShell, системные администраторы могут увеличить продуктивность, уменьшить время на изучение новых инструментов, а также снизить количество ошибок из-за неоправданных ожиданий, ставших результатом отсутствия согласованности простых операций. By exposing core WSUS operations through Windows PowerShell, system administrators can increase productivity, reduce the learning curve for new tools, and reduce errors due to failed expectations resulting from a lack of consistency across similar operations.

Что работает иначе? What works differently?

В более ранних версиях операционной системы Windows Server отсутствовали командлеты Windows PowerShell, а автоматизация управления обновлениями была затруднительным делом. In earlier versions of the Windows Server operating system, there were no Windows PowerShell cmdlets, and update management automation was challenging. Командлеты Windows PowerShell для операций WSUS дают дополнительную гибкость и быстроту системному администратору. The Windows PowerShell cmdlets for WSUS operations add flexibility and agility for the system administrator.

Содержание коллекции In this collection

В эту коллекцию включены следующие руководства по планированию, развертыванию и администрированию служб WSUS. The following guides for planning, deploying, and managing WSUS are in this collection:

Introduction to Windows Service Applications

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Windows SDK documentation.

You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.

You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.

After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service’s executable file. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.

Service Applications vs. Other Visual Studio Applications

Service applications function differently from many other project types in several ways:

The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service’s process. For more information, see How to: Debug Windows Service Applications.

Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.

The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See «Service Lifetime» below for more information.

Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.

The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.

The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.

Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.

Service Lifetime

A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.

After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application’s OnStart method and processes any code you have defined there.

A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.

You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.

Types of Services

There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.

You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.

Services and the ServiceController Component

The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.

For more information, see ServiceController.

Requirements

Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.

Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.