Plano de solução de problemas de desempenho do Microsoft 365

Você precisa saber as etapas a serem seguidas para identificar e corrigir atrasos, travamentos e baixo desempenho entre o SharePoint, o OneDrive, o Exchange Online ou o Skype for Business Online e o computador cliente? Antes de ligar para o suporte, este artigo pode ajudá-lo a solucionar problemas de desempenho do Microsoft 365 e até mesmo corrigir alguns dos problemas mais comuns.

Este artigo é, na verdade, um exemplo de plano de ação que você pode usar para capturar dados valiosos sobre seu problema de desempenho enquanto ele está acontecendo. Alguns dos principais problemas também estão incluídos neste artigo.

Se você é iniciante no desempenho de rede e deseja fazer um plano de longo prazo para monitorar o desempenho entre seus computadores cliente e o Microsoft 365, dê uma olhada no ajuste de desempenho e solução de problemas do Microsoft 365 - Administração e Profissional de TI.

Exemplo de plano de ação para solução de problemas de desempenho

Este plano de ação contém duas partes; uma fase de preparação e uma fase de registro em log. Se você tiver um problema de desempenho no momento e precisar fazer a coleta de dados, poderá começar a usar este plano imediatamente.

Preparar o computador cliente

• Encontre um computador cliente que possa reproduzir o problema de desempenho. Esse computador será usado durante a solução de problemas.
• Anote as etapas que causam o problema de desempenho para estar pronto quando chegar a hora de testar.
• Instale ferramentas para coletar e registrar informações:
  • Instale o Netmon 3.4 (ou use uma ferramenta de rastreamento de rede equivalente).
  • Instale a Edição Básica gratuita do HTTPWatch (ou use uma ferramenta de rastreamento de rede equivalente).
  • Use um gravador de tela ou execute o Gravador de Etapas (PSR.exe) que vem com o Windows Vista e posterior, para manter um registro das etapas executadas durante o teste.

Registrar o problema de desempenho

• Feche todos os navegadores de Internet estranhos.

• Inicie o Gravador de Etapas ou outro gravador de tela.

• Inicie a captura do Netmon (ou a ferramenta de rastreamento de rede).

• Limpe o cache DNS no computador cliente pela linha de comando digitando ipconfig /flushdns.

• Inicie uma nova sessão do navegador e ative o HTTPWatch.

• Opcional: se você estiver testando o Exchange Online, execute a ferramenta Exchange Client Performance Analyzer no console de administração do Microsoft 365.

• Reproduza as etapas exatas que causam o problema de desempenho.

• Pare o rastreamento do Netmon ou de outra ferramenta.

• Na linha de comando, execute uma rota de rastreamento para sua assinatura do Microsoft 365 digitando o seguinte comando e pressionando ENTER:

  tracert <subscriptionname>.onmicrosoft.com
  

• Pare o Gravador de Etapas e salve o vídeo. Certifique-se de incluir a data e a hora da captura e se ela demonstra um desempenho bom ou ruim.

• Salve os arquivos de rastreamento. Novamente, certifique-se de incluir a data e a hora da captura e se ela demonstra um desempenho bom ou ruim.

Se você não estiver familiarizado com a execução das ferramentas mencionadas neste artigo, não se preocupe, pois fornecemos essas etapas a seguir. Se você está acostumado a fazer esse tipo de captura de rede, pode pular para Como coletar linhas de base, que descreve a filtragem e a leitura dos logs.

Limpar o cache DNS primeiro

Por quê? Ao liberar o cache DNS, você inicia os testes com uma limpo lousa. Ao limpar o cache, você está redefinindo o conteúdo do resolvedor DNS para as entradas mais atualizadas. Lembre-se de que uma liberação não remove entradas de arquivo HOST. Se você usar entradas de arquivo HOST extensivamente, deverá copiar essas entradas para um arquivo em outro diretório e, em seguida, esvaziar o arquivo HOST.

Liberar o cache do resolvedor de DNS

1. Abra o prompt de comando (Iniciar>Executar>cmd ou tecla> Windowscmd).

2. Digite o seguinte comando e pressione ENTER:

   ipconfig /flushdns
   

Netmon

A ferramenta de Monitoramento de Rede da Microsoft (Netmon) analisa pacotes (tráfego de rede) que passam entre computadores em redes. Usando o Netmon para rastrear o tráfego com o Microsoft 365, você pode capturar, exibir e ler cabeçalhos de pacotes, identificar dispositivos intervenientes, marcar configurações importantes no hardware de rede, procurar por pacotes descartados e seguir o fluxo de tráfego entre os computadores em sua rede corporativa e o Microsoft 365. Como o corpo real do tráfego é criptografado, ou seja, ele viaja na porta 443 via SSL/TLS, você não pode ler os arquivos que estão sendo enviados. Em vez disso, você obtém um rastreamento não filtrado do caminho que o pacote percorre, o que pode ajudá-lo a rastrear o comportamento do problema.

Certifique-se de não aplicar um filtro neste momento. Em vez disso, execute as etapas e demonstre o problema antes de interromper o rastreamento e salvar.

Depois de instalar o Netmon 3.4, abra a ferramenta e execute estas etapas:

Use um rastreamento Netmon e reproduza o problema

1. Inicie o Netmon 3.4. Há três painéis na página Iniciar: Capturas Recentes, Selecionar Redes e a Introdução ao Microsoft Network Monitor 3.4. Aviso prévio. O painel Selecionar redes também fornecerá uma lista das redes padrão das quais você pode capturar. Verifique se as placas de rede estão selecionadas aqui.

2. Clique em Nova Captura na parte superior da página Iniciar. Isso adiciona uma nova guia ao lado da guia Página inicial chamada Captura 1.

   

3. Para fazer uma captura simples, clique em Iniciar na barra de ferramentas.

4. Reproduza as etapas que apresentam um problema de desempenho.

5. Clique em Parar>Arquivo>Salvar Como. Lembre-se de fornecer a data e a hora com o fuso horário e de menção se ele demonstra um desempenho ruim ou bom.

HTTPWatch

O HTTPWatch vem em uma edição gratuita e gratuita. A Edição Básica gratuita cobre tudo o que você precisa para este teste. O HTTPWatch monitora o tráfego da rede e o tempo de carregamento da página diretamente da janela do navegador. HTTPWatch é um plug-in para o Microsoft Edge que descreve graficamente o desempenho. A análise pode ser salva e visualizada no HTTPWatch Studio.

Execute o HTTPWatch e reproduza o problema

HTTPWatch é um plug-in do navegador, portanto, expor a ferramenta no navegador é ligeiramente diferente para cada versão do Microsoft Edge. Normalmente, você pode encontrar o HTTPWatch na barra de comandos no navegador Microsoft Edge. Se você não vir o plug-in HTTPWatch na janela do navegador, Marque a versão do navegador clicando em>Ajuda Sobre, ou em versões posteriores do Microsoft Edge, clique no símbolo de engrenagem e em Sobre o Edge. Para iniciar a barra de comandos , clique com o botão direito do mouse na barra de menus no Microsoft Edge e clique em barra de comandos.

No passado, o HTTPWatch era associado às barras Commands e Explorer, portanto, depois de instalar, se você não vir imediatamente o ícone (mesmo após a reinicialização), marque Ferramentas e as barras de ferramentas para o ícone. Lembre-se de que as barras de ferramentas podem ser personalizadas e opções podem ser adicionadas a elas.

1. Inicie o HTTPWatch em uma janela do navegador Microsoft Edge. Ele aparece encaixado no navegador na parte inferior da janela. Clique em Gravar.

2. Reproduza as etapas exatas envolvidas no problema de desempenho. Clique no botão Parar em HTTPWatch.

3. Salve o HTTPWatch ou envie por Email. Lembre-se de nomear o arquivo para que ele inclua informações de data e hora e uma indicação se o seu relógio contém uma demonstração de bom ou mau desempenho.

   

   Esta captura de tela é da versão Profissional do HTTPWatch. Você pode abrir rastreamentos obtidos na versão básica em um computador com uma versão profissional e lê-los lá. Informações adicionais podem estar disponíveis a partir do rastreamento por meio desse método.

Gravador de Etapas de Problemas

O Gravador de Etapas, ou PSR.exe, permite que você registre problemas à medida que eles ocorrem. É uma ferramenta muito útil e simples de executar.

Execute o Gravador de Etapas do Problema (PSR.exe) para gravar seu trabalho

1. Use o tipo Iniciar>Execução>PSR.exe>OK ou clique no tipo de Tecla> Windows PSR.exe> e pressione ENTER.

2. Quando a pequena janela PSR.exe for exibida, clique em Iniciar Registro e reproduza as etapas que reproduzem o problema de desempenho. Você pode adicionar comentários conforme necessário, clicando em Adicionar Comentários.

3. Clique em Parar Gravação quando concluir as etapas. Se o problema de desempenho for uma renderização de página, aguarde a renderização da página antes de interromper a gravação.

4. Clique em Salvar.

   

   A data e a hora são registradas para você. Isso vincula o PSR ao rastreamento do Netmon e ao HTTPWatch a tempo e ajuda na solução de problemas com precisão. A data e a hora no registro PSR podem mostrar que um minuto se passou entre o login e a navegação da URL e a renderização parcial do site de administração, por exemplo.

Ler seus rastreamentos

Não é possível ensinar tudo sobre solução de problemas de rede e desempenho que alguém precisaria saber por meio de um artigo. Ficar bom em desempenho exige experiência e conhecimento de como sua rede funciona e geralmente funciona. Mas é possível reunir uma lista dos principais problemas e mostrar como as ferramentas podem facilitar a eliminação dos problemas mais comuns.

Se você deseja adquirir habilidades de leitura de rastreamentos de rede para seus sites do Microsoft 365, não há professor melhor do que criar rastreamentos de carregamentos de página regularmente e ganhar experiência lendo-os. Por exemplo, quando você tiver uma chance, carregue um serviço do Microsoft 365 e rastreie o processo. Filtre o rastreamento para tráfego DNS ou pesquise o FrameData para o nome do serviço que você navegou. Examine o rastreamento para ter uma ideia das etapas que ocorrem quando o serviço é carregado. Isso ajuda você a saber como deve ser o carregamento normal da página e, no caso de solução de problemas, principalmente em relação ao desempenho, comparar traços bons com ruins pode ensinar muito.

O Netmon usa o Microsoft Intellisense no campo Filtro de exibição. Intellisense, ou intelligent code completion, é aquele truque em que você digita um ponto e todas as opções disponíveis são exibidas em uma caixa de seleção suspensa. Por exemplo, se você estiver preocupado com o dimensionamento da janela TCP, poderá encontrar o caminho para um filtro (como .protocol.tcp.window < 100) por esse meio.

Os rastreamentos Netmon podem ter muito tráfego. Se você não tem experiência em lê-los, é provável que fique sobrecarregado ao abrir o rastreamento pela primeira vez. A primeira coisa a fazer é separar o sinal do ruído de fundo no rastreamento. Você testou em relação ao Microsoft 365, e esse é o tráfego que você deseja ver. Se você está acostumado a navegar por rastreamentos, talvez não precise dessa lista.

O tráfego entre seu cliente e o Microsoft 365 viaja via TLS, o que significa que o corpo do tráfego será criptografado e não legível em um rastreamento genérico do Netmon. Sua análise de desempenho não precisa conhecer as especificidades das informações no pacote. Está, no entanto, muito interessado em cabeçalhos de pacotes e nas informações que eles contêm.

Dicas para obter um bom rastreamento

• Saber o valor do endereço IPv4 ou IPv6 do seu computador cliente. Você pode obter isso no prompt de comando digitando IPConfig e pressionando ENTER. Saber esse endereço permite saber rapidamente se o tráfego no rastreamento envolve diretamente o computador cliente. Se houver um proxy conhecido, faça ping nele e obtenha seu endereço IP também.

• Limpe o cache do resolvedor de DNS e, se possível, feche todos os navegadores, exceto aquele em que você está executando os testes. Se você não puder fazer isso, por exemplo, se o suporte estiver usando alguma ferramenta baseada em navegador para ver a área de trabalho do computador cliente, esteja preparado para filtrar o rastreamento.

• Em um rastreamento ocupado, localize o serviço do Microsoft 365 que você está usando. Se você nunca ou raramente viu seu tráfego antes, esta é uma etapa útil para separar o problema de desempenho de outros ruídos de rede. Existem algumas maneiras de fazer isso. Imediatamente antes do teste, você pode usar ping ou PsPing na URL do serviço específico (ping outlook.office365.com ou psping -4 microsoft-my.sharepoint.com:443, por exemplo). Você também pode encontrar facilmente esse ping ou PsPing em um rastreamento Netmon (pelo nome do processo). Isso lhe dará um lugar para começar a procurar.

Se você estiver usando apenas o rastreamento Netmon no momento do problema, tudo bem também. Para se orientar, use um filtro como ContainsBin(FrameData, ASCII, "office") ou ContainsBin(FrameData, ASCII, "outlook"). Você pode gravar o número do quadro a partir do arquivo de rastreamento. Você também pode rolar o painel Resumo do quadro totalmente para a direita e procurar a coluna ID da conversa. Há um número indicado lá para a ID desta conversa específica que você também pode gravar e examinar isoladamente mais tarde. Lembre-se de remover esse filtro antes de aplicar qualquer outro filtro.

Familiarize-se com seu tráfego e aprenda a localizar as informações necessárias. Por exemplo, aprenda a determinar qual pacote no rastreamento tem a primeira referência ao serviço Microsoft 365 que você está usando (como "Outlook").

Tomando o Microsoft 365 Outlook na Web como exemplo, o tráfego começa mais ou menos assim:

• Consulta de Standard DNS e Resposta DNS para outlook.office365.com com QueryIDs correspondentes. É importante observar o deslocamento de tempo para essa reviravolta e para onde no mundo o DNS Global do Microsoft 365 envia a solicitação para resolução de nomes. Idealmente, o mais localmente possível, em vez do outro lado do mundo.

• Uma Solicitação HTTP GET cujo relatório de status foi movido permanentemente (301)

• Tráfego RWS, incluindo solicitações de conexão RWS e respostas de conexão. (Este é o Winsock remoto fazendo uma conexão para você.)

• Uma conversa TCP SYN e TCP SYN/ACK. Muitas configurações nesta conversa afetam seu desempenho.

• Em seguida, uma série de tráfego TLS:TLS, que é onde ocorrem as conversas de handshake TLS e de certificado TLS. (Lembre-se de que os dados são criptografados via SSL/TLS.)

Todas as partes do tráfego são importantes e conectadas, mas pequenas partes do rastreamento contêm informações importantes em termos de solução de problemas de desempenho, portanto, vamos nos concentrar nessas áreas. Além disso, como fizemos o suficiente de solução de problemas de desempenho do Microsoft 365 na Microsoft para compilar uma lista dos 10 principais problemas comuns, vamos nos concentrar nesses problemas e em como usar as ferramentas que temos para eliminá-los a seguir.

Se você ainda não os instalou, a matriz abaixo faz uso de várias ferramentas sempre que possível. Os links são fornecidos para os pontos de instalação. A lista inclui ferramentas comuns de rastreamento de rede, como Netmon e Wireshark, mas use qualquer ferramenta de rastreamento com a qual você se sinta confortável e na qual esteja acostumado a filtrar o tráfego de rede. Quando estiver testando, lembre-se:

• Feche seus navegadores e teste com apenas um navegador em execução - Isso reduzirá o tráfego geral que você captura. Isso contribui para um rastreamento menos ocupado.
• Libere o cache do resolvedor de DNS no computador cliente - Isso lhe dará uma lousa limpa quando você começar a fazer sua captura, para um rastreamento mais limpo.

Problemas comuns

Alguns problemas comuns que você pode enfrentar e como encontrá-los em seu rastreamento de rede.

TCP Windows Scaling

Encontrado na SYN - SYN/ACK. O hardware herdado ou antigo pode não aproveitar o dimensionamento do TCP do Windows. Sem as configurações adequadas de dimensionamento de janelas TCP, o buffer padrão de 16 bits nos cabeçalhos TCP é preenchido em milissegundos. O tráfego não pode continuar a ser enviado até que o cliente receba uma confirmação de que os dados originais foram recebidos, causando atrasos.

Ferramentas

• Netmon
• Wireshark

O que procurar

Procure o tráfego SYN - SYN/ACK no rastreamento de rede. No Netmon, use um filtro como tcp.flags.syn == 1. Esse filtro é o mesmo no Wireshark.

Observe que, para cada SYN, há um número de porta de origem (SrcPort) que é correspondido na porta de destino (DstPort) da Confirmação relacionada (SYN/ACK).

Para ver o valor de dimensionamento do Windows usado pela conexão de rede, expanda primeiro o SYN e, em seguida, o SYN/ACK relacionado.

Configurações de tempo ocioso TCP

Historicamente, a maioria das redes de perímetro é configurada para conexões transitórias, o que significa que as conexões ociosas geralmente são encerradas. Sessões TCP ociosas podem ser encerradas por proxies e firewalls com mais de 100 a 300 segundos. Isso é problemático para o Outlook na Web porque ele cria e usa conexões de longo prazo, estejam elas ociosas ou não.

Quando as conexões são encerradas por proxy ou dispositivos de firewall, o cliente não é informado e uma tentativa de usar o Outlook na Web significará que o computador cliente tentará, repetidamente, reativar a conexão antes de criar uma nova. Você pode ver travamentos no produto, prompts ou baixo desempenho no carregamento da página.

Ferramentas

• Netmon
• Wireshark

O que procurar

No Netmon, examine o campo Deslocamento de tempo para uma viagem de ida e volta. Uma viagem de ida e volta é o tempo entre o cliente enviar uma solicitação ao servidor e receber uma resposta. Verifique entre o Cliente e o ponto de saída (por exemplo, Cliente --> Proxy) ou o Cliente para o Microsoft 365 (Cliente --> Microsoft 365). Você pode ver isso em muitos tipos de pacotes.

Por exemplo, o filtro no Netmon pode se parecer com .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12, ou, no Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Se houver um problema, espere que longos deslocamentos de tempo apareçam, neste caso (Outlook na Web), particularmente em pacotes TLS:TLS que mostram a passagem de dados do aplicativo (por exemplo, no Netmon você pode encontrar pacotes de dados do aplicativo via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Você deve ver uma progressão suave no tempo ao longo da sessão. Se você observar longos atrasos ao atualizar o Outlook na Web, isso pode ser causado por um alto grau de redefinições enviadas.

Latência/Tempo de ida e volta

A latência é uma medida que pode mudar muito dependendo de muitas variáveis, como atualizar dispositivos antigos, adicionar um grande número de usuários a uma rede e a porcentagem da largura de banda geral consumida por outras tarefas em uma conexão de rede.

Há calculadoras de largura de banda para o Microsoft 365 disponíveis nesta página de planejamento de rede e ajuste de desempenho para o Microsoft 365 .

Precisa medir a velocidade da sua conexão ou a largura de banda da conexão do seu ISP? Experimente este site (ou sites semelhantes): Site oficial do Speedtest ou consulte seu mecanismo de pesquisa favorito para obter a frase teste de velocidade.

Ferramentas

• Ping
• PsPing
• Netmon
• Wireshark

O que procurar

Para acompanhar a latência em um rastreamento, você se beneficiará de ter registrado o endereço IP do computador cliente e o endereço IP do servidor DNS no Microsoft 365. Isso é para facilitar a filtragem de rastreamento. Se você se conectar por meio de um proxy, precisará do endereço IP do computador cliente, do endereço IP do proxy/saída e do endereço IP DNS do Microsoft 365 para facilitar o trabalho.

Uma solicitação de ping enviada a outlook.office365.com informará o nome do datacenter que está recebendo a solicitação, mesmo que o ping não consiga se conectar para enviar à marca registrada pacotes ICMP consecutivos. Se você usar o PsPing (uma ferramenta gratuita para download) e especificar a porta (443) e talvez usar o IPv4 (-4), obterá um tempo médio de ida e volta para os pacotes enviados. Isso funcionará para outras URLs nos serviços do Microsoft 365, como psping -4 yourSite.sharepoint.com:443. Na verdade, você pode especificar vários pings para obter uma amostra maior para sua média, tente algo como psping -4 -n 20 yourSite-my.sharepoint.com:443.

Se você carregou a página do Microsoft 365 de desempenho lento ao fazer um rastreamento de rede, deverá filtrar um rastreamento Netmon ou Wireshark para DNS. Este é um dos IPs que estamos procurando.

Aqui estão as etapas a serem seguidas para filtrar seu Netmon para obter o endereço IP (e dê uma olhada na latência de DNS). Este exemplo usa outlook.office365.com, mas também pode usar a URL de um locatário do SharePoint (hithere.sharepoint.com por exemplo).

1. Faça ping na URL ping outlook.office365.com e, nos resultados, registre o nome e o endereço IP do servidor DNS para o qual a solicitação de ping foi enviada.
2. O rastreamento de rede abrindo a página, ou realizando a ação que fornece o problema de desempenho ou, se você vir uma latência alta no ping, rastreiá-lo de rede.
3. Abra o rastreamento no Netmon e filtre o DNS (esse filtro também funciona no Wireshark, mas diferencia maiúsculas de minúsculas -- dns). Como você sabe o nome do servidor DNS pelo seu ping, também pode filtrar mais rapidamente no Netmon assim: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), que se parece com isso no DNS do Wireshark e o quadro contém "namnorthwest".
   Abra o pacote de resposta e, na janela Detalhes do Quadro Netmon, clique em DNS para expandir para obter mais informações. Nas informações de DNS, você encontrará o endereço IP do servidor DNS para o qual a solicitação foi no Microsoft 365. Você precisará desse endereço IP para a próxima etapa (a ferramenta PsPing). Remova o filtro, clique com o botão direito do mouse na Resposta DNS no Netmon (Resumo do Quadro>Localizar Conversas>DNS) para ver a Consulta DNS e a Resposta lado a lado.
4. No Netmon, observe também a coluna Deslocamento de tempo entre a solicitação e a resposta DNS. Na próxima etapa, a ferramenta PsPing fácil de instalar e usar é muito útil, tanto porque o ICMP geralmente é bloqueado em firewalls quanto porque o PsPing rastreia elegantemente a latência em milissegundos. O PsPing conclui uma conexão TCP com um endereço e uma porta (no nosso caso, abra a porta 443).
5. Instale o PsPing.
6. Abra um prompt de comando (tipo de Iniciar > Execução > , cmd ou tecla Windows > , digite cmd) e altere o diretório para o diretório onde você instalou o PsPing para executar o comando PsPing. Nos meus exemplos, você pode ver que criei uma pasta 'Perf' na raiz de C. Você pode fazer o mesmo para acesso rápido.
7. Digite o comando para que você esteja fazendo seu PsPing no endereço IP do servidor DNS do Microsoft 365 de seu rastreamento Netmon anterior, incluindo o número da porta, como psping -n 20 132.245.24.82:445. Isso fornecerá uma amostra de 20 pings e calculará a média da latência quando o PsPing parar.

Se você estiver acessando o Microsoft 365 por meio de um servidor proxy, as etapas serão um pouco diferentes. Primeiro, faça o PsPing no servidor proxy para obter um valor médio de latência em milissegundos para o proxy/saída e vice-versa e, em seguida, execute o PsPing no proxy ou em um computador com conexão direta com a Internet para obter o valor ausente (aquele para o Microsoft 365 e vice-versa).

Se você optar por executar o PsPing do proxy, terá dois valores de milissegundos: computador cliente para o servidor proxy ou ponto de saída e servidor proxy para o Microsoft 365. E pronto! Bem, registrando valores, de qualquer maneira.

Se você executar o PsPing em outro computador cliente que tenha uma conexão direta com a Internet, ou seja, sem um proxy, você terá dois valores de milissegundos: computador cliente para servidor proxy ou ponto de saída e computador cliente para o Microsoft 365. Nesse caso, subtraia o valor do computador cliente para o servidor proxy ou ponto de saída do valor do computador cliente para o Microsoft 365 e você terá os números RTT do computador cliente para o servidor proxy ou ponto de saída e do servidor proxy ou ponto de saída para o Microsoft 365.

No entanto, se você puder encontrar um computador cliente no local afetado que esteja diretamente conectado ou ignore o proxy, você pode optar por ver se o problema se reproduz lá para começar e testar usá-lo posteriormente.

Latência, como visto em um rastreamento Netmon, esses milissegundos extras podem aumentar, se houver um número suficiente deles em uma determinada sessão.

Lembre-se de expandir todos os nós (há um botão na parte superior para isso) se quiser pesquisar, por exemplo, 132.245.

Autenticação de proxy

Isso só se aplica a você se você estiver usando um servidor proxy. Caso contrário, você pode ignorar essas etapas. Quando funcionar corretamente, a autenticação por proxy deve ocorrer em milissegundos, de forma consistente. Você não deve ver um desempenho ruim intermitente durante períodos de pico de uso (por exemplo).

Se a autenticação de proxy estiver ativada, sempre que você fizer uma nova conexão TCP com o Microsoft 365 para obter informações, precisará passar por um processo de autenticação nos bastidores. Assim, por exemplo, ao alternar do Calendar para o Email no Outlook na Web, você se autenticará. E no SharePoint, se uma página exibir mídia ou dados de vários sites ou locais, você se autenticará para cada conexão TCP diferente necessária para renderizar os dados.

No Outlook na Web, você pode enfrentar tempos de carregamento lentos sempre que alternar entre o Calendar e sua caixa de correio ou carregamentos de página lentos no SharePoint. No entanto, há outros sintomas não listados aqui.

A autenticação de proxy é uma configuração no servidor proxy de saída. Se isso estiver causando um problema de desempenho com o Microsoft 365, você deverá consultar sua equipe de rede.

Ferramentas

• Netmon
• Wireshark

O que procurar

A autenticação por proxy ocorre sempre que uma nova sessão TCP deve ser ativada, geralmente para solicitar arquivos ou informações do servidor ou para fornecer informações. Por exemplo, você pode ver autenticação de proxy em torno de solicitações HTTP GET ou HTTP POST. Se você quiser ver os quadros nos quais está autenticando solicitações em seu rastreamento, adicione a coluna 'Resumo NTLMSSP' ao Netmon e filtre por .property.NTLMSSPSummary. Para ver quanto tempo a autenticação está demorando, adicione a coluna Time Delta.

Para adicionar uma coluna ao Netmon:

1. Clique com o botão direito do mouse em uma coluna, como Descrição.
2. Clique em Escolher colunas.
3. Localize o Resumo NTLMSSP e o Delta de Tempo na lista e clique em Adicionar.
4. Mova as novas colunas para o lugar antes ou depois da coluna Descrição para que você possa lê-las lado a lado.
5. Clique em OK.

Mesmo que você não adicione a coluna, o filtro Netmon funcionará. Mas a solução de problemas será muito mais fácil se você puder ver em que estágio de autenticação está.

Ao procurar instâncias de autenticação de proxy, certifique-se de estudar todos os quadros em que há um desafio NTLM ou uma mensagem de autenticação presente. Se necessário, clique com o botão direito do mouse na parte específica do tráfego e encontre o TCP de conversas > . Esteja ciente dos valores do Time Delta nessas conversas.

Um atraso de quatro segundos na autenticação de proxy, como visto no Wireshark. O delta de tempo da coluna de quadro exibida anterior foi feito clicando com o botão direito do mouse no campo de mesmo nome nos detalhes do quadro e selecionando Adicionar como coluna.

Desempenho de DNS

A resolução de nomes funciona melhor e mais rapidamente quando ocorre o mais próximo possível do país/região do cliente.

Se a resolução de nomes DNS estiver ocorrendo no exterior, ela poderá adicionar segundos aos carregamentos de página. Idealmente, a resolução de nomes ocorre em menos de 100 ms. Caso contrário, você deve fazer uma investigação mais aprofundada.

Ferramentas

• Netmon
• Wireshark
• PsPing

O que procurar

Analisar o desempenho do DNS normalmente é outro trabalho para um rastreamento de rede. No entanto, o PsPing também é útil para determinar ou excluir uma possível causa.

O tráfego DNS é baseado em solicitações TCP e UDP, e as respostas são claramente marcadas com uma ID que ajudará a combinar uma solicitação específica com sua resposta específica. Você verá o tráfego DNS quando, por exemplo, o SharePoint usar um nome de rede ou URL em uma página da Web. Como regra geral, a maior parte desse tráfego, exceto durante a transferência de zonas, é executada por UDP.

No Netmon e no Wireshark, o filtro mais básico que permitirá que você veja o tráfego DNS é simplesmente dns. Certifique-se de usar letras minúsculas ao especificar o filtro. Lembre-se de liberar o cache do resolvedor DNS antes de começar a reproduzir o problema no computador cliente. Por exemplo, se você tiver um carregamento lento da página do SharePoint para a página inicial, feche todos os navegadores, abra um novo navegador, inicie o rastreamento, libere o cache do resolvedor DNS e navegue até o site do SharePoint. Depois que a página inteira for resolvida, você deverá parar e salvar o rastreamento.

Você quer ver o deslocamento de tempo aqui. E pode ser útil adicionar a coluna Time Delta ao Netmon, o que você pode fazer concluindo estas etapas:

1. Clique com o botão direito do mouse em uma coluna, como Descrição.
2. Clique em Escolher colunas.
3. Localize o Time Delta na lista e clique em Adicionar.
4. Mova a nova coluna para o lugar antes ou atrás da coluna Descrição para que você possa lê-las lado a lado.
5. Clique em OK.

Se você encontrar uma consulta de interesse, considere isolá-la clicando com o botão direito do mouse nessa consulta no painel de detalhes do quadro, escolhendo Find Conversations>DNS. Observe que o painel Conversas de Rede salta direto para a conversa específica em seu registro de tráfego UDP.

No Wireshark, você pode criar uma coluna para o tempo DNS. Pegue seu rastreamento (ou abra um rastreamento) no Wireshark e filtre por dns, ou, mais útil, dns.time. Clique em qualquer consulta DNS e, no painel que mostra detalhes, expanda os Domain Name System (response) detalhes. Você verá um campo de tempo (por exemplo, [Time: 0.001111100 seconds]. Clique com o botão direito do mouse desta vez e selecione Aplicar como Coluna. Isso fornecerá uma coluna Tempo para uma classificação mais rápida do rastreamento. Clique na nova coluna para classificar por valores decrescentes e ver qual chamada DNS demorou mais para ser resolvida.

Se você quiser investigar mais o tempo de resolução de DNS, tente um PsPing na porta DNS usada pelo TCP (por exemplo, psping <IP address of DNS server>:53). Você ainda vê um problema de desempenho? Se você fizer isso, é mais provável que o problema seja um problema de rede mais amplo do que um problema específico do aplicativo DNS que você está recorrendo para resolver. Também vale a pena mencionar, novamente, que um ping para outlook.office365.com informará onde a resolução de nomes DNS para Outlook na Web está ocorrendo (por exemplo, outlook-namnorthwest.office365.com).

Se o problema parecer específico do DNS, talvez seja necessário entrar em contato com o departamento de TI para examinar as configurações de DNS e os encaminhadores de DNS para investigar ainda mais esse problema.

Escalabilidade de proxy

Serviços como o Outlook na Web no Microsoft 365 concedem aos clientes várias conexões de longo prazo. Portanto, cada usuário pode usar mais conexões que exigem uma vida útil mais longa.

Ferramentas

Matemática

O que procurar

Não há rastreamento de rede ou ferramenta de solução de problemas específica para isso. Em vez disso, ela se baseia em cálculos de largura de banda, dadas as limitações e outras variáveis.

Tamanho Máx. do Segmento TCP

Encontrado na SYN - SYN/ACK. Faça isso para marcar qualquer rastreamento de rede de desempenho que você tenha feito para garantir que os pacotes TCP estejam configurados para transportar a quantidade máxima de dados possível.

O objetivo é ver um MSS de 1.460 bytes para transmissão de dados. Se você estiver protegido por um proxy ou estiver usando um NAT, lembre-se de executar este teste de cliente para proxy/saída/NAT e de proxy/saída/NAT para o Microsoft 365 para obter melhores resultados! Estas são sessões TCP diferentes.

Ferramentas

Netmon

O que procurar

O MSS (Tamanho Máximo do Segmento TCP) é outro parâmetro do handshake de três vias no rastreamento de rede, o que significa que você encontrará os dados necessários no pacote SYN-SYN/ACK. MSS é muito simples de ver.

Abra qualquer rastreamento de rede de desempenho que você tenha e encontre a conexão sobre a qual você está curioso ou que demonstra o problema de desempenho.

Olhando para o rastreamento de segunda mão? Tente usar filtros para se orientar. No Netmon, execute uma pesquisa com base na URL, como Containsbin(framedata, ascii, "sphybridExample"), anote o número do quadro.

No Wireshark, use algo como frame contains "sphybridExample". Se você perceber que encontrou tráfego Remote Winsock (RWS) (pode aparecer como [PSH, ACK] no Wireshark), lembre-se de que as conexões RWS podem ser vistas pouco antes de SYN - SYN/ACKs relevantes, conforme discutido anteriormente.

Neste ponto, você pode gravar o número do quadro, soltar o filtro e clicar em Todo o tráfego na janela Conversas de rede no Netmon para ver o SYN mais próximo.

É importante ressaltar que, se você não recebeu nenhuma das informações de endereço IP no momento do rastreamento, localizar sua URL no rastreamento (parte de sphybridExample-my.sharepoint.com, por exemplo), fornecerá endereços IP pelos quais filtrar.

Localize a conexão no rastreamento que você está interessado em ver. Você pode fazer isso verificando o rastreamento, filtrando por endereços IP ou selecionando IDs de conversa específicas usando a janela Conversas de rede no Netmon. Depois de encontrar o pacote SYN, expanda TCP (no Netmon) ou o Protocolo de Controle de Transmissão (no Wireshark) no painel Detalhes do quadro. Expanda Opções de TCP e MaxSegmentSize. Localize o quadro SYN-ACK relacionado e expanda as opções de TCP e MaxSegmentSize. O menor dos dois valores será o Tamanho máximo do segmento. Nesta foto, uso a coluna interna do Netmon chamada TCP Troubleshoot.

A coluna interna está na parte superior do painel Detalhes do quadro . (Para voltar ao modo de exibição normal, clique em Colunas novamente e escolha Fuso Horário.)

Aqui está um rastreamento filtrado no Wireshark. Há um filtro específico para o valor MSS (tcp.options.mss). Os quadros de um handshake SYN, SYN / ACK, ACK são vinculados na parte inferior do Wireshark equivalentes aos detalhes do quadro (portanto, o quadro 47 ACK, links para 46 SYN / ACK, links para 43 SYN) para facilitar esse tipo de trabalho.

Se você precisar marcar Reconhecimento Seletivo (próximo tópico nesta matriz), não feche seu rastreamento!

Confirmação Seletiva

Encontrado na SYN - SYN/ACK. Deve ser relatado como Permitido em SYN e SYN/ACK. O SACK (Reconhecimento Seletivo) permite uma retransmissão mais suave de dados quando um pacote ou pacotes desaparecem. Os dispositivos podem desabilitar esse recurso, o que pode levar a problemas de desempenho.

Se você estiver protegido por um proxy ou estiver usando um NAT, lembre-se de executar este teste de cliente para proxy/saída/NAT e de proxy/saída/NAT para o Microsoft 365 para obter melhores resultados! Estas são sessões TCP diferentes.

Ferramentas

Netmon

O que procurar

O Reconhecimento Seletivo (SACK) é outro parâmetro no handshake SYN-SYN/ACK. Você pode filtrar o rastreamento para SYN - SYN/ACK de várias maneiras.

Localize a conexão no rastreamento que você está interessado em ver examinando o rastreamento, filtrando por endereços IP ou clicando em uma ID de conversa usando a janela Conversas de rede no Netmon. Depois de encontrar o pacote SYN, expanda TCP no Netmon ou o Protocolo de Controle de Transmissão no Wireshark na seção Detalhes do quadro. Expanda Opções de TCP e, em seguida, SACK. Localize o quadro SYN-ACK relacionado e expanda as opções de TCP e seu campo SACK. Certifique-se de que SACK é permitido em SYN e SYN/ACK. Aqui estão os valores de SACK vistos no Netmon e no Wireshark.

Geolocalização DNS

Onde no mundo o Microsoft 365 tenta resolver sua chamada DNS afeta a velocidade da sua conexão.

No Outlook na Web, depois que a primeira pesquisa de DNS for concluída, a localização desse DNS será usada para se conectar ao datacenter mais próximo. Você será conectado a um servidor CAS do Outlook na Web, que usará a rede de backbone para se conectar ao datacenter (DC) onde seus dados estão armazenados. Isso é mais rápido.

Ao acessar o SharePoint, um usuário que viaja para o exterior será direcionado para seu datacenter ativo - esse é o dC cuja localização é baseada na base de origem de seu locatário SPO (portanto, um dC nos EUA, se o usuário estiver nos EUA).

O Lync Online tem nós ativos em mais de um dC por vez. Quando as solicitações são enviadas para instâncias do Lync Online, o DNS da Microsoft determinará de onde veio a solicitação e retornará endereços IP do dC regional mais próximo onde o Lync online está ativo.

Ferramentas

• Ping
• PsPing

O que procurar

Solicitações de resolução de nomes dos servidores DNS do cliente para os servidores DNS da Microsoft devem, na maioria dos casos, resultar no DNS da Microsoft retornando o endereço IP de um datacenter regional (DC). O que isso significa para você? Se sua sede estiver em Bangalore, Índia, mas você estiver viajando para os Estados Unidos, quando seu navegador fizer uma solicitação para o Outlook na Web, os servidores DNS da Microsoft devem fornecer a você endereços IP para datacenters nos Estados Unidos - um datacenter regional. Se for necessário enviar email do Outlook, esses dados trafeguem pela rede de backbone rápido da Microsoft entre os datacenters.

O DNS funciona mais rápido quando a resolução de nomes é feita o mais próximo possível do local do usuário. Se você estiver na Europa, você deseja ir para um DNS da Microsoft na Europa e (idealmente) lidar com um datacenter na Europa. O desempenho de um cliente na Europa que vai para o DNS e um datacenter na América será mais lento.

Execute a ferramenta Ping em outlook.office365.com para determinar em que lugar do mundo sua solicitação DNS está sendo roteada. Se você estiver na Europa, deverá ver uma resposta de algo como outlook-emeawest.office365.com. Nas Américas, espere algo como outlook-namnorthwest.office365.com.

Abra o prompt de comando no computador cliente (via Iniciar > Executar > cmd ou tecla Windows > digite cmd). Digite ping outlook.office365.com e pressione ENTER. Lembre-se de especificar -4 se quiser especificar ping via IPv4. Talvez você não consiga obter uma resposta dos pacotes ICMP, mas deverá ver o nome do DNS para o qual a solicitação foi roteada. Se você quiser ver os números de latência para esta conexão, tente PsPing para o endereço IP do servidor que é retornado por ping.

Solução de problemas de aplicativos do Microsoft 365

Ferramentas

• Netmon
• HTTPWatch
• Console F12 no navegador

Neste artigo específico de rede, não abordamos as ferramentas usadas na solução de problemas específicos do aplicativo. Mas você encontrará recursos que pode usar nesta página.

Artigos relacionados

Gerenciando os pontos de extremidade do Microsoft 365

Perguntas frequentes sobre pontos de extremidade do Microsoft 365