Поддержка протокола OMA DM — Windows Client Management
- Статья
- Чтение занимает 10 мин
Клиент OMA DM взаимодействует с сервером по протоколу HTTPS и использует синхронизацию DM (OMA DM версии 1.2) в качестве полезных данных сообщения. В этом разделе описаны функциональные возможности OMA DM, поддерживаемые клиентом DM в целом. Полное описание протокола OMA DM версии 1.2 можно найти на веб-сайте OMA.
Стандарты OMA DM
В следующей таблице показаны стандарты OMA DM, которые используются в Windows.
| Общая область | Поддерживаемый стандарт OMA DM |
|---|---|
| Передача данных и сеанс |  |
| XML-код начальной загрузки | XML-файл подготовки клиента OMA. |
| Команды протокола DM | В следующем списке показаны команды, используемые устройством. Дополнительные сведения об элементах команд OMA DM см. на веб-сайте OMA. Выполнение команды Добавить, за которой следует Заменить на том же узле в атомарном элементе, не поддерживается. Вложенные команды Atomic и Get запрещены и приведут к возникновению ошибки с кодом 500.Если XML-элемент, который не является допустимой командой OMA DM, находится в одном из следующих элементов, для этого элемента возвращается код состояния 400: Если cmdID не указан в команде DM, клиент возвращает пустое значение в элементе status и коде состояния 400. Если элементы Atomic вложены, возвращаются следующие коды состояния: Дополнительные сведения о команде Atomic см. в разделе Общие элементы протокола OMA DM. LocURI не может начинаться с Мета-XML-тег в SyncHdr игнорируется устройством. |
| Стандартные объекты OMA DM | DevInfo |
| Security | |
| Узлов | В дереве OMA DM для имени узла применяются следующие правила: » может быть частью имени узла.*). |
| Файлы подготовки | Xml-код подготовки должен быть правильно сформирован и соответствовать определению в протоколе представления SyncML. Если XML-элемент, который не является допустимой командой OMA DM, находится в разделе SyncBody, для этого элемента возвращается код состояния 400. Примечание. |
| Поддержка WBXML | Windows поддерживает отправку и получение SyncML как в формате XML, так и в закодированном формате WBXML. Эту двухформатную поддержку можно настроить с помощью узла DEFAULTENCODING в характеристике приложения w7 во время регистрации. Дополнительные сведения о кодировке WBXML см. в разделе 8 спецификации протокола представления SyncML . |
| Обработка больших объектов | В Windows 10 версии 1511 была добавлена поддержка клиента для отправки больших объектов на сервер. |
Общие элементы протокола OMA DM
Общие элементы используются другими типами элементов DM OMA. В следующей таблице перечислены общие элементы OMA DM, используемые для настройки устройств. Дополнительные сведения об общих элементах OMA DM см. в разделе Использование протокола Управление устройствами представления SyncML (OMA-SyncML-DMRepPro-V1_1_2-20030613-A), доступном на веб-сайте OMA.
| Элемент | Описание |
|---|---|
| Чал | Указывает запрос проверки подлинности. Сервер или клиент может отправить запрос другому, если в исходном сообщении запроса не были предоставлены учетные данные или неадекватные учетные данные. |
| Cmd | Указывает имя команды OMA DM, на которое ссылается элемент Status. |
| CmdID | Задает уникальный идентификатор для команды OMA DM. |
| CmdRef | Указывает идентификатор команды, для которой возвращаются сведения о состоянии или результатах. Этот элемент принимает значение элемента CmdID соответствующего сообщения запроса. |
| Указывает учетные данные проверки подлинности для инициатора сообщения. | |
| Окончательный | Указывает, что текущее сообщение является последним сообщением в пакете. |
| LocName | Указывает отображаемое имя в элементах Target и Source, используемых для отправки идентификатора пользователя для проверки подлинности MD5. |
| LocURI | Указывает адрес целевого или исходного расположения. Если адрес содержит небуквенно-цифровой символ, его необходимо правильно экранировать в соответствии со стандартом кодирования URL-адресов. |
| MsgID | Задает уникальный идентификатор для сообщения сеанса OMA DM. |
| MsgRef | Указывает идентификатор соответствующего сообщения запроса. |
| RespURI | Указывает универсальный код ресурса (URI), который получатель должен использовать при отправке ответа на это сообщение. |
| Sessionid | Указывает идентификатор сеанса OMA DM, связанного с содержащим сообщением. Примечание. |
| Источник | Указывает адрес источника сообщения. |
| SourceRef | Указывает источник соответствующего сообщения запроса. Этот элемент принимает значение элемента Source сообщения запроса и возвращается в элементе Status или Results. |
| Target | Указывает адрес узла в дереве DM, который является целевым объектом команды OMA DM. |
| TargetRef | Указывает целевой адрес в соответствующем сообщении запроса. Этот элемент принимает значение элемента target сообщения запроса и возвращается в элементе Status или Results. |
| VerDTD | Указывает основной и дополнительный идентификатор версии спецификации протокола представления OMA DM, используемого для представления сообщения. |
| VerProto | Указывает основной и дополнительный идентификаторы версий спецификации протокола OMA DM, используемой с сообщением. |
Сеанс управления устройствами
Сеанс Управление устройствами (DM) состоит из ряда команд, обменивается между сервером dm и клиентским устройством. Сервер отправляет команды, указывающие на операции, которые необходимо выполнить в дереве управления клиентского устройства. Клиент отвечает, отправляя команды, содержащие результаты и все запрошенные сведения о состоянии.
Короткий сеанс интеллектуальной работы можно свести к следующим значениям:
Сервер отправляет команду Get клиентскому устройству для получения содержимого одного из узлов дерева управления.
Устройство выполняет операцию и отвечает командой Result, содержащей запрошенное содержимое.
Сеанс dm можно разделить на два этапа:
- Этап установки. В ответ на событие триггера клиентское устройство отправляет инициирующее сообщение на сервер DM. Для обмена данными об устройстве и сервере требуется проверка подлинности и сведения об устройстве. Этот этап представлен шагами 1, 2 и 3 в следующей таблице.
- Этап управления. Сервер dm находится под контролем. Он отправляет на устройство команды управления, и устройство отвечает. Этап 2 завершается, когда сервер dm server прекращает отправку команд и завершает сеанс. Этот этап представлен шагами 3, 4 и 5 в следующей таблице.
В следующих сведениях показана последовательность событий во время типичного сеанса dm.
Клиент DM вызывается для обратного вызова сервера управления
Корпоративный сценарий. Расписание задач устройства вызывает клиент dm.
Mo-сервер отправляет сообщение триггера сервера для вызова клиента dm.
Сообщение триггера содержит идентификатор сервера и сообщает клиентскому устройству, что нужно инициировать сеанс с сервером. Клиентское устройство выполняет проверку подлинности сообщения триггера и проверяет, имеет ли сервер право взаимодействовать с ним.
Корпоративный сценарий. В запланированное время клиент DM периодически вызывается для обратного вызова сервера управления предприятия по протоколу HTTPS.
Устройство отправляет сообщение через IP-подключение для запуска сеанса.
Это сообщение содержит сведения об устройстве и учетные данные. Клиент и сервер выполняют взаимную проверку подлинности через SSL-канал или на уровне приложения dm.
Сервер интеллектуальной службы отвечает через IP-подключение (HTTPS). Сервер отправляет начальные команды управления устройствами, если таковые есть.
Устройство реагирует на команды управления сервером. Это сообщение содержит результаты выполнения указанных операций управления устройствами.
Сервер интеллектуальной службы завершает сеанс или отправляет другую команду. Сеанс интеллектуальной службы завершается или повторяется шаг 4.
Номера шагов не представляют идентификационные номера сообщений (MsgID). Все сообщения с сервера должны иметь уникальный идентификатор MsgID в рамках сеанса, начиная с 1 для первого сообщения и увеличиваясь на 1 для каждого дополнительного сообщения. Дополнительные сведения о протоколе MsgID и OMA SyncML см. в разделе Протокол представления Управление устройствами OMA (DM_RepPro-V1_2-20070209-A).
Во время взаимной проверки подлинности на уровне приложения OMA DM, если код отклика устройства на элемент Cred в серверном запросе равен 212, дальнейшая проверка подлинности не требуется для оставшейся части сеанса dm. Если выполняется проверка подлинности MD5, можно вернуть элемент Chal. Затем следующий nonce в Chal должен использоваться для дайджеста MD5 при запуске следующего сеанса dm.
Если запрос содержит учетные данные, а код ответа на запрос равен 200, эти же учетные данные должны быть отправлены в следующем запросе.
Если элемент Chal включен и требуется проверка подлинности MD5, создается новый дайджест с помощью следующего nonce через элемент Chal для следующего запроса.
Дополнительные сведения о проверке подлинности клиента Basic или MD5, проверке подлинности сервера MD5, хэсе MD5 и MD5 nonce см. в спецификации безопасности Управление устройствами OMA (OMA-TS-DM_Security-V1_2_1-20080617-A), обработке кода ответа проверки подлинности и пошаговые примеры в OMA Управление устройствами Спецификация протокола (OMA-TS-DM_Protocol-V1_2_1-20080617-A), доступная на веб-сайте OMA.
Целевая конфигурация для пользователей и устройств
Для поставщиков служб конфигурации и политик, поддерживающих конфигурацию каждого пользователя, сервер MDM может отправлять целевые значения параметров пользователя на устройство, на которое активно входит зарегистрированный в MDM пользователь. Устройство уведомляет сервер о состоянии входа с помощью оповещения устройства (1224) с типом оповещения = в DM pkg#1.
Часть данных этого оповещения может быть одной из следующих строк:
- Пользователь: пользователь, зарегистрировав устройство, активно вошел в систему. Сервер MDM может отправлять конфигурацию для конкретных пользователей для поставщиков служб или политик, поддерживающих конфигурацию каждого пользователя.
- Другие: вход другого пользователя, но у него нет учетной записи MDM. Сервер может применять только конфигурацию на уровне устройства, например, конфигурация применяется ко всем пользователям на устройстве.
- Нет: активный вход пользователя отсутствует. Сервер может применять только конфигурацию на уровне устройства, а доступная конфигурация ограничена средой устройства (без активного входа пользователя).
Ниже приведен пример оповещения:
<Alert>
<CmdID>1</CmdID>
<Data>1224</Data>
<Item>
<Meta>
<Type xmlns="syncml:metinf">com.microsoft/MDM/LoginStatus</Type>
<Format xmlns="syncml:metinf">chr</Format>
</Meta>
<Data>user</Data>
</Item>
</Alert>
Сервер уведомляет устройство о том, является ли оно конфигурацией, ориентированной на пользователя или устройством, с помощью префикса LocURL узла управления, с . для конфигурации, ориентированной на пользователей, или 
/user./device для конфигурации, ориентированной на устройство. По умолчанию, если нет префикса с ./device или ./user, это конфигурация, предназначенная для устройства.
В следующем LocURL показана конфигурация узла CSP для каждого пользователя: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall
В следующем LocURL показана конфигурация узла CSP для каждого устройства: ./device/vendor/MSFT/RemoteWipe/DoWipe
При использовании SyncML в OMA DM возвращаются стандартные коды состояния ответа. В следующей таблице перечислены распространенные коды состояния ответов SyncML, которые вы, вероятно, увидите. Дополнительные сведения о кодах состояния ответов SyncML см. в разделе 10 спецификации протокола представления SyncML .
| Код состояния | Описание |
|---|---|
| 200 | Команда SyncML успешно завершена. |
| 202 | Принято к обработке. Этот код обозначает асинхронную операцию, например запрос на выполнение удаленного выполнения приложения. |
| 212 | Проверка подлинности принята. Обычно этот код отображается только в ответ на элемент SyncHdr (используется для проверки подлинности в стандарте OMA-DM). Вы можете увидеть этот код, если посмотрите на журналы dm OMA, но поставщики служб конфигурации обычно не создают этот код. |
| 214 | Операция отменена. Команда SyncML успешно завершена, но больше команды не будут обрабатываться в сеансе. |
| 215 | Не выполняется. Команда не была выполнена в результате взаимодействия с пользователем для отмены команды. |
| 216 | Atomic откат ОК. Команда находилась внутри Atomic элемента и Atomic завершилась сбоем. Эта команда успешно выполнена. |
| 400 | Неправильный запрос. Не удалось выполнить запрошенную команду из-за неправильного синтаксиса. Поставщики служб конфигурации обычно не создают эту ошибку, однако вы можете увидеть ее, если ваш SyncML имеет неправильный формат. |
| 401 | Недопустимые учетные данные. Запрошенная команда завершилась ошибкой, так как инициатор запроса должен обеспечить правильную проверку подлинности. Поставщики служб конфигурации обычно не создают эту ошибку. |
| 403 | Запрещено. Запрошенная команда завершилась ошибкой, но получатель понял запрошенную команду. |
| 404 | Не найдено. Запрошенный целевой объект не найден. Этот код будет создан при запросе узла, который не существует. |
| 405 | Команда не разрешена. Этот код ответа будет создан при попытке выполнить запись на узел, доступный только для чтения. |
| 406 | Необязательная функция не поддерживается. Этот код ответа будет создан при попытке получить доступ к свойству, которое поставщик служб CSP не поддерживает. |
| 415 | Неподдерживаемый тип или формат. Этот код ответа может быть результатом ошибок синтаксического анализа или форматирования XML. |
| 418 | Уже существует. Этот код ответа возникает при попытке добавить узел, который уже существует. |
| 425 | Отказано в разрешении. Запрошенная команда завершилась ошибкой, так как у отправителя нет достаточных разрешений на управление доступом (ACL) для получателя. Ошибки «Доступ запрещен» обычно переводятся в этот код ответа. |
| 500 | Сбой команды. Универсальный сбой. Получатель столкнулся с непредвиденным условием, которое помешало ему выполнить запрос. Этот код ответа будет возникать, когда DPU SyncML не может сопоставить исходный код ошибки. |
| 507 | Atomic Сбой при. Сбой одной из операций в блоке Atomic . |
| 516 | Atomic Сбой отката. Операция Atomic завершилась сбоем, и команда не была успешно выполнена. |
Справочник по поставщикам служб конфигурации
Развертывание OMA-URIs для целевого CSP через Intune и сравнение с локальной средой — Intune
- Статья
- Чтение занимает 5 мин
В этой статье описывается значение поставщиков служб конфигурации Windows ( CSP), Open Mobile Alliance — uniform Resources (OMA-URIs) и доставки пользовательских политик на устройство на основе Windows 10 с Microsoft Intune.
Intune предоставляет удобный и простой в использовании интерфейс для настройки этих политик. Однако не все параметры обязательно доступны в Центре администрирования Microsoft Endpoint Manager. Хотя многие параметры могут быть потенциально настроены на устройстве с Windows, нецелесообразно иметь их все в Центре администрирования. Кроме того, по мере того как прогресс делается, это не редкость иметь определенную степень задержки, прежде чем новый параметр будет добавлен. В этих сценариях решением является развертывание пользовательского профиля OMA-URI, использующего поставщика служб конфигурации Windows (CSP).
Область CSP
Поставщики служб управления мобильными устройствами (MDM) — это интерфейс, используемый для чтения, установки, изменения и удаления параметров конфигурации на устройстве. Как правило, это делается с помощью разделов и значений в реестре Windows. Политики CSP имеют область, которая определяет уровень, на котором можно настроить политику. Это похоже на политики, доступные в Центре администрирования Microsoft Endpoint Manager.
Некоторые политики можно настроить только на уровне устройства. Эти политики применяются независимо от того, кто вошел в систему на устройстве. Другие политики можно настроить на уровне пользователя. Эти политики применяются только к такому пользователю. Уровень конфигурации определяется платформой, а не поставщиком MDM. При развертывании настраиваемой политики вы можете найти область CSP, которую вы хотите использовать.
Область CSP важна, так как она определяет синтаксис строки OMA-URI, которую следует использовать. Например:
Область пользователя
./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName для настройки политики. ./User/Vendor/MSFT/Policy/Result/AreaName/PolicyName, чтобы получить результат.
Область устройства
./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName для настройки политики. ./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName, чтобы получить результат.
OMA-URIs
OMA-URI — это путь к определенному параметру конфигурации, поддерживаемому CSP.
OMA-URI. Это строка, представляющая настраиваемую конфигурацию для устройства на основе Windows 10. Синтаксис определяется поставщиками служб конфигурации на клиенте. Подробные сведения о каждом поставщике служб CSP можно найти здесь.
Настраиваемая политика: она содержит OMA-URIs для развертывания. Он настроен в Intune.
Intune. После создания и назначения настраиваемой политики клиентским устройствам Intune становится механизмом доставки, который отправляет OMA-URIs этим клиентам Windows. Intune использует для этого протокол Open Mobile Alliance Управление устройствами (OMA-DM). Это предварительно определенный стандарт, который использует SyncML на основе XML для отправки информации клиенту.
Поставщики служб конфигурации. После того как OMA-URIs достигнут клиента, поставщик служб CSP считывает их и настраивает платформу Windows соответствующим образом. Как правило, это делается путем добавления, чтения или изменения значений реестра.
Подводя итоги: OMA-URI — это полезные данные, настраиваемая политика — контейнер, Intune — механизм доставки для этого контейнера, OMA-DM — это протокол, используемый для доставки, а поставщик CSP Windows считывает и применяет параметры, настроенные в полезных данных OMA-URI.
Это тот же процесс, который используется Intune для доставки стандартных политик конфигурации устройств, которые уже встроены в пользовательский интерфейс. Когда OMA-URIs используют пользовательский интерфейс Intune, они скрыты за удобными интерфейсами конфигурации. Это делает процесс более простым и интуитивно понятным для администратора. По возможности используйте встроенные параметры политики и используйте настраиваемые политики OMA-URI только для параметров, которые в противном случае недоступны.
Чтобы продемонстрировать этот процесс, можно использовать встроенную политику, чтобы задать изображение экрана блокировки на устройстве. Вы также можете развернуть OMA-URI и нацелить соответствующий поставщик служб CSP.
Оба метода достигают одного и того же результата.
OMA-URIs из Центра администрирования Microsoft Endpoint Manager
Использование настраиваемой политики
Этот же параметр можно задать напрямую с помощью следующего OMA-URI:
./Vendor/MSFT/Policy/Config/DeviceLock/EnforceLockScreenAndLogonImage
Это описано в справочнике по windows CSP. Определив OMA-URI, создайте для него настраиваемую политику.
Независимо от того, какой метод вы используете, конечный результат будет идентичным.
Вот еще один пример использования BitLocker.
Использование настраиваемой политики из Центра администрирования Microsoft Endpoint Manager
Использование настраиваемой политики
Связывание пользовательских OMA-URIs с локальным миром
Существующие параметры групповая политика можно использовать в качестве справки при создании конфигурации политики MDM. Если ваша организация хочет перейти на MDM для управления устройствами, рекомендуется подготовиться, проанализировав текущие параметры групповая политика, чтобы узнать, что необходимо для перехода на управление MDM.
Средство анализа миграции MDM (MMAT) определяет, какие групповые политики были заданы для целевого пользователя или компьютера. Затем создается отчет с уровнем поддержки каждого параметра политики в эквивалентах MDM.
Аспекты групповая политика до и после миграции в облако
В следующей таблице показаны различные аспекты групповая политика как до, так и после миграции в облако с помощью MMAT.
| Локальная архитектура | Облако |
|---|---|
| Групповая политика | MDM |
| Контроллеры домена | Сервер MDM (служба Intune) |
| Папка Sysvol | Intune базы данных и MSU |
| Расширение на стороне клиента для обработки объекта групповой политики | Поставщики служб конфигурации для обработки политики MDM |
| Протокол SMB, используемый для обмена данными | Протокол HTTPS, используемый для обмена данными |
.pol | . файл (обычно это входные данные) | SyncML — это входные данные для устройств. |
iniВажные заметки о поведении политики
Если политика меняется на сервере MDM, обновленная политика передается на устройство, а параметр настраивается на новое значение. Однако при удалении назначения политики с пользователя или устройства может не вернуться к значению по умолчанию. Существует несколько профилей, которые удаляются после удаления назначения или удаления профиля, таких как профили Wi-Fi, профили VPN, профили сертификатов и профили электронной почты. Так как это поведение контролируется каждым поставщиком служб CSP, необходимо попытаться понять поведение CSP, чтобы правильно управлять параметрами. Дополнительные сведения см. в справочнике по windows CSP.
Сложите все вместе
Чтобы развернуть пользовательский OMA-URI для целевого CSP на устройстве Windows, создайте настраиваемую политику. Политика должна содержать путь к пути OMA-URI вместе со значением, которое требуется изменить в CSP (включить, отключить, изменить или удалить).
После создания политики назначьте ее группе безопасности, чтобы она действовала.
Устранение неполадок
При устранении неполадок с пользовательскими политиками вы обнаружите, что большинство проблем относится к следующим категориям:
- Пользовательская политика не достигла клиентского устройства.
- Пользовательская политика достигла клиентского устройства, но ожидаемое поведение не наблюдается.
Если у вас есть политика, которая работает неправильно, проверьте, достигла ли она клиента. Существует два журнала, которые необходимо проверить для проверки доставки.
Журналы диагностики MDM
Журнал событий Windows
Оба журнала должны содержать ссылку на настраиваемую политику или параметр OMA-URI, который вы пытаетесь развернуть. Если вы не видите эту ссылку, скорее всего, политика не была доставлена на устройство. Убедитесь, что политика настроена правильно и нацелена на правильную группу.
Если вы убедитесь, что политика достигает клиента, проверьте DeviceManagement-Enterprise-Diagnostics-Provider > Admin Event log на наличие ошибок в клиенте.
Вы можете увидеть запись об ошибке, содержащую дополнительные сведения о том, почему политика не применяется. Причины могут различаться, но часто возникает проблема в синтаксисе строки OMA-URI, настроенной в настраиваемой политике. Проверьте ссылку на CSP и убедитесь, что синтаксис правильный.
ОМА — АЭРОКОСМИЧЕСКАЯ ГРУППА
ГОРДИМСЯ СОЗДАВАТЬ БУДУЩЕЕ
прокрутить вниз
Откройте для себя продукты
Службы обнаружения
Службы обнаружения
ПРОГРАММЫ Программы обороны — Коммерческие программы ПРОГРАММЫ Горжусь тем, что создаюлетать в будущее Сертификаты
посмотреть все
СВЯЖИТЕСЬ С НАМИ
Пожалуйста, заполните быструю форму
Оставьте это поле пустым
AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntarcticaAntigua & BarbudaArgentinaArmeniaArubaAustraliaAustriaAzerbaijanBahamaBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBouvet IslandBrazilBritish Indian Ocean TerritoryBritish Virgin IslandsBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaChristmas IslandCocos (Keeling) IslandsColombiaComorosCongoCook IislandsCosta RicaCôte D’ivoire (Ivory Coast)CroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFalkland Islands (Malvinas)Faroe IslandsFijiFinlandFrance, MetropolitanFranceFrench GuianaFrench PolynesiaFrench Southern ТерриторииГабонГамбияГрузияГерманияГанаГибралтарГрецияГренландияГренадаГваделупаГуамГватемалаГвинеяГвинея-БиссауГайанаГаитиОстрва Херд и МакдональдГондурасГонконгВенгрияИсландия IndiaIndonesiaIraqIrelandIslamic Republic of IranIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiKorea, Democratic People’s Republic ofKorea, Republic ofKuwaitKyrgyzstanLao People’s Democratic RepublicLatviaLebanonLesothoLiberiaLibyan Arab JamahiriyaLiechtensteinLithuaniaLuxembourgMacauMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesiaMoldova, Republic ofMonacoMongoliaMonserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlands AntillesNetherlandsNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorthern Mariana IslandsNorwayOmanPakistanPalauPanamaPapua New GuineaParaguayPeruPhilippinesPitcairnPolandPortugalPuerto RicoQatarRéunionRomaniaRussian FederationRwandaSaint LuciaSamoaSan MarinoSao Tome & PrincipeSaudi ArabiaSenegalSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSouth Georgia and the South Sandwich IslandsSpainSri LankaSt.
