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
msiexecconsegue fornecer uma. O Servidor a tem na própriaCertificates:Validation:License. Até que a máquina seja admitida e se conecte, todo certificado nela aparece comoUNTRUSTED. - 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:
- Verifica
SERVER_URLe faz a transação inteira falhar se o valor estiver vazio ou não começar com um esquema. - Coloca os dois componentes em
C:\Program Files\TrustBridge\, cria a árvore de estado da máquina emC:\ProgramData\TrustBridge\, com uma DACL que só admite Administradores e LocalSystem, e registra a entrada de inicialização automática do Tray App. - Grava a configuração da instalação em
HKLM\Software\TrustBridge. - 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.
- 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.
| Propriedade | Valor no Registro | Chave de configuração | |
|---|---|---|---|
SERVER_URL | ServerUrl | Server:Url | Obrigatória. Controlada pela condição de inicialização. |
INSTALLER_KEY | InstallerKey | Server:InstallerKey | Opcional. 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\TrustBridge | Os dois valores definidos na instalação |
HKLM\…\CurrentVersion\Run → TrustBridge Tray App | Inicialização automática para toda a máquina, para que o Tray seja executado para todo usuário interativo |
Serviço TrustBridge Workstation Service | LocalSystem, automático, reinicia três vezes em caso de falha, em intervalos de um minuto |
Origem de eventos de Aplicativo TrustBridge Workstation Service | Onde 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ção | Por quê |
|---|---|
| A Chave da Estação de Trabalho | Ela 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 Servidor | Arquivos em C:\ProgramData\TrustBridge\ que nenhum componente inclui |
ServerUrl, InstallerKey | Regravados a partir dos valores da própria máquina |
| A interface em pt-BR | Os 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.
| Workstation | Protocolo | Servidores que a aceitam |
|---|---|---|
| 1.5.0 | 5 | 1.13.0 |
| 1.4.0 a 1.4.2 | 4 | 1.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.0 | 3 | 1.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:
- 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.
- Ofereça a 1.5.0 à frota imediatamente. As máquinas na 1.4.x a recebem do Servidor (Atualizações entregues pelo Servidor).
- 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:
- 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.
- Baixa o pacote do Servidor para
C:\ProgramData\TrustBridge\updates\, onde só SYSTEM e Administradores podem gravar. Um download interrompido continua de onde parou. - 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.
- 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 quePinCache:SurviveRestartesteja 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
msiexece 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 cujomsiexecnã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 Trabalho | Excluí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\TrustBridge | Os dois valores |
| O serviço, o Tray App, a entrada de inicialização automática | Remoção comum |
HKLM\Software\Policies\TrustBridge | Intocado. Pertence ao mecanismo de diretivas |
HKCU\Software\TrustBridge\Tray App, por usuário | Intocado. 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_URL | A condição de inicialização | Passe SERVER_URL=https://…. O esquema não é opcional. |
| Código de saída 1603, log diz que uma versão mais nova está instalada | Um downgrade | Remova antes o pacote mais novo, depois de ler Removendo uma máquina. |
| Reverte em Starting services | O serviço se recusou a iniciar: uma INSTALLER_KEY que não pode ser interpretada ou um valor de Registro do tipo errado | O log de eventos Aplicativo cita o valor recusado. |
| Uma tela de arquivos em uso listando o Tray App | Uma atualização ou remoção interativa | Continue. 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 pacote | Um pacote sem assinatura, que nunca é uma versão publicada | Use o pacote da versão e verifique-o antes: A assinatura. |
| Concluída, mas a máquina não está na fila | Quase sempre a URL; às vezes um valor de diretiva sobrepondo o que você passou | Se a máquina nunca aparece na fila, acima. |
Concluída, mas todo certificado aparece como UNTRUSTED | Ainda 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 recusa | Admita 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. |