Política de Grupo: Unidades mapeadas falham ao carregar, Windows Server 2012 Active Directory e Windows Pro 10

Question

Rede:

• domínio de vários sites.
• Cada site tem 2 controladores de domínio locais (no local, mesma sub-rede) do Windows Server 2012 R2.
• Os sites estão definidos corretamente em sites e serviços do Windows.
• Os registros DNS de cada site SOMENTE têm os dois servidores DNS locais definidos.
• TODOS os clientes são o Windows 10 Pro de 64 bits com todas as atualizações.
• As duas redes são totalmente executadas em switches Cisco com cabeamento certificado CAT6.
• Cada site tem um servidor de armazenamento Synology local (on-site, mesmo sub-rede).
• Como parte da Política de Grupo, duas unidades de rede são mapeadas para compartilhamentos no servidor Synology.

Diagnóstico de conectividade:

• dcdiag /test:dns /v /c /e relatórios PASS para TODOS os servidores e TODOS os testes
• echo %logonserver% sempre retorna um DC local
• nltest /dsgetdc sempre mostra um DC local e corrige o IP local
• No Site A, as duas unidades de rede são exibidas, com talvez uma chance de 0,5% de falha (experimentei algumas inicializações em que as unidades não são exibidas corretamente).

Problema:

No Site B, as unidades de rede não são exibidas 30% do tempo. Às vezes são as duas unidades, às vezes é uma ou outra. O problema é principalmente aleatório e não parece seguir nenhum usuário ou estação de trabalho em particular.

Sintomas:

Dos 30% do tempo em que um problema se apresenta:

• 5% das vezes, um gpupdate ou gpupdate /force corrigirá o problema e as unidades aparecerão imediatamente. Se o gpupdate não funcionar na primeira tentativa, ele praticamente nunca funcionará depois disso (para essa inicialização)
• 5% do tempo em que gpupdate ou gpupdate /force fará com que apenas uma unidade apareça
• 20% do tempo, um gpupdate não corrigirá o problema, mas a próxima inicialização será satisfatória
• Em 50% do tempo, um gpupdate não corrigirá o problema, mas após uma inicialização e outra gpupdate , as unidades aparecerão

• 20% do tempo, serão necessárias várias reinicializações (e gpupdate para cada inicialização) antes que as unidades apareçam. Às vezes é 2 botas, mas eu tive que raramente reiniciar um computador, por vezes, 6 ou 7 vezes antes de as unidades aparecerem.

  • Nos últimos 20% do tempo, às vezes recebo erros do processo gpupdate.

    The processing of Group Policy failed. Windows attempted to read the file 
    \domain\SysVol\domain.local\Policies{5898270F-33D0-41E8-A516-56B3E6D2DBAB}\gpt.ini 
    from a domain controller and was not successful. Group Policy settings may not be 
    applied until this event is resolved. This issue may be transient and could be 
    caused by one or more of the following:  
    
    a) Name Resolution/Network Connectivity to the current domain controller.  
    b) File Replication Service Latency (a file created on another domain controller 
       has not replicated to the current domain controller).  
    c) The Distributed File System (DFS) client has been disabled.
    

  • Este erro é, na verdade, normalmente mas nem sempre, um sinal bom porque geralmente depois de receber este erro, a próxima ´gpupdate´ ou a próxima inicialização e "atualização" fará as unidades reaparecerem.

Diagnósticos do Mapa do Drive:

1. gpresult /h gpresult.html mostra:

   Drive Map (Drive: X)
    The following settings have applied to this object. Within this category, settings nearest the top of the report are the prevailing settings when resolving conflicts.
      X:
       Winning GPO  DriveMaps 
        General Settings
         Result: Success
   

2. Eu habilitei o log de depuração do ambiente de diretiva de grupo (por link criou a entrada de registro [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002 ). O arquivo de log em c:\Windows\debug\UserMode\gpsvc.log não me mostrou erros claros, nem consegui encontrar muita ajuda através do google. Aqui estão algumas mensagens interessantes que recebi:

   GPSVC(158.33c) 23:33:24:921 CheckGPOs: No GPO changes but extension Group Policy Drive Maps's returned error status 183 earlier.  
   GPSVC(158.c24) 23:38:12:203 ProcessGPOs(Machine): Extension Group Policy Drive Maps skipped with flags 0x110057. 
   GPSVC(158.157c) 23:08:08:216 ProcessGPOs(User): Extension Group Policy Drive Maps ProcessGroupPolicy failed, status 0xb7.
   

3. Eu ativei a depuração de preferências de política de grupo para o Drive Maps (conforme link defina Drive Map Policy Processing para Enabled e ative Event Logging nas propriedades de \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing ). O arquivo de log em C:\ProgramData\GroupPolicy\Preference\Trace\User.log não retornou nenhum erro.

   2015-11-21 17:47:38.849 [pid=0x22c,tid=0xcd0] Starting class <Drive> - X:.
   2015-11-21 17:47:38.864 [pid=0x22c,tid=0xcd0] Adding child elements to RSOP.
   2015-11-21 17:47:38.880 [pid=0x22c,tid=0xcd0] Beginning drive mapping.
   2015-11-21 17:47:38.896 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] User does not have a split token.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] Drive doesn't exist (full token).
   2015-11-21 17:47:39.114 [pid=0x22c,tid=0xcd0] Connected with access name x:.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification Session ID is 2.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification discovered drive mask of 8388608.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] SendNotification drive event broadcast sent.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] SendNotification to Shell.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Properties handled.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Handle Children.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] EVENT : The element of user preferences 'X:' of the group policy object 'DriveMaps {06FEB8B9-632C-4A1C-A7C9-5A05E1041BEE}' was applied correctly.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] Completed class <Drive> - X:.
   

4. Eu também tenho várias capturas netmon de um login com unidades não carregadas, mas a captura tem tanta informação que não sei por onde começar.

5. Se, após um login com falha, eu tentar navegar diretamente para \SynologyServer\ShareName\ , o compartilhamento sempre será carregado imediatamente sem nenhum erro. Não há sinais de problemas de conexão ou permissão.

Pergunta:

Por que esse problema ocorre com tanta frequência em um site, mas quase nunca no outro site, quando ambos estão no mesmo domínio, têm a mesma política e estão executando o mesmo software?

A única diferença de software que posso imaginar é que, no Site A, todos os computadores estavam executando o Windows 8.1 Pro e foram atualizados para o Windows 10 Pro, enquanto no Site B, todos os computadores têm novas instalações do Windows 10 Pro.

    

Answer 1

Como eu quase não tenho representante, ainda não posso fazer perguntas, por isso vou tentar fazer uma pergunta enquanto coloco uma resposta e espero não ser enlatada. ;)

Suponho que você tenha assegurado que a parte do GPO deste caso não é um problema, testando esse GPO em relação a um compartilhamento UNC "tradicional" em outro sistema Windows. A informação importante que falta, na minha opinião, é se os dispositivos da Synology estão ou não associados ao domínio. Muitas unidades NAS baseadas em Linux, como Synology, QNAP, e outros, possuem componentes de software integrados que permitem a participação em domínios do Active Directory. Se o dispositivo está ou não participando do domínio, isso afeta a solução.

Dito isto, tenho instalações remotas na minha rede interconectadas com circuitos T1. Nós exigimos o uso de backups de imagens Acronis em todos os sistemas devido aos requisitos do sistema. Assim, o backup remoto de imagens de vários GB de estações de trabalho do Windows em T1s é um não-inicial. Então, colocamos unidades Drobo NAS em cada segmento local para superar isso e nos dar um pouco de tolerância a falhas. Esses Drobos em particular não têm a capacidade de participar do domínio do AD.

Para ativar os compartilhamentos UNC conforme configurados, tivemos que configurar duas coisas principais. Primeiro, criamos entradas DNS estáticas nos servidores DNS para permitir a resolução correta de nomes. Em segundo lugar, tivemos que "soltar" duas políticas que a DISA normalmente recomenda para a maioria dos membros do domínio. Nós apenas soltamos essas políticas no servidor de backup, e as estações de trabalho foram copiadas em sites de "link lento", já que esses eram os únicos sistemas que precisavam acessar os respectivos compartilhamentos:

• Configuração do computador \ Configurações do Windows \ Configurações de segurança \ Opções de segurança:
  • Microsoft Network Client: assinar digitalmente as comunicações (sempre) = desativado
  • Microsoft Network Client: Enviar senha não criptografada para servidores SMB de terceiros = Ativado
  • Servidor de rede da Microsoft: assinar digitalmente as comunicações (sempre) = desativado

Os GPOs para "Assinar digitalmente as comunicações, se negociados" ainda estão definidos como Ativados, atenuando um pouco do risco de segurança envolvido. Depois que ativamos essas alterações, os compartilhamentos puderam ser acessados imediatamente por meio do caminho UNC, enquanto anteriormente era impossível.

É por isso que eu disse anteriormente que, dependendo se os seus NASes podem participar do domínio ou não, determinam o caminho da solução. Se eles podem participar, o DNS e as políticas de grupo "SMB" não devem ser um problema para você e, portanto, a solução estaria em outro lugar. Se eles NÃO PODEM participar (como os meus NASes), então esta pode ser a sua solução.

    

Answer 2

Bem, eu encontrei esses tópicos, e parece uma situação quase idêntica à minha:

Windows 10: Diretiva de Grupo falha ao aplicar diretamente após o boot, é bem sucedido depois

As unidades mapeadas do Windows 8.1 / 10 GPO não se conectam

Aparentemente, esse problema é causado pela Microsoft, que habilita o UNC Hardening no Windows 10 por padrão. Isso é para corrigir uma falha de segurança, mas aparentemente involuntariamente faz com que as unidades mapeadas sejam montadas de maneira não confiável. Não surpreendentemente, parece que a Microsoft ainda tem que resolver esse bug (ou eles têm?)

Isso também explica por que eu não estava tendo problemas no Site A. Como todos os computadores foram atualizados do Windows 8.1 Pro para o Windows 10, presumo que as configurações relacionadas ao UNC Hardening tenham sido transferidas do Windows 8 e permanecessem off , enquanto os computadores com a nova instalação do Windows 10 usaram o padrão de proteção UNC on .

Eu ainda não tentei a solução ainda, mas parece perfeito demais para meus sintomas não serem relevantes. Estou preocupado com uma solução que abre meu sistema para mais ameaças de segurança, então estou procurando alternativas. Eu não gosto da idéia de definir isso via política de grupo, e estou querendo saber se é possível desativar o fortalecimento UNC via edição manual do registro apenas. Eu quero experimentar alguns computadores antes de decidir o que fazer a seguir. No entanto, só posso encontrar etapas para alterar a configuração via GPO ou GPP atualmente ...

Alguma opinião?

    

Answer 3

Depois de ler tudo o que você forneceu na atualização Daniel, eu realmente sugiro que o hardening da UNC, embora relacionado, não é a causa raiz aqui, e que pode ser a opção "fastboot" que o OP do segundo post disse resolveu seu problema. Todas essas informações sobre o hardening UNC referiam-se aos compartilhamentos SYSVOL e NETLOGON ficando endurecidos por padrão. Embora esse problema impeça que seus clientes recebam atualizações do GP, o fato é que o GPO do Google Drive Map já foi aplicado pelo menos uma vez aos clientes em questão e NÃO PRECISA reaplicar após cada reinicialização (mesmo que tenha) para ser executado o mapeamento.

Obviamente, você desejará testar cada opção independentemente da outra, mas, independentemente de qual opção pode ou não funcionar, essa linha de raciocínio parece estar próxima da causa raiz do problema.