Forum
See question

Aviso: “Não foi possível obter a versão do servidor.”   

12 views
0
0

Muitas vezes na hora de atualizar um posto surge o aviso:

Não foi possível obter a versão do servidor. Por favor verifique as credenciais e as permissões na partilha de rede.

Como resolver?

Faça login para poder traduzir
Deployment Center
Primavera
Marked as spam
Criado há 13 horas e 15 minutos martinfernandes
m
martinfernandes Martin Fernandes Most Valuable Professional
1 answers
0
Private answer

Este tipo de mensagens está relacionado com uma de duas situações:

  1. Permissões do utilizador do Deployment Center Client, na partilha de rede;
  2. Instalações corrompidas/mal efetuadas/danificadas.

Situação 1

É necessário que o utilizador fornecido nas configurações do Deployment Center Client exista no servidor e tenha permissões de escrita na partilha de rede. Em caso de dúvida, é possível criar um utilizador administrador no servidor, com permissões na partilha de rede e utilizar esse utilizador no Deployment Center Client, no posto.

Situação 2

Para despistar esta segunda situação fazer um backup da chave do registry:

    HKEY_LOCAL_MACHINE\SOFTWARE\PRIMAVERA\WindowsService100\Services\PRIMAVERA AutoUpdateClient\Applications

Caso o seu sistema operativo seja de 64 bits a chave é:

     HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PRIMAVERA\WindowsService100\Services\PRIMAVERA AutoUpdateClient\Applications

E começar a remover linhas do produto, no registry acima (ex: L100\LE, L100\LP, L900\LE, L900\LP, PFR800\IND) e tentar novamente. Ao apagar todas as linhas (LE/LP) deve apagar-se também a família (ex: L100, L900). Deve repetir-se todos os passos até que seja possível determinar em que família\linha está a corrupção.

Quando a origem da corrupção for detetada, deve repor-se todo o registo apagado a partir do backup inicial. Se se quiser investigar mais a fundo, é possível ir apagando as aplicações (ex: L900\LE\GCP, L900\LE\CBL) para determinar qual ou quais delas estão a provocar o erro. Após apagar cada aplicação, deve repetir-se a pesquisa para ver se o erro desaparece.

Importante: No final é sempre necessário repor o backup do registry, caso contrário o Deployment Center Client irá ignorar as famílias\linhas\aplicações apagadas.

Validar também os pontos abaixo (quer tenha sido ou não detetada a família que apresenta o problema):

  1. Chave PathSetupPosto (ex: SGE900\PathSetupPosto) - O valor desta chave deverá ser a localização do SetupN.ini, no servidor;
  2. Versões - Para cada aplicação instalada no posto, deverá haver uma chave “VERSAO_” na secção “Servidor” do SetupN.ini referido no passo anterior, que contenha uma versão corretamente formatada;
  3. Chave Apls - No SetupN.ini referido em 1, deve existir uma chave “APLS=aaa;bbb;ccc”, na secção “Servidor” que deve conter todos os módulos da família\linha, instalados no servidor.

Caso se apaguem todas as famílias\linhas da chave referida acima e o problema continuar a ocorrer, então o mesmo é da integridade da instalação do AWS/AUC. Nesse caso devem ser validados os pontos acima, mas para o Windows Services (AWS), ou seja:

  1. Chave do registry WindowsService100\PathSetupN - O valor desta chave deverá ser a localização do SetupN.ini, no servidor;
  2. Versão - Devem estar presentes as chaves VERSAO_AWS, VERSAO_AUP, VERSAO_AUC no SetupN.ini referido em 1, e estas terem versões corretamente formatadas.

O ponto 3 não se aplica neste caso, dado que no SetupN.ini do AWS não existe chave APLS. É normal.

O cenário mais comum que tem ocorrido é que no posto tem mais módulos/modelos instalados que no servidor (desinstalaram no servidor e não nos postos).

Faça login para poder traduzir
Marked as spam
Criado há 13 horas e 10 minutos martinfernandes
m
martinfernandes Martin Fernandes Most Valuable Professional