Tag: Windows

Instalar o Volume Licensing Activation Services
Ativar o chave de Host KMS
Aguardar a replicação do DNS

Para configurar novos clients Windows não é necessário fazer nada!

Para converter clients de MAK para KMS:

REM Este comando remove chaves instaladas. Com ele vamos remover a chave MAK
cscript slmgr.vbs /upk
REM Este comando instala uma nova chave. Utilize uma das GVLK disponibilizadas pela Microsoft no link abaixo.
cscript slmgr.vbs /ipk:XXXX-XXXX-XXXX-XXXX-XXXX

GVLK para Windows: https://technet.microsoft.com/en-us/library/jj612867(v=ws.11).aspx

Habilitar o KMS Host para ativar instalações de Microsoft Office 2016

Para habilitar o KMS Host para ativar instalações do Office 2016 é necessário rodar o script de configuração do KMS Host para Office.

Para isso, acesse o Microsoft Volume Licensing Service Center (VLSC), em “Downloads e Chaves” localize e faça download do aplicativo “Office Professional Plus 2016 Key Management Service Host”.

Ele é uma ISO com pouco mais de 1MB que você deve copiar e montar no seu KMS Server. Ao fazer isso, você deve enxergar os seguintes arquivos:

Depois abra um prompt de comando com permissões elevadas e execute o seguinte comando:

wscript.exe kms_host.vbs

O script irá configurar o Volume Activation Services instalado no servidor e abrirá a janela de administração.  Insira a chave de KMS Host para Office Professional Plus 2016 nesse servidor e finalize o Wizard.

Nota: se você precisar habilitar o KMS Host para ativar instalações de Project ou Visio, basta repetir este processo, inserindo as chaves KMS correspondentes.

Configurando os Clients para utilizar o novo KMS Host

Assim como para ativações do Windows, no caso de novas instalações do Office 2016 o computador buscará por padrão um servidor KMS na rede e o ativará.

No entanto, caso precise converter uma instalação existente que ja esteja ativada com chave MAK utilize o seguinte procedimento:

No computador cliente abra um prompt de comando com permissões elevadas.

Execute o seguintes comandos:

cd "C:\Program Files\Microsoft Office\Office16"
REM Este comando instala uma nova chave. Utilize uma das GVLK disponibilizadas pela Microsoft no link abaixo.
cscript ospp.vbs /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

GVLK para Office: https://technet.microsoft.com/en-us/library/dn385360(v=office.16).aspx

Validando a configuração

Para validar que tudo funcionou execute no prompt de comando com permissões elevadas os seguintes comandos:

cscript OSPP.VBS /dcmid

O resultado desse comando deve indicar que o Office foi ativado utilizando  o KMS Host

If you Google “the trust relationship between this workstation and the primary domain failed”, you get plenty of information from support blogs and Microsoft articles; however, most of them ask you to rejoin your machine to the domain. That’s not always possible.

##TL;DR You got this error and you can’t simply unjoin and rejoin because the machine is a Certificate Authority. Run this command from PowerShell:

##What’s the problem and how did I get here?

The underlying problem when you see this error is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined. The machine’s private secret is not set to the same value store in the domain controller. You can think of this secret as a password but really it’s some bits of cryptographic data called a Kerberos keytab stored in the local security authority. When you try to access this machine using a domain account, it fails to verify the Kerberos ticket you receive from Active Directory against the private secret that it stores locally. I think you can also come across this error if for some reason the system time on the machine is out of sync with the system time on the domain controller. This solution also fixes that problem.

##The standard fix This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before. When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months. The password changes are required to maintain the security integrity of the domain.

 

Fonte: DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed