Устранение неполадок автономной среды выполнения интеграции

Статья
01/05/2024

ОБЛАСТЬ ПРИМЕНЕНИЯ: Фабрика данных Azure Azure Synapse Analytics Microsoft Purview

Совет

Попробуйте использовать фабрику данных в Microsoft Fabric, решение для аналитики с одним интерфейсом для предприятий. Microsoft Fabric охватывает все, от перемещения данных до обработки и анализа данных в режиме реального времени, бизнес-аналитики и отчетности. Узнайте, как бесплатно запустить новую пробную версию !

В этой статье рассматриваются стандартные методы устранения неполадок с локальной средой выполнения интеграции (IR) в Фабрике данных Azure и рабочих областях Synapse.

Сбор журналов локальной среды выполнения интеграции

Фабрика данных Azure и Azure Synapse Analytics

В службе предусмотрена возможность просмотра и отправки журналов ошибок в случае сбоя при выполнении действий в локальной или общей среде IR. Следуйте приведенным здесь инструкциям, чтобы получить идентификатор отчета об ошибках, а затем введите идентификатор отчета для поиска связанных известных проблем.

На странице "Мониторинг" пользовательского интерфейса службы выберите Выполнения конвейеров.
В разделе Выполнения действий в столбце Ошибка выберите выделенную кнопку для отображения журналов действий, как показано на следующем снимке экрана.
- Фабрика данных Azure
- Azure Synapse
Журналы действий отображаются в случае сбоя при выполнении действия.
Для получения дополнительной помощи выберите Отправка журналов.

Откроется окно Share the self-hosted integration runtime (IR) logs with Microsoft (Использование журналов локальной среды выполнения интеграции (IR) совместно с Майкрософт).
Выберите журналы, которые требуется отправить.
- Для локальной среды IR можно передать журналы, связанные с действиями, завершившимися сбоем, или все журналы на узле локальной среды IR.
- Для общей среды IR можно передать только журналы, которые относятся к завершившемуся сбоем действию.
После отправки журналов следует сохранить запись идентификатора отчета для последующего использования в случае, если требуется дополнительная помощь по устранению проблемы.

Примечание.

Запросы на просмотр и отправку журналов выполняются во всех подключенных к сети экземплярах локальной среды выполнения интеграции. Если какие-либо журналы отсутствуют, убедитесь, что все экземпляры локальной среды IR подключены к сети.

Microsoft Purview

Для неудачных действий Microsoft Purview, выполняемых в локальной среде IR или общей среды IR, служба поддерживает просмотр и отправку журналов ошибок из Windows Просмотр событий.

Вы можете просмотреть все ошибки, которые вы видите в приведенном ниже руководстве по ошибке. Чтобы получить рекомендации по поддержке и устранению неполадок с SHIR, может потребоваться создать идентификатор отчета об ошибках и обратиться в службу поддержки Майкрософт.

Чтобы создать идентификатор отчета об ошибке для служба поддержки Майкрософт, выполните следующие инструкции:

Перед началом сканирования на портале управления Microsoft Purview:
1. Перейдите на компьютер, на котором установлена локальная среда выполнения интеграции и откройте Просмотр событий Windows.
2. Снимите журналы Windows Просмотр событий в разделе "Среда выполнения интеграции". Щелкните правой кнопкой мыши журналы и выберите параметр очистки журналов.
3. Вернитесь на портал управления Microsoft Purview и запустите проверку.
После отображения состояния проверки вернитесь к виртуальной машине SHIR или компьютеру и обновите средство просмотра событий в разделе "Среда выполнения интеграции".
Журналы действий отображаются для выполнения неудачной проверки.
Для получения дополнительной помощи от Корпорации Майкрософт выберите "Отправить журналы".

Откроется окно " Общий доступ" к журналам локальной среды выполнения интеграции (SHIR).
Выберите журналы, которые требуется отправить.
- Для локальной среды IR можно передать журналы, связанные с действиями, завершившимися сбоем, или все журналы на узле локальной среды IR.
- Для общей среды IR можно передать только журналы, которые относятся к завершившемуся сбоем действию.
После отправки журналов следует сохранить запись идентификатора отчета для последующего использования в случае, если требуется дополнительная помощь по устранению проблемы.

Примечание.

Общая неисправность или ошибка в локальной среде IR

Проблема нехватки памяти

Симптомы

Ошибка OutOfMemoryException (OOM) происходит при попытке выполнить операцию поиска для связанной или локальной среды IR.
Причина

Новое действие может вызвать ошибку OOM, если на компьютере среды выполнения интеграции наблюдается мгновенное повышение интенсивности использования памяти. Такая неполадка может быть вызвана параллельным выполнением большого числа действий, а сама эта ошибка предусмотрена конструктивно.
Решение

Проверьте использование ресурсов и параллельное выполнение действий на узле IR. Чтобы избежать одновременного выполнения слишком большого количества действий на одном узле IR, настройте внутреннее время и время активации выполнения действий.

Проблема с ограничением количества параллельных заданий

Симптомы

При попытке увеличить ограничение количества одновременных заданий из пользовательского интерфейса процесс зависает в состоянии Обновляется.

Пример сценария. Максимальное количество одновременных заданий в настоящее время равно 24. Требуется увеличить это значение, чтобы задания могли выполняться быстрее. Минимальное значение, которое можно ввести, равно 3, а максимальное — 32. Вы увеличиваете значение с 24 до 32, а затем нажимаете кнопку Обновить. Процесс зависает в состоянии Обновление, как показано на снимке экрана ниже. Вы обновляете страницу, но на ней по-прежнему отображается значение 24. Оно не было обновлено до 32, как ожидалось.
Причина

Ограничение на количество параллельных заданий зависит от логического ядра и памяти компьютера. Попробуйте уменьшить значение, например до 24, а затем просмотрите результат.
Совет
- Дополнительные сведения о количестве логических ядер и определении их числа на компьютере см. на странице Четыре способа определения количества ядер ЦП в Windows 10.
- Чтобы узнать, как вычислить math.log, перейдите к калькулятору логарифма.

Проблема с SSL-сертификатом в локальной среде IR с высоким уровнем доступности (HA)

Симптомы

От рабочего узла локальной среды IR поступило следующее сообщение об ошибке:

"Не удалось извлечь общие состояния из основного узла net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. Идентификатор действия: XXXXX. Сертификат X.509 CN=abc.cloud.corp.Microsoft.com, OU=test, O=Сбой при создании цепочки сертификатов Майкрософт. Используемый сертификат имеет цепочку доверия, которую невозможно проверить. Замените сертификат или измените certificateValidationMode. Функции отзыва не удалось проверить отзыв, так как сервер отзыва был не в сети".
Причина

При обработке обращений, связанных с подтверждением SSL или TLS, могут возникать проблемы, связанные с проверкой цепочки сертификатов.
Решение
- Вот быстрый и понятный способ устранения неполадок со сборкой цепочки сертификатов X.509:
  1. Экспортируйте сертификат, который необходимо проверить. Для этого выполните следующее.
    
    а. В Windows нажмите кнопку Пуск, начните вводить сертификаты, а затем выберите Управление сертификатами компьютеров.
    
    b. В проводнике в области слева найдите сертификат, который требуется проверить, щелкните его правой кнопкой мыши и выберите Все задачи>Экспорт.
  2. Скопируйте экспортированный сертификат на клиентский компьютер.
  3. На стороне клиента в окне командной строки запустите выполнение следующей команды. Не забудьте заменить <путь к сертификату> и <путь к выходному TXT-файлу> фактическими путями.
```
Certutil -verify -urlfetch    <certificate path>   >     <output txt file path> 
```
    Например:
```
Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt
```
  4. Проверьте наличие ошибок в выходном TXT-файле. Сводку ошибок можно найти в конце TXT-файла.
    
    Например:
    
    Если в конце файла журнала отсутствует ошибка, как показано на следующем снимке экрана, можно считать, что цепочка сертификатов на клиентском компьютере построена успешно.
- Если в файле сертификата настроено расширение имени файла AIA (доступ к информации о центре сертификации), CDP (точка распространения списка отзыва сертификатов) или OCSP (Online Certificate Status Protocol), его можно проверить с помощью более интуитивно понятного способа.
  1. Для получения этих сведений проверьте данные сертификата, как показано на следующем снимке экрана.
  2. Выполните следующую команду. Не забудьте заменить <путь к сертификату> фактическим путем к сертификату.
```
  Certutil   -URL    <certificate path> 
```
    Откроется средство извлечения URL-адресов.
  3. Чтобы проверить сертификаты с расширениями имени файла AIA, CDP и OCSP, выберите Получить.
    
    Цепочку сертификатов успешно создано, если сертификат из AIA находится в состоянии Проверено. Состояние сертификатов из CDP или OCSP также должно быть Проверено.
    
    Если при попытке получения данных AIA и CDP отображается сообщение об ошибке, обратитесь в команду по работе с сетями, чтобы подготовить клиентский компьютер к подключению к целевому URL-адресу. Будет достаточно обеспечить возможность проверки пути HTTP или LDAP.

Локальной среде IR не удалось загрузить файл или сборку

Симптомы

Возникает следующее сообщение об ошибке:

"Не удалось загрузить файл или сборку "XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX" либо одну из их зависимостей. Системе не удается найти указанный файл. Идентификатор действия: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

Вот более конкретное сообщение об ошибке:

"Не удалось загрузить файл или сборку "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX" либо одну из их зависимостей. Системе не удается найти указанный файл. Идентификатор действия: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"
Причина

В мониторе процессов можно просмотреть следующий результат:

Совет

В мониторе процессов можно задать фильтры, как показано на следующем снимке экрана.

Приведенное выше сообщение об ошибке указывает на то, что библиотека DLL System.ValueTuple не находится в связанной папке глобального кэша сборок (GAC), в папке C:\Program Files\Microsoft Integration Runtime\4.0\Gateway или в папке C:\Program Files\Microsoft Integration Runtime\4.0\Shared.

По сути, процесс загружает библиотеку DLL сначала из папки GAC, затем из папки Shared и, наконец, из папки Gateway. Таким образом, библиотека DLL может загружаться из любого удобного пути.
Решение

Файл System.ValueTuple.dll находится в папке C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Чтобы устранить эту проблему, скопируйте файл System.ValueTuple.dll в папку C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.

Этот же метод можно использовать для устранения других проблем, при которых отсутствуют файлы или сборки.
Дополнительные сведения об этой проблеме

Причина, по которой файл System.ValueTuple.dll находится в папке %windir%\Microsoft.NET\assembly и %windir%\assembly, заключается в том, что такое поведение предусмотрено .NET.

В следующем сообщении об ошибке видно, что сборка System.ValueTuple отсутствует. Эта проблема возникает, когда приложение пытается проверить сборку System.ValueTuple.dll.

"<LogProperties><ErrorInfo>[{"Code":0,"Message":"Инициализатор типа для Npgsql.PoolManager породил исключение.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Не удалось загрузить файл или сборку System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX, либо одну из соответствующих зависимостей. Системе не удается найти указанный файл.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

Подробнее о GAC см. в статье Глобальный кэш сборок.

Отсутствует ключ проверки подлинности локальной среды выполнения интеграции

Симптомы

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

"Ключ проверки подлинности еще не назначен".
Причина
- На портале Azure удален узел локальной среды IR или удалена логическая локальная среда IR.
- Выполнено чистое удаление.
Решение

Если ни одна из описанных выше причин не применима, перейдите в папку %programdata%\Microsoft\Data Transfer\DataManagementGateway и проверьте, не удален ли файл конфигураций. Если он удален, следуйте инструкциям, приведенным в статье Netwrix, чтобы определить, кто удалил файл с файловых серверов Windows.

Не удается создать мост между двумя локальными хранилищами данных с помощью локальной среды IR

Симптомы

После создания локальных сред IR для исходного и целевого хранилищ данных необходимо соединить эти две среды IR для завершения операции копирования. Если хранилища данных настроены в разных виртуальных сетях или не поддерживают механизм шлюза, отображается одно из следующих сообщений об ошибке:
- The driver of source cannot be found in destination IR (Не удается найти драйвер источника в целевой среде IR)
- The source cannot be accessed by the destination IR (Источник недоступен для целевой среды IR)
Причина

Локальная среда IR разработана как центральный узел действия копирования, а не агент клиента, который необходимо установить для каждого хранилища данных.

В этом случае нужно создавать связанную службу с одной и той же средой IR для каждого хранилища данных. Такая среда должна иметь доступ к обоим хранилищам данных по сети. Не имеет значения, установлена ли среда выполнения интеграции в исходном или целевом хранилище данных или же на отдельном от них компьютере. Если две связанные службы создаются с разными средами выполнения интеграции, но используются в одном и том же действии копирования, используется целевая среда IR. При этом на целевом компьютере IR необходимо установить драйверы для обоих хранилищ данных.
Решение

Установите драйверы для исходного и целевого хранилищ данных в целевой среде IR и убедитесь, что у нее есть доступ к исходному хранилищу данных.

Если трафик не может пройти через сеть между двумя хранилищами данных (например, они настроены в двух виртуальных сетях), вы не сможете завершить копирование в рамках одного действия, даже при наличии установленной среды IR. Если не удается завершить копирование в рамках одного действия, можно создать два действия копирования с двумя средами IR, каждая из которых находится в виртуальной сети:
- скопируйте одну среду IR из хранилища данных 1 в Хранилище BLOB-объектов Azure;
- скопируйте другую среду IR из Хранилища BLOB-объектов Azure в хранилище данных 2.
Это решение позволяет сымитировать соответствие требованию использовать IR для создания моста, соединяющего два неподключенных хранилища данных.

Ошибка синхронизации учетных данных приводит к потере учетных данных в режиме HA

Симптомы

Если учетные данные источника данных "XXXXXXXXXX" удалены из текущего узла среды выполнения интеграции с полезной нагрузкой, отображается следующее сообщение об ошибке:

"Если служба связи удалена на портале Azure либо у задачи неверная полезная нагрузка, создайте службу связи со своими учетными данными еще раз".
Причина

Локальная среда IR создана в режиме высокой доступности с двумя узлами, но узлы не находятся в состоянии синхронизации учетных данных. Это означает, что учетные данные, хранящиеся в узле диспетчера, не синхронизируются с другими рабочими узлами. Если отработка отказа происходит с узла диспетчера на рабочий узел, но учетные данные существовали только в предыдущем узле диспетчера, то при попытке доступа к учетным данным происходит сбой и отображается приведенное выше сообщение об ошибке.
Решение

Единственный способ избежать этой проблемы — проследить за тем, чтобы учетные данные в обоих узлах находились в состоянии синхронизации. Если они не синхронизированы, необходимо повторно ввести учетные данные для нового диспетчера.

Не удается выбрать сертификат, поскольку отсутствует закрытый ключ

Симптомы
- Вы импортировали PFX-файл в хранилище сертификатов.
- При выборе сертификата через пользовательский интерфейс среды выполнения интеграции Configuration Manager отобразилось следующее сообщение об ошибке:
  
  "Не удалось изменить режим шифрования коммуникации интрасети. Возможно, у сертификата <имя сертификата> нет закрытого ключа, обеспечивающего обмен ключами, или у процесса нет прав доступа к закрытому ключу. Дополнительные сведения см. в внутреннем исключении.
Причина
- Учетная запись пользователя имеет низкий уровень привилегий и не может получить доступ к закрытому ключу.
- Сертификат создан как сигнатура и не предназначен для обмена ключами.
Решение
- Для работы с пользовательским интерфейсом используйте учетную запись с соответствующими привилегиями для доступа к закрытому ключу.
- Импортируйте сертификат с помощью следующей команды:
```
certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
```

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

Симптомы

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

The Integration Runtime (Self-hosted) node is trying to sync the credentials across nodes. It may take several minutes (Узел Integration Runtime (Self-hosted) пытается синхронизировать учетные данные между узлами. Это может занять несколько минут).

Примечание.

Если эта ошибка происходит в течение более 10 минут, проверьте подключение к узлу диспетчера.
Причина

Причина заключается в том, что рабочие узлы не имеют доступа к закрытым ключам. В этом можно убедиться в журналах локальной среды выполнения интеграции, как показано ниже.

[14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

При использовании проверки подлинности субъекта-службы в связанной службе проблемы с процессом синхронизации не возникают. Однако при смене типа проверки подлинности на проверку с помощью ключа учетной записи возникает проблема синхронизации. Это связано с тем, что служба локальной среды выполнения интеграции работает в учетной записи службы (NT SERVICE\DIAHostService) и ее необходимо добавить к разрешениям закрытого ключа.
Решение

Чтобы решить эту проблему, необходимо добавить учетную запись службы локальной среды выполнения интеграции (NT SERVICE\DIAHostService) в разрешения закрытого ключа. В этом случае можно выполнить указанные ниже действия.
1. Откройте окно выполнения команд в консоли управления (MMC).
2. В области MMC выполните следующие действия.
  1. Выберите Файл.
  2. В раскрывающемся меню выберите Добавить или удалить оснастку.
  3. В области "Доступные оснастки" выберите Сертификаты.
  4. Выберите Добавить.
  5. Во всплывающем окне "Оснастка диспетчера сертификатов" выберите Учетная запись компьютера.
  6. Выберите Далее.
  7. На странице "Выбор компьютера" выберите Локальный компьютер (на котором запущена эта консоль) .
  8. Выберите Готово.
  9. Нажмите кнопку ОК в области "Добавление и удаление оснасток".
3. В области консоли MMC перейдите к следующим шагам.
  1. В списке папок слева выберите Корень консоли > Сертификаты (локальный компьютер) > Личные > Сертификаты.
  2. Щелкните правой кнопкой мыши Microsoft Intune Beta MDM.
  3. В раскрывающемся списке выберите Все задачи.
  4. Выберите Управление закрытыми ключами.
  5. В разделе "Имена пользователей или групп" выберите Добавить.
  6. Выберите NT SERVICE\DIAHostService, чтобы предоставить полный доступ к этому сертификату, применить изменения и сохранить их.
  7. Выберите Проверить имена и нажмите кнопку ОК.
  8. В области "Разрешения" выберите Применить, а затем нажмите кнопку ОК.

Сообщение об ошибке "UserErrorJreNotFound" при выполнении действия копирования в Azure

Симптомы

При попытке скопировать содержимое в Microsoft Azure с помощью средства или программы на основе Java (например, при копировании файлов формата ORC или Parquet) появляется сообщение об ошибке следующего вида:

ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment is not found. Перейдите в раздел http://go.microsoft.com/fwlink/?LinkId=808605, чтобы скачать и установить на компьютере узел Integration Runtime (Self-hosted). Примечание. Для 64-битной среды Integration Runtime требуется 64-битная среда выполнения Java, а для 32-битной Integration Runtime — 32-разрядная среда выполнения Java, Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': The specified module could not be found (Исключение из HRESULT: 0x8007007E), Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge
Причина

Эта проблема возникает по одной из следующих причин:
- Среда выполнения Java (JRE) неправильно установлена на сервере Integration Runtime.
- Сервер Integration Runtime не имеет необходимой зависимости для JRE.
По умолчанию Integration Runtime разрешает путь JRE с помощью записей реестра. Эти записи должны быть автоматически заданы во время установки JRE.
Решение

Внимательно выполните действия, описанные в этом разделе. Неправильное изменение реестра может привести к серьезным проблемам. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем.

Чтобы устранить эту проблему и проверить состояние установки JRE, выполните следующие действия:
1. Убедитесь, что Integration Runtime (Diahost.exe) и JRE установлены на одной платформе. Убедитесь в следующем:
  - 64-разрядная среда выполнения Java для 64-разрядной ADF Integration Runtime должна быть установлена в папке C:\Program Files\Java\.
    
    Примечание.
    
    Это не папка C:\Program Files (x86)\Java\.
  - Среда выполнения Java (JRE) — это версия 11 или больше, от поставщика JRE, например Microsoft OpenJDK 11 или Eclipse Temurin 11. Убедитесь, что переменная системной среды JAVA_HOME задана в папку JDK (а не только в папке JRE), возможно, также потребуется добавить папку bin в переменную среды PATH системы.
2. Проверьте реестр на наличие нужных параметров. Для этого выполните следующие действия:
  1. В меню Выполнить введите regedit и нажмите клавишу ВВОД.
  2. В области навигации выберите следующий подключ:
    
    HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.
    
    В области сведений должна быть запись текущей версии, которая показывает версию JRE (например, 1.8).
  3. В области навигации выберите подключ, точно соответствующий версии (например, 1.8) в папке JRE. В области сведений должна быть запись JavaHome. Значение этой записи — путь установки JRE.
3. Откройте папку bin\server по следующему пути:
  
  C:\Program Files\Java\jre1.8.0_74
4. Проверьте, содержит ли эта папка файл jvm.dll. Если это не так, проверьте наличие файла в папке bin\client.
Примечание.
- Если какая либо из этих конфигураций не описана в этих шагах, используйте установщик Windows JRE для устранения неполадок.
- Если все конфигурации в этих шагах правильные, как описано, в системе может отсутствовать библиотека среды выполнения VC++. Эту проблему можно решить, установив распространяемый пакет VC++ 2010.

Установка локальной среды IR

Ошибка регистрации среды выполнения интеграции

Симптомы

Локальную среду IR иногда требуется запустить с другой учетной записью по одной из следующих причин:
- политика компании запрещает использование учетной записи службы;
- требуется проверка подлинности.
После изменения учетной записи службы на панели службы может быть указано, что среда выполнения интеграции перестала работать, и появится следующее сообщение об ошибке:

"На узле Integration Runtime (Self-hosted) произошла ошибка при регистрации. Не удается подключиться к службе узла Integration Runtime (Self-hosted)".
Причина

Многие ресурсы предоставляются только учетной записи службы. При изменении учетной записи службы на другую учетную запись разрешения всех зависимых ресурсов остаются неизменными.
Решение

Чтобы проверить наличие ошибки, перейдите в журнал событий среды выполнения интеграции.
- Если в журнале событий содержится ошибка UnauthorizedAccessException, выполните следующие действия.
  1. Проверьте учетную запись службы входа DIAHostService на панели службы Windows.
  2. Проверьте, имеет ли учетная запись службы входа разрешения на чтение и запись для папки %programdata%\Microsoft\DataTransfer\DataManagementGateway.
    - По умолчанию, если учетная запись для входа в службу не изменена, она должна иметь разрешения на чтение и запись.
    - Если вы изменили учетную запись входа в службу, выполните следующие действия, чтобы устранить проблему.
      
      a. Выполните чистое удаление установки текущей локальной среды IR.
      b. Установите код локальной среды IR.
      c. Измените учетную запись службы, выполнив следующие действия.
      
      i. Перейдите к папке установки локальной среды IR, а затем — в папку Microsoft Integration Runtime\4.0\Shared.
      ii. Откройте окно командной строки с более высоким уровнем привилегий. Замените <имя пользователя> и <пароль> своим именем пользователя и паролем, а затем выполните следующую команду:
      dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
      iii. Если вы хотите перейти на учетную запись LocalSystem, убедитесь, что для нее используется правильный формат: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" "".
      Не используйте этот формат: dmgcmd.exe -SwitchServiceAccount "LocalSystem" "".
      iv. Поскольку локальная система имеет более высокий уровень привилегий, чем администратор, вы можете при необходимости изменить ее напрямую в разделе "Службы".
      v. Для учетной записи входа в службу IR можно использовать локального пользователя или пользователя домена.
      
      d. Зарегистрируйте среду выполнения интеграции.
- Если произошла ошибка "Не удалось запустить службу Integration Runtime Service (DIAHostService). Убедитесь в том, что у вас имеются достаточные привилегии для запуска системных служб", выполните следующие действия:
  1. Проверьте учетную запись службы входа DIAHostService на панели службы Windows.
  2. Проверьте, имеет ли учетная запись службы входа разрешение Вход в качестве службы для запуска службы Windows.
Дополнительные сведения

Если ни одна из двух предыдущих схем разрешения не применима к вашему случаю, попробуйте собрать следующие журналы событий Windows:
- "Журналы приложений и служб" > "Integration Runtime";
- "Журналы Windows" > "Приложение".

Не удается найти кнопку регистрации, чтобы зарегистрировать локальную среду IR

Симптомы

При регистрации локальной среды IR в области Configuration Manager не отображается кнопка Регистрация.
Причина

В выпуске Integration Runtime 3.0 кнопка Регистрация на имеющемся узле среды выполнения интеграции была удалена для создания более надежной и безопасной среды. Если узел был зарегистрирован в среде выполнения интеграции (в сети или в автономном режиме), для его повторной регистрации в другой среде выполнения интеграции необходимо удалить предыдущий узел, а затем установить и зарегистрировать узел.
Решение
1. Удалите имеющуюся среду выполнения интеграции с помощью панели управления.
  
  Внимание
  
  В следующем процессе выберите Да. Не оставляйте данные во время процесса удаления.
2. Если у вас нет MSI-файла установщика среды выполнения интеграции, перейдите в центр загрузки, чтобы скачать последнюю версию этой среды.
3. Установите MSI-файл и зарегистрируйте среду выполнения интеграции.

Не удалось зарегистрировать локальную среду IR из-за localhost

Симптомы

На новом компьютере не удается зарегистрировать локальную среду IR при использовании get_LoopbackIpOrName.

Отладка. Произошла ошибка среды выполнения. Инициализатор типа "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" выдал исключение. При просмотре базы данных произошла неисправимая ошибка.

Сведения об исключении. System.TypeInitializationException. Инициализатор типа Microsoft.DataTransfer.DIAgentHost.DataSourceCache выдал исключение. ---> System.Net.Sockets.SocketException. При просмотре базы данных произошла неисправимая ошибка в System.Net.Dns.GetAddrInfo(строковое имя).
Причина

Эта проблема обычно возникает при разрешении localhost.
Решение

Чтобы разместить файл и устранить проблему, используйте IP-адрес localhost 127.0.0.1.

Сбой установки локальной среды

Симптомы

Не удалось удалить имеющуюся среду IR, установить новую среду IR или обновить имеющуюся среду IR до новой.
Причина

Установка среды выполнения интеграции зависит от службы установщика Windows. Проблемы установки могут возникать по следующим причинам:
- недостаточно свободного места на диске;
- отсутствие необходимых разрешений;
- блокировка службы Windows NT;
- слишком высокий уровень использования ЦП;
- медленная работа сетевого расположения, в котором размещен MSI-файл;
- непреднамеренное изменение некоторых системных файлов или реестров.

Учетной записи службы IR не удалось получить доступ к сертификату

Симптомы

При установке локальной среды IR с помощью Configuration Manager для Microsoft Integration Runtime создается сертификат с доверенным центром сертификации. Сертификат не удалось применить для шифрования данных, передаваемых между двумя узлами, и отображается следующее сообщение об ошибке:

"Не удалось изменить режим шифрования коммуникации интрасети. Не удалось предоставить доступ к сертификату "<имя сертификата>" для учетной записи Integration Runtime. Код ошибки: 103".
Причина

Сертификат использует хранилище поставщика хранилища ключей (KSP), которое пока не поддерживается. На сегодняшний день локальная среда IR поддерживает только хранилище поставщика служб шифрования (CSP).
Решение

В этом случае рекомендуется использовать сертификаты CSP.

Решение 1

Чтобы импортировать сертификат, воспользуйтесь следующей командой:

Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

Решение 2

Чтобы преобразовать сертификат, воспользуйтесь следующими командами:

openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

До и после преобразования:

Локальная среда выполнения интеграции версии 5.x

Для обновления до версии 5.x локальной среды выполнения интеграции требуется среда выполнения .NET Framework 4.7.2 или более поздней версии. На странице загрузки приведена ссылка для скачивания последней версии 4.x и последних двух версий 5.x.

Для пользователей Фабрики данных Azure версии 2 и Azure Synapse:

Если включено автоматическое обновление и вы уже обновили среду выполнения платформы .NET Framework до версии 4.7.2 или более поздней, локальная среда выполнения интеграции будет автоматически обновлена до последней версии 5.x.
Если автоматическое обновление включено, но не обновили среду выполнения платформы .NET Framework до версии 4.7.2 или более поздней, локальная среда выполнения интеграции не будет автоматически обновлена до последней версии 5.x. Сохранится текущая версия 4.x локальной среды выполнения интеграции. Предупреждение об обновлении среды выполнения платформы .NET Framework отобразится на портале и в клиенте локальной среды выполнения интеграции.
Если автоматическое обновление отключено и вы уже обновили среду выполнения платформы .NET Framework до версии 4.7.2 или более поздней, вы можете вручную скачать последнюю версию 5.x и установить ее на компьютере.
Если автоматическое обновление отключено, но вы не обновили среду выполнения платформы .NET Framework до версии 4.7.2 или более поздней, при попытке вручную установить локальную среду выполнения интеграции версии 5.x и зарегистрировать ключ потребуется сначала обновить версию среды выполнения платформы .NET Framework.

Проблемы с подключением локальной среды IR

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

Симптомы

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

"На узле Integration Runtime (Self-hosted) произошла ошибка при регистрации".
Причина

Локальной среде выполнения интеграции не удалось подключиться к серверной части службы. Обычно такая проблема возникает из-за настроек брандмауэра.
Решение
1. Проверьте, запущена ли среда выполнения интеграции. Если да, перейдите к шагу 2.
2. Если для локальной среды IR не используется прокси-сервер (вариант по умолчанию), выполните следующую команду PowerShell на том компьютере, где установлена локальная среда выполнения интеграции.
```
(New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
```
  Примечание.
  
  URL-адрес службы может отличаться в зависимости от расположения экземпляра фабрики данных или рабочей области Synapse. Чтобы найти URL-адрес службы, используйте страницу "Управление" в пользовательском интерфейсе в экземпляре фабрики данных или Azure Synapse, чтобы найти Среды выполнения интеграции, и щелкните свой объект локальной среды выполнения интеграции, чтобы изменить его. Откройте вкладку Узлы и щелкните Просмотреть URL-адреса службы.
  
  Ожидается примерно такой ответ:
3. Если получен не тот ответ, который ожидался, воспользуйтесь одним из описанных ниже методов в зависимости от ситуации.
  - Если вы получаете сообщение Remote name could not be resolved (Не удалось разрешить удаленное имя), это указывает на проблему в службе доменных имен (DNS). Для устранения этой проблемы свяжитесь с командой по работе с сетями.
  - Если вы получаете сообщение ssl/tls cert не является доверенным, проверьте сертификат (https://wu2.frontend.clouddatahub.net/), чтобы узнать, является ли сертификат доверенным на компьютере, а затем установите общедоступный сертификат с помощью диспетчера сертификатов. Это действие должно устранить проблему.
  - Последовательно выберите Windows>Просмотр событий (журналы)>Журналы приложений и служб>Среда выполнения интеграции и проверьте, нет ли здесь сведений об ошибках, вызванных DNS, правилами брандмауэра или настройками корпоративной сети. Если такие ошибки есть, принудительно закройте подключение. В каждой компании настройки собственной сети будут отличаться, поэтому устранение неполадок следует поручить команде по работе с сетями.
4. Если для локальной среды выполнения интеграции настроен прокси-сервер, убедитесь, что этот прокси-сервер имеет доступ к конечной точке службы. Пример команды для такой проверки см. здесь.
```
$user = $env:username
$webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
Settings').ProxyServer
$pwd = Read-Host "Password?" -assecurestring
$proxy = new-object System.Net.WebProxy
$proxy.Address = $webproxy
$account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
$proxy.credentials = $account
$url = "https://wu2.frontend.clouddatahub.net/"
$wc = new-object system.net.WebClient
$wc.proxy = $proxy
$webpage = $wc.DownloadData($url)
$string = [System.Text.Encoding]::ASCII.GetString($webpage)
$string
```
Ожидается примерно такой ответ:
Примечание.

Рекомендации по использованию прокси-сервера:
- Проверьте, не нужно ли добавить прокси-сервер в список надежных получателей. Если это так, включите в список надежных получателей эти домены.
- Проверьте, является ли ssl/TLS-сертификат wu2.frontend.clouddatahub.net/ доверенным на прокси-сервере.
- Если вы используете в прокси-сервере проверку подлинности Active Directory, укажите в поле "Служба среды выполнения интеграции" вместо учетной записи службы учетную запись пользователя с доступом к прокси-серверу.

Сообщение об ошибке: Self-hosted integration runtime node/logicalself-hosted IR is in Inactive/ "Running (Limited)" state (Узел локальной среды выполнения интеграции или логическая локальная среда выполнения интеграции находится в неактивном или ограниченном состоянии)

Причина

Узел локальной среды выполнения интеграции может находиться в состоянии Неактивно, как показано на следующем снимке экрана.

Такое может происходить, если узлы не могут нормально взаимодействовать.
Решение
1. Войдите на виртуальную машину, размещенную на узле. В разделе Журналы приложений и служб>Среда выполнения интеграции откройте "Просмотр событий" и отфильтруйте журналы ошибок.
2. Проверьте, содержит ли журнал ошибок следующую ошибку.
```
System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
10.2.4.10:8060
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
```
3. В случае этой ошибки в окне командной строки выполните следующую команду:
```
telnet 10.2.4.10 8060
```
4. Если в командной строке отобразится сообщение об ошибке "Не удалось открыть подключение к этому узлу", которое показано на следующем снимке экрана, обратитесь в ИТ-отдел за помощью в устранении этой проблемы. Если у вас по-прежнему возникают проблемы с состоянием узла среды выполнения интеграции после успешной установки Telnet, обратитесь в службу поддержки Майкрософт.
5. Проверьте, содержит ли журнал ошибок следующую запись:
```
Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)
```
6. Для устранения этой проблемы воспользуйтесь одним из указанных ниже способов или обоими сразу.
  - Разместите все узлы в одном домене.
  - Добавьте сопоставление IP-адресов и узлов во все файлы узлов размещенной виртуальной машины.

Проблемы с подключением между локальной средой IR и экземпляром фабрики данных или Azure Synapse либо локальной средой IR и источником или приемником данных

Чтобы устранить неполадки с сетевым подключением, необходимо знать, как получить трассировку сети, понимать, как ее использовать, и проанализировать трассировку Microsoft Network Monitor (Netmon) перед применением средств Netmon на практике из локальной среды IR.

Симптомы

Иногда может потребоваться устранить ряд проблем с подключением между локальной средой IR и экземпляром фабрики данных или Azure Synapse, как показано на следующем снимке экрана, либо между локальной средой IR и источником или приемником данных.

В обоих случаях могут возникать следующие ошибки:
- "Не удалось выполнить копирование. Ошибка:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Не удается подключиться к SQL Server: "IP-адрес";
- "Произошла одна или более ошибок. An error occurred while sending the request. Базовое соединение закрыто. Непредвиденная ошибка при приеме. Не удается прочитать данные из транспортного соединения. Удаленный хост принудительно разорвал существующее подключение. Удаленный хост принудительно разорвал существующее подключение (идентификатор действия)".
Решение

В случае возникновения предыдущих ошибок следуйте инструкциям из этого раздела для их устранения.
- Получите трассировку Netmon для анализа:
  1. Вы можете настроить фильтр для просмотра сброса с сервера на стороне клиента. На следующем снимке экрана показан пример, где стороной сервера является сервер Фабрики данных.
  2. При получении пакета сброса беседу можно найти, выбрав протокол TCP.
  3. Получите беседу между клиентом и сервером фабрики данных, удалив фильтр.
- Анализ полученной трассировки Netmon показывает, что общий срок жизни составляет 64. В соответствии со значениями, указанными в статье Основные сведения о предельных значениях срока жизни и числа прыжков для протокола IP, выдержка из которой приведена в следующем списке, можно установить, что это система Linux, которая сбрасывает пакет и вызывает отключение.
  
  Как показано ниже, предельные значения срока жизни и числа прыжков по умолчанию различны в разных операционных системах.
  - Ядро Linux 2.4 (приблизительно 2001 год): 255 для TCP, UDP и ICMP
  - Ядро Linux 4.10 (2015): 64 для TCP, UDP и ICMP
  - Windows XP (2001): 128 для TCP, UDP и ICMP
  - Windows 10 (2015): 128 для TCP, UDP и ICMP
  - Windows Server 2008: 128 для TCP, UDP и ICMP
  - Windows Server 2019 (2018): 128 для TCP, UDP и ICMP
  - macOS (2001): 64 для TCP, UDP и ICMP
  В предыдущем примере вместо 64 для срока жизни отображается 61, так как при достижении сетевым пакетом места назначения он должен осуществить различные прыжки, например через маршрутизаторы или сетевые устройства. Для получения окончательного срока жизни из значения вычитается число маршрутизаторов или сетевых устройств.
  
  В этом случае можно увидеть, что команда сброса может быть отправлена из системы Linux со сроком жизни 64.
- Чтобы определить, какое устройство инициирует сброс, проверьте четвертый прыжок из локальной среды IR.
  
  Сетевой пакет из системы Linux A со сроком жизни 64 -> срок жизни B 64 минус 1 = 63 -> срок жизни C 63 минус 1 = 62 -> срок жизни 62 минус 1 = 61 в локальной среде IR
- В идеальной ситуации число прыжков для определения срока жизни было бы равно 128 и это означало бы, что экземпляр фабрики данных выполняется в операционной системе Windows. Как показано в следующем примере, 128 минус 107 = 21 прыжок. Это означает, что во время подтверждения TCP 3 из экземпляра фабрики данных в локальную среду IR для пакета был отправлен 21 прыжок.
  
  Поэтому необходимо попросить проверить, каким был четвертый прыжок из локальной среды IR. Если это брандмауэр, как в системе Linux, проверьте все журналы, чтобы узнать, почему устройство сбрасывает пакет после подтверждения TCP 3.
  
  Если вы не знаете, где искать причину, попытайтесь получить трассировку Netmon из локальной среды IR и брандмауэра во время возникновения проблемы. Этот подход поможет вам определить, какое устройство может сбрасывать пакет и что приводит к отсоединению. В этом случае для выполнения дальнейших действий также необходимо привлечь команду по работе с сетями.

Анализ трассировки Netmon

Примечание.

Приведенные ниже инструкции относятся к трассировке Netmon. Так как трассировка Netmon в настоящее время не поддерживается, для этой цели можно использовать Wireshark.

При попытке установить подключение Telnet 8.8.8.8 888 с полученной трассировкой Netmon должна отобразиться такая же трассировка, как показанная на следующих снимках экрана.

Снимок экрана:

Снимок экрана, на котором показано описание трассировки Netmon.

На приведенных выше изображениях показано, что установить TCP-подключение на стороне сервера 8.8.8.8 через порт 888 не удалось, поэтому здесь отображается два дополнительных пакета SynReTransmit. Поскольку источнику SELF-HOST2 не удалось подключиться к серверу 8.8.8.8 с помощью первого пакета, он продолжит попытки установить соединение.

Совет

Чтобы установить это подключение, попробуйте следующее решение.

Выберите Загрузить фильтр>Стандартные фильтры>Адреса>Адреса IPv4.
Чтобы применить фильтр, введите IPv4.Address == 8.8.8.8, а затем нажмите кнопку Применить. После этого должна установиться связь между локальным компьютером и сервером назначения 8.8.8.8.

Снимок экрана, на котором показаны адреса фильтров.

Снимок экрана, на котором показаны дополнительные адреса фильтров.

В следующих примерах показаны успешные сценарии.

Если вы можете установить подключение Telnet 8.8.8.8 53 без каких-либо проблем, то подтверждение TCP 3 будет успешным, а сеанс завершится с подтверждением TCP 4.
Предыдущее подтверждение TCP 3 создает следующий рабочий процесс:
Подтверждение TCP 4 для завершения сеанса проиллюстрировано следующими рабочими процессами:

Определение применимости уведомления

Это уведомление касается следующих сценариев:

Сценарий 1. Исходящий трафик из локальной среды выполнения интеграции, которая работает локально за корпоративным брандмауэром

Определить применимость уведомления к этому сценарию можно следующим образом:

Если правила брандмауэра определены на основе полных доменных имен (FQDN), которые используют подход, описанный в разделе Настройка конфигурации брандмауэра и списка разрешений для IP-адресов, уведомление вас не касается.
Если список разрешений для исходящих IP-адресов в корпоративном брандмауэре включен явно, оповещение вас касается.

Если оно вас касается, выполните следующее. До 8 ноября 2020 года сообщите представителям команды по работе с сетевой инфраструктурой, что они должны обновить конфигурацию сети и использовать в ней новейшие IP-адреса фабрики данных. Чтобы скачать новейшие IP-адреса, перейдите к разделу Обнаружение тегов службы с помощью скачиваемых файлов JSON.

Сценарий 2. Исходящий трафик из локальной среды выполнения интеграции, которая выполняется на виртуальной машине Azure в управляемой клиентом виртуальной сети Azure

Определить применимость уведомления к этому сценарию можно следующим образом:

Проверьте, есть ли у вас правила группы безопасности сети (NSG) для исходящего трафика в частной сети, содержащей локальную среду выполнения интеграции. Если ограничения для исходящего трафика отсутствуют, уведомление вас не касается.
Если у вас есть ограничения на правила для исходящего трафика, проверьте, используются ли теги службы. Если вы используете теги службы, уведомление вас не касается. Нет необходимости что-либо изменять или добавлять, так как новый диапазон IP-адресов охватывает имеющиеся теги службы.
Если список разрешений для IP-адресов исходящего трафика явно включен с помощью параметра правил NSG в виртуальной сети Azure, уведомление вас касается.

Если оно вас касается, выполните следующее. До 8 ноября 2020 года сообщите представителям команды по работе с сетевой инфраструктурой, что они должны обновить правила NSG для конфигурации виртуальной сети Azure и использовать в ней новейшие IP-адреса фабрики данных. Чтобы скачать новейшие IP-адреса, перейдите к разделу Обнаружение тегов службы с помощью скачиваемых файлов JSON.

Сценарий 3. Исходящий трафик из SSIS Integration Runtime в управляемой клиентом виртуальной сети Azure

Определить применимость уведомления к этому сценарию можно следующим образом:

Проверьте, имеются ли правила NSG для исходящего трафика в частной сети, содержащей Integration Runtime для SQL Server Integration Services (SSIS). Если ограничения для исходящего трафика отсутствуют, уведомление вас не касается.
Если у вас есть ограничения на правила для исходящего трафика, проверьте, используются ли теги службы. Если вы используете теги службы, уведомление вас не касается. Нет необходимости что-либо изменять или добавлять, так как новый диапазон IP-адресов охватывают имеющиеся теги службы.
Если список разрешений для IP-адресов исходящего трафика явно включен с помощью параметра правил NSG в виртуальной сети Azure, уведомление вас касается.

Если оно вас касается, выполните следующее. До 8 ноября 2020 года сообщите представителям команды по работе с сетевой инфраструктурой, что они должны обновить правила NSG для конфигурации виртуальной сети Azure и использовать в ней новейшие IP-адреса фабрики данных. Чтобы скачать новейшие IP-адреса, перейдите к разделу Обнаружение тегов службы с помощью скачиваемых файлов JSON.

Не удалось установить доверительные отношения для защищенного канала SSL/TLS

Симптомы

Локальной среде IR не удалось подключиться к службе "Фабрика данных Azure" или Azure Synapse.

При проверке локального журнала событий IR после входа в средство просмотра событий Windows>(logs)>Applications and Services Logs>Integration Runtime вы найдете следующее сообщение об ошибке.

"Базовое соединение закрыто. Не удалось установить доверительные отношения для защищенного канала SSL/TLS. Удаленный сертификат недопустим согласно процедуре проверки".

Самый простой способ проверить сертификат сервера службы — открыть ее URL-адрес в браузере. Например, откройте ссылку на сертификат сервера проверки (https://eu.frontend.clouddatahub.net/) на компьютере, где установлена локальная среда IR, а затем просмотрите сведения о сертификате сервера.
Причина

Эта ошибка может произойти по двум причинам:
- Причина 1. Корневой центр сертификации сертификата сервера службы не является доверенным на компьютере, где установлена локальная среда IR.
- Причина 2. Вы используете прокси-сервер в своей среде, сертификат сервера службы заменяется прокси-сервером, а замененный сертификат сервера не является доверенным для компьютера, на котором установлена локальная среда IR.
Решение
- В случае причины 1. Убедитесь, что сертификат сервера службы и его цепочка сертификатов являются доверенными для компьютера, на котором установлена локальная среда IR.
- В случае причины 2. Обозначьте замененный корневой центр сертификации на компьютере локальной среды IR как доверенный либо настройте прокси-сервер так, чтобы он не заменил сертификат сервера службы.
Дополнительные сведения о доверии сертификатов в Windows см. в статье Установка доверенного корневого сертификата.
Дополнительные сведения
Мы развернули новый SSL-сертификат, который подписывается из DigiCert. Проверьте, находится ли Digicert Global Root G2 в доверенном корневом центре сертификации.

Если он не находится в доверенном корневом центре сертификации, скачайте его здесь.

Дополнительные сведения об устранении неполадок см. в статьях, указанных ниже.

Поделиться через

Устранение неполадок автономной среды выполнения интеграции

Сбор журналов локальной среды выполнения интеграции