Ativando KMS Host Server

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”.

KMS_IMG_1.PNG

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:

KMS_IMG_2.PNG

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.

KMS_IMG_3.PNG

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

Anúncios

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

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:

Reset-ComputerMachinePassword [-Credential ] [-Server ]

##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

Como publicar uma aplicação Web no Citrix XenApp

Existem algumas formas de publicar uma aplicação Web no Citrix XenApp.

A mais simples, talvez, é utilizar o modo “Kyosk” do Internet Explorer. Para isso basta utiilizar o parâmetro “-k” ao chamar o aplicativo. A configuração da aplicação no Citrix Studio deveria ficar mais ou menos assim:

Internet Explorer modo Kyosk
Internet Explorer modo Kyosk

O problema do modo Kyosk é que o IE é iniciado em tela cheia e sem o botão “Fechar”. Isso pode confundir o usuário e prejudicar a sua experiência de uso.

Outra forma de fazer isso é utilizar um script que instancia o Internet Explorer desabilitando alguns componentes (tais como a barra de endereços, botões de navegação, complementos e etc). Aqui nesse post, há um exemplo de um VB Script bem simples que dá conta do recado, e que reproduzo abaixo:

Set oIE1 = WScript.CreateObject ("InternetExplorer.Application")

oIE1.Navigate "http://www.yahoo.com"
oIE1.Visible = 1
oIE1.AddressBar = 0
oIE1.StatusBar = 0
oIE1.ToolBar = 0
oIE1.MenuBar = 0

No entanto, a minha solução preferida foi a desse outro Blog. O VB Script publicado aqui é bem mais robusto e reutilizável. Nesse caso, basta chamar o script e passar como parâmetro a URL da aplicação Web.

Set objArgs = WScript.Arguments 
If objArgs.Count = 0 Then 
 WScript.Echo "No URL provided, please supply a URL to open" & VbCrLf & VbCrLf & "e.g. CScript OpenURL.vbs http://www.google.com" 
 wscript.quit
End If

Set objIE = CreateObject("InternetExplorer.Application")

With CreateObject("internetexplorer.application") 
 .navigate "about:blank" 
 With .document.parentWindow.screen 
 iHeight = .height 
 iWidth = .width 
 End With 
End With

objIE.StatusBar = False 
objIE.Visible = True 
objIE.AddressBar = False 
objIE.MenuBar = False 
objIE.ToolBar = False 
objIE.Top = 0 
objIE.Left = 0 + 8 'Move to the side just a bit to show the desktop
objIE.Width = iWidth - 16 'Shrink to let a bit of the desktop show on the sides
objIE.Height = iHeight - 28 'Shrink a bit to see the taskbar
objIE.Navigate (objArgs(0))

A publicação de uma aplicação Web no XenDesktop utilizando essa ferramenta ficaria mais ou menos assim:

Internet Explorer chamado através do VBScrit
Internet Explorer chamado através do VBScript

Fontes: JasonSamuel.com, Citrix Discussions

 

Microsoft encerra suporte ao Windows 8 nesta terça-feira

Utilizado por menos de 3% dos computadores, sistema não vai mais receber atualizações de segurança a partir desta terça

A partir desta terça-feira, 12/01, a Microsoft vai encerrar o suporte ao sistema operacional Windows 8. Deste modo, ele deixará de receber atualizações de segurança, de desempenho e de suporte para novos dispositivos.

A maioria dos sistemas operacionais da Microsoft tem um ciclo de vida de dez anos. Contudo, o Windows 8, lançado em 2012, foge a essa regra: segundo a própria Microsoft, o Windows 8.1, que continua a receber atualizações, substituiu a versão 8 em 2013. A empresa garante que a versão 8.1 terá suporte até 2023.

Por essa razão a empresa recomenda que os usuários atualizem o sistema para a versão 8.1 ou mais recente, o que pode ser feito gratuitamente, para não deixar o computador vulnerável a ataques cibernéticos.

Conforme foi divulgado no blog Link do Estadão, uma pesquisa realizada pela Statista constatou que menos de 3% dos computadores no mundo ainda utilizam o Windows 8. Segundo a mesma pesquisa, o Windows 7 ainda é o sistema operacional mais popular da Microsoft, presente mais de 43% de PCs e notebooks.

Fonte: Microsoft encerra suporte ao Windows 8 nesta terça-feira – Link Estadão – Notícias de Tecnologia – Estadao.com.br

Alterar Windows Server 2012 R2 de Core para interface gráfica de usuário (GUI)

Desde a versão Windows Server 2008 R2 é possível optar pela instalação do Sistema Operacional com a interface gráfica (with GUI) ou sem ela (server core installation).

No entanto, no Windows Server 2012 e 2012 R2 a instalação da interface gráfica é um componente que pode ser instalado ou removido a qualquer momento.

Se você instalou o Windows Server 2012 R2 sem a interface gráfica (Server Core) e precisa – ou deseja – alterar essa característica, será necessário um repositório que contenha todos os arquivos de instalação. Normalmente esses arquivos estão armazenados em <%WINDIR%>\WinSxS\. Caso eles não estejam mais disponíveis é possível utilizar também a imagem padrão disponível no DVD de instalação do Sistema Operacional. Para isso, localize na mídia o arquivo “Install.wim” dentro do diretório D:\sources\ (supondo que “D:\” seja o seu drive de CD).

No prompt de comando execute o PowerShell para identificar as imagens do Windows disponíveis no arquivo. Verifique o Index das imagens que não se referem a Server Core e que correspondam ao seu tipo de licença (Standard ou Datacenter).

Get-WindowsImage -ImagePath:D:\Sources\Install.Wim

Get-WindowsImage
Index das Imagens disponíveis na mídia

Para identificar as funcionalidades que precisam ser habilitadas execute no PowerShell o seguinte cmdlet:

Get-WindowsFeature

Como resultado, esse cmdlet listará todas as features disponíveis para o Sistema Operacional e identificará as instaladas com o [X]. Os componentes de Interface Gráfica estão aninhados em “User Interfaces and Infrastructure“:

Get-WindowsFeature
Resultados do cmdlet Get-WindowsFeature

Portanto, para instalar a interface gráfica do Windows Server execute o cmdlet Install-WindowsFeature no PowerShell conforme abaixo:

Install-WindowsFeature -Name server-gui-shell,server-gui-mgmt-infra -source: D:\sources\install.wim:2 -restart

O parâmetro “:2” refere-se ao número do Index da imagem. Neste caso, indica que a imagem utilizada é a “Windows Server 2012 R2 SERVERSTANDARD”.

Após o término da execução será necessário reiniciar o servidor.

Habilitar o Gerenciamento Remoto do Windows Server 2012 R2 em servidores com Windows Server 2008 R2

As ferramentas de gerenciamento remoto do Windows Server 2012 R2 são uma mão na roda para administrar servidores no ambiente.

Elas proporcionam fácil acesso a uma série de recursos administrativos e possibilitam criar um ponto único de contato, tornando rápido identificar e solucionar problemas em servidores.

Entretanto, essas ferramentas só estão disponíveis de forma nativa no Windows Server 2012 em diante.

Embora seja possível adicionar um servidor com Windows Server 2008 R2 ao grupo de gerenciamento, o painel exibirá um erro e, ao tentar gerencia-lo, recebemos a mensagem:

Online - Verify WinRM 3.0 service is installed, running and required firewall ports are open
Console de gerenciamento remoto do Windows Server 2012 R2
Console de gerenciamento remoto do Windows Server 2012 R2

Para habilitar o gerenciamento remoto em servidores Windows Server 2008 R2 é necessário instalar:

Depois de instalado os dois pacotes, será necessário configurar o WinRM para “escutar” solicitações de gerenciamento remoto. A forma mais rápida de se fazer isso é executar o comando a seguir com permissões elevadas:

winrm quickconfig

Aceite a criação do listener sugerido e verifique que a configuração ocorreu sem erros.

Configuração do WinRM 3.0
Configuração do WinRM 3.0

Depois disso, atualize a console de gerenciamento remoto no servidor e verifique que o gerenciamento está ocorrendo.

Windows Server 2012 – ADFS 2.1 – Erro MSIS7613:The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration

Ao tentar utilizar um mesmo certifcado para entradas diferentes utilizando o ADFS 2.0, aparece a mensagem:

MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration”

O Rollup 3 disponibilizado pela Microsoft permite corrigir este erro facilmente, conforme pode ser visto neste excelente post do Paul Williams, ou em outros tantos pela internet. Entretanto, este Rollup só pode ser aplicado no Windows Server 2008 r2.

No Windows Server 2012, o ADFS 2.1 é instalado como uma Role, e esperava-se que este problema não ocorresse mais, porém não foi o que observei. Ao tentar encontrar a solução para este problema,  deparei-me com a inexistência (até o momento) de atualizações para o ADFS 2.1.

Deste modo, encontrei uma alternativa para solucionar isso:

  • Separe uma maquina de testes com Windows Windows Server 2008 R2 e instale o ADFS 2.0 e o Rollup 3.
  • Após a instalação abra a pasta “C:\Program Files\Active Directory Federation Services 2.0\SQL” e copie os seguintes arquivos:
    • IdentityServerAttestation.cer
    • IdentityServerAttestation.dll
    • IdentityServerAttestation.sql
    • PostReleaseSchemaChanges.ps1
Copiar os arquivos do ADFS 2.0
Copiar os arquivos do ADFS 2.0
  • Cole os arquivos no seu servidor Windows Server 2012, em “C:\Windows\Adfs\SQL\”;
  • No servidor Windows Server 2012, clique com o botão direito sobre PostReleaseSchemaChanges.ps1 e selecione editar;
  • Altere a linha 6, 8 e 9 do script, substituindo a variável “$env:ProgramFiles\Active Directory Federation Services 2.0\” por “$env:windir\ADFS\“:
Alterando o Script
Alterando o Script
Script Alterado
Script Alterado
  • Salve as alterações e feche o arquivo;
  • Execute o PowerShell como Administrador e execute o script;

 

 

 

Corrigindo problemas na inicialização do Windows XP devido a DLLs corrompidas

Primeiramente inicie o computador normalmente e anote a DLL ou arquivo corrompido (p0r exemplo, C:\Windows\System32\hal.dll).

Dê um boot na máquina usando o CD do windows XP e, quando perguntado sobre a instalação de uma nova versão ou reparar a existente pressione “R” para reparar.

Quando solicitado selecione a instalação do Windows e informe a senha de administrador local.

Execute o comando cd system32 para acessar o diretório system32, onde está a dll com problema.

Execute o  comando ren hal.dll hal.old para renomear a dll (óbvio demais?).

Execute o comando map e localize a letra referente ao drive de CDROM do seu computador (deve ser algo parecido com E:\ Device\CdRom0)

Assumindo que a letra referente ao seu mapeamento seja E:\, execute o comando expand E:\i386\hal.dl_

*Importante: note o caracter   _  substituindo a última letra da extensão.

Execute o comando exit e reinicie a máquina

Removendo Aba “Conexões” no Internet Explorer

Para remover a aba Conexões do Internet Explorer há duas maneiras: a primeira é acessando o console de políticas de segurança, a outra manipulando diretamente o registro do Windows.

Para realizar essa configuração através do Console de Políticas de Segurança (gpedit.msc)

 

  • Vá no Executar e digite gpedit.msc para executar o console:

image

  • No painel à direita, localize a opção Configurações do Computador –> Modelos Administrativos –> Componentes do Windows –> Internet Explorer –> Internet Control Panel;

image

  • No painel à esquerda, localize a chave referente a aba que você deseja desativar. No nosso caso, a aba “Conexões”. Dê um duplo clique sobre ela e mude o status para Ativado:

image image

  • Dê OK e reinicie o Internet Explorer.

Para realizar essa configuração diretamente pelo Registro do Windows:

 

  • Execute o regedit e navegue até a chave:

 HKLM\SOFTWARE\Policies\Microsoft\Internet Explorer\Control Panel\

  • Localize no painel à direita a chave referente à Aba desejada (no nosso caso, a aba “Conexões”). Caso não exista nenhuma chave nesse diretório crie a chave da seguinte maneira:
    • Clique com o botão direito no painel à direita e aponte para Novo e selecione DWORD Value:

image

  • Chame essa chave de ConnectionsTab:

image

 

  • Dê um duplo clique sobre ela e altere o valor para “1” para desativar a aba Conexões:

image

  • Reinicie o Internet Explorer.