Pular para o conteúdo principal

Instalação da estação de trabalho

Um MSI, uma linha de msiexec, e uma máquina limpa passa a aguardar na fila de admissão. O pacote TrustBridge-Workstation-<version>-x64.msi traz os dois componentes da estação de trabalho, o Workstation Service e o Tray App, publicados como autocontidos (self-contained), então uma máquina sem runtime do .NET não precisa de nada instalado antes. Junto com ele, a Lacuna Software fornece TrustBridge-Workstation-GroupPolicy-<version>.zip, com os modelos de Diretiva de Grupo. A versão atual é a Workstation 1.5.0.

Esta página é o que o operador digita. A página Configuração da estação de trabalho é o que cada valor pode dizer: cada configuração que o serviço aceita, o padrão dela e o que um valor inválido provoca.

Antes de começar​

  • Uma máquina Windows de 64 bits e direitos administrativos nela. O pacote é por máquina, somente x64, e exige o Windows Installer 5.0 (Windows 7 e posteriores). ARM64 não é suportado.
  • Nada mais instalado. Os dois componentes são autocontidos, e é por isso que o pacote tem cerca de 100 MB.
  • A URL do Servidor, acessível a partir da máquina. O único valor sem o qual a instalação se recusa a prosseguir.
  • Um Servidor que fale o protocolo desta versão. A Workstation 1.5.0 exige o Servidor 1.13.0. Um Servidor mais antigo recusa a máquina no handshake; veja Qual Servidor uma versão exige.
  • Nada para a licença da PKI. A máquina recebe a licença do Servidor dela, no handshake, depois de admitida, e nada na linha de msiexec consegue fornecer uma. O Servidor a tem na própria Certificates:Validation:License. Até que a máquina seja admitida e se conecte, todo certificado nela aparece como UNTRUSTED.
  • Um Administrador que vá admitir a máquina. Instalar não faz a máquina entrar na frota; uma pessoa faz isso, no Servidor.
  • Uma cadeia TLS em que a máquina confie. O Workstation Service recusa um certificado de Servidor não confiável, e o sintoma é uma máquina que nunca aparece na fila.
  • O pacote assinado. As versões têm assinatura Authenticode; verifique o pacote antes de implantá-lo (seção seguinte).

A assinatura​

O pacote de uma versão tem assinatura Authenticode, assim como todo assembly do TrustBridge dentro dele. O signatário é o certificado de assinatura de código da Lacuna Software, com subject LACUNA SOFTWARE LTDA, emitido pela Sectigo, e toda assinatura tem um carimbo de tempo RFC 3161, então um pacote continua validando depois que o certificado que o assinou expira. O Windows mostra o publicador como LACUNA SOFTWARE LTDA no aviso de elevação; Programas e Recursos lista o produto em Lacuna Software. Os arquivos do runtime do .NET ao lado dos do produto são da Microsoft e têm a assinatura da Microsoft.

As versões são assinadas a partir da 1.2.1. A própria 1.2.1 foi retirada no dia em que saiu (ela não conseguia atualizar uma máquina na 1.2.0), então a primeira versão assinada a implantar é a 1.2.2.

Verifique um pacote antes de implantá-lo. A primeira linha exige o signtool do Windows SDK, que não está no PATH por padrão; a segunda não exige nada:

signtool verify /pa /v TrustBridge-Workstation-1.5.0-x64.msi
Get-AuthenticodeSignature TrustBridge-Workstation-1.5.0-x64.msi | Format-List Status, SignerCertificate, TimeStamperCertificate

O pacote de uma versão responde Successfully verified à primeira, com The signature is timestamped acima, e Valid à segunda, com um TimeStamperCertificate preenchido. Os executáveis instalados respondem da mesma forma (C:\Program Files\TrustBridge\Workstation Service\TrustBridge.WorkstationService.exe e C:\Program Files\TrustBridge\Tray App\TrustBridge.TrayApp.exe), e é assim que se sabe, em uma máquina, se o que está em execução é uma versão publicada.

Um pacote sem assinatura nunca é uma versão publicada. Uma retenção do SmartScreen, um Editor desconhecido no aviso de elevação ou um pacote que uma GPO ou uma configuração do Intune que exige publicador recusa significa que você tem em mãos algo diferente do pacote que a Lacuna Software publicou: use o pacote da versão.

A linha única​

msiexec /i TrustBridge-Workstation-1.5.0-x64.msi /qn SERVER_URL=https://trustbridge.example.com

Essa é uma instalação completa para a frota. Em ordem, ela:

  1. Verifica SERVER_URL e faz a transação inteira falhar se o valor estiver vazio ou não começar com um esquema.
  2. Coloca os dois componentes em C:\Program Files\TrustBridge\, cria a árvore de estado da máquina em C:\ProgramData\TrustBridge\, com uma DACL que só admite Administradores e LocalSystem, e registra a entrada de inicialização automática do Tray App.
  3. Grava a configuração da instalação em HKLM\Software\TrustBridge.
  4. Registra o TrustBridge Workstation Service no SCM (LocalSystem, inicialização automática, reinício em caso de falha) e o inicia, aguardando a inicialização ser bem-sucedida.
  5. O serviço gera a Chave da Estação de Trabalho no TPM da máquina (recorrendo ao provider de software, se necessário), se anuncia ao Servidor e fica Pendente na fila de admissão. Ele também inicia o Tray App em toda sessão em que alguém esteja conectado.

O último ato da instalação é o serviço subir. Um serviço que se recusa a iniciar (uma INSTALLER_KEY que não é uma chave, um valor de Registro do tipo errado) faz a instalação falhar e ser revertida, em vez de deixar uma máquina que parece instalada e nunca se conecta.

O msiexec não espera. Ele retorna imediatamente, e a linha seguinte de um script de implantação é executada enquanto a instalação ainda está em andamento. Para ler o resultado, aguarde o processo:

$install = Start-Process msiexec -Wait -PassThru -ArgumentList @(
'/i', 'TrustBridge-Workstation-1.5.0-x64.msi',
'/qn',
'/l*v', 'C:\Windows\Temp\trustbridge-install.log',
'SERVER_URL=https://trustbridge.example.com'
)
$install.ExitCode

Os códigos de saída são os do próprio Windows Installer: 0 sucesso, 1602 cancelado, 3010 sucesso com algo pedindo reinicialização, 1603 erro fatal, que é como as duas recusas próprias deste pacote aparecem. O motivo é uma linha do log /l*v; procure nele por SERVER_URL ou newer version.

As duas propriedades​

As duas são gravadas em HKLM\Software\TrustBridge como valores de Registro, e não em um arquivo de configuração, e é isso que as faz sobreviver a uma atualização sem nenhum mecanismo para lembrar propriedades.

PropriedadeValor no RegistroChave de configuração
SERVER_URLServerUrlServer:UrlObrigatória. Controlada pela condição de inicialização.
INSTALLER_KEYInstallerKeyServer:InstallerKeyOpcional. A maioria das implantações nunca a passa.

Não há propriedade de licença. A Workstation 1.0 aceitava uma, PKI_LICENSE; ela foi removida na 1.1.0, quando o Servidor passou a ser a única fonte da licença da máquina. Uma linha que ainda a passe instala, e nada lê o valor.

INSTALLER_KEY é para uma implantação que gerou uma Installer Key própria e configurou a metade pública dela no Servidor, em Admission:InstallerKeys. Se não for definida, nenhum valor é gravado e vale a chave do próprio produto. Ela não é um segredo e não admite nada sozinha.

Nenhuma das duas deve precisar de aspas. Uma URL não tem espaços, e a chave é base64 em uma linha.

A condição de inicialização​

SERVER_URL precisa estar presente e começar com http:// ou https://, ou a transação falha antes que qualquer coisa seja gravada. Vale para instalações silenciosas e interativas; para instalação, atualização e reparo, embora uma atualização e um reparo a satisfaçam com o valor que a própria máquina já tem, sem que você precise passar nada. A única transação que ela não controla é a remoção. Um serviço que se recusasse a iniciar seria uma máquina em loop de falhas, descoberta quando alguém não conseguisse assinar; uma instalação recusada é uma falha única e visível enquanto alguém está acompanhando.

O pacote da versão não traz URL de Servidor padrão. Um build feito para uma implantação específica pode trazer uma; assim, a linha para a frota dela passa a ser msiexec /i <msi> /qn e o campo interativo já vem preenchido. Um valor na linha de comando continua prevalecendo, assim como o valor que a máquina já tem.

O que uma instalação coloca na máquina​

C:\Program Files\TrustBridge\Workstation Service\O serviço e o runtime autocontido dele
C:\Program Files\TrustBridge\Tray App\O Tray App e o runtime próprio dele
C:\ProgramData\TrustBridge\O estado da máquina: o Cache de PIN, o chaveiro dele, o conjunto de Autoridades Certificadoras Confiáveis em cache, os PINs de Certificado A1 e a versão que iniciou por último, que é como o serviço distingue uma atualização de um reinício. Somente Administradores e LocalSystem
C:\ProgramData\TrustBridge\anchors\Onde ficam os arquivos de âncora de confiança, com a mesma DACL
C:\ProgramData\TrustBridge\updates\Criado quando a máquina recebe a primeira atualização do Servidor: o pacote baixado, o registro da última atualização entregue pelo Servidor e os logs de instalação. Somente SYSTEM e Administradores
HKLM\Software\TrustBridgeOs dois valores definidos na instalação
HKLM\…\CurrentVersion\Run → TrustBridge Tray AppInicialização automática para toda a máquina, para que o Tray seja executado para todo usuário interativo
Serviço TrustBridge Workstation ServiceLocalSystem, automático, reinicia três vezes em caso de falha, em intervalos de um minuto
Origem de eventos de Aplicativo TrustBridge Workstation ServiceOnde são gravados uma recusa ocorrida antes de o log existir e o relatório de limpeza de uma desinstalação

O diretório de instalação é fixo. A Chave da Estação de Trabalho não está nesta tabela porque o serviço a gera em um container CNG na primeira vez que inicia, e nada além do próprio verbo de limpeza do serviço consegue removê-la.

O serviço inicia o Tray App em toda sessão em que alguém esteja conectado, uma vez, na primeira inicialização depois de uma instalação ou de uma atualização. Ele executa a própria linha de comando da entrada de inicialização automática como o usuário de cada sessão, então o ícone aparece sem que ninguém precise sair e entrar de novo; os logins seguintes o recebem pela entrada de inicialização automática, como sempre. Uma sessão em que o Windows recuse a inicialização é citada no log do serviço. Enquanto o Tray App não estiver em execução em uma sessão, não há ninguém ali para responder a uma solicitação de PIN.

Instalando interativamente​

Clicar duas vezes no MSI mostra uma tela própria deste pacote entre as telas padrão de progresso e de conclusão: em uma máquina limpa, um único campo Server URL, associado à mesma propriedade SERVER_URL; em uma máquina que já tem o pacote, uma tela para reparar, reapontar ou remover, com o campo já preenchido. Não há EULA, seletor de diretório nem árvore de recursos. As caixas de diálogo são somente em inglês, de propósito: são ferramentas de implantação para o operador. O Tray App que o usuário vê fala o idioma do usuário.

A Installer Key não tem campo. Forneça-a a uma máquina interativa isolada por uma linha de reparo silencioso.

Admitindo a máquina​

Instalar não faz a máquina entrar na frota. A máquina se anuncia e aguarda, Pendente, até que um Administrador a torne Admitida na fila de admissão, em /admin/admission. Até lá, o serviço está em execução, acessando o Servidor e sem se conectar a nada; o log dele diz o motivo a cada reconexão, e o Tray App mostra Ainda não admitida.

O que admitir significa é limitado, e a tela diz isso: sem um canal externo (out-of-band) com que conferir uma impressão digital, admitir é uma barreira humana, com limite de requisições, sobre uma fila. Uma máquina é notada, e não verificada. O que torna isso aceitável é que a etapa não é opcional; nada que a máquina tenha a admite sozinha. Leia o nome do host, o sistema operacional, as versões e a postura da chave (em hardware ou em software) da máquina antes de admiti-la.

Depois de admitida, a máquina se conecta na próxima tentativa de reconexão, recebe a licença da PKI e aparece na tela Estações de Trabalho, em /admin/fleet. Uma máquina devolvida a Pendente mantém a chave e o histórico; uma máquina Revogada é recusada permanentemente e não tem como voltar, exceto como uma máquina nova, com uma chave nova.

Uma requisição Pendente abandonada expira depois de Admission:PendingExpiry (7 dias por padrão, contados a partir da última requisição da máquina), e a linha dela é excluída. Isso não é uma recusa; a máquina simplesmente pede de novo, como uma que a plataforma nunca viu.

Se a máquina nunca aparece na fila​

Leia primeiro o que o próprio serviço registra: o log Aplicativo do Windows, origem TrustBridge Workstation Service, e o log do serviço. Quatro coisas fazem uma requisição de admissão ser recusada, e o Servidor deliberadamente não diz qual, então o log da máquina cita as quatro: a máquina foi revogada; a Installer Key dela não é uma em que este Servidor confia; vieram requisições demais do endereço dela; ou a fila está cheia. As duas últimas se resolvem sozinhas.

O serviço informa de onde veio cada um dos valores definidos na instalação, a cada inicialização, uma linha por valor, no formato Server:Url is https://…, supplied by …. A Installer Key tem a mesma linha, com set ou not set no lugar do valor, assim como a licença, que, em uma máquina configurada só pelo MSI, aparece como not set: o Servidor a fornece depois que a máquina é admitida e se conecta. Leia essas linhas antes de mexer no Registro.

sc.exe query "TrustBridge Workstation Service"
Get-ItemProperty 'HKLM:\Software\TrustBridge'
Get-ItemProperty 'HKLM:\Software\Policies\TrustBridge' -ErrorAction SilentlyContinue

Execute esses comandos em um PowerShell de 64 bits. A preferência fica na visão de 64 bits do Registro; um host de 32 bits é redirecionado para WOW6432Node, onde uma máquina perfeitamente configurada parece vazia.

São dois locais, porque o segundo prevalece: um valor de Diretiva de Grupo em HKLM\Software\Policies\TrustBridge vence o que o instalador gravou, e uma máquina apontando para o Servidor errado normalmente é uma máquina no escopo de uma GPO de que alguém se esqueceu. Os dois são lidos uma vez, na inicialização.

Uma máquina cuja versão é mais nova que a janela de protocolo do Servidor não chega a ter utilidade na fila: o Servidor recusa o handshake dela com update the Server first, e o serviço registra esse veredito no log. Veja Qual Servidor uma versão exige.

Diretiva de Grupo: implantando os modelos​

O modelo ADMX permite que um domínio defina dois valores em toda a frota: a URL do Servidor (Server:Url) e se as máquinas recebem atualizações do Servidor delas (ServerUpdates:Enabled). Ele nunca é instalado pelo MSI: nada que o pacote grava pode ficar em \Policies, porque o processamento de diretivas exclui os valores que deixa de gerenciar. Descompactado, o arquivo de modelos da versão tem três arquivos:

admx\TrustBridge.admx
admx\en-US\TrustBridge.adml
admx\pt-BR\TrustBridge.adml

Copie-os para o repositório central do domínio, incluindo as pastas de idioma:

$store = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\PolicyDefinitions"
New-Item -ItemType Directory -Force -Path $store, "$store\en-US", "$store\pt-BR" | Out-Null
Copy-Item admx\TrustBridge.admx $store
Copy-Item admx\en-US\TrustBridge.adml "$store\en-US"
Copy-Item admx\pt-BR\TrustBridge.adml "$store\pt-BR"

A linha New-Item não é mera formalidade: Copy-Item para uma pasta que não existe cria um arquivo com esse nome, e um repositório nesse estado fica quebrado de um jeito de que nada reclama. Uma máquina sem repositório central recebe os mesmos três arquivos em %SystemRoot%\PolicyDefinitions. De qualquer forma, as configurações aparecem em Configuração do Computador → Modelos Administrativos → TrustBridge Workstation, como URL do Servidor e Receber atualizações do Servidor TrustBridge.

Copie os dois idiomas, mesmo que os seus administradores leiam inglês. O gpedit recorre ao idioma alternativo por arquivo, e não por string, então um repositório sem pt-BR\TrustBridge.adml faz um console em português perder o modelo inteiro.

Uma alteração de diretiva exige reiniciar o serviço, não atualizar a Diretiva de Grupo. O serviço lê os dois locais do Registro uma vez, na inicialização. O gpupdate /force entrega o valor, e a máquina o adota na próxima inicialização do serviço:

Restart-Service "TrustBridge Workstation Service"

As atualizações entregues pelo Servidor ficam ligadas, a menos que a diretiva diga o contrário. Receber atualizações do Servidor TrustBridge grava HKLM\Software\Policies\TrustBridge\ServerUpdates, um REG_DWORD: 0 quando a diretiva está desabilitada, o que desliga o canal, e 1 quando está habilitada. Não configurada equivale a ligada. Qualquer outra coisa ali, como um item de Preferências que grave o valor como string, é lida como desligada, e o log de inicialização do serviço avisa isso em Error. Não há propriedade do MSI para ela, então uma GPO é a única forma de desligá-la em uma frota. Uma máquina com ela desligada avisa o Servidor, o Servidor não lhe oferece nada, e a tela Estações de Trabalho a mostra como Atualizações desativadas por diretiva.

Não há diretiva para a licença da PKI. O modelo da Workstation 1.0 tinha uma, e ela foi removida na 1.1.0: uma máquina Admitida recebe a licença do Servidor a cada conexão, então uma renovação é uma alteração e um reinício no Servidor, nunca uma atualização de GPO. Um domínio que publicou a diretiva da 1.0 pode desvinculá-la quando quiser, porque o valor que ela deixa não é lido.

Não há, de propósito, diretiva para a Installer Key: uma troca de chave é uma implantação em etapas (informe a chave nova ao lado da antiga no Servidor, atualize as máquinas, remova a entrada antiga), e não uma atualização de GPO.

Reparando e reapontando​

Um reparo reinstala o pacote e regrava os dois valores de Registro a partir das propriedades, e é assim que você altera a configuração de instalação de uma máquina sem desinstalá-la:

# Repair: put back what a machine lost, keeping its current configuration.
msiexec /i TrustBridge-Workstation-1.5.0-x64.msi /qn REINSTALL=ALL REINSTALLMODE=ecmus

# Re-point: the same transaction, with a new value.
msiexec /i TrustBridge-Workstation-1.5.0-x64.msi /qn REINSTALL=ALL REINSTALLMODE=ecmus `
SERVER_URL=https://trustbridge-2.example.com

Uma propriedade que você não passa é lida de novo da máquina e regravada sem alteração. O serviço é parado e iniciado pela transação, então um reapontamento entra em vigor quando o reparo termina. O Tray App é fechado e não é iniciado de novo: um reparo não muda a versão, então o serviço não o reinicia, e o Tray App de cada usuário volta no próximo login dele, ou na hora, se Tray App\TrustBridge.TrayApp.exe for iniciado manualmente. A máquina mantém a Chave da Estação de Trabalho, então é a mesma estação de trabalho para o Servidor dela. Um reapontamento para um Servidor diferente chega à fila desse Servidor como uma nova máquina Pendente.

Atualizando​

Um MSI mais novo se instala sobre um mais antigo. Esse é o procedimento inteiro.

msiexec /i TrustBridge-Workstation-1.5.0-x64.msi /qn

Nenhuma propriedade é necessária; o pacote novo lê os valores existentes da máquina antes de o produto antigo ser removido e os grava de volta. Uma máquina atualizada é a mesma estação de trabalho, sem PINs para digitar de novo:

Sobrevive a uma atualizaçãoPor quê
A Chave da Estação de TrabalhoEla fica em um container CNG que nenhuma tabela do instalador cita
O Cache de PIN, o chaveiro dele, o conjunto de Autoridades Certificadoras Confiáveis em cache, os PINs de Certificado A1, o registro da última atualização entregue pelo ServidorArquivos em C:\ProgramData\TrustBridge\ que nenhum componente inclui
ServerUrl, InstallerKeyRegravados a partir dos valores da própria máquina
A interface em pt-BROs assemblies satélites são substituídos, e não deixados para trás

O Tray App é fechado pelo instalador durante o processo, então uma atualização não termina em reinicialização. O serviço atualizado o inicia de novo em toda sessão conectada assim que está em execução, e o Tray App mostra O TrustBridge foi atualizado uma vez a cada usuário. Um downgrade é recusado: voltar atrás é uma desinstalação de verdade, com tudo o que Removendo uma máquina descreve.

Atualizar a partir da 1.0.x também remove o valor PkiLicense que o pacote antigo gravou; dali em diante, a licença da máquina vem do Servidor dela.

Qual Servidor uma versão exige​

Cada versão da estação de trabalho fala uma versão de protocolo, e um Servidor aceita a própria versão e a anterior.

WorkstationProtocoloServidores que a aceitam
1.5.051.13.0
1.4.0 a 1.4.241.9.0 a 1.13.0. No 1.13.0, ela se conecta, mas não atende a novas sessões (abaixo)
1.1.0 a 1.3.031.7.0 a 1.12.0

Para quase toda versão, a ordem é primeiro o Servidor, depois as estações de trabalho, dentro de um mesmo ciclo de versão. Uma máquina mais nova que a janela do Servidor não consegue se conectar: o Servidor recusa o handshake com update the Server first, não lhe entrega licença, e todo certificado nela aparece como UNTRUSTED até que o Servidor seja atualizado.

A Workstation 1.5.0 e o Servidor 1.13.0 são a exceção: atualize os dois juntos. No protocolo 5, o Servidor deixa de enviar a qualquer máquina o PIN da aplicação cliente, e um Servidor 1.13.0 não envia a uma máquina na 1.4.x nenhum desafio de PIN nem solicitação. Essa máquina ainda se conecta, recebe a licença, assina pelas sessões já vinculadas a ela e pode receber uma oferta de versão, mas, para novas sessões, conta como offline. Então:

  1. Atualize o Servidor para a 1.13.0 e faça o upload do pacote 1.5.0 na tela Versões da Estação de Trabalho dele na mesma mudança.
  2. Ofereça a 1.5.0 à frota imediatamente. As máquinas na 1.4.x a recebem do Servidor (Atualizações entregues pelo Servidor).
  3. As máquinas na 1.3.0 ou anterior não conseguem receber atualizações do Servidor e são recusadas pelo 1.13.0: instale a 1.5.0 nelas manualmente ou por Diretiva de Grupo.

Veja Operação para o lado do Servidor.

Atualizações entregues pelo Servidor​

A partir da 1.4.0, uma máquina também pode receber uma versão do Servidor dela, sem ninguém junto a ela. Um Administrador faz o upload do MSI assinado na tela Versões da Estação de Trabalho do console administrativo e o oferece às máquinas na tela Estações de Trabalho; cada máquina que recebe a oferta o instala sozinha. É a mesma atualização principal (major upgrade) da linha de msiexec acima: tudo o que está na tabela sobrevive a ela, e o Tray App volta da mesma forma. Uma máquina na 1.3.0 ou anterior não tem código para receber uma, aparece como Precisa de atualização manual na tela Estações de Trabalho e não recebe oferta nenhuma.

O que uma máquina faz com uma oferta, em ordem:

  1. Aguarda um atraso aleatório de até dez minutos, sorteado uma vez por oferta, para que uma frota que recebe a mesma oferta não acesse o Servidor no mesmo segundo.
  2. Baixa o pacote do Servidor para C:\ProgramData\TrustBridge\updates\, onde só SYSTEM e Administradores podem gravar. Um download interrompido continua de onde parou.
  3. Verifica o pacote e o recusa na primeira verificação que falhar, não importa o que o Servidor tenha dito sobre ele: o SHA-256 e o tamanho que o Servidor anunciou; a assinatura Authenticode; um carimbo de tempo RFC 3161; um signatário que esteja no Publisher Pin compilado no Service já instalado; a revogação, em que só passa uma verificação bem-sucedida ou uma consulta que não pôde ser respondida; o UpgradeCode da própria TrustBridge Workstation; uma ProductVersion igual à da oferta e acima da instalada. Assim, o pior que um Servidor comprometido consegue fazer por esse canal é instalar antes da hora uma versão genuína e mais nova.
  4. Aguarda até que nada esteja em andamento: nenhuma assinatura em curso e nenhuma solicitação de PIN aberta. Então, por até dois minutos, recusa novas assinaturas e solicitações (uma assinatura falha dizendo que a máquina está instalando uma atualização; uma solicitação passa para outra máquina) e inicia msiexec /i <package> /qn /norestart /l*v <log> desacoplado, para que a instalação sobreviva ao Service que ela para. Uma Sessão de Assinatura aberta continua depois do reinício, mas os PINs em cache não sobrevivem a ele, a menos que PinCache:SurviveRestart esteja ligado, então os titulares podem ter de digitar um PIN de novo.

Cada máquina informa o resultado no próximo handshake, e a tela Estações de Trabalho e a Trilha de Auditoria o mostram:

  • instalada, depois que o novo Service iniciou na nova versão;
  • com falha, com o código de saída do msiexec e o trecho do log dele que levou à ação que falhou. Uma instalação que não gravou código de saída em trinta minutos, ou cujo msiexec não pôde ser iniciado, também é informada como com falha;
  • ou recusada, citando a verificação que falhou.

Uma versão com falha ou recusada não é tentada de novo até ser oferecida de novo: ofereça-a outra vez, ou use Entregar a todas ainda não atualizadas, e cada máquina tenta mais uma vez, inclusive uma que estava desligada na hora, no próximo handshake. Uma instalação que o Windows Installer estava ocupado demais para iniciar (msiexec com código de saída 1618, outra instalação em andamento) não informa nada e é tentada de novo cerca de quinze minutos depois.

O pacote é excluído assim que o resultado é conhecido, e o mesmo vale para o que uma oferta retirada ou substituída deixou baixado pela metade. Os cinco logs de instalação mais recentes ficam em updates\, como install-<version>-<time>.log, com o horário em UTC.

Retirar uma oferta interrompe toda máquina que ainda não iniciou o msiexec, mesmo uma que esteja no meio do download ou aguardando o momento ocioso. Uma máquina que já instalou a versão continua nela: não há como voltar, exceto por uma versão mais alta.

A Diretiva de Grupo desliga as atualizações. Uma máquina cuja diretiva Receber atualizações do Servidor TrustBridge está desabilitada não baixa nem instala nada, seja o que for que lhe ofereçam, a partir da próxima inicialização do Service (ServerUpdates:Enabled).

Removendo uma máquina​

Uma desinstalação é a saída da máquina da plataforma, e não é o inverso de uma atualização.

msiexec /x TrustBridge-Workstation-1.5.0-x64.msi /qn

Ou, sem o MSI à mão, pelo código do produto:

$product = Get-ChildItem HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall |
Where-Object { $_.GetValue('DisplayName') -eq 'TrustBridge Workstation' }
Start-Process msiexec -Wait -ArgumentList "/x $($product.PSChildName) /qn"

O que a remoção destrói, e nada mais destrói:

A Chave da Estação de TrabalhoExcluída tanto do TPM quanto do repositório de software pelo verbo purge-machine-identity do próprio serviço, que a desinstalação agenda
C:\ProgramData\TrustBridge\Toda a árvore de estado da máquina: Cache de PIN, chaveiro, conjunto de Autoridades Certificadoras Confiáveis em cache, PINs de Certificado A1, a versão que iniciou por último, âncoras e updates\, com o registro, os logs de instalação e qualquer download. Além de um Cache de PIN realocado, se PinCache:StorePath ou PinCache:KeyRingPath o moveu para fora da árvore
HKLM\Software\TrustBridgeOs dois valores
O serviço, o Tray App, a entrada de inicialização automáticaRemoção comum
HKLM\Software\Policies\TrustBridgeIntocado. Pertence ao mecanismo de diretivas
HKCU\Software\TrustBridge\Tray App, por usuárioIntocado. Uma string, a versão do Tray App que aquele usuário executou por último. Um pacote por máquina não consegue acessar o hive de todos os usuários

A limpeza é executada em uma desinstalação de verdade e nunca na etapa de desinstalação de uma atualização. Uma desinstalação é concluída mesmo quando a limpeza não é; nesse caso, o verbo grava uma entrada bem visível no log Aplicativo, citando o que deixou para trás.

A revogação no Servidor é o controle que não depende da cooperação da máquina. Revogue uma máquina removida no painel dela, na tela Estações de Trabalho, em /admin/fleet. Reinstalar depois produz uma máquina realmente nova: ela volta à fila com uma nova impressão digital, os titulares dela digitam os PINs de novo, e todo PIN de Certificado A1 precisa ser definido de novo no console da máquina.

Quando uma instalação falha​

O que você vêO que éO que fazer
Código de saída 1603, log cita SERVER_URLA condição de inicializaçãoPasse SERVER_URL=https://…. O esquema não é opcional.
Código de saída 1603, log diz que uma versão mais nova está instaladaUm downgradeRemova antes o pacote mais novo, depois de ler Removendo uma máquina.
Reverte em Starting servicesO serviço se recusou a iniciar: uma INSTALLER_KEY que não pode ser interpretada ou um valor de Registro do tipo erradoO log de eventos Aplicativo cita o valor recusado.
Uma tela de arquivos em uso listando o Tray AppUma atualização ou remoção interativaContinue. O Tray é encerrado antes que qualquer arquivo seja tocado; não há reinicialização.
Editor desconhecido no aviso de elevação, uma retenção do SmartScreen ou uma diretiva que exige publicador recusando o pacoteUm pacote sem assinatura, que nunca é uma versão publicadaUse o pacote da versão e verifique-o antes: A assinatura.
Concluída, mas a máquina não está na filaQuase sempre a URL; às vezes um valor de diretiva sobrepondo o que você passouSe a máquina nunca aparece na fila, acima.
Concluída, mas todo certificado aparece como UNTRUSTEDAinda não há licença da PKI. A única fonte da máquina é o Servidor dela: a máquina está Pendente, não consegue acessar o Servidor, é mais nova que o Servidor (update the Server first no log) ou a licença do Servidor é uma que o SDK recusaAdmita a máquina ou atualize o Servidor. Se ela está Admitida e conectada, renove Certificates:Validation:License no Servidor e reinicie o Servidor; a máquina a aplica quando se reconecta. A linha de licença do Tray App diz qual é o caso.
Ver em Markdown