duct_tape_coder's questions

Tentamos configurar as permissões de uma chave de registro (HKLM\Software) via GPO. ( https://www.stigviewer.com/stig/windows_server_2019/2019-12-12/finding/V-93025 )

No entanto, isso resultou em um "SID de capacidade" necessário ( https://answers.microsoft.com/en-us/windows/forum/all/what-the-heck-account-unknowns-1-15-3-1024/65852c0e -d185-4eef-abfb-967263519cc0?page=2 ) sendo removido das permissões.

Infelizmente não há como adicionar manualmente um SID por meio do GPMC GP Editor. Você deve procurar um usuário existente, mas os "SIDs de capacidade" não possuem mapeamento de usuário por design.

Existe uma maneira de recuperar esse SID nas permissões de registro via GPO de domínio?

Estou trabalhando na criação de um Docker Swarm de 3 gerenciadores usando o Docker CE 19.03 e três máquinas CentOS 7.

Instalei o docker via yum, habilitei o serviço e o iniciei.

Eu criei um 'serviço' firewalld e permiti (por docker docker):

• Porta TCP 2377 para comunicações de gerenciamento de cluster
• Porta TCP e UDP 7946 para comunicação entre nós
• Porta UDP 4789 para tráfego de rede de sobreposição

Consegui iniciar o enxame e me juntar a um trabalhador. O terceiro servidor que tentei entrar como gerente no entanto e falhou com

Resposta de erro do daemon: gerenciador parado: não é possível inicializar nó de jangada: erro de rpc: código = Desconhecido desc = não foi possível conectar ao novo membro de cluster potencial usando seu endereço anunciado: erro de rpc: código = Prazo Excedido desc = prazo de contexto excedido

Então eu desisti docker swarm leavee tentei entrar como trabalhador. Deu certo sem problemas. Agora, por que eu não entraria como gerente, mas entraria com sucesso como trabalhador?

Eu tentei permitir 2376/tcp (por https://www.digitalocean.com/community/tutorials/how-to-configure-the-linux-firewall-for-docker-swarm-on-centos-7 ) e desabilitar firewalld em o único gerente para ver se era um problema de firewall, mas recebi o mesmo erro.

TL;DR em negrito

Olá, configurei um novo namespace e replicação DFS para um compartilhamento de software e usuário de um servidor 2012R2 mais antigo para um servidor 2019 mais recente para o qual desejamos migrar. Deixei os servidores funcionando há vários dias, mas não parece haver nenhum progresso na replicação.

A execução dfsrdiag backlogmostra "Nenhum membro do Backlog x está em sincronia com o parceiro y", mas isso claramente não é o caso. A execução de um relatório de replicação DFS mostra que nenhum arquivo ou pasta foi copiado e que as unidades no novo servidor não mudaram de tamanho desde os 753 MB iniciais consumidos quando a replicação foi configurada.

No log de eventos de Replicação DFS no servidor antigo, tenho um log contínuo de aproximadamente 25.000 eventos por minuto, todos indicando o evento 4308: "O serviço de Replicação DFS foi recuperado com êxito de violações de compartilhamento encontradas em um arquivo". Parece estar acionando o evento para cada arquivo no compartilhamento, um por um.

Em um ponto, chegou a uma pasta que está corrompida e apenas enviava spam com o nome da pasta continuamente. Parei e reiniciei o serviço DFS e parece reiniciar todo o processo de spam em arquivos que já vi passar. Agendei uma chkdsk /freinicialização para lidar com a corrupção esta noite. No entanto, parece-me lógico que o sistema possa replicar os arquivos não corrompidos nesse meio tempo.

Por que estou recebendo tantos eventos 4308 no log? Ele está rolando o log de 15 MB basicamente a cada minuto e não há nada no log além de 4308 eventos. Não quero aumentar o log ou forçá-lo a arquivar, pois isso apenas encherá meu sistema com mais eventos inúteis. Enquanto isso, estou vendo todas essas recuperações e nenhum erro inicial. Não há nenhum progresso visível.

Mais detalhes (provavelmente não relevantes): o servidor antigo está em um cluster Hyper-V Failover usando discos de cluster iSCSI para as unidades. Os compartilhamentos são hospedados a partir de montagens iSCSI diretas dentro do servidor. O novo servidor é VMware com drives fornecidos pelo vSAN (armazenamento de dados virtual replicado em hosts locais). Ambos os servidores têm o Backup do Windows configurado, o backup do servidor antigo leva cerca de 18 horas e deixa apenas 6 horas por dia para replicação (o Backup do Windows parece pausar a Replicação DFS). No entanto, nenhum progresso é feito durante essas 6 horas, então não acho que o backup seja o principal culpado. Eu fiz dfsrdiag polladpara ambas as máquinas que não muda nada. O destinatário geralmente fica lá fazendo coisas nos logs, exceto ocasionalmente reclamando diariamente sobre o backup do Windows, deixando a replicação offline por ~ 30 minutos. O servidor antigo faz o spam acima.