Rede:
- Domínio multi-site.
- Cada site tem 2 controladores de domínio Windows Server 2012 R2 locais (no local, na mesma sub-rede).
- Os sites são definidos corretamente nos sites e serviços do Windows.
- Os registros DNS para cada site APENAS têm os dois servidores DNS locais definidos.
- TODOS os clientes são Windows 10 Pro de 64 bits com todas as atualizações.
- Ambas as redes são totalmente gigabit rodando em switches Cisco com cabeamento CAT6 certificado.
- Cada local tem um servidor de armazenamento Synology local (no local, na mesma 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 /erelatóriosPASSpara TODOS os servidores e TODOS os testesecho %logonserver%sempre retorna um DC localnltest /dsgetdcsempre mostra um DC local e IP local correto- No Site A, ambas as unidades de rede aparecem, com talvez 0,5% de chance de falha (experimentei algumas inicializações em que 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 outra. O problema é principalmente aleatório e não parece seguir nenhum usuário ou estação de trabalho em particular.
Sintomas:
Dos 30% das vezes em que um problema se apresenta:
- 5% das vezes um
gpupdateougpupdate /forceresolverá o problema e as unidades aparecerão imediatamente. Segpupdatenão funcionar na primeira tentativa, praticamente nunca funcionará depois disso (para essa inicialização) - 5% do tempo a
gpupdateougpupdate /forcefará com que apenas uma unidade apareça - 20% do tempo, a
gpupdatenão resolverá o problema, mas a próxima inicialização estará bem - 50% das vezes, um
gpupdatenão vai resolver o problema, mas depois de um boot e outrogpupdate, os drives vão aparecer Em 20% das vezes, 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 tive que reiniciar um computador às vezes 6 ou 7 vezes antes que as unidades aparecessem.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, geralmente , mas nem sempre, um bom sinal, porque geralmente depois que recebo esse erro, a próxima ´gpupdate´ ou a próxima inicialização e ´gpupdate´ fará com que as unidades reapareçam.
Diagnóstico do mapa da unidade:
gpresult /h gpresult.htmlmostra: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: SuccessAtivei o log de depuração do ambiente de política de grupo (conforme http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx criou a entrada de registro
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). O arquivo de logc:\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.Eu habilitei a depuração de preferências de política de grupo para Drive Maps (conforme http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the -rsat.aspx definido
Drive Map Policy ProcessingcomoEnablede ativadoEvent Loggingnas propriedades de\Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). O arquivo de logC:\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:.Eu também tenho várias capturas netmon de um login com falha ao carregar as unidades, mas a captura tem tantas informações que não sei por onde começar.
Se, após uma falha no login, 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, quando ambos estão no mesmo domínio, têm a mesma política e executam o mesmo software?
A única diferença de software em que consigo pensar é que no Local A, todos os computadores estavam executando o Windows 8.1 Pro e foram atualizados para o Windows 10 Pro, enquanto no Local B, todos os computadores têm novas instalações do Windows 10 Pro.
Como quase não tenho representante, ainda não posso fazer perguntas, então tentarei fazer uma pergunta enquanto posto uma resposta e espero não ser enlatado. ;)
Vou presumir 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 associados ao domínio. Muitas unidades NAS baseadas em Linux, como Synology, QNAP e outros, possuem componentes de software incorporados que permitem que participem de domínios do Active Directory. Se este dispositivo está ou não participando do domínio afeta a solução.
Dito isto, tenho instalações remotas em minha rede interligadas com circuitos T1. Exigimos o uso de backups de imagem Acronis em todos os sistemas devido aos requisitos do sistema. Portanto, fazer backup remoto de imagens de vários GB de estações de trabalho Windows em T1s não é uma tarefa fácil. 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 específicos não têm a capacidade de participar do domínio AD.
Para habilitar os compartilhamentos UNC conforme configurado, tivemos que configurar duas coisas principais. Primeiro, criamos entradas DNS estáticas nos servidores DNS para permitir a resolução adequada de nomes. Em segundo lugar, tivemos que "afrouxar" duas políticas que a DISA normalmente recomenda para a maioria dos membros do domínio. Afrouxamos essas políticas apenas no servidor de backup e nas estações de trabalho com backup em sites de "link lento", pois esses eram os únicos sistemas que precisavam acessar os respectivos compartilhamentos:
Os GPOs para "Assinar digitalmente as comunicações se negociadas" ainda estão definidos como Habilitados, mitigando um pouco o risco de segurança envolvido. Depois de habilitarmos essas alterações, os compartilhamentos poderiam ser acessados imediatamente pelo caminho UNC, o que antes era impossível.
É por isso que eu disse anteriormente que, dependendo se seus NASes podem participar do domínio ou não, determina o caminho da solução. Se eles puderem participar, o DNS e as políticas de grupo "SMB" não serão um problema para você e, portanto, a solução estaria em outro lugar. Se eles NÃO PODEM participar (como meus NASes), então esta pode ser sua solução.
Bem, encontrei esses tópicos e parece uma situação quase idêntica à minha:
Windows 10: a política de grupo falha ao ser aplicada diretamente após a inicialização, é 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 surpreendentemente, parece que a Microsoft ainda não resolveu esse bug (ou já?)
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 relacionadas ao UNC Hardening foram transferidas do Windows 8 e permaneceram desligadas , enquanto os computadores com o novo a instalação do Windows 10 usou o padrão de UNC Hardening em .
Na verdade, ainda não tentei a solução, mas parece perfeita demais para meus sintomas não ser relevante. Estou preocupado com uma solução que abra meu sistema para mais ameaças de segurança, então estou procurando alternativas. Não gosto da ideia de definir isso por meio da política de grupo e estou me perguntando se é possível desativar o UNC Hardening apenas por meio da edição manual do registro. Quero experimentar em 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 atualmente...
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, só por precaução.
Depois de ler tudo o que você forneceu na atualização Daniel, eu sugeriria que o hardening UNC, embora relacionado, não é a causa raiz aqui, e que pode realmente ser a opção "fastboot" que o OP do 2º post disse que corrigiu seu problema . Todas essas informações sobre proteção UNC referem-se aos compartilhamentos SYSVOL e NETLOGON sendo protegidos por padrão. Embora esse problema impeça que seus clientes recebam atualizações de GP, o fato é que o Drive Map GPO já foi aplicado pelo menos uma vez aos clientes em questão e não PRECISA reaplicar após cada reinicialização (mesmo que seja) 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.