A hardware management error has occurred trying to contact server

При развёртывании очередного агента System Center 2016 VMM на новых хостах виртуализации Hyper-V на базе Windows Server 2016 столкнулись с проблемой невозможности установки агента с консоли управления VMM. Несколько предпринятых попыток установки завершалась ошибкой 2927 следующего вида (в локализованном варианте консоли VMM):

Ошибка (2927)
При попытке связаться с сервером SCVMM1.holding.com произошла ошибка управления оборудованием: : .

WinRM: URL: [http://scvmm01.holding.com:5985], Verb: [INVOKE], Method: [AddPeerCertificate], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/AgentManagement]

Unknown error (0x80338113)

Рекомендуемое действие
Убедитесь, что на сервере SCVMM01.holding.com установлена и запущена служба WinRM. Дополнительные сведения можно получить с помощью команды "winrm helpmsg hresult" и в статье http://support.microsoft.com/kb/2742275.

Из текста ошибки понятно, что на сервере VMM возникли проблемы с работой WinRM.

Для первичной диагностики проблемы можем воспользоваться статьёй, на которую ссылается текст ошибки: «Troubleshoot issues when you add a Hyper-V host in Virtual Machine Manager». В числе проверок, в первую очередь, убедимся в том, что не блокируется порт WinRM (TCP 5985) на стороне сервера VMM.

Однако, в нашем случае проблема была явно в чём-то другом, так как ещё недавно развёртывание агентов VMM работало без ошибок. Перейдя на сервер VMM, проверяем состояние текущей конфигурации WinRM.

winrm quickconfig
winrm enumerate winrm/config/listener

Первая команда выполняет быструю конфигурацию службы, если она ещё не была включена и настроена ранее. Вторая команда показывает текущее состояние TCP-прослушивателя WinRM.

Как видно в нашем примере, служба WinRM уже запущена и настроена. При этом обращаем внимание на то, что источником конфигурации являются групповые политики домена. Выполним команду просмотра общей конфигурации WinRM и обратим внимание на то, как настроены IP-фильтры для удалённого подключения:

winrm get winrm/config

Как видим, IPv4Filter настроен в групповой политике как «*«, то есть подключение к WinRM разрешено с любых хостов. При этом IPv6Filter также идёт из GPO, но не задан. Казалось бы мелочь, но мелочь с точки зрения VMM важная.

Если обратимся к старой статье из архива блога VMM «SC VMM 2012 RC: Understanding the Hyper-V host addition operation if Window Remote Management (WinRM) is configured using Group Policy (GPO) settings», то обнаружим то, что для корректной работы VMM при условии настройки WinRM через GPO, требуется обращать внимание на три параметра в разделе административных шаблонов GPO Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service:

1. Allow automatic configuration of listeners
2. Turn on Compatibility HTTP Listener
3. Turn on Compatibility HTTPS Listener

Первый параметр в современных версиях административных шаблонов звучит несколько иначе «Allow remote server management through WinRM«.

При этом в выше упомянутой статье есть отдельное замечание о том, как должен быть настроен этот самый первый параметр GPO:

If «Automatic configuration of listeners» is enabled, it’s important that the IPv4 and IPv6 filter is set to *.

Ну и вот, как выяснилось в нашем случае, администратор домена, настраивающий GPO, включил IP-фильтрацию для IPv4, но не задал аналогичной настройки для IPv6.

Откорректируем эту политику с учётом выше обозначенного замечания:

Применим новые параметры GPO на сервере VMM и снова проверим общую конфигурацию WinRM:

gpupdate
winrm get winrm/config

Не смотря на то, что на сервере VMM у нас в явном виде не используется протокол IPv6, выполненное изменение GPO привело к тому, что развёртывание агентов VMM стало работать в штатном режиме и ранее описанная ошибка исчезла. При этом параметры GPO «Turn on Compatibility HTTP Listener» и «Turn on Compatibility HTTPS Listener» для дополнительной активации TCP-прослушивателей WinRM на портах 80 и 443 мы в своей конфигурации не использовали.

Ошибка WinRM при установке агента System Center 2016 VMM «Error (2927) A Hardware Management error has occurred trying to contact server . Unknown error (0x80338113)»

При развёртывании очередного агента System Center 2016 VMM на новых хостах виртуализации Hyper-V на базе Windows Server 2016 столкнулись с проблемой невозможности установки агента с консоли управления VMM. Несколько предпринятых попыток установки завершалась ошибкой 2927 следующего вида (в локализованном варианте консоли VMM):

Из текста ошибки понятно, что на сервере VMM возникли проблемы с работой WinRM.

Для первичной диагностики проблемы можем воспользоваться статьёй, на которую ссылается текст ошибки: «Troubleshoot issues when you add a Hyper-V host in Virtual Machine Manager». В числе проверок, в первую очередь, убедимся в том, что не блокируется порт WinRM (TCP 5985) на стороне сервера VMM.

Однако, в нашем случае проблема была явно в чём-то другом, так как ещё недавно развёртывание агентов VMM работало без ошибок. Перейдя на сервер VMM, проверяем состояние текущей конфигурации WinRM.

Первая команда выполняет быструю конфигурацию службы, если она ещё не была включена и настроена ранее. Вторая команда показывает текущее состояние TCP-прослушивателя WinRM.

Как видно в нашем примере, служба WinRM уже запущена и настроена. При этом обращаем внимание на то, что источником конфигурации являются групповые политики домена. Выполним команду просмотра общей конфигурации WinRM и обратим внимание на то, как настроены IP-фильтры для удалённого подключения:

Как видим, IPv4Filter настроен в групповой политике как » * «, то есть подключение к WinRM разрешено с любых хостов. При этом IPv6Filter также идёт из GPO, но не задан. Казалось бы мелочь, но мелочь с точки зрения VMM важная.

Если обратимся к старой статье из архива блога VMM «SC VMM 2012 RC: Understanding the Hyper-V host addition operation if Window Remote Management (WinRM) is configured using Group Policy (GPO) settings», то обнаружим то, что для корректной работы VMM при условии настройки WinRM через GPO, требуется обращать внимание на три параметра в разделе административных шаблонов GPO Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service:

1. Allow automatic configuration of listeners
2. Turn on Compatibility HTTP Listener
3. Turn on Compatibility HTTPS Listener

Первый параметр в современных версиях административных шаблонов звучит несколько иначе «Allow remote server management through WinRM«.

При этом в выше упомянутой статье есть отдельное замечание о том, как должен быть настроен этот самый первый параметр GPO:

If «Automatic configuration of listeners» is enabled, it’s important that the IPv4 and IPv6 filter is set to *.

Ну и вот, как выяснилось в нашем случае, администратор домена, настраивающий GPO, включил IP-фильтрацию для IPv4, но не задал аналогичной настройки для IPv6.

Откорректируем эту политику с учётом выше обозначенного замечания:

Применим новые параметры GPO на сервере VMM и снова проверим общую конфигурацию WinRM:

Не смотря на то, что на сервере VMM у нас в явном виде не используется протокол IPv6, выполненное изменение GPO привело к тому, что развёртывание агентов VMM стало работать в штатном режиме и ранее описанная ошибка исчезла. При этом параметры GPO «Turn on Compatibility HTTP Listener» и «Turn on Compatibility HTTPS Listener» для дополнительной активации TCP-прослушивателей WinRM на портах 80 и 443 мы в своей конфигурации не использовали.

Источник

Veeam R&D Forums

Technical discussions about Veeam products and related data center technologies

Failed to send certificate, but certificate is required for remote agent management

Failed to send certificate, but certificate is required for remote agent management

Post by psych » Apr 17, 2020 1:05 pm 1 person likes this post

What kind of certificate it wants? I have two more linux machines properly running with Veeam Agent installed. Also I have tried to renew Veeam certificate, but it doesnt work. Attaching photo of error

Re: Failed to send certificate, but certificate is required for remote agent management

Post by Egor Yakovlev » Apr 17, 2020 1:39 pm this post

Re: Failed to send certificate, but certificate is required for remote agent management

Post by psych » Apr 17, 2020 3:26 pm this post

Re: Failed to send certificate, but certificate is required for remote agent management

Post by Egor Yakovlev » Apr 17, 2020 5:28 pm this post

Can you also check Veeam Certificates:

— on VBR Server (Type ‘Manage User Cert’ into the search of the Windows start menu. Select the ‘Trusted Root Certificate’ folder, then the ‘Certificate’ folder and scroll down to the Veeam Backup & Replication certificate)
— on Windows Server (Type ‘MMC’ into the search of the Windows start menu. Once open, select ‘File > Add plugins’ , then select ‘Local Account’, ‘Certificate > Add’. Then ‘Certificates’ folder, and ‘Personal’)

Both certificates should share the expiration date. If they are different, delete one from Windows Server and rescan agent from VBR Console again.Thanks!

Re: Failed to send certificate, but certificate is required for remote agent management

Post by psych » Apr 23, 2020 11:25 am this post

Re: Failed to send certificate, but certificate is required for remote agent management

Post by Egor Yakovlev » Apr 23, 2020 1:06 pm 1 person likes this post

Here are 2 more checks for you:

— On your Windows Server, check «netstat -b» if you have anything but Veeam is listening on local port :6184. If some app took our default communications port, we will work over next one, 6185, which will need a firewall allow rule as well.
— Last but not least, check local policies under «Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options» on both servers(Windows agent + VBR). Following keys should be in NotConfiguredAllowAll state: [Network security: LAN Manager authentication level], [Restrict NTLM: Incoming traffic], [Restrict NTLM: Outgoing traffic].

Re: Failed to send certificate, but certificate is required for remote agent management

Post by psych » Apr 24, 2020 1:14 pm this post

Источник

Veeam R&D Forums

Technical discussions about Veeam products and related data center technologies

Failed to send certificate, but certificate is required for remote agent management Error: No authority could be contact

Failed to send certificate, but certificate is required for remote agent management Error: No authority could be contact

Post by govi » Jul 10, 2019 7:53 am this post

Trying to deploy Veeam Agent through Veeam B&R Server and i m getting below error message

Failed to send certificate, but certificate is required for remote agent management Error: No authority could be contacted for authentication.

any clue with above error.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by wishr » Jul 10, 2019 8:46 am this post

As usual, please reach out to our technical support team directly for advanced troubleshooting and post your support case ID for our and forum community members reference.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by govi » Jul 16, 2019 5:43 am this post

Case number #03659676. All relevant logs already provided to support team. Waiting for reply.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by TimoW » Jul 18, 2019 10:00 am this post

Hi Govi,
just having exactly the same issue. Any progress or solution with support?

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by wishr » Jul 18, 2019 10:17 am this post

Could you please check if it works under Local Admin? This has resolved the initial issue reported by Govi. As of now, our engineers requested a remote session to take a look at another difficulty related to rescan.

It feels like the root cause is environment-specific, but it’s, of course, better to wait until we’ll have all the pieces of evidence in place.

I’d suggest you raise a separate support case in parallel since it’s the fastest way to get a proper solution.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by TimoW » Jul 18, 2019 11:20 am 1 person likes this post

Hi Fedor,
I’ve checked it with a local admin account configured at the credentials page on the protection group but got no success.
Unfortunately the user needs to take away his notebook to a meeting . now.
As for now it looks like that only one notebook have this issue. I’ll more dig into the problem asap.
And yes, as soon as I can tell something more than «it does not work» I’ll raise a support ticket.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by govi » Jul 18, 2019 11:51 am this post

for me after updating with local account this particular issue got fixed but encountered new issue where in scan shows old IP address of VAW. Meaning DHCP lease IP address which was assign by DHCP server when i deployed veeam agent. Today DCHP assinged different IP address to that laptop and new IP is not getting updated in veeam console and for some reason it was not able to access Admin$ share as well . We started netlogon or network logon services.

Was able to access Admin$ share from veeam server but still we faced issue with scanning veeam agent.

Support person has collected few logs from server and hopefully we should have answer to our problem.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by mlavie » Sep 20, 2019 3:24 pm this post

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by wishr » Sep 23, 2019 1:17 pm this post

As far as I see from Govi’s case, the initial issue has been resolved using an account with the required permissions (not sure, how the second issue has been resolved, though). I’d suggest you go ahead and open a separate case if you’ve encountered something similar.

Re: Failed to send certificate, but certificate is required for remote agent management Error: No authority could be con

Post by govi » Sep 23, 2019 1:22 pm 1 person likes this post

Just check if laptop and servers resolves IP address correctly(should resolve IP to IPv4 only) and check if server can access $admin share correctly using credentials used on veeam backup server.

That’s what i remember we had done during remote session with veeam support.

Who is online

Users browsing this forum: No registered users and 18 guests

• Main
• All times are UTC
• Delete cookies
• Members
• The team
• Contact us

DISCLAIMER: All feature and release plans are subject to change without notice.

Powered by phpBB® Forum Software © phpBB Limited

Источник

Remote management agent error

Error 1603 is a Windows error that can be displayed for a number of reasons. In many cases, this issue can be resolved by restarting your computer. Continue reading for additional steps to resolve this error, depending on what is displayed.

Error 1603 during a local installation of the ESET Management Agent

If you are running ESET Live Installer from a shared location, copy the live installer file to the local disk and attempt the installation again.

When you run the ESET Management Agent Live installer, right-click it and select Run as Administrator from the context menu.

Error 1603 during a push (remote) installation of the ESET Management Agent

Uninstall all other antivirus products before installing ESET and remove all files, folders and registry keys left by any previous antivirus products.

Verify that the Base Filtering engine is present and running on your target client workstation(s) (Windows 7 only).

Disable the Windows Firewall on the server and client workstation. After installation, you can re-enable the firewall. See the Microsoft Knowledgebase article for instructions to disable the Windows Firewall.

Verify that the system drive on the target client workstation(s) has enough free disk space for the installation.

If after following the steps above you are unable to push install due to the same error code, create a preconfigured Agent Live Installer file and try to install it locally.

Error 1603 during a push (remote) uninstallation of the ESET Management Agent

Verify that you have included the necessary credentials with your push uninstallation package.

Error 1603 during ESET PROTECT Cloud Live Install or ESET PROTECT Live All-in-One Install

If the endpoint is a Windows 7 machine, verify the latest Windows updates are installed.

Error 1603 in ESET Security Management Center

ESET business product no longer supported

This content applies to an ESET product version that is currently in End of Life status and is no longer supported. This content is no longer updated.

For a complete list of supported products and support level definitions, review the ESET End of Life policy for business products.

Error 1603 when installing the ESET Management Agent

1. If you are running ESET Live Installer from a shared location, copy the live installer file to the local disk and attempt installation again.

When you run the ESET Management Agent Live installer, right-click it and select Run as Administrator from the context menu.

Error 1603 during a push (remote) installation

Uninstall all other antivirus products before installing ESET and remove all files, folders and registry keys left by any previous antivirus products.

Disable the Windows Firewall on the server and client workstation. After installation, you can re-enable the firewall. See the Microsoft Knowledge Base article for instructions to disable the Windows Firewall.

Verify that the system drive on the target client workstations has enough free disk space for the installation.

If after following the steps above you are unable to push install due to the same error code, create a preconfigured install file and try to install it locally.

Error 1603 during a push (remote) uninstallation

Error 1603 in ESET Remote Administrator

ESET business product no longer supported

This content applies to an ESET product version that is currently in End of Life status and is no longer supported. This content is no longer updated.

For a complete list of supported products and support level definitions, review the ESET End of Life policy for business products.

Error 1603 when installing the ERA Agent

1. If you are running ESET Live Installer from a shared location, copy the live installer file to the local disk and attempt installation again.

When you run the ERA Agent Live installer, right-click it and select Run as Administrator from the context menu.

Error 1603 during a push (remote) installation

1. Verify that you have completed each step in the ESET Remote Administrator Push Installation Requirements and Checklist.
2. Uninstall all other antivirus products before installing ESET and remove all files, folders and registry keys left by any previous antivirus products.

Verify that the Base Filtering engine is present and running (Windows 7 and Vista only) on your target client workstations.

Disable the Windows Firewall on the server and client workstation. After installation, you can re-enable the firewall. See the Microsoft Knowledge Base article for instructions to disable the Windows Firewall.

Verify that the system drive on the target client workstations has enough free disk space for the installation.

Download a new copy of your ESET product and create a new push install package.

If after following the steps above you are unable to push install due to the same error code, create a preconfigured install file and try to install it locally.

Источник

First published on TECHNET on Jan 31, 2012

Here’s a new Knowledge Base article we published today that applies to both VMM 2008 and VMM 2012. This one talks about an error you can get when trying to add a Host or Cluster to System Center Virtual Machine Manager:

=====

Symptoms

Adding a Hyper-V Host or Cluster to a System Center Virtual Machine Manager (SCVMM) server generates the following error message:

Error (2927)






A Hardware Management error has occurred trying to contact server <FQDN_Name>.





(Unknown error (



0x803380e4



))










Recommended Action





Check that WinRM is installed and running on server

<FQDN_Name>

. For more information use the command «winrm helpmsg hresult».

Cause

This can occur when the WinRM Trusthost policy of the SCVMM server is set to blank. The default is

TrustedHosts = *

. To determine the WinRm Trusthost setting, run the following command on the SCVMM server from an elevated command prompt:

winrm g winrm/config

Here is a snippet from a Host where the WinRM Trusthost policy is set to blank:





DefaultPorts





HTTP = 5985





HTTPS = 5986





TrustedHosts





Service





RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

Here is a snippet from a Host where the WinRM Trusthost policy is set to the default setting:

DefaultPorts





HTTP = 5985





HTTPS = 5986





TrustedHosts = *





Service





RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-21-2210657229-244641257.

Resolution

To resolve this issue, run the following command from an elevated command prompt with Administrative rights on the SCVMM server:

winrm/config/client @{TrustedHosts=»*»}

More Information

The issue described above can be created by deploying a Windows Remote Management (WinRM) AD Group Policy and then removing it, leaving the server in an unknown state once the policy is removed.

GP Policy vs. Preference vs. GP preferences:

http://blogs.technet.com/b/grouppolicy/archive/2008/03/04/gp-policy-vs-preference-vs-gp-prefere…

Local Group policy setting found running gpedit.msc:

Local Computer Policy -> Computer Configuration -> Administrative Templates ->Windows Components -> Windows Remote Management (WinRM) -> WinRM Client

=====

For the most current version of this article please see the following:

2668596 : Error (2927) — (Unknown error (0x803380e4)) when trying to add a Host or Cluster to S…

J.C. Hornbeck


| System Center & Security Knowledge Engineer

Get the latest System Center news on

Facebook

and

Twitter

:

App-V Team blog:

http://blogs.technet.com/appv/

AVIcode Team blog:

http://blogs.technet.com/b/avicode

ConfigMgr Support Team blog:

http://blogs.technet.com/configurationmgr/

DPM Team blog:

http://blogs.technet.com/dpm/

MED-V Team blog:

http://blogs.technet.com/medv/

OOB Support Team blog:

http://blogs.technet.com/oob/

Opalis Team blog:

http://blogs.technet.com/opalis

Orchestrator Support Team blog:

http://blogs.technet.com/b/orchestrator/

OpsMgr Support Team blog:

http://blogs.technet.com/operationsmgr/

SCMDM Support Team blog:

http://blogs.technet.com/mdm/

SCVMM Team blog:

http://blogs.technet.com/scvmm

Server App-V Team blog:

http://blogs.technet.com/b/serverappv

Service Manager Team blog:

http://blogs.technet.com/b/servicemanager

System Center Essentials Team blog:

http://blogs.technet.com/b/systemcenteressentials

WSUS Support Team blog:

http://blogs.technet.com/sus/

The Forefront Server Protection blog:

http://blogs.technet.com/b/fss/

The Forefront Identity Manager blog :

http://blogs.msdn.com/b/ms-identity-support/

The Forefront TMG blog:

http://blogs.technet.com/b/isablog/

The Forefront UAG blog:

http://blogs.technet.com/b/edgeaccessblog/

Skip to content

UPDATE 1/31/2013
I strongly suggest that you uninstall the SC 2012 VMM SP1 Beta DHCP and agents on the VMM hosts before upgrading to SP1 from SP1 Beta.  In my lab there were too much inconstancies with VMM reporting older agents, not reporting older agents, the error below, and having leftover old versions of the DHCP server agent.  Basically don’t trust the VMM console to reliably notify and upgrade the agents from SP1 Beta to SP1.  Remove the agents and install them again at the SP1 version level. 

Last week I upgraded/refreshed my lab from System Center Beta SP1 to SP1.  Today while creating a virtual machine I kept running into an error in VMM.  Below is the text of the error and the screenshot. 

Error (2927)
A Hardware Management error has occurred trying to contact server host2.lab.local.

WinRM: URL: [http://host2.lab.local:5985], Verb: [ENUMERATE], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/virtualization/v2/Msvm_VirtualSystemManagementService], Filter: []

Unknown error (0x8033800f)

Recommended Action
Check that WinRM is installed and running on server host2.lab.local. For more information use the command «winrm helpmsg hresult».

I completely forgot to upgrade the VMM agent on my hosts and I think that was the problem.  Below is the text and screenshots when looking at the host’s health status in VMM.

Warning (20510)
An upgrade is available for Virtual Machine Manager agent version 3.1.3612.0 on the computer host1.lab.local.

Recommended Action
Update the VMM agent, and then try the operation again.

Updating the host agent is as simple as clicking repair all, supplying the run as account, and waiting. 

You’ll now see that the version went from 3.1.3612.0(Beta SP1) to 3.1.6011.0(SP1)

Now I’m able to create VMs without any error messages!