Avevamo capito prima di procederre cosa fosse successo alle due macchine ma quella spiegazione \u00e8 fuori dall’obbiettivo di questo post che si incentra su come poter recuperare velocemente da quella situazione.<\/div>\n\n\n\n
Qualche giorno fa abbiamo riscontrato uno strano problema su un paio di server dopo avere aggiornato gli agent di Acronis. La console non consentirva pi\u00f9 l’esecuzione del piano di backup, sia in modo automatico che manuale, segnalando che l’agent non era pi\u00f9 registrato. Sembrava molto strano visto che avevamo effettuato aggiornamenti degli agent diverse volte in passato senza riscontrare alcun problema ma questa volta gli agent non riuscivano pi\u00f9 a registrarsi. <\/p>\n\n\n\n
In realt\u00e0 nello stesso ciclo di aggiornamenti avevamo avuto altri due problemi su macchine Linux ma questi erano spariti riavviando i due server. Inoltre, avevamo notato che i due server che presentavano questo problema erano installazioni di Windows Server Core che ospitavano SQL Server. Abbiamo quindi deciso di registrare nuovamente gli agent manualmente ma sorprendentemente non era possibile perch\u00e8 l’agent si lamentava del fatto che il certificato dell’endpoint non fosse valido. Anzi, in maniera pi\u00f9 specifica, che la Certification Authority fosse sconosciuta.<\/p>\n\n\n\n
Quei due server funzionavano correttamente prima dell’aggiornamento e, cosa ancora pi\u00f9 strana, sembrava che non fossimo in grado di registrare gli agent nemmeno usando l’endpoint di Acronis invece che il nostro endpoint specifico. Stesso errore. Se era possibile, anche se improbabile, che il nostro endpoint usasse un certificato che causava problemi – anche se funzionava correttamente con le altre macchine e nei browser – non era possibile che ci fosse qualche problema con quello di Acronis.<\/p>\n\n\n\n
Aggiornamento autorit\u00e0 di root<\/h4>\n\n\n\n
L’errore riportato dall’agent era abbastanza indicativo ma noi avevamo problemi a collegarci agli endpoint anche in modo standard, usando per esempio Powershell<\/p>\n\n\n\n
Invoke-WebRequest -UseBasicParsing -Uri https:\/\/cloud.acronis.com<\/code><\/pre>\n\n\n\nC’era sicuramente un problema con le connessioni SSL. Anche se PowerShell restituiva un errore generico sull’impossibilit\u00e0 di completare la connessione, l’agent di Acronis riportava un errore di molto pi\u00f9 specifico per il quale abbiamo deciso di aggiornare i certificati di root sulla macchina:<\/p>\n\n\n\n
md C:\\Temp\ncd C:\\Temp\n# Scarica TUTTI i certificati di root da Windows Update\ncertutil.exe -generateSSTFromWU roots.sst\n# Importa TUTTI i certificati nello store delle autorit\u00e0 di root\n$sstContainer = (Get-ChildItem -Path C:\\temp\\roots.sst)\n$sstContainer | Import-Certificate -CertStoreLocation Cert:\\LocalMachine\\Root<\/code><\/pre>\n\n\n\nDopo aver lanciato questo questi comandi sar\u00e0 necessario riavviare la macchina per consentirle di ricaricare tutti i certificati.<\/p>\n\n\n\n
Problemi di cifratura<\/h4>\n\n\n\nQuesto non ha risolto il problema di per s\u00e8. Quando la macchina \u00e8 tornata online le connessioni agli endpoint di Acronis continuavano a non riuscire anche se con un errore diverso da parte dell’agent e lo stesso errore da parte di Powershell. Abbiamo quindi deciso di verificare meglio se fosse un problema di cifratura e di forzare le connessioni TLS1.2 in Powershell usando:<\/p>\n\n\n\n
# Forza PowerShell ad usare TLS1.2\n[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12<\/code><\/pre>\n\n\n\nOvviamente devi ricordare di non chiudere la sessione o perderai l’impostazione effettuata e dovrai applicarla di nuovo. Un altro tentativo di connessione ai nostri endpoint e … bingo! Ora tutto funzionava correttamente! <\/p>\n\n\n\n
PS C:\\temp> Invoke-WebRequest -UseBasicParsing -Uri https:\/\/backup.vaisulweb.cloud                          \n\nStatusCode        : 200\nStatusDescription : OK\nContent           : <!DOCTYPE html><html lang=en><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible\n                    content=\"IE=edge\"><meta name=viewport content=\"width=device-width,initial-scale=1\"><meta\n                    name=referrer content=o...\nRawContent        : HTTP\/1.1 200 OK\n                    Connection: keep-alive\n                    Vary: Accept-Encoding\n                    X-Frame-Options: DENY,SAMEORIGIN\n                    Access-Control-Allow-Credentials: true\n                    Access-Control-Expose-Headers: ETag,Content-Length,Content-Typ...\nForms             :\nHeaders           : {[Connection, keep-alive], [Vary, Accept-Encoding], [X-Frame-Options, DENY,SAMEORIGIN],\n                    [Access-Control-Allow-Credentials, true]...}\nImages            : {}\nInputFields       : {}\nLinks             : {}\nParsedHtml        :\nRawContentLength  : 570<\/code><\/pre>\n\n\n\nQuindi avevamo due problemi separati. Abbiamo riprovato a registrare nuovamente l’agent:<\/p>\n\n\n\n
register_agent.exe -o register -t cloud -a https:\/\/cloud.acronis.com -u <account> -p <password><\/code><\/pre>\n\n\n\ned ora tutto funzionava correttamente! Whoa! I piani di backup hanno ripreso a funzionare senza problemi. Speriamo che questo post sia utile anche a qualcuno di voi !<\/p>\n","protected":false,"raw":"\n[alert variation=\"alert-info\"]Avevamo capito prima di procederre cosa fosse successo alle due macchine ma quella spiegazione \u00e8 fuori dall'obbiettivo di questo post che si incentra su come poter recuperare velocemente da quella situazione.[\/alert]\n\n\n\n
Qualche giorno fa abbiamo riscontrato uno strano problema su un paio di server dopo avere aggiornato gli agent di Acronis. La console non consentirva pi\u00f9 l'esecuzione del piano di backup, sia in modo automatico che manuale, segnalando che l'agent non era pi\u00f9 registrato. Sembrava molto strano visto che avevamo effettuato aggiornamenti degli agent diverse volte in passato senza riscontrare alcun problema ma questa volta gli agent non riuscivano pi\u00f9 a registrarsi. <\/p>\n\n\n\n
In realt\u00e0 nello stesso ciclo di aggiornamenti avevamo avuto altri due problemi su macchine Linux ma questi erano spariti riavviando i due server. Inoltre, avevamo notato che i due server che presentavano questo problema erano installazioni di Windows Server Core che ospitavano SQL Server. Abbiamo quindi deciso di registrare nuovamente gli agent manualmente ma sorprendentemente non era possibile perch\u00e8 l'agent si lamentava del fatto che il certificato dell'endpoint non fosse valido. Anzi, in maniera pi\u00f9 specifica, che la Certification Authority fosse sconosciuta.<\/p>\n\n\n\n
Quei due server funzionavano correttamente prima dell'aggiornamento e, cosa ancora pi\u00f9 strana, sembrava che non fossimo in grado di registrare gli agent nemmeno usando l'endpoint di Acronis invece che il nostro endpoint specifico. Stesso errore. Se era possibile, anche se improbabile, che il nostro endpoint usasse un certificato che causava problemi - anche se funzionava correttamente con le altre macchine e nei browser - non era possibile che ci fosse qualche problema con quello di Acronis.<\/p>\n\n\n\n
Aggiornamento autorit\u00e0 di root<\/h4>\n\n\n\nL'errore riportato dall'agent era abbastanza indicativo ma noi avevamo problemi a collegarci agli endpoint anche in modo standard, usando per esempio Powershell<\/p>\n\n\n\n
Invoke-WebRequest -UseBasicParsing -Uri https:\/\/cloud.acronis.com<\/code><\/pre>\n\n\n\nC'era sicuramente un problema con le connessioni SSL. Anche se PowerShell restituiva un errore generico sull'impossibilit\u00e0 di completare la connessione, l'agent di Acronis riportava un errore di molto pi\u00f9 specifico per il quale abbiamo deciso di aggiornare i certificati di root sulla macchina:<\/p>\n\n\n\n
md C:\\Temp\ncd C:\\Temp\n# Scarica TUTTI i certificati di root da Windows Update\ncertutil.exe -generateSSTFromWU roots.sst\n# Importa TUTTI i certificati nello store delle autorit\u00e0 di root\n$sstContainer = (Get-ChildItem -Path C:\\temp\\roots.sst)\n$sstContainer | Import-Certificate -CertStoreLocation Cert:\\LocalMachine\\Root<\/code><\/pre>\n\n\n\nDopo aver lanciato questo questi comandi sar\u00e0 necessario riavviare la macchina per consentirle di ricaricare tutti i certificati.<\/p>\n\n\n\n
Problemi di cifratura<\/h4>\n\n\n\nQuesto non ha risolto il problema di per s\u00e8. Quando la macchina \u00e8 tornata online le connessioni agli endpoint di Acronis continuavano a non riuscire anche se con un errore diverso da parte dell'agent e lo stesso errore da parte di Powershell. Abbiamo quindi deciso di verificare meglio se fosse un problema di cifratura e di forzare le connessioni TLS1.2 in Powershell usando:<\/p>\n\n\n\n
# Forza PowerShell ad usare TLS1.2\n[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12<\/code><\/pre>\n\n\n\nOvviamente devi ricordare di non chiudere la sessione o perderai l'impostazione effettuata e dovrai applicarla di nuovo. Un altro tentativo di connessione ai nostri endpoint e ... bingo! Ora tutto funzionava correttamente! <\/p>\n\n\n\n
PS C:\\temp> Invoke-WebRequest -UseBasicParsing -Uri https:\/\/backup.vaisulweb.cloud                          \n\nStatusCode        : 200\nStatusDescription : OK\nContent           : <!DOCTYPE html><html lang=en><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible\n                    content=\"IE=edge\"><meta name=viewport content=\"width=device-width,initial-scale=1\"><meta\n                    name=referrer content=o...\nRawContent        : HTTP\/1.1 200 OK\n                    Connection: keep-alive\n                    Vary: Accept-Encoding\n                    X-Frame-Options: DENY,SAMEORIGIN\n                    Access-Control-Allow-Credentials: true\n                    Access-Control-Expose-Headers: ETag,Content-Length,Content-Typ...\nForms             :\nHeaders           : {[Connection, keep-alive], [Vary, Accept-Encoding], [X-Frame-Options, DENY,SAMEORIGIN],\n                    [Access-Control-Allow-Credentials, true]...}\nImages            : {}\nInputFields       : {}\nLinks             : {}\nParsedHtml        :\nRawContentLength  : 570<\/code><\/pre>\n\n\n\nQuindi avevamo due problemi separati. Abbiamo riprovato a registrare nuovamente l'agent:<\/p>\n\n\n\n
register_agent.exe -o register -t cloud -a https:\/\/cloud.acronis.com -u <account> -p <password><\/code><\/pre>\n\n\n\ned ora tutto funzionava correttamente! Whoa! I piani di backup hanno ripreso a funzionare senza problemi. Speriamo che questo post sia utile anche a qualcuno di voi !<\/p>\n"},"excerpt":{"rendered":"","protected":false,"raw":""},"author":8,"featured_media":1605,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_en_post_content":"\n[alert variation=\"alert-info\"]We had previously identified what happened to those two boxes but that explanation is out of scope. This post is about how you can quickly recover form that situation.[\/alert]\n\n\n\n
A few days ago we had a weird issue on a couple of servers after upgrading Acronis agent. Console was unable to start any backup plan, either automatically or manually, complaining that the agent was not registered anymore. That looked weird since we had updated our agents many times in the past but this time, somehow, agents unregistered or were unable to re-register. <\/p>\n\n\n\n
Actually, this round of updates had caused issues on a couple of Linux servers too but those had been quickly fixed by rebooting those machines. We quickly noticed that servers that were failing both had Windows Server Core as their base OS and SQL Server was installed on them too and in the end we decided to access those machines and manually re-register those agents as detailed inside Acronis documentation. It was surprising to find that agent was unable to re-register, complaining that the endpoint certificate was invalid or, more specifically, the Certification Authority that signed the certificate was unknown.<\/p>\n\n\n\n
Thing is that both those server were working fine before the update plus we seemed to be unable to re-register those agents even when using Acronis own endpoint. The same error was reported, which was so weird seems it could well be (though unlikely) that our own customized certificate had something wrong - even if it was working fine when accessed through browsers or on other machines - but Acronis own certificate could not have had any issue.<\/p>\n\n\n\n
Updating root certificates<\/h4>\n\n\n\nThe very single fact that agent was reporting an unknown certificate authority was pretty indicative but we also had troubles connecting to the endpoint on our own, for example when using Powershell<\/p>\n\n\n\n
Invoke-WebRequest -UseBasicParsing -Uri https:\/\/cloud.acronis.com<\/code><\/pre>\n\n\n\nDefinitely there was a problem connecting to SSL endpoints. While PowerShell was only complaining that the underlying connection was closed, Acronis agent reported a much more specific issue so we decided to investigate and check if we had any problems with our root certificates. We decided to update them altogether, just in case:<\/p>\n\n\n\n
md C:\\Temp\ncd C:\\Temp\n# Download ALL root certificates from Windows Update\ncertutil.exe -generateSSTFromWU roots.sst\n# Import ALL root certificates back inside root authorities\n$sstContainer = (Get-ChildItem -Path C:\\temp\\roots.sst)\n$sstContainer | Import-Certificate -CertStoreLocation Cert:\\LocalMachine\\Root<\/code><\/pre>\n\n\n\nRight after you do this, you need to reboot the affected machine to let it reload all root certificates. <\/p>\n\n\n\n
Encryption issue<\/h4>\n\n\n\nThat didn't fix the problem per se. Once the first machine was back, any attempt to connect to our endpoint or Acronis own one using Powershell was still failing. So we decided to investigate to check if machine was not using the proper cypher and we decided to force TLS1.2 in Powershell by using:<\/p>\n\n\n\n
# Force PowerShell to use TLS1.2\n[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12<\/code><\/pre>\n\n\n\nThen you have to remember not to close that session or your will need to issue that command again. So now we attempted to connect to our endpoint or Acronis endpoint again and... bingo! It was working fine!<\/p>\n\n\n\n
PS C:\\temp> Invoke-WebRequest -UseBasicParsing -Uri https:\/\/backup.vaisulweb.cloud                          \n\nStatusCode        : 200\nStatusDescription : OK\nContent           : <!DOCTYPE html><html lang=en><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible\n                    content=\"IE=edge\"><meta name=viewport content=\"width=device-width,initial-scale=1\"><meta\n                    name=referrer content=o...\nRawContent        : HTTP\/1.1 200 OK\n                    Connection: keep-alive\n                    Vary: Accept-Encoding\n                    X-Frame-Options: DENY,SAMEORIGIN\n                    Access-Control-Allow-Credentials: true\n                    Access-Control-Expose-Headers: ETag,Content-Length,Content-Typ...\nForms             :\nHeaders           : {[Connection, keep-alive], [Vary, Accept-Encoding], [X-Frame-Options, DENY,SAMEORIGIN],\n                    [Access-Control-Allow-Credentials, true]...}\nImages            : {}\nInputFields       : {}\nLinks             : {}\nParsedHtml        :\nRawContentLength  : 570<\/code><\/pre>\n\n\n\nSo we had two separate issues. We attempted to re-register agent again:<\/p>\n\n\n\n
register_agent.exe -o register -t cloud -a https:\/\/cloud.acronis.com -u <account> -p <password><\/code><\/pre>\n\n\n\nAnd now it worked fine! Geez! Backup plans were not working fine and executed without any issue. Hope it helps anyone!<\/p>\n","_en_post_name":"acronis-agent-not-registered-windows-server-core-and-ssl-issues","_en_post_excerpt":"","_en_post_title":"Acronis agent not registered, Windows Server core and SSL issues","_it_post_content":"\n[alert variation=\"alert-info\"]Avevamo capito prima di procederre cosa fosse successo alle due macchine ma quella spiegazione \u00e8 fuori dall'obbiettivo di questo post che si incentra su come poter recuperare velocemente da quella situazione.[\/alert]\n\n\n\n
Qualche giorno fa abbiamo riscontrato uno strano problema su un paio di server dopo avere aggiornato gli agent di Acronis. La console non consentirva pi\u00f9 l'esecuzione del piano di backup, sia in modo automatico che manuale, segnalando che l'agent non era pi\u00f9 registrato. Sembrava molto strano visto che avevamo effettuato aggiornamenti degli agent diverse volte in passato senza riscontrare alcun problema ma questa volta gli agent non riuscivano pi\u00f9 a registrarsi. <\/p>\n\n\n\n
In realt\u00e0 nello stesso ciclo di aggiornamenti avevamo avuto altri due problemi su macchine Linux ma questi erano spariti riavviando i due server. Inoltre, avevamo notato che i due server che presentavano questo problema erano installazioni di Windows Server Core che ospitavano SQL Server. Abbiamo quindi deciso di registrare nuovamente gli agent manualmente ma sorprendentemente non era possibile perch\u00e8 l'agent si lamentava del fatto che il certificato dell'endpoint non fosse valido. Anzi, in maniera pi\u00f9 specifica, che la Certification Authority fosse sconosciuta.<\/p>\n\n\n\n
Quei due server funzionavano correttamente prima dell'aggiornamento e, cosa ancora pi\u00f9 strana, sembrava che non fossimo in grado di registrare gli agent nemmeno usando l'endpoint di Acronis invece che il nostro endpoint specifico. Stesso errore. Se era possibile, anche se improbabile, che il nostro endpoint usasse un certificato che causava problemi - anche se funzionava correttamente con le altre macchine e nei browser - non era possibile che ci fosse qualche problema con quello di Acronis.<\/p>\n\n\n\n
Aggiornamento autorit\u00e0 di root<\/h4>\n\n\n\nL'errore riportato dall'agent era abbastanza indicativo ma noi avevamo problemi a collegarci agli endpoint anche in modo standard, usando per esempio Powershell<\/p>\n\n\n\n
Invoke-WebRequest -UseBasicParsing -Uri https:\/\/cloud.acronis.com<\/code><\/pre>\n\n\n\nC'era sicuramente un problema con le connessioni SSL. Anche se PowerShell restituiva un errore generico sull'impossibilit\u00e0 di completare la connessione, l'agent di Acronis riportava un errore di molto pi\u00f9 specifico per il quale abbiamo deciso di aggiornare i certificati di root sulla macchina:<\/p>\n\n\n\n
md C:\\Temp\ncd C:\\Temp\n# Scarica TUTTI i certificati di root da Windows Update\ncertutil.exe -generateSSTFromWU roots.sst\n# Importa TUTTI i certificati nello store delle autorit\u00e0 di root\n$sstContainer = (Get-ChildItem -Path C:\\temp\\roots.sst)\n$sstContainer | Import-Certificate -CertStoreLocation Cert:\\LocalMachine\\Root<\/code><\/pre>\n\n\n\nDopo aver lanciato questo questi comandi sar\u00e0 necessario riavviare la macchina per consentirle di ricaricare tutti i certificati.<\/p>\n\n\n\n
Problemi di cifratura<\/h4>\n\n\n\nQuesto non ha risolto il problema di per s\u00e8. Quando la macchina \u00e8 tornata online le connessioni agli endpoint di Acronis continuavano a non riuscire anche se con un errore diverso da parte dell'agent e lo stesso errore da parte di Powershell. Abbiamo quindi deciso di verificare meglio se fosse un problema di cifratura e di forzare le connessioni TLS1.2 in Powershell usando:<\/p>\n\n\n\n
# Forza PowerShell ad usare TLS1.2\n[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12<\/code><\/pre>\n\n\n\nOvviamente devi ricordare di non chiudere la sessione o perderai l'impostazione effettuata e dovrai applicarla di nuovo. Un altro tentativo di connessione ai nostri endpoint e ... bingo! Ora tutto funzionava correttamente! <\/p>\n\n\n\n
PS C:\\temp> Invoke-WebRequest -UseBasicParsing -Uri https:\/\/backup.vaisulweb.cloud                          \n\nStatusCode        : 200\nStatusDescription : OK\nContent           : <!DOCTYPE html><html lang=en><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible\n                    content=\"IE=edge\"><meta name=viewport content=\"width=device-width,initial-scale=1\"><meta\n                    name=referrer content=o...\nRawContent        : HTTP\/1.1 200 OK\n                    Connection: keep-alive\n                    Vary: Accept-Encoding\n                    X-Frame-Options: DENY,SAMEORIGIN\n                    Access-Control-Allow-Credentials: true\n                    Access-Control-Expose-Headers: ETag,Content-Length,Content-Typ...\nForms             :\nHeaders           : {[Connection, keep-alive], [Vary, Accept-Encoding], [X-Frame-Options, DENY,SAMEORIGIN],\n                    [Access-Control-Allow-Credentials, true]...}\nImages            : {}\nInputFields       : {}\nLinks             : {}\nParsedHtml        :\nRawContentLength  : 570<\/code><\/pre>\n\n\n\nQuindi avevamo due problemi separati. Abbiamo riprovato a registrare nuovamente l'agent:<\/p>\n\n\n\n
register_agent.exe -o register -t cloud -a https:\/\/cloud.acronis.com -u <account> -p <password><\/code><\/pre>\n\n\n\ned ora tutto funzionava correttamente! Whoa! I piani di backup hanno ripreso a funzionare senza problemi. Speriamo che questo post sia utile anche a qualcuno di voi !<\/p>\n","_it_post_name":"","_it_post_excerpt":"","_it_post_title":"L'agent di Acronis, Windows Server Core e problemi di connessione SSL","edit_language":"it"},"categories":[400],"tags":[408,109,407,411,115,409],"_links":{"self":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/1604"}],"collection":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/comments?post=1604"}],"version-history":[{"count":15,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/1604\/revisions"}],"predecessor-version":[{"id":1629,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/1604\/revisions\/1629"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/media\/1605"}],"wp:attachment":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/media?parent=1604"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/categories?post=1604"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/tags?post=1604"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}