| ♥ 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? Marked as spam |
| Private answer Este tipo de mensagens está relacionado com uma de duas situações:
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):
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:
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). Marked as spam |