Diretiva de Grupo: Unidades mapeadas que não carregam, Windows Server 2012 Active Directory e Windows Pro 10

Rede:

• Domínio de vários sites.
• Cada site possui 2 controladores de domínio local (no local, mesma sub-rede) do Windows Server 2012 R2.
• Os sites estão definidos corretamente nos Serviços e Sites do Windows.
• Os registros DNS para 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.
• Ambas as redes são totalmente gigabit em execução nos comutadores Cisco com cabeamento CAT6 certificado.
• Cada site possui um servidor de armazenamento Synology local (no local, mesma sub-rede).
• Como parte da Diretiva de Grupo, duas unidades de rede são mapeadas para compartilhamentos no servidor Synology.

Diagnóstico de conectividade:

• dcdiag /test:dns /v /c /erelatórios PASSpara TODOS os servidores e TODOS os testes
• echo %logonserver% sempre retorna um controlador de domínio local
• nltest /dsgetdc sempre mostra um controlador de domínio local e o IP local correto
• No site A, as duas unidades de rede são exibidas, com uma chance de 0,5% de falha (experimentei algumas inicializações nas quais as unidades não aparecem corretamente).

Questão:

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

Sintomas:

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

• 5% das vezes um gpupdateou gpupdate /forcecorrigirá o problema e as unidades aparecerão imediatamente. Se gpupdatenão funcionar na primeira tentativa, nunca funcionará depois disso (para essa inicialização)
• 5% do tempo gpupdateou gpupdate /forcefará com que apenas uma unidade apareça
• 20% do tempo, a gpupdatenão resolverá o problema, mas a próxima inicialização será boa
• 50% do tempo, a gpupdatenão solucionará 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 gpupdatepara cada inicialização) antes que as unidades apareçam. Às vezes, são 2 inicializações, mas raramente precisei reiniciar um computador 6 ou 7 vezes antes das 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.
    

  • Esse erro é realmente, geralmente , mas nem sempre, um bom sinal, porque geralmente depois que eu recebo esse erro, o próximo 'gpupdate' ou a próxima inicialização e o 'gpupdate' farão as unidades reaparecerem.

Diagnóstico do mapa de unidades:

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. Habilitei o log de depuração do ambiente de diretiva de grupo (por http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx criado entrada de registro [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). O arquivo de log c:\Windows\debug\UserMode\gpsvc.lognão me mostrou nenhum erro claro, nem consegui encontrar muita ajuda no 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. Ativei a depuração de preferências de diretiva de grupo para o Google Maps (conforme http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the -rsat.aspx conjunto Drive Map Policy Processingcom Enablede ligado Event Loggingem propriedades de \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). O arquivo de log C:\ProgramData\GroupPolicy\Preference\Trace\User.lognã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 logon com unidades que não carregam, mas a captura tem tantas informações que não tenho certeza por onde começar.

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

Questão:

Por que esse problema ocorre com tanta frequência em um site, mas quase nunca no outro, 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 consigo pensar é 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 instalações novas do Windows 10 Pro.

Como quase não tenho representante, ainda não posso fazer perguntas, portanto tentarei fazer uma pergunta enquanto publico uma resposta e espero que não seja enlatada. ;)

Vou assumir que você garantiu que a parte do GPO deste caso não é um problema, testando esse GPO em um compartilhamento UNC "tradicional" em outro sistema Windows. A informação importante que falta, na minha opinião, é se os dispositivos Synology estão ou não ingressados ​​no domínio. Muitas unidades NAS baseadas em Linux, como Synology, QNAP e outros, possuem componentes de software incorporados que permitem a participação em domínios do Active Directory. A participação ou não deste dispositivo no domínio afeta a solução.

Dito isto, tenho instalações remotas em minha rede interconectadas com circuitos T1. Exigimos o uso de backups de imagem da Acronis em todos os sistemas devido a requisitos do sistema. Portanto, o backup remoto de imagens com vários GB de estações de trabalho do Windows em T1s não é obrigatório. Por isso, colocamos as unidades Drobo NAS em cada segmento local para superar isso e fornecer 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 habilitar 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 adequada de nomes. E segundo, tivemos que "afrouxar" duas políticas que a DISA normalmente recomenda para a maioria dos membros do domínio. Apenas afrouxamos essas políticas no servidor de backup e as estações de trabalho foram copiadas em sites de "link lento", pois 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: Assine digitalmente as comunicações (sempre) = desativado
  • Microsoft Network Client: Enviar senha não criptografada para servidores SMB de terceiros = ativado
  • Microsoft Network Server: Assinar digitalmente comunicações (sempre) = desativado

Os GPOs para "Assinar comunicações digitalmente se negociadas" ainda estão definidos como Ativado, atenuando um pouco do risco de segurança envolvido. Depois de ativar essas alterações, os compartilhamentos podem ser acessados ​​imediatamente via caminho UNC, enquanto anteriormente isso era impossível.

Foi por isso que eu disse anteriormente que, dependendo de seus NASes poderem participar do domínio ou não, determinar o caminho da solução. Se eles puderem 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 puderem participar (como meus NASes), essa pode ser sua solução.

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

Windows 10: a diretiva de grupo falha ao se aplicar diretamente após a inicialização e é bem-sucedida posteriormente

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

Aparentemente, esse problema é causado pela Microsoft habilitando o UNC Hardening no Windows 10 por padrão. Isso é para corrigir uma falha de segurança, mas aparentemente não intencionalmente faz com que as unidades mapeadas sejam montadas de maneira não confiável. Não é de surpreender que parece que a Microsoft ainda não solucionou esse problema (ou não?)

Isso também explica por que 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 do Hardening UNC foram transferidas do Windows 8 e permaneceram fora , enquanto os computadores com os novos instalação do Windows 10 utilizado o padrão de UNC Endurecimento no .

Na verdade, ainda não tentei a solução, mas parece perfeito demais para que meus sintomas não sejam relevantes. Estou preocupado com uma solução que abra meu sistema para mais ameaças à segurança, por isso estou procurando alternativas. Não gosto da ideia de definir isso por meio da diretiva de grupo e estou pensando se é possível desativar o UNC Hardening apenas através da edição manual do registro. Quero experimentar alguns computadores antes de decidir o que fazer a seguir. No entanto, só consigo encontrar etapas para alterar a configuração via GPO ou GPP no momento ...

Alguma ideia?

Eu só quero atualizar isso e dizer que em algum momento uma das principais atualizações do Windows 10 corrigiu esse problema. Esta é uma pergunta antiga, mas não gosto de deixar as coisas em suspenso, apenas por precaução.

Depois de ler tudo o que você forneceu na atualização Daniel, eu realmente sugeriria que o fortalecimento UNC, embora relacionado, não seja a causa raiz aqui, e que pode ser realmente a opção "fastboot" que o OP do 2º post corrigiu seu problema . Todas essas informações sobre o fortalecimento UNC se referiam aos compartilhamentos SYSVOL e NETLOGON sendo fortalecidos por padrão. Embora esse problema impeça seus clientes de receber atualizações de GP, o fato é que o Drive Map GPO já se aplicou pelo menos uma vez aos clientes em questão e não PRECISA se inscrever novamente após cada reinicialização (mesmo que isso ocorra) para executar o mapeamento.

Obviamente, você deseja 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 seu problema.