Plano de resolução de problemas de desempenho para Office 365

Precisa de saber os passos a seguir para identificar e corrigir atrasos, bloqueios e desempenho lento entre o SharePoint, o OneDrive, o Exchange Online ou o Skype para Empresas Online e o seu computador cliente? Antes de contactar o suporte, este artigo pode ajudá-lo a resolver problemas de desempenho Office 365 e até mesmo corrigir alguns dos problemas mais comuns.

Este artigo é, na verdade, um plano de ação de exemplo que pode utilizar para capturar dados valiosos sobre o seu problema de desempenho à medida que está a acontecer. Alguns dos principais problemas também estão incluídos neste artigo.

Se não estiver familiarizado com o desempenho da rede e quiser fazer um plano a longo prazo para monitorizar o desempenho entre as máquinas cliente e Office 365, veja Office 365 otimização e resolução de problemas de desempenho – Administração e Profissionais de TI.

Exemplo de plano de ação de resolução de problemas de desempenho

Este plano de ação contém duas partes; uma fase de preparação e uma fase de registo. Se tiver um problema de desempenho neste momento e precisar de fazer a recolha de dados, pode começar a utilizar este plano imediatamente.

Preparar o computador cliente

• Localize um computador cliente que possa reproduzir o problema de desempenho. Este computador será utilizado durante a resolução de problemas.
• Anote os passos que fazem com que o problema de desempenho aconteça para que esteja pronto quando chegar a altura de testar.
• Ferramentas de instalação para recolher e gravar informações:
  • Instale o Netmon 3.4 (ou utilize uma ferramenta de rastreio de rede equivalente).
  • Instale a Edição Básica gratuita do HTTPWatch (ou utilize uma ferramenta de Rastreio de rede equivalente).
  • Utilize um gravador de ecrã ou execute o Gravador de Passos (PSR.exe) fornecido com o Windows Vista e posterior, para manter um registo dos passos que efetua durante os testes.

Registar o problema de desempenho

• Feche todos os browsers estranhos da Internet.

• Inicie o Gravador de Passos ou outro gravador de ecrã.

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

• Limpe a cache DNS no computador cliente da linha de comandos ao escrever ipconfig /flushdns.

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

• Opcional: se estiver a testar Exchange Online, execute a ferramenta de Analisador de Desempenho do Cliente Exchange a partir da consola de administração do Office 365.

• Reproduza os passos exatos que causam o problema de desempenho.

• Pare o rastreio do Netmon ou de outra ferramenta.

• Na linha de comandos, execute uma rota de rastreio para a sua subscrição Office 365 ao escrever o seguinte comando e, em seguida, ao premir ENTER:

  tracert <subscriptionname>.onmicrosoft.com
  

• Pare o Gravador de Passos e guarde o vídeo. Certifique-se de que inclui a data e hora da captura e se demonstra um bom ou mau desempenho.

• Guarde os ficheiros de rastreio. Mais uma vez, certifique-se de que inclui a data e hora da captura e se demonstra um bom ou mau desempenho.

Se não estiver familiarizado com a execução das ferramentas mencionadas neste artigo, não se preocupe porque fornecemos esses passos a seguir. Se estiver habituado a fazer este tipo de captura de rede, pode avançar para Como recolher linhas de base, que descreve a filtragem e a leitura dos registos.

Remova primeiro a Cache DNS

Porquê? Ao remover a cache DNS, está a iniciar os testes com uma folha limpa. Ao limpar a cache, está a repor os conteúdos de resolução de DNS para as entradas mais atualizadas. Lembre-se de que uma remoção de cache não remove as entradas de ficheiro HOST. Se utilizar entradas de ficheiro HOST extensivamente, deve copiar essas entradas para um ficheiro noutro diretório e, em seguida, esvaziar o ficheiro HOST.

Esvaziar a cache de resolução de DNS

1. Abra a linha de comandos (cmdIniciar>Execução> oucmd de chave> do Windows).

2. Escreva o seguinte comando e prima ENTER:

   ipconfig /flushdns
   

Netmon

A Ferramenta de Monitorização de Rede (Netmon) da Microsoft analisa pacotes (tráfego de rede) que passam entre computadores em redes. Ao utilizar o Netmon para rastrear o tráfego com Office 365 pode capturar, ver e ler cabeçalhos de pacotes, identificar dispositivos intervenientes, verificar definições importantes no hardware de rede, procurar pacotes removidos e seguir o fluxo de tráfego entre computadores na sua rede empresarial e Office 365. Uma vez que o corpo real do tráfego está encriptado, ou seja, viaja na porta 443 através de SSL/TLS, não pode ler os ficheiros que estão a ser enviados. Em vez disso, obtém um rastreio não filtrado do caminho que o pacote toma, o que pode ajudá-lo a detetar o comportamento do problema.

Certifique-se de que não aplica um filtro neste momento. Em vez disso, execute os passos e demonstre o problema antes de parar o rastreio e guardar.

Depois de instalar o Netmon 3.4, abra a ferramenta e siga estes passos:

Fazer um rastreio do Netmon e reproduzir o problema

1. Inicie o Netmon 3.4. Existem três painéis na página Início: Capturas Recentes, Selecionar Redes e o Introdução com o Microsoft Network Monitor 3.4. Repare. O painel Selecionar Redes também lhe dará uma lista das redes predefinidas a partir das quais pode capturar. Certifique-se de que as placas de rede estão selecionadas aqui.

2. Clique em Nova Captura na parte superior da página Início . Esta ação adiciona um novo separador ao lado do separador Página Inicial denominado Captura 1.

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

4. Reproduza os passos que apresentam um problema de desempenho.

5. Clique em Parar>Guardar Ficheiro>Como. Lembre-se de dar a data e hora com o fuso horário e mencionar se demonstra um mau ou bom desempenho.

HTTPWatch

O HTTPWatch é cobrado e tem uma edição gratuita. A Edição Básica gratuita abrange tudo o que precisa para este teste. O HTTPWatch monitoriza o tráfego de rede e o tempo de carregamento da página diretamente a partir da janela do browser. O HTTPWatch é um plug-in do Microsoft Edge que descreve graficamente o desempenho. A análise pode ser guardada e visualizada no HTTPWatch Studio.

Nota

Se utilizar outro browser, como o Firefox, o Google Chrome ou se não conseguir instalar o HTTPWatch no Edge, abra uma nova janela do browser e prima F12 no teclado. Deverá ver o pop-up Ferramenta de Programador na parte inferior do browser. Se utilizar Opera, prima CTRL+SHIFT+I para Inspetor Web e, em seguida, clique no separador Rede e conclua o teste descrito abaixo. As informações serão ligeiramente diferentes, mas os tempos de carregamento continuarão a ser apresentados em milissegundos. > O HTTPWatch também é muito útil para problemas com os tempos de carregamento de páginas do SharePoint.

Execute o HTTPWatch e reproduza o problema

O HTTPWatch é um plug-in do browser, pelo que expor a ferramenta no browser é ligeiramente diferente para cada versão do Microsoft Edge. Normalmente, pode encontrar o HTTPWatch na barra comandos no browser Microsoft Edge. Se não vir o plug-in HTTPWatch na janela do browser, verifique a versão do browser ao clicar em Ajuda>Acerca do ou em versões posteriores do Microsoft Edge, clique no símbolo de engrenagem e em Acerca do Edge. Para iniciar a Barra de comandos , clique com o botão direito do rato na barra de menus no Microsoft Edge e clique em Barra de comandos.

No passado, o HTTPWatch foi associado às barras Comandos e Explorador, por isso, depois de instalar, se não vir imediatamente o ícone (mesmo após o reinício), verifique as Ferramentas e as barras de ferramentas do ícone. Lembre-se de que as barras de ferramentas podem ser personalizadas e as opções podem ser adicionadas às mesmas.

1. Inicie o HTTPWatch numa janela do browser Microsoft Edge. Parece ancorado ao browser na parte inferior dessa janela. Clique em Gravar.

2. Reproduza os passos exatos envolvidos no problema de desempenho. Clique no botão Parar no HTTPWatch.

3. Guarde o HTTPWatch ou Enviar por Email. Lembre-se de atribuir um nome ao ficheiro para que inclua informações de data e hora e uma indicação de se o Seu Relógio contém uma demonstração de bom ou mau desempenho.

Esta captura de ecrã é da versão Professional do HTTPWatch. Pode abrir rastreios recolhidos na Versão Básica num computador com uma versão Professional e lê-lo aí. Poderão estar disponíveis informações adicionais a partir do rastreio através desse método.

Gravador de Passos do Problema

O Gravador de Passos, ou PSR.exe, permite-lhe registar problemas à medida que ocorrem. É uma ferramenta muito útil e simples de executar.

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

1. Utilize o tipo Iniciar>Execução>PSR.exe>OK ou clique no tipo de Tecla> do Windows PSR.exe> e, em seguida, prima ENTER.

2. Quando for apresentada a pequena janela PSR.exe, clique em Iniciar Registo e reproduza os passos que reproduzem o problema de desempenho. Pode adicionar comentários conforme necessário ao clicar em Adicionar Comentários.

3. Clique em Parar Registo quando concluir os passos. Se o problema de desempenho for uma composição de página, aguarde que a página seja composta antes de parar a gravação.

4. Clique em Guardar.

A data e hora são gravadas automaticamente. Esta ação liga o seu PSR ao rastreio netmon e ao HTTPWatch no tempo e ajuda na resolução de problemas de precisão. A data e hora no registo PSR podem mostrar que passou um minuto entre o início de sessão e a navegação do URL e a composição parcial do site de administração, por exemplo.

Ler os seus rastreios

Não é possível ensinar tudo sobre resolução de problemas de rede e desempenho que alguém precisa de saber através de um artigo. Obter um bom desempenho requer experiência e conhecimento de como a sua rede funciona e geralmente funciona. No entanto, é possível reunir uma lista dos principais problemas e mostrar como as ferramentas podem facilitar a eliminação dos problemas mais comuns.

Se quiser aprender competências a ler rastreios de rede para os seus sites de Office 365, não há melhor professor do que criar rastreios de carregamentos de páginas regularmente e obter experiência na leitura dos mesmos. Por exemplo, quando tiver uma oportunidade, carregue um serviço Office 365 e rastree o processo. Filtre o rastreio do tráfego DNS ou procure no FrameData o nome do serviço que navegue. Analise o rastreio para ter uma ideia dos passos que ocorrem quando o serviço é carregado. Isto ajuda-o a saber como deve ser o carregamento normal de páginas e, no caso de resolução de problemas, especialmente em relação ao desempenho, comparar bons e maus rastreios pode ensinar-lhe muito.

O Netmon utiliza o Microsoft Intellisense no campo Filtro de visualização. O Intellisense, ou conclusão inteligente de código, é esse truque em que escreve um período e todas as opções disponíveis são apresentadas numa caixa de seleção pendente. Por exemplo, está preocupado com o dimensionamento de janelas TCP, pode encontrar o caminho para um filtro (por .protocol.tcp.window < 100exemplo, ) por este meio.

Os rastreios netmon podem ter muito tráfego. Se não tiver experiência em lê-los, é provável que fique sobrecarregado ao abrir o rastreio pela primeira vez. A primeira coisa a fazer é separar o sinal do ruído de fundo no rastreio. Testou contra Office 365 e é esse o tráfego que pretende ver. Se estiver habituado a navegar pelos rastreios, poderá não precisar desta lista.

O tráfego entre o cliente e o Office 365 viaja através do TLS, o que significa que o corpo do tráfego será encriptado e não legível num rastreio genérico do Netmon. A sua análise de desempenho não precisa de saber as especificidades das informações no pacote. No entanto, está muito interessado nos cabeçalhos de pacotes e nas informações que contêm.

Sugestões para obter um bom rastreio

• Conheça o valor do endereço IPv4 ou IPv6 do computador cliente. Pode obtê-lo na linha de comandos ao escrever IPConfig e, em seguida, premir ENTER. Conhecer este endereço permite-lhe saber rapidamente se o tráfego no rastreio envolve diretamente o computador cliente. Se existir um proxy conhecido, envie um ping para o mesmo e obtenha também o respetivo endereço IP.

• Remova a cache de resolução DNS e, se possível, feche todos os browsers, exceto aquele em que está a executar os testes. Se não conseguir fazê-lo, por exemplo, se o suporte estiver a utilizar alguma ferramenta baseada no browser para ver o ambiente de trabalho do computador cliente, esteja preparado para filtrar o rastreio.

• Num rastreio ocupado, localize o serviço Office 365 que está a utilizar. Se nunca viu o seu tráfego antes ou raramente, este é um passo útil para separar o problema de desempenho de outro ruído de rede. Existem algumas formas de o fazer. Diretamente antes do teste, pode utilizar ping ou PsPing no URL do serviço específico (ping outlook.office365.com ou psping -4 microsoft-my.sharepoint.com:443, por exemplo). Também pode encontrar facilmente esse ping ou PsPing num rastreio Netmon (pelo respetivo nome de processo). Isso dar-lhe-á um lugar para começar a procurar.

Se estiver a utilizar apenas o rastreio do Netmon no momento do problema, também não há problema. Para se orientar, utilize um filtro como ContainsBin(FrameData, ASCII, "office") ou ContainsBin(FrameData, ASCII, "outlook"). Pode registar o número da moldura a partir do ficheiro de rastreio. Também poderá querer deslocar o painel Resumo da Moldura até à direita e procurar a coluna ID da Conversação. Existe um número indicado para o ID desta conversação específica que também pode gravar e analisar isoladamente mais tarde. Lembre-se de remover este filtro antes de aplicar qualquer outra filtragem.

Sugestão

O Netmon tem muitos filtros incorporados úteis. Experimente o botão Carregar Filtro na parte superior do painel Filtro de visualização .

Familiarize-se com o seu tráfego e saiba como localizar as informações de que precisa. Por exemplo, saiba como determinar que pacote no rastreio tem a primeira referência ao serviço Office 365 que está a utilizar (como "Outlook").

Tomando Office 365 Outlook Online como exemplo, o tráfego começa algo assim:

• Consulta DNS Standard e Resposta DNS para outlook.office365.com com QueryIDs correspondentes. É importante ter em conta o desvio de tempo para esta reviravolta e onde no mundo o Office 365 DNS Global envia o pedido de resolução de nomes. Idealmente, o mais localmente possível, em vez de metade do mundo.

• Um Pedido HTTP GET cujo relatório de estado foi Movido Permanentemente (301)

• Tráfego RWS, incluindo pedidos do RWS Connect e Respostas de ligação. (Este é o Winsock Remoto que faz uma ligação para si.)

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

• Em seguida, uma série de tráfego TLS:TLS, que é onde ocorrem as conversações do handshake TLS e do certificado TLS. (Lembre-se de que os dados são encriptados através de SSL/TLS.)

Todas as partes do tráfego são importantes e ligadas, mas pequenas partes do rastreio contêm informações importantes em termos de resolução de problemas de desempenho, pelo que vamos concentrar-nos nessas áreas. Além disso, uma vez que fizemos o suficiente Office 365 resolução de problemas de desempenho na Microsoft para compilar uma lista dos 10 principais problemas comuns, vamos focar-nos nesses problemas e como utilizar as ferramentas que temos para os eliminar a seguir.

Se ainda não as instalou, a matriz abaixo utiliza várias ferramentas sempre que possível. São fornecidas ligações para os pontos de instalação. A lista inclui ferramentas comuns de rastreio de rede, como o Netmon e o Wireshark, mas utilize qualquer ferramenta de rastreio com a qual se sinta confortável e em que esteja habituado a filtrar o tráfego de rede. Quando estiver a testar, lembre-se:

• Feche os browsers e teste com apenas um browser em execução – isto reduzirá o tráfego geral que capturar. Permite um rastreio menos ocupado.
• Esvaziar a cache de resolução DNS no computador cliente – isto irá dar-lhe uma imagem de ardósia limpa quando começar a capturar, para obter um rastreio mais limpo.

Problemas comuns

Alguns problemas comuns que pode enfrentar e como encontrá-los no seu Rastreio de rede.

Dimensionamento do Windows TCP

Encontrado no SYN – SYN/ACK. O hardware legado ou antigo pode não tirar partido do dimensionamento de janelas TCP. Sem as definições de dimensionamento de janelas TCP adequadas, a memória intermédia predefinida de 16 bits nos cabeçalhos TCP preenche 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, o que causa atrasos.

Ferramentas

• Netmon
• Wireshark

O que procurar

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

Repare que para cada SYN existe um número de porta de origem (SrcPort) correspondente na porta de destino (DstPort) da Confirmação relacionada (SYN/ACK).

Para ver o valor do Dimensionamento do Windows que é utilizado pela sua ligação de rede, expanda primeiro o SYN e, em seguida, o SYN/ACK relacionado.

Definições de Tempo de Inatividade do TCP

Historicamente, a maioria das redes de perímetro são configuradas para ligações transitórias, o que significa que as ligações inativas são geralmente terminadas. As sessões TCP inativas podem ser terminadas por proxies e firewalls superiores a 100 a 300 segundos. Isto é problemático para o Outlook Online porque cria e utiliza ligações de longo prazo, quer estejam inativas ou não.

Quando as ligações são terminadas por dispositivos proxy ou firewall, o cliente não é informado e uma tentativa de utilização do Outlook Online significará que um computador cliente tentará, repetidamente, reavivar a ligação antes de criar uma nova. Poderá ver bloqueios no produto, pedidos ou desempenho lento no carregamento da página.

Ferramentas

• Netmon
• Wireshark

O que procurar

No Netmon, observe o campo Desvio de Tempo para uma viagem de ida e volta. Um percurso de ida e volta é o tempo entre o cliente enviar um pedido para o servidor e receber uma resposta de volta. Verifique entre o Cliente e o ponto de saída (por exemplo, Cliente --> Proxy) ou o Cliente para Office 365 (Cliente --> Office 365). Pode ver isto em muitos tipos de pacotes.

Por exemplo, o filtro no Netmon pode ter um aspeto semelhante .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12a ou, no Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Sugestão

Não sabe se o endereço IP no seu rastreio pertence ao servidor DNS? Experimente procurar na linha de comandos. Clique em Iniciar>Execução> e escreva cmd ou prima a Tecla> Windows e escreva cmd. Na linha de comandos, escreva nslookup <the IP address from the network trace>. Para testar, utilize nslookup no endereço IP do seu computador. >Para ver uma lista dos intervalos de IP da Microsoft, veja Office 365 URLs e intervalos de endereços IP.

Se existir um problema, espere que sejam apresentados Desvios de Tempo longos, neste caso (Outlook Online), particularmente em pacotes TLS:TLS que mostram a passagem dos Dados da Aplicação (por exemplo, no Netmon, pode encontrar pacotes de dados da aplicação através de .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Deverá ver uma progressão suave no tempo ao longo da sessão. Se vir atrasos longos ao atualizar o Outlook Online, tal poderá dever-se ao envio de um elevado grau de reposições.

Latência/Tempo de Ida e Volta

A latência é uma medida que pode mudar muito consoante muitas variáveis, como atualizar dispositivos antigos, adicionar um grande número de utilizadores a uma rede e a percentagem de largura de banda geral consumida por outras tarefas numa ligação de rede.

Existem calculadoras de largura de banda para Office 365 disponíveis nesta página Planeamento de rede e otimização do desempenho para Office 365 página.

Precisa de medir a velocidade da ligação ou a largura de banda da ligação ISP? Experimente este site (ou sites semelhantes): Site Oficial do Speedtest ou consulte o seu motor de busca favorito para o teste de velocidade da expressão.

Ferramentas

• Ping
• PsPing
• Netmon
• Wireshark

O que procurar

Para controlar a latência num rastreio, beneficiará de ter registado o endereço IP do computador cliente e o endereço IP do servidor DNS no Office 365. Isto destina-se a uma filtragem de rastreio mais fácil. Se se ligar através de um proxy, precisará do endereço IP do computador cliente, do endereço IP do proxy/saída e do endereço IP do Office 365 DNS para facilitar o trabalho.

Um pedido de ping enviado para outlook.office365.com indicará o nome do datacenter que está a receber o pedido, mesmo que o ping possa não conseguir ligar-se para enviar os pacotes ICMP consecutivos da marca registada. Se utilizar o PsPing (uma ferramenta gratuita para transferência) e especificar a porta (443) e talvez para utilizar o IPv4 (-4), obterá um tempo médio de ida e volta para os pacotes enviados. Isto irá funcionar para outros URLs nos serviços Office 365, como psping -4 yourSite.sharepoint.com:443. Na verdade, pode especificar um número de pings para obter uma amostra maior para a média. Experimente algo como psping -4 -n 20 yourSite-my.sharepoint.com:443.

Nota

O PsPing não envia pacotes ICMP. Faz pings com pacotes TCP numa porta específica, para que possa utilizar qualquer um que saiba que está aberto. No Office 365, que utiliza SSL/TLS, experimente anexar a porta :443 ao seu PsPing.

Se carregou a página de Office 365 de desempenho lento enquanto fazia um rastreio de rede, deve filtrar um rastreio Netmon ou Wireshark para DNS. Este é um dos IPs que procuramos.

Eis os passos a seguir para filtrar o Netmon para obter o endereço IP (e ver a Latência de DNS). Este exemplo utiliza outlook.office365.com, mas também pode utilizar o URL de um inquilino do SharePoint (hithere.sharepoint.com por exemplo).

1. Execute ping no URL ping outlook.office365.com e, nos resultados, registe o nome e o endereço IP do servidor DNS para o qual o pedido ping foi enviado.
2. Rastreio de rede a abrir a página ou a efetuar a ação que lhe dá o problema de desempenho ou, se vir uma latência elevada no próprio ping, rastreia-o pela rede.
3. Abra o rastreio no Netmon e filtre por DNS (este filtro também funciona no Wireshark, mas é sensível às maiúsculas e minúsculas -- dns). Uma vez que sabe o nome do servidor DNS a partir do seu ping, também pode filtrar mais rapidamente no Netmon da seguinte forma: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), que tem o seguinte aspeto em dns e frame wireshark contém "namnorthwest".
   Abra o pacote de resposta e, na janela Detalhes do Pacote Netmon, clique em DNS para expandir para obter mais informações. Nas informações de DNS, encontrará o endereço IP do servidor DNS para o qual o pedido foi enviado no Office 365. Precisará deste endereço IP para o próximo passo (a ferramenta PsPing). Remova o filtro, clique com o botão direito do rato na Resposta DNS no Netmon (Resumo da Moldura>Localizar Conversações>DNS) para ver a Consulta DNS e a Resposta lado a lado.
4. No Netmon, tenha também em atenção a coluna Desvio de Tempo entre o Pedido de DNS e a Resposta. No próximo passo, a ferramenta PsPing de fácil instalação e utilização é muito útil, tanto porque o ICMP é frequentemente bloqueado em Firewalls como porque o PsPing monitoriza elegantemente a latência em milissegundos. O PsPing conclui uma ligação TCP a um endereço e porta (no nosso caso, abra a porta 443).
5. Instale o PsPing.
6. Abra uma linha de comandos (Iniciar > Execução > tipo cmd ou Cmd de tipo de Chave > do Windows) e altere o diretório para o diretório onde instalou o PsPing para executar o comando PsPing. Nos meus exemplos, pode ver que fiz uma pasta "Perf" na raiz de C. Pode fazer o mesmo para acesso rápido.
7. Escreva o comando para que faça o PsPing no endereço IP do servidor DNS Office 365 a partir do seu rastreio Netmon anterior, incluindo o número da porta, como psping -n 20 132.245.24.82:445. Isto irá dar-lhe uma amostra de 20 pings e uma média da latência quando o PsPing parar.

Se quiser Office 365 através de um servidor proxy, os passos são um pouco diferentes. Primeiro, utilize o PsPing para o servidor proxy para obter um valor de latência médio em milissegundos para proxy/saída e para trás e, em seguida, execute o PsPing no proxy ou num computador com uma ligação direta à Internet para obter o valor em falta (o valor a Office 365 e voltar).

Se optar por executar o PsPing a partir do proxy, terá dois valores de milissegundos: Computador cliente para servidor proxy ou ponto de saída e servidor proxy para Office 365. E já está! Bem, gravar valores, de qualquer forma.

Se executar o PsPing noutro computador cliente que tenha uma ligação direta à Internet, ou seja, sem um proxy, terá dois valores milissegundos: Computador cliente para servidor proxy ou ponto de saída e computador cliente para Office 365. Neste caso, subtraia o valor do computador cliente para o servidor proxy ou ponto de saída do valor do computador cliente para Office 365 e 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 Office 365.

No entanto, se conseguir encontrar um computador cliente na localização afetada que está diretamente ligada ou ignorar o proxy, poderá optar por ver se o problema se reproduz aí para começar e testá-lo a partir daí.

A latência, como se pode ver num rastreio netmon, esses milissegundos extra podem somar-se, se forem suficientes em qualquer sessão.

Nota

O seu endereço IP pode ser diferente dos IPs apresentados aqui, por exemplo, o ping pode devolver algo mais parecido com 157.56.0.0/16 ou um intervalo semelhante. Para obter uma lista dos intervalos utilizados pelo Office 365, consulte Office 365 URLs e intervalos de endereços IP.

Lembre-se de expandir todos os nós (existe um botão na parte superior para isto) se quiser procurar, por exemplo, 132.245.

Autenticação de Proxy

Isto só se aplica a si se estiver a passar por um servidor proxy. Caso contrário, pode ignorar estes passos. Ao trabalhar corretamente, a autenticação de proxy deve ocorrer em milissegundos, de forma consistente. Não deverá ver um mau desempenho intermitente durante os períodos de pico de utilização (por exemplo).

Se a autenticação de Proxy estiver ativada, sempre que fizer uma nova ligação TCP ao Office 365 para obter informações, terá de passar por um processo de autenticação nos bastidores. Por exemplo, ao mudar do Calendário para o Correio no Outlook Online, irá autenticar-se. No SharePoint, se uma página apresentar multimédia ou dados de vários sites ou localizações, será autenticado para cada ligação TCP diferente necessária para compor os dados.

No Outlook Online, poderá deparar-se com tempos de carregamento lentos sempre que alternar entre o Calendário e a sua caixa de correio ou carregamentos lentos de páginas no SharePoint. No entanto, existem outros sintomas não listados aqui.

A autenticação de proxy é uma definição no servidor proxy de saída. Se estiver a causar um problema de desempenho com Office 365, tem de consultar a equipa de rede.

Ferramentas

• Netmon
• Wireshark

O que procurar

A autenticação de proxy ocorre sempre que tem de ser criada uma nova sessão TCP, normalmente para pedir ficheiros ou informações ao servidor ou para fornecer informações. Por exemplo, poderá ver a autenticação de proxy em torno de pedidos HTTP GET ou HTTP POST. Se quiser ver os fotogramas onde está a autenticar pedidos no seu rastreio, adicione a coluna "Resumo NTLMSSP" ao Netmon e filtre por .property.NTLMSSPSummary. Para ver quanto tempo a autenticação está a demorar, adicione a coluna Time Delta.

Para adicionar uma coluna ao Netmon:

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

Mesmo que não adicione a coluna, o filtro Netmon funcionará. No entanto, a resolução de problemas será muito mais fácil se conseguir ver em que fase da autenticação se encontra.

Ao procurar instâncias de Autenticação de Proxy, certifique-se de que estuda todos os fotogramas em que existe um Desafio NTLM ou se está presente uma Mensagem de Autenticação. Se necessário, clique com o botão direito do rato no tráfego específico e em Localizar TCP de Conversações > . Tenha em atenção os valores do Time Delta nestas Conversações.

Um atraso de quatro segundos na autenticação de proxy, como se pode ver no Wireshark. O intervalo de tempo da coluna da moldura apresentada anterior foi efetuado ao clicar com o botão direito do rato no campo com o mesmo nome nos detalhes da moldura e ao selecionar Adicionar como Coluna.

Desempenho do 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 a ocorrer no exterior, pode adicionar segundos aos carregamentos de página. Idealmente, a resolução de nomes ocorre em menos de 100 ms. Caso contrário, deve fazer uma investigação mais aprofundada.

Sugestão

Não tem a certeza de como funciona a Conectividade de Cliente no Office 365? Veja o documento Referência de Conectividade do Cliente aqui.

Ferramentas

• Netmon
• Wireshark
• PsPing

O que procurar

Analisar o desempenho de DNS é normalmente outra tarefa para um rastreio de rede. No entanto, o PsPing também é útil para decidir uma possível causa.

O tráfego DNS baseia-se em pedidos TCP e UDP e as respostas estão claramente marcadas com um ID que ajudará a corresponder um pedido específico com a respetiva resposta específica. Verá tráfego DNS quando, por exemplo, o SharePoint utilizar um nome de rede ou URL numa página Web. Regra geral, a maior parte deste tráfego, exceto ao transferir Zonas, é executada através de UDP.

No Netmon e no Wireshark, o filtro mais básico que lhe permitirá ver o tráfego DNS é simplesmente dns. Certifique-se de que utiliza maiúsculas/minúsculas ao especificar o filtro. Lembre-se de remover a cache de resolução de DNS antes de começar a reproduzir o problema no computador cliente. Por exemplo, se tiver uma carga de página lenta do SharePoint para a Home page, deve fechar todos os browsers, abrir um novo browser, iniciar o rastreio, remover a cache de resolução de DNS e navegar para o seu site do SharePoint. Depois de toda a página ser resolvida, deve parar e guardar o rastreio.

Quer ver o desvio de tempo aqui. Além disso, pode ser útil adicionar a coluna Time Delta ao Netmon, o que pode fazer ao concluir estes passos:

1. Clique com o botão direito do rato numa coluna, como Descrição.
2. Clique em Escolher Colunas.
3. Localize a Diferença de Tempo na lista e clique em Adicionar.
4. Mova a nova coluna para o lugar antes ou atrás da coluna Descrição para que possa lê-las lado a lado.
5. Clique em OK.

Se encontrar uma consulta de interesse, considere isolá-la ao clicar com o botão direito do rato nessa consulta no painel de detalhes da moldura, selecionando LocalizarDNSde Conversações>. Repare que o painel Conversações de Rede passa diretamente para a conversação específica no respetivo registo de tráfego UDP.

No Wireshark, pode criar uma coluna para o tempo DNS. Faça o rastreio (ou abra um rastreio) no Wireshark e filtre por dnsou, mais útil, dns.time. Clique em qualquer consulta DNS e, no painel que mostra os detalhes, expanda os Domain Name System (response) detalhes. Verá um campo para a hora (por exemplo, [Time: 0.001111100 seconds]. Clique com o botão direito do rato desta vez e selecione Aplicar como Coluna. Isto irá dar-lhe uma coluna Time para uma ordenação mais rápida do seu rastreio. Clique na nova coluna para ordenar por valores descendentes para ver que chamada DNS demorou mais tempo a resolver.

Uma procura do SharePoint filtrada no Wireshark por dns.time (minúsculas), com o tempo dos detalhes transformados numa coluna e ordenados ascendentes.

Se quiser investigar melhor o tempo de resolução do DNS, experimente um PsPing na porta DNS utilizada pelo TCP (por exemplo, psping <IP address of DNS server>:53). Continua a ver um problema de desempenho? Se o fizer, é mais provável que o problema seja um problema de rede mais amplo do que um problema específico da aplicação DNS que está a atingir para resolver o problema. Também vale a pena mencionar, mais uma vez, que um ping para outlook.office365.com irá indicar-lhe onde está a ocorrer a resolução de nomes DNS para o Outlook Online (por exemplo, outlook-namnorthwest.office365.com).

Se o problema parecer específico do DNS, poderá ser necessário contactar o departamento de TI para ver as configurações de DNS e os Reencaminhadores de DNS para investigar melhor este problema.

Escalabilidade do Proxy

Serviços como o Outlook Online no Office 365 conceder aos clientes múltiplas ligações de longo prazo. Por conseguinte, cada utilizador pode utilizar mais ligações que exijam uma vida útil mais longa.

Ferramentas

Matemática

O que procurar

Não existe nenhum rastreio de rede ou ferramenta de resolução de problemas específica. Em vez disso, baseia-se em cálculos de largura de banda com base em limitações e outras variáveis.

Tamanho Máximo do Segmento TCP

Encontrado no SYN – SYN/ACK. Faça esta verificação em qualquer rastreio de rede de desempenho que tenha feito para garantir que os pacotes TCP estão configurados para transportar a quantidade máxima de dados possível.

O objetivo é ver um MSS de 1460 bytes para transmissão de dados. Se estiver atrás de um proxy ou estiver a utilizar um NAT, lembre-se de executar este teste de cliente para proxy/saída/NAT e de proxy/saída/NAT para Office 365 para obter os melhores resultados! Estas são sessões TCP diferentes.

Ferramentas

Netmon

O que procurar

O Tamanho Máximo do Segmento TCP (MSS) é outro parâmetro do handshake tridirecional no seu rastreio de rede, o que significa que encontrará os dados de que precisa no pacote SYN - SYN/ACK. O MSS é muito simples de ver.

Abra qualquer rastreio de rede de desempenho que tenha e encontre a ligação sobre a qual está curioso ou que demonstre o problema de desempenho.

Nota

Se estiver a analisar um rastreio e precisar de encontrar o tráfego relevante para a sua conversação, filtre pelo IP do Cliente ou pelo IP do servidor proxy ou ponto de saída, ou ambos. Indo diretamente, terá de enviar um ping para o URL que está a testar para o endereço IP de Office 365 no rastreio e filtrar pelo mesmo.

Está a ver o rastreio em segunda mão? Experimente utilizar filtros para se orientar. No Netmon, execute uma pesquisa com base no URL, como Containsbin(framedata, ascii, "sphybridExample"), tome nota do número da moldura.

No Wireshark, utilize algo como frame contains "sphybridExample". Se reparar que encontrou tráfego Do Winsock Remoto (RWS) (pode aparecer como um [PSH, ACK] no Wireshark), lembre-se de que as ligações RWS podem ser vistas pouco antes de SYN - SYN/ACKs relevantes, conforme abordado anteriormente.

Neste momento, pode gravar o número da moldura, largar o filtro e clicar em Todo o Tráfego na janela Conversações de Rede no Netmon para ver o SYN mais próximo.

Importante, se não tiver recebido nenhuma das informações do endereço IP no momento do rastreio, encontrar o URL no rastreio (parte de sphybridExample-my.sharepoint.com, por exemplo), irá fornecer-lhe endereços IP para filtrar.

Localize a ligação no rastreio que está interessado em ver. Pode fazê-lo ao analisar o rastreio, ao filtrar por endereços IP ou ao selecionar IDs de Conversação específicos através da janela Conversações de Rede no Netmon. Depois de encontrar o pacote SYN, expanda TCP (no Netmon) ou Protocolo de Controlo de Transmissão (em Wireshark) no painel Detalhes da Moldura. Expanda Opções de TCP e MaxSegmentSize. Localize a moldura SYN-ACK relacionada e Expanda As Opções de TCP e MaxSegmentSize. O menor dos dois valores será o Tamanho Máximo do Segmento. Nesta imagem, utilizo a Coluna incorporada no Netmon denominada Resolução de Problemas de TCP.

A coluna incorporada encontra-se na parte superior do painel Detalhes da Moldura . (Para voltar à vista normal, clique novamente em Colunas e, em seguida, selecione Fuso Horário.)

Eis um rastreio filtrado no Wireshark. Existe um filtro específico para o valor MSS (tcp.options.mss). Os fotogramas de um handshake SYN, SYN/ACK e ACK estão ligados na parte inferior do Wireshark equivalente a Detalhes da Moldura (portanto, frame 47 ACK, ligações para 46 SYN/ACK, ligações para 43 SYN) para facilitar este tipo de trabalho.

Se precisar de verificar a Confirmação Seletiva (tópico seguinte nesta matriz), não feche o rastreio!

Confirmação Seletiva

Encontrado no SYN – SYN/ACK. Tem de ser comunicado como Permitido no SYN e no SYN/ACK. A Confirmação Seletiva (SACK) permite uma repetição mais suave dos dados quando um pacote ou pacotes desaparecem. Os dispositivos podem desativar esta funcionalidade, o que pode originar problemas de desempenho.

Se estiver atrás de um proxy ou estiver a utilizar um NAT, lembre-se de executar este teste de cliente para proxy/saída/NAT e de proxy/saída/NAT para Office 365 para obter os melhores resultados! Estas são sessões TCP diferentes.

Ferramentas

Netmon

O que procurar

A Confirmação Seletiva (SACK) é outro parâmetro no handshake SYN-SYN/ACK. Pode filtrar o seu rastreio por SYN – SYN/ACK de várias formas.

Localize a ligação no rastreio que está interessado em ver ao analisar o rastreio, filtrar por endereços IP ou ao clicar num ID de Conversação através da janela Conversações de Rede no Netmon. Depois de encontrar o pacote SYN, expanda TCP no Netmon ou Protocolo de Controlo de Transmissão no Wireshark na secção Detalhes da Moldura. Expanda Opções de TCP e, em seguida, SACK. Localize a moldura SYN-ACK relacionada e Expanda As Opções de TCP e o respetivo campo SACK. Certifique-se de que o SACK é permitido no SYN e no SYN/ACK. Seguem-se os valores SACK, como se pode ver no Netmon e no Wireshark.

Geolocalização de DNS

Onde o mundo Office 365 tenta resolver a sua chamada DNS afeta a velocidade da sua ligação.

No Outlook Online, após a conclusão da primeira pesquisa de DNS, a localização desse DNS será utilizada para ligar ao seu datacenter mais próximo. Estará ligado a um servidor CAS do Outlook Online, que utilizará a rede principal para ligar ao datacenter (dC) onde os seus dados estão armazenados. Isto é mais rápido.

Ao aceder ao SharePoint, um utilizador que viaje para o estrangeiro será direcionado para o respetivo datacenter ativo, ou seja, o dC cuja localização se baseia na home-base do inquilino do SPO (por isso, um dC nos EUA, se for o utilizador baseado nos EUA).

O Lync Online tem nós ativos em mais do que um dC de cada vez. Quando são enviados pedidos para instâncias online do Lync, o DNS da Microsoft determinará de onde veio o pedido e devolverá os endereços IP do DC regional mais próximo onde o Lync online está ativo.

Sugestão

Precisa de saber mais sobre como os clientes se ligam ao Office 365? Veja o artigo Referência de conectividade do Cliente (e os gráficos úteis).

Ferramentas

• Ping
• PsPing

O que procurar

Os pedidos de resolução de nomes dos servidores DNS do cliente para os servidores DNS da Microsoft devem, na maioria dos casos, resultar na devolução do endereço IP de um datacenter regional (dC) do Microsoft DNS. O que significa isto para si? Se a sua sede estiver em Bengaluru, na Índia, mas estiver a viajar no Estados Unidos, quando o seu browser fizer um pedido para o Outlook Online, os servidores DNS da Microsoft devem entregar-lhe endereços IP a datacenters no Estados Unidos - um datacenter regional. Se for necessário correio do Outlook, esses dados irão percorrer a rede principal rápida da Microsoft entre os datacenters.

O DNS funciona mais rapidamente quando a resolução de nomes é feita o mais perto possível da localização do utilizador. Se estiver na Europa, quer aceder a 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 no outlook.office365.com para determinar onde o seu pedido DNS está a ser encaminhado no mundo. Se 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 a linha de comandos no computador cliente (através do cmd Iniciar > Execução > ou do tipo de chave > do Windows cmd). Escreva ping outlook.office365.com e prima ENTER. Lembre-se de especificar -4 se pretender especificar o ping através de IPv4. Poderá não conseguir obter uma resposta dos pacotes ICMP, mas deverá ver o nome do DNS para o qual o pedido foi encaminhado. Se quiser ver os números de latência para esta ligação, experimente o PsPing para o endereço IP do servidor que é devolvido por ping.

Resolução de Problemas da Aplicação Office 365

Ferramentas

• Netmon
• HTTPWatch
• Consola F12 no browser

Não abrangemos as ferramentas utilizadas na resolução de problemas específicos da aplicação neste artigo específico da rede. No entanto, encontrará recursos que pode utilizar nesta página.

Artigos relacionados

Gerir pontos finais do Office 365

FAQ sobre pontos finais de Office 365