Resolve: jobs, reinicializações e aprovações

Como o Resolve congela, aprova, executa e verifica cada mudança em um host, como trata reinicializações e agentes em silêncio, e como a governança de aprovação define quem autoriza por ambiente.

O WASViking Resolve é o lado de remediação do Infrastructure Defense. Toda mudança que ele faz em um host, de uma atualização de segurança a uma reinicialização, é um job com o mesmo contrato: um escopo congelado, uma aprovação sob as suas regras, uma janela de manutenção e um veredito do próximo inventário. Esta página acompanha um job da recomendação ao veredito.

Da recomendação ao veredito

1. As ações recomendadas agrupam as atualizações de segurança pendentes de cada host, ordenadas pela redução de pontuação que se espera delas.
2. Agendar uma ação a congela como um job com a lista exata de pacotes, de modo que o aprovador autoriza uma mudança concreta. Abra Review e desmarque as atualizações que você quer deixar para depois: o job só toca no que permanece marcado, e as vulnerabilidades fechadas e a pontuação esperada são recalculadas para essa seleção. As atualizações deixadas de fora continuam recomendadas para o próximo job.
3. O job é aprovado conforme a regra do ambiente do host (veja Governança de aprovação). A menos que o aprovador escolha Run now (executar agora), ele só começa dentro da janela de manutenção da política de host (veja Políticas). Nada é instalado sozinho, a menos que uma regra de implantação automática assinada pelos seus aprovadores inclua o host, e a reinicialização automática vem desativada por padrão.
4. O agente executa pré-verificações, aplica as atualizações pelo mecanismo nativo de cada plataforma (o gerenciador de pacotes do sistema no Linux, o serviço de atualização no Windows, as atualizações de software no macOS) e reporta o resultado por item.
5. O próximo inventário é o veredito: o job só se conclui quando a reavaliação mostra quais vulnerabilidades fecharam e quanto a pontuação caiu. Os números de antes e depois são medidos, e quando uma reinicialização ainda está pendente o job informa isso em vez de dar o trabalho por concluído.

Cada ativo tem a sua própria visão do Resolve. Deploy through Resolve na página do ativo e Schedule remediation no Command Center abrem o Resolve filtrado para aquele ativo, só com as ações recomendadas, as aprovações e os jobs dele. Schedule pede uma confirmação que lista cada atualização que o job instala e quem aprova em seguida. Quando a regra do ambiente permite que quem solicitou também aprove, o job espera em Awaiting your approval, no topo do Resolve, que mostra o que cada job instala: nada roda antes de ser aprovado.

Quando o Resolve não consegue agendar a correção

O Resolve instala o que o próprio canal de atualização do host oferece. Quando um achado tem correção publicada que esse canal não oferece, a página do ativo diz o motivo: Software at Risk lista cada pacote com How it gets fixed, e o cartão Vulnerabilities começa pelo que fazer. No Windows, os achados do sistema operacional fecham com a atualização cumulativa mensal da versão instalada, e o Resolve lista os hosts cujo Windows Update não a oferece em Windows hosts missing their cumulative update, com o motivo:

• Fora de suporte. A versão ou edição do Windows não recebe mais atualizações de segurança, por exemplo uma edição Home ou Pro depois do fim do suporte da sua versão. Só o upgrade para uma versão com suporte fecha esses achados, feito pelo Windows Update ou pela sua ferramenta de gerenciamento de dispositivos; o Resolve não faz upgrade da versão do Windows.
• Reinicialização pendente. A atualização cumulativa pode estar instalada e esperando a reinicialização. Agende a reinicialização; o próximo inventário lê o novo build e fecha o que a atualização corrigiu.
• Não oferecida. As atualizações estão pausadas ou adiadas por uma política, um servidor de atualização não aprovou a atualização, ou o Windows Update falha no host. Quando o host passar a oferecê-la, ela aparece como atualização para agendar.

Gerenciamento de patches: hosts e decisões

O Gerenciamento de patches lista todas as atualizações que os hosts reportam como pendentes, uma linha por atualização. Uma atualização do Windows é o seu número KB, seja qual for o idioma em que cada host a nomeia; qualquer outra atualização é o seu pacote e a versão de destino. O número em Ativos abre a página da própria atualização: cada host que está sem ela, a versão instalada nele hoje e a situação da atualização em cada host. Ela pode estar pronta para instalar, em uma tarefa do Resolve, ter falhado na última tentativa (com o link para a tarefa e o que o host reportou), instalada com reinício pendente, esperando outra mudança no host, pausada após um rollback, ou fora do alcance do Resolve, com o motivo. A coluna Falhou conta os hosts onde a última tarefa do Resolve que levou a atualização não a instalou.

A coluna Resolve instala diz se o Resolve leva a atualização:

• Atualizações de segurança são oferecidas em todo host que pode receber uma tarefa.
• Atualizações comuns (drivers, componentes da plataforma, definições) só são oferecidas depois que alguém as libera.
• Atualizações do Windows sem número KB, em geral drivers, ainda não são instaladas pelo Resolve: o agente localiza as atualizações do Windows pelo número KB. O Windows Update ou a ferramenta do fabricante as instala.

Uma decisão vale para a organização inteira:

• Liberar. O Resolve oferece a atualização em todo host que pode instalá-la, inclusive as comuns.
• Recusar. O Resolve deixa de oferecê-la em todos os hosts, e o risco após as atualizações de segurança não a considera. O motivo é obrigatório. Os achados dela continuam abertos: recusar uma atualização não é aceitar o risco dos achados, que é uma decisão separada, tomada nos próprios achados.
• Desfazer decisão. Volta para não avaliada: atualizações de segurança são oferecidas, as comuns não.

Toda decisão registra quem decidiu, quando e por quê, e vai para o log de auditoria. Ela vale para uma versão, então a atualização do mês seguinte é uma nova linha para avaliar. Ela define o que o WASViking oferece; as atualizações automáticas do próprio sistema operacional ficam fora dela.

Selecione atualizações e use Agendar nos hosts que estão sem elas para criar uma tarefa do Resolve por host, levando só essas atualizações. Cada tarefa segue a governança do ambiente do host. Os aprovadores de um ambiente formal recebem um pedido para o grupo inteiro, e a aprovação em lote do Resolve decide todas juntas. Hosts com outra mudança em andamento, sem agente, com política que bloqueia tarefas de patch ou com plano de reversão exigido e não preenchido são ignorados e contados.

Regras de implantação automática

Uma regra instala atualizações pendentes sozinha, na janela de manutenção de cada host, dentro do que ela permite. Abra Gerenciamento de patches, Implantação automática, e escolha Nova regra. Uma regra responde a quatro perguntas:

• Quais hosts. Servidores, estações ou os dois; os ambientes; opcionalmente algumas políticas, sites ou tags (só hosts com uma das tags marcadas, ou nunca hosts com uma das tags excluídas); nunca os hosts que você excluir. Só hosts com agente contam. Um host pertence a uma regra só: a mais antiga que o inclui.
• Quais atualizações. Atualizações de segurança pela pior gravidade dos achados que elas fecham no host (crítica, alta, média, baixa, ou sem gravidade conhecida para uma atualização de segurança não associada a nenhum achado) e, opcionalmente, as atualizações comuns que a organização liberou e aplicativos de terceiros no Windows. Uma regra pode esperar alguns dias depois de a plataforma ver a atualização na frota pela primeira vez.
• Quando. Sempre dentro da janela de manutenção da política de cada host, no relógio do próprio host; a janela de uma política pode abrir em vários dias da semana. Em toda janela, ou uma vez por mês: a primeira janela alguns dias depois da Patch Tuesday.
• Como. Reiniciar quando uma atualização pedir, onde a política do host permite reinício automático; no máximo um número de hosts ao mesmo tempo; hosts piloto primeiro e os demais só depois que eles derem certo; e pausa quando mais de uma parte definida dos jobs de uma janela falha.

O agente distingue servidor de estação pela edição do sistema no Windows (Windows Server contra Windows 10 e 11), pela interface gráfica ou por uma sessão gráfica ativa no Linux, e todo Mac é estação. A página do ativo pode fixar o tipo de um host ("Tratar como servidor" ou "Tratar como estação"); o que você fixar decide se um reinício pergunta antes à pessoa conectada e quais regras pegam o host. As tags são adicionadas na página do ativo ou, para vários hosts de uma vez, na lista de Ativos: marque os hosts, digite a tag e escolha Adicionar tag aos selecionados.

Nunca entram num job da regra: uma atualização recusada, uma atualização retida depois de uma reversão no host, uma atualização que falhou duas vezes no host em 30 dias, e uma atualização ainda não testada num ambiente inferior quando a governança de aprovação do ambiente exige (ela espera uma janela seguinte). Aplicativos de terceiros entram numa janela sem atualização do sistema operacional pendente para o host, porque um host recebe um job por vez.

Aprovação. Salvar uma regra pede a governança de aprovação de cada ambiente que ela atinge: um ambiente automático assina na hora, um ambiente de uma pessoa precisa de um aprovador, e um ambiente formal precisa do seu quórum e nunca conta quem salvou a regra. A regra fica aprovada por 90 dias; depois disso não cria nada até todos os ambientes assinarem de novo. Mudar os hosts ou as atualizações pede as assinaturas de novo e cancela os jobs que nenhum host pegou ainda; mudar o nome, o reinício ou o ritmo, não.

Em cada janela. Trinta minutos antes de a janela de um host abrir, a regra cria o job do host com o que ela permite naquele host e o aprova em nome do aprovador do ambiente, com um registro de decisão que cita a regra. O job leva o selo Automático no Resolve e segue a janela como qualquer job: um host desligado durante toda a janela o recebe na próxima. A página da regra conta cada janela em palavras: um estado (Tudo certo, Com falhas, Em andamento, Hosts perderam a janela, Cancelada, Nada a instalar) e uma frase como "2 hosts: instalou em srv-a, 1 sem nada a instalar". Abra uma janela para ver cada host com o que aconteceu com ele, as atualizações que instalou, o risco antes e depois, a última linha do log quando falhou, por que não recebeu nada (por exemplo, atualizações pendentes comuns ou de terceiros enquanto a regra só pega atualizações de segurança) e um link para o job; os números filtram a lista. Pausas, retomadas e mudanças da regra aparecem entre as janelas. O bloco Hosts desta regra lista os hosts em que a regra instala, cada um com a janela da política e o último resultado, e os hosts com agente que ela deixa de fora, com o motivo (tipo, ambiente, tags, uma regra mais antiga). Precisa de atenção fica na página e diz quando nada precisa de uma pessoa. A Prévia host a host mostra o que a regra instalaria agora. Depois de cada janela, quem salvou a regra e quem a assinou recebem um resumo por e-mail; o resultado de cada job também chega aos canais de alerta da organização.

Hosts fora de todas as regras continuam como antes: o Resolve recomenda e uma pessoa agenda.

O Gerenciamento de patches abre numa Visão geral: a próxima ação recomendada (uma instalação que falhou, uma regra aguardando assinatura, uma atualização comum aguardando decisão, um host de regra sem janela, nessa ordem), seis indicadores que abrem o próprio recorte da lista (atualizações aguardando decisão, atualizações que fecham achados, hosts aguardando reinício, jobs implantados pelo Resolve desde o início, regras ativas com o que instalaram em 30 dias, e o que precisa de uma pessoa), o estado da regra com a última janela, a atividade recente das regras e a última queda de risco que a reavaliação confirmou. Atualizações e decisões mantém todos os contadores, o gráfico, a lista e as ações Liberar, Recusar, Desfazer decisão e Agendar, agora em três partes: atualizações do sistema (com busca, filtro por decisão, o impacto de risco, a decisão e a implantação de cada pacote em palavras), aplicativos de terceiros e histórico do Resolve; um botão Ver pacote abre cada atualização. Implantação automática tem as regras e, ao lado, Execuções e resultados: uma linha por host e janela em todas as regras, com filtro por regra, resultado ou host, e CSV. A página da regra tem quatro abas (Resumo, Hosts e elegibilidade, Janelas e jobs, Aprovação e registro) e o formulário da regra é um assistente de seis passos cujo último passo resume a regra em palavras e a mostra host a host antes de salvar qualquer coisa.

Aplicativos de terceiros no Windows

Navegadores, leitores, runtimes e outros aplicativos têm a sua própria ação, "Upgrade third-party applications" (atualizar aplicativos de terceiros), alimentada pelos upgrades que o canal winget oferece naquele host. Ela segue o mesmo congelamento, a mesma aprovação e o mesmo resultado por item, e o agente atualiza cada aplicativo pelo seu id de canal e nada que o job não tenha nomeado. Para os aplicativos que o motor de detecção mapeia (navegadores, clientes de e-mail, editores, runtimes e outros softwares comuns de desktop), a versão instalada é comparada com a NVD por produto e versão, então a ação mostra as vulnerabilidades que o upgrade fecha e a pontuação esperada, como faz uma atualização de segurança. Um aplicativo sem mapeamento mantém o rótulo "app currency" (atualidade do aplicativo), e o job o mantém na versão atual do fornecedor. O veredito é o próximo inventário deixar de oferecer o upgrade, com os achados que ele fechou.

Reinicializações

Uma mudança por vez. Logo antes de instalar, o agente lê os sinais de reinicialização do próprio host: a servicing stack, o Windows Update e as renomeações de arquivo pendentes no Windows; o marcador reboot-required ou o needs-restarting no Linux. Quando uma reinicialização de uma mudança anterior ainda está pendente, o job fica retido em vez de empilhar uma segunda mudança sobre uma inacabada. A tela Resolve mostra "Held, restart pending" (retido, reinicialização pendente) com o motivo, o ativo mostra desde quando e depois de qual mudança a reinicialização é devida, e o job é retomado sozinho no momento em que o host reporta a reinicialização concluída.

A política decide a exceção: reiniciar o host primeiro (somente quando o aprovador também concedeu a reinicialização) ou instalar mesmo assim. No Windows, atualizações de segurança e rollbacks continuam esperando pelos sinais da servicing stack e do Windows Update, já que o Windows Update recusa instalações enquanto eles existem. As renomeações de arquivo pendentes são um sinal fraco: soluções de proteção de endpoint e instaladores as gravam o tempo todo e uma reinicialização nem sempre as limpa, por isso elas não retêm o upgrade de uma aplicação de terceiros, e um job retido só por elas roda assim que o host tiver reiniciado. Uma ação "Restart host" (reiniciar o host) no próprio job retido, no ativo e na tela Agents encerra a espera com um clique, para pessoas com a permissão Remediate. Um aprovador também pode rodar um job retido sem a reinicialização, com um motivo declarado que fica no registro de aprovação do job e no log de auditoria. Um job que ainda espera depois de um dia gera um alerta nos seus canais.

Uma reinicialização também pode ser agendada como um job próprio. A tela Resolve recomenda "Restart host to finish pending changes" (reiniciar o host para concluir mudanças pendentes) para todo host com uma reinicialização pendente, e o relatório "Hosts waiting for a restart" (hosts aguardando reinicialização) lista esses hosts do mais antigo para o mais recente, com a causa, a função do host, as sessões conectadas e a política aplicável, com uma exportação CSV e uma ação "Schedule restart for all" (agendar reinicialização para todos). Um job de reinicialização segue o mesmo contrato de qualquer mudança: aprovação conforme a política, a janela de manutenção e um veredito do próximo inventário, que comprova a reinicialização pelo horário de boot que o host reporta. O agente distingue servidores de estações de trabalho por conta própria. Um servidor reinicia após a contagem regressiva que a política define; uma estação de trabalho com uma pessoa conectada recebe antes uma pergunta e pode adiar quantas vezes a política permitir, e depois disso a contagem regressiva roda sem pergunta. Um host cuja reinicialização permanece pendente por sete dias gera o seu próprio alerta, com ou sem job.

Reinicialização pendente, no menu do Infrastructure Defense, lista em uma tela própria todos os hosts aguardando reinicialização: o que causou, desde quando, quem está conectado, o último boot e contato, o que a política do host faz e a nota de risco, com contadores para os atrasados, os que têm usuários conectados, os que seguram jobs do Resolve e os que já estão agendados. Marque hosts e use Agendar a reinicialização para ver a mudança host a host (aprovação, janela, aviso, ou por que um host é pulado) e criar um job de reinicialização por host; Reiniciar agora envia ao agente um comando imediato, fora de qualquer janela ou aprovação, para quando uma pessoa decidiu que não pode esperar.

Acompanhar um job

Todo job em andamento diz onde está e qual é o próximo passo: esperando o próximo check-in do agente (com o último contato dele), esperando a janela de manutenção, retido por uma reinicialização (o sinal, quantas verificações até agora, a próxima verificação e quando a retenção expira), rodando no host ou confirmando o resultado.

Enquanto um job roda, o agente reporta cada passo no momento em que acontece: a fase (verificando o host, atualizando as fontes de pacotes, baixando, aplicando, conferindo o resultado), o pacote ou a aplicação em que está, quantos já foram concluídos, com uma barra de progresso quando o gerenciador de pacotes informa o total, há quanto tempo o job está rodando e quando o agente reportou pela última vez. O Windows Update reporta as fases de download e instalação; winget, apt e dnf reportam item a item. Um job cujo agente continua reportando não é dado como falho pela janela de resultado, por mais longa que seja a transação. A tabela do Resolve se atualiza sozinha enquanto há jobs em andamento, e o passo em execução é atualizado no próprio lugar.

Um job aprovado para um host cujo agente parou de fazer check-in, por exemplo porque a proteção de endpoint o removeu, mostra o agente offline desde o último contato, gera um alerta depois de um dia e falha depois de sete dias com uma nota que diz o que fazer. Os jobs em espera de um host cujo agente é removido são cancelados na hora, e um job cancelado guarda o que estava esperando.

A tabela de jobs do Resolve foi feita para volume. Chips no topo filtram por situação (aguardando decisão, em andamento, concluídos, com falha ou parciais, rejeitados ou cancelados), cada um com a sua contagem; ao lado, um host, um tipo de job (atualizações de segurança, aplicativos de terceiros, reinicializações, reversões, mitigações, regras automáticas), um período e uma busca livre (host, pacote, id do job ou lote) estreitam a lista. Os filtros ficam no endereço da página, então uma visão filtrada pode ser compartilhada ou salva nos favoritos. A tabela mostra 25 jobs por página, do mais novo para o mais antigo, e diz quantos correspondem. Os jobs que aguardam a sua decisão ficam no topo da página seja o que for que a tabela mostre, e os cartões de resumo contam todos os jobs, não só a página. A nota abaixo do status de um job, o que a reavaliação verificou, por que um job está retido, quem o cancelou, aparece no idioma do portal.

A coluna de risco se lê como uma frase, não como um par de números. Antes é a nota do host quando o job foi criado (Agora, numa ação recomendada); Esperado é a nota que a mudança deve alcançar; Depois é a nota que a reavaliação mediu depois que o job rodou, e é a que vale. A diferença vem em palavras: uma queda em pontos em verde, "Sem mudança", ou uma subida em vermelho numa reversão, que sobe a nota de propósito. Quando a nota não mexeu, uma linha abaixo dos números diz por quê: o achado que a nota segue, ou o fato de que o que o job fechou não define a nota. "O que é a nota VES?" ao lado das tabelas abre a explicação.

Reverter uma mudança

Um job de atualização de segurança concluído em um host Linux ou Windows oferece "Roll back this change" (reverter esta mudança): um job de rollback para os mesmos pacotes, cada um devolvido à versão exata que tinha antes, com um motivo obrigatório, o plano de reversão herdado e as regras de aprovação, janela e reinicialização de qualquer outra mudança. O Linux faz o downgrade pelo gerenciador de pacotes e não toca no kernel; o Windows remove cada atualização pelo seu KB por meio do Windows Update e reporta as que a plataforma não permite remover; o macOS não tem caminho de desinstalação, e a tela informa isso. A reavaliação mede o resultado como ele é, por exemplo "VES 70 to 88, 3 of 3 packages returned, 17 vulnerabilities open again" (VES de 70 para 88, 3 de 3 pacotes devolvidos, 17 vulnerabilidades abertas de novo), e as atualizações devolvidas ficam retidas fora das recomendações pelos dias que o job pediu, visíveis no host e liberadas antes do prazo com um clique. Veja Reverter uma mudança que deu problema.

Patches aplicados, uma aba do Gerenciamento de patches, lista toda atualização que o Resolve instalou por patch e por host, com a versão que substituiu, quando, o job que comprovou e se pode voltar. Marque pacotes em um ou vários hosts e use Reverter a seleção: a prévia mostra, host a host, exatamente o que volta, os achados que reabrem, a nota esperada e a aprovação do ambiente, com cada escolha que não pode voltar explicada (um kernel, uma atualização sem versão anterior, um pacote atualizado de novo depois, um job em andamento). Criar os jobs gera um job de reversão por host só com os pacotes escolhidos, com motivo obrigatório e uma espera que os mantém fora do Resolve pelos dias escolhidos. Atualizações instaladas fora do Resolve não aparecem, porque a plataforma não sabe a versão para a qual voltar. Cada host que pode voltar traz também um botão Reverter, que abre a prévia daquele pacote naquele host, e a página de qualquer job de atualização concluído oferece os mesmos dois caminhos: reverter o job inteiro ou escolher os pacotes em Patches aplicados.

Mitigar sem patch

Nem todo achado se fecha com uma atualização. A tela Mitigation altera o próprio host quando um patch não é a resposta: um valor de registro, o estado de um serviço, um parâmetro do kernel do Linux, um script aprovado da sua própria biblioteca, ou a instalação ou remoção de um software. Mitigações prontas corrigem os controles de postura com falha que elas nomeiam, e workarounds documentados contêm vulnerabilidades conhecidas do Windows que ainda não têm correção aplicada; um workaround verificado marca o achado como "Mitigated, no fix applied" (mitigado, sem correção aplicada), o que o trata na pontuação como um risco aceito e o reabre no momento em que a mudança é revertida. As mesmas ações rodam antes e depois das atualizações de um job de patch, por exemplo um serviço parado antes e iniciado de novo depois.

Toda mudança é um job sob a governança de aprovação do ambiente do host. Uma mudança de script ou de software não é aprovada automaticamente, os scripts ficam desligados até que a sua organização os ligue e exigem a revisão de uma segunda pessoa, e um host pode recusá-los na configuração local. O agente registra o que cada mudança substituiu para que ela possa ser desfeita, o inventário seguinte prova que ela se manteve, e uma mudança que algo coloca de volta aparece como Reverted, com um alerta. Veja Mitigar um achado sem patch.

Governança de aprovação

A governança de aprovação decide quem autoriza, por ambiente. Cada host traz um ambiente (produção, staging, desenvolvimento ou outro), e a tela Approval Governance define uma regra para cada um: seguir a política de host, aprovar automaticamente, deixar uma pessoa aprovar (inclusive o solicitante) ou exigir uma aprovação formal. Uma regra formal diz de quantas aprovações um job precisa e, opcionalmente, quem pode dá-las, por nome ou por papel; a pessoa que agendou o job não conta.

Toda decisão é registrada com quem decidiu, quando, o motivo declarado e a referência da mudança, e os registros de aprovação são exportados como CSV: a evidência que uma auditoria de controle de mudanças pede. Uma regra de produção também pode exigir que os mesmos pacotes tenham sido concluídos em staging ou em desenvolvimento dentro de uma janela antes que a produção os aceite; um job que chega sem teste informa isso, e um aprovador precisa dispensar a exigência de propósito. A pessoa que agenda uma mudança pode declarar por que ela é necessária e como é desfeita, e uma regra pode recusar uma mudança agendada sem esse plano de reversão; ambos ficam no registro de aprovação e na exportação.

Aprovações que esperam além da janela definida na regra são canceladas, aprovações formais em espera são anunciadas aos seus canais de alerta e aos aprovadores por e-mail, e o solicitante fica sabendo da decisão. Quando a regra permite, uma aprovação de emergência executa o job sem o quórum, com um motivo declarado; todo aprovador é notificado e o job permanece sinalizado até que outro aprovador o revise. Quando a regra nomeia os seus aprovadores, o caminho de emergência também pertence a essa lista.

Um job responde ao ambiente em que foi criado. Mover um host para um ambiente menos protegido depois disso não muda nada para os jobs que já estão esperando, e a própria movimentação exige a permissão Approve, é registrada com o antes e o depois e gera um alerta nos seus canais.

Políticas

As políticas decidem até onde a plataforma pode ir em cada grupo de hosts: o que é avaliado, se os jobs precisam de aprovação manual onde a governança segue a política, e quando as mudanças são permitidas. A mesma política define quanto de cada máquina o agente pode usar, como descrito em Agente Sentinel Host: requisitos e operação. Toda ação vai para a trilha de auditoria, e o resultado de um job de patch pode notificar os seus canais de Slack, Teams, e-mail ou webhook.

A janela de manutenção é um ou mais dias da semana com início e fim, lidos no relógio de cada host: uma janela das 22:00 abre às 22:00 onde o host está. A janela pode passar da meia-noite (22:00 às 02:00 termina no dia seguinte). Um job aprovado sem Run now só é entregue ao host enquanto a janela está aberta, e a linha do job no Resolve diz quando ela fecha. Quando o host fica desligado ou offline durante a janela inteira, o job passa para a próxima, então uma mudança nunca começa fora dela. Um job com passos assinados que venceriam antes da próxima janela é cancelado com uma nota, para ser agendado de novo. O Run anyway (executar mesmo assim) em um job retido por reinicialização libera a retenção, não a janela.