Como reduzir o impacto no desempenho de ingressar no domínio do Windows?

Question

Somos um escritório satélite de uma empresa multinacional. Temos um controlador de domínio local, mas ainda temos uma queda de desempenho paralisante após a junção de máquinas ao nosso domínio. Alguém tem alguma sugestão sobre como podemos diminuir ou mitigar o impacto no desempenho de ter máquinas associadas ao domínio? Por favor, sinta-se à vontade para fazer perguntas nos comentários, caso precise de mais informações.

Observação: não temos acesso total ao domínio ou ao DC e, portanto, não podemos efetuar alterações nem mesmo em nossa UO local em relação a GPOs ou estrutura geral / layout etc. No entanto, no interesse da integralidade, postaremos até mesmo idéias que podem exigir esse nível de acesso.

    

Answer 1

Depois de ler os comentários de Dayton Brown e sysadmin1138, eu dei uma olhada nos scripts de inicialização e notei a instalação de um aplicativo que usamos para enviar pacotes de software para máquinas remotas. Após uma investigação mais aprofundada, descobri que aparentemente faz muito mais do que empurrar software.

É uma solução completa de IDS e antivírus (além do Symantec Antivirus por algum motivo), com cerca de seis processos relacionados em execução em cada máquina. Acho que é seguro dizer que isso está causando nossos problemas de desempenho.

Meu chefe concordou em permitir que eu reconstruísse uma máquina e a impedisse de instalar, testar. Vou manter todos vocês informados, obrigado pelo seu feedback até agora pessoal.

    

Answer 2

Parece-me que você tem scripts de inicialização / desligamento que podem estar em execução e fazer referência a recursos em servidores fora do escritório. Também vi administradores que não entendem o DFS e tentam fazer instalações de software em uma WAN.

Execute o RSoP e veja o que está sendo aplicado a uma de suas máquinas para scripts de inicialização / desligamento. As chances são boas, as permissões serão tais que você pode sair e ler os scripts e ver o que eles estão fazendo. Procure também atribuições de software e veja se estão se referindo a servidores externos.

Também recomendo farejar o tráfego em um PC durante a inicialização ou qualquer outro horário que seja lento. Pegue uma caixa com duas placas de rede, conecte-as e use o Wireshark para farejar a ponte com o PC conectado a uma NIC e a LAN à outra. Você verá o que seu PC está tentando conversar durante esses "tempos lentos".

    

Answer 3

Hrm. Isso é interessante. De que desempenho você está falando? Desempenho de rede WAN? Isso pode apontar para a sincronização do AD. Desempenho da LAN da máquina sendo sincronizada? Isso me faria questionar o seu tamanho AD. Desempenho de LAN do DC local? Eu não tenho certeza onde eu iria com isso, honestamente.

Ou isso está demorando para sempre? Se esse for o caso, talvez ele esteja consultando inadvertidamente um DC remoto na WAN.

    

Answer 4

Hmmmm .... Pode ser que o ID master relativo esteja fora da rede para você. Quando você cria novos objetos de computador (aderir ao domínio, eu estou supondo que você não pré-criar seus objetos), ele tem que ir para o mestre de RID. Se o DC que detém esse papel estiver fora da rede para você, poderá levar um longo tempo até a viagem de ida e volta.

Como alternativa, pode ser que sua árvore do AD não tenha um site declarado para sua rede de satélites. Portanto, as máquinas dominadas não fazem referência aos servidores de catálogo global que não são locais para você porque nenhum limite de site foi declarado por algum motivo. Você pode ser capaz de ver isso (mas não fazer alterações) através da ferramenta MMC do AD Sites.

Um par de pensamentos (muito possivelmente errados).

Editar: tudo? Isso soa muito como a verificação de segurança é terrivelmente lenta por algum motivo. SID pesquisas e afins são terrivelmente lentos. Isso faz parecer que você está passando pela WAN por essas pesquisas quando não deveria. Sites incorretos, ou talvez o seu DC local não tenha GC.

Como funciona é assim:

• o Visual Studio acessa uma DLL
• O sistema operacional determina se o Visual Studio pode acessar essa DLL
  • O token de segurança do usuário, fornecido ao usuário um login e contém todos os membros do grupo, bem como seus identificadores diretos de segurança, é então referenciado
  • O sistema operacional verifica os detalhes de segurança dessa DLL, encontrando uma lista de SIDs
  • O sistema operacional resolve esses SIDs contra o domínio
    • O domínio provavelmente está na Austrália para você
  • O sistema operacional verifica os princípios de segurança em relação ao token de segurança do usuário
• O sistema operacional concede acesso

Lave, enxague, repita para cada arquivo acessado. A estação de trabalho deve manter um cache de SIDs, mas o VisualStudio abre um conjunto métrico de arquivos que podem sobrecarregar o cache.

Você pode fazer uma verificação muito aproximada das velocidades de pesquisa de domínio clicando com o botão direito do mouse em qualquer arquivo ou diretório NTFS e indo para Segurança, inserindo um usuário real e clicando no botão Pesquisar usuário. A rapidez com que você deve escalar com as velocidades que você está passando entre suas estações de trabalho com e sem domínio.

    

Answer 5

Você pode verificar se o desempenho está realmente confinado ao escritório remoto, possivelmente levando uma nova máquina ao site do PDC e ingressando no domínio lá? Se o desempenho ainda for afetado negativamente por ingressar no domínio no site do PDC, ele não será o controlador de domínio do seu escritório remoto.

Se o desempenho não for afetado ao ingressar no site do PDC, você terá certeza de que há um problema com o controlador de domínio do seu site.

Além disso, para fins de referência, você pode nos dar uma ideia de que tipo de credenciais você tem em seu domínio, para que possamos basear nossas sugestões em coisas que você realmente será capaz de fazer?