Resumo
A Deteção Automática é a funcionalidade Outlook utilizada para obter informações de configuração dos servidores aos quais se liga. No Outlook 2016 com servidores Exchange, a Deteção Automática é considerada o único ponto de verdade para as informações de configuração e tem de ser configurada e a funcionar corretamente para que o Outlook esteja totalmente funcional. Este artigo descreve a implementação da Deteção Automática no canal atual do lançamento Clique-e-Outlook 2016. Para obter mais informações sobre os lançamentos das Office 365 de cliente, consulte os seguintes sites da Microsoft:
Números de versão e com build dos lançamentos das vias de atualizações para Office 365 clientes
Mais informações
Temporração da Deteção Automática
A Deteção Automática é executada nas seguintes alturas:
-
Durante a criação de contas.
-
Em intervalos definidos para recolher alterações aos URLs que fornecem Exchange do Serviço Web (OOF, Serviço de Disponibilidade, etc.). Se este processo for e concluída com êxito, outra tentativa será feita uma hora depois. Se a tentativa não for bem-sucedida, a tentativa seguinte será esvaída 5 minutos depois. Cada tentativa pode ser escalada até 25 por cento devido à infraestrutura de tarefas em segundo plano utilizada por todas Microsoft Office aplicações.
-
Em resposta a determinadas falhas de conectividade. Em vários cenários, quando uma tentativa de ligação falhar, o Outlook uma tarefa de Deteção Automática para obter novas definições em qualquer tentativa de corrigir o problema de ligação.
-
Quando outra aplicação invoca a aplicação através de MAPI. Para obter mais informações sobre MAPI, consulte o seguinte artigo do MSDN: Referência Outlook MAPI.
Eficiência da Deteção Automática
Utilize o Nome Principal de Utilizador (UPN) para acelerar o processo de Deteção Automática.
Num computador associado a um domínio, Outlook saber o UPN de um utilizador para iniciar o processo de Deteção Automática. O UPN pode ter sido utilizado para o início de sessão Windows, neste caso, Outlook tem acesso direto ao UPN a partir das credenciais de início de sessão. No entanto, se um utilizador utilizar domínio /nome de utilizador para iniciar sessão Windows, o Outlook apenas tem a mesma credencial para o utilizador. Para obter o UPN, Outlook primeiro tem de procurar o utilizador no diretório. Outlook pedirão que esta consulta consulte este caso. Em ambientes complexos, isto pode fazer com que um grande número de DCs seja contactado antes de um resultado ser encontrado. Após Outlook detetar o UPN do utilizador, o valor é cache no perfil e a procura não deverá ocorrer novamente para este utilizador.
Para evitar este cenário, o utilizador pode iniciar sessão com um UPN em vez de um domínio /nome de utilizador.
Considerações sobre ITAR
Microsoft Office 365 fornece funcionalidades que podem suportar clientes com obrigações de ITAR. No contexto da funcionalidade Deteção Automática no Outlook, este conjunto de funcionalidades inclui definições e comportamentos de políticas que garantem os pontos finais de serviço utilizados para a Deteção Automática como controlo de requisitos soberanos na nuvem. Mais especificamente, nos passos específicos do Office 365 indicados no processo de Deteção Automática (passo 4 e 11), o controlo da política está disponível para garantir que os pontos finais de serviço adequados são utilizados durante o processo de Deteção Automática.
Processo de Deteção Automática Sempre que o Outlook necessitar de informações de Deteção Automática, utiliza um conjunto de passos ordenados para tentar obter um payload XML que contenha definições de configuração. Muitos destes passos podem ser controlados através da utilização de Objetos da Política de Grupo (GPO) e o valor GPO é incluído na descrição do passo.
Passo 1: verifique se há cenários de reinício
Em alguns casos, como quando adiciona uma segunda conta enquanto o Outlook está em execução, o payload de Deteção Automática é arquivado em cache num ficheiro local a ser utilizado durante um reinício do cliente Outlook. O primeiro passo de Deteção Automática é consultar o registo para obter algumas informações especiais sobre o "arranque" que Outlook informa que está a meio de um destes cenários de reinício e ler o payload da Deteção Automática a partir do ficheiro local especial. Este é um caso raro e, normalmente, não é a causa dos problemas genéricos da Deteção Automática. Para este passo, se o Outlook decidir que está neste cenário de arranque especial e a tentativa de recuperar os dados XML de Deteção Automática falhar, a tentativa de Deteção Automática falha. Não são tentados passos adicionais.
Não existe controlo de política específico para este passo.
Passo 2: verificar a preferência de Dados Locais
Outlook fornece um GPO para permitir que os administradores implementem um ficheiro XML de Deteção Automática específico a ser utilizado na configuração. Se o administrador tiver implementado este valor de registo e tiver inscrito um ficheiro autodiscover.xml, Outlook o payload de Deteção Automática a partir deste ficheiro. Isto é novamente um caso invulgar e normalmente não é a causa dos problemas genéricos da Deteção Automática. Se este passo não recuperar um payload, o Outlook avançar para o passo 3.
Para obter mais informações sobre o XML de Deteção Automática, consulte o seguinte artigo do TechNet: Planear a configuração automática de contas de utilizador no Outlook 2010Nota Este artigo foi criado para o
Outlook 2010. No entanto, ainda é relevante para versões posteriores do Outlook.
O valor de controlo da política para este passo é o seguinte: PreferLocalXML.
Passo 3: procurar dados de Último Bom Conhecido (LKG)
Quando a Deteção Automática recupera um payload XML com êxito através de qualquer passo, o payload pode ser cache localmente como a configuração "último bem conhecido". O primeiro método frequentemente utilizado para obter um payload de Deteção Automática é a partir deste último ficheiro bom conhecido. O caminho do último ficheiro XML bom conhecido é a partir do Outlook perfil. O passo LKG só é utilizado para descobrir a configuração principal da caixa de correio. Se a procura de Deteção Automática se der a uma caixa de correio não principal (alternativa, delegada, pasta pública, caixa de correio de grupo, entre outros), o passo LKG é ignorado automaticamente. Se este passo não recuperar um payload, o Outlook avança para o passo 4.
O valor de controlo da política para este passo é o seguinte: ExcludeLastKnownGoodURL.
Passo 4: Verificar o O365 como prioridade
Outlook utiliza um conjunto de heurísticas para determinar se a conta de utilizador fornecida é Office 365. Se o Outlook determinar com confiança que é um utilizador do O365, é feita uma tentativa de obter o payload de Deteção Automática a partir dos pontos finais conhecidos do O365 (normalmente https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml ou https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Se este passo não recuperar um payload, o Outlook avançar para o Passo 5.
O valor de controlo da política para este passo é o seguinte:
ExcludeExplicitO365Endpoint.
Considerações de ITAR
Por predefinição, Outlook consultas no ponto final conhecido para obter o payload de Deteção Automática. A política existente para ultrapassar este passo ainda é válida e pode ser utilizada para ir para o Passo 5 sem experimentar o ponto final. Em alternativa, existe uma nova política que direcionará o Outlook para consulta de um Serviço de Configuração do Office 365 central para obter URLs adequados a partir dos quais seja possível obter o payload de Deteção Automática. Conceptualmente, o processo funciona da seguinte forma:
-
A nova política é definida.
-
Durante o passo 4 do processo de Deteção Automática, Outlook consultas no serviço Office 365 configuração.
-
O serviço determina que (se alguma) necessidades de ITAR especiais estão em vigor para o utilizador especificado e devolve os URLs adequados para esse utilizador ao utilizar as informações de domínio do UPN.
-
Outlook tenta obter o payload de Deteção Automática a partir dos URLs fornecidos pelo serviço.
O valor de controlo da política para a nova funcionalidade utilizar o Serviço Office 365 Configuração é EnableOffice365ConfigService.
Nota: A partir da comtrução 16.0.9327.1000,a política EnableOffice365ConfigService já não é utilizada.
Passo 5: procurar dados SCP
Se o computador tiver uma ligação de domínio, o Outlook executa uma consulta LDAP para obter dados do Ponto de Ligação de Serviço que devolve um caminho do XML de Deteção Automática. Em seguida, é feita uma tentativa para cada URL devolvido pela procura de SCP para tentar obter o payload da Deteção Automática. Se este passo não recuperar um payload, o Outlook avançar para o passo 6.
Para obter mais informações sobre o SCP, consulte o seguinte artigo do MSDN: Publicação com Pontos de Ligação de Serviço.
O valor de controlo da política para este passo é o seguinte: ExcludeScpLookup.
Passo 6: verificar o domínio raiz
Para este passo, o Outlook cria um URL a partir do nome de domínio do endereço inicial no formato https://<de domínio>/autodiscover/autodiscover.xml e tenta obter o payload a partir do URL resultante. Uma vez que muitos domínios de raiz não estão configurados para a Deteção Automática, o Outlook silencia propositadamente todos os erros de certificado que ocorrem durante a tentativa de recuperação. Se este passo não recuperar um payload, o Outlook avança para o passo 7.
O valor de controlo da política para este passo é o seguinte: ExcludeHttpsRootDomain.
Passo 7: verificar o domínio da Deteção Automática
Para este passo, o Outlook cria um URL a partir do nome de domínio do endereço inicial no formato https://autodiscover.<do>/autodiscover/autodiscover.xml e tenta obter o payload a partir do URL resultante. Uma vez que este é o URL principal normalmente para dados de Deteção Automática, o Outlook não silencia os erros de certificado que ocorrem durante a tentativa de recuperação. Se este passo não recuperar um payload, o Outlook avança para o passo 8.
O valor de controlo da política para este passo é o seguinte: ExcludeHttpsAutoDiscoverDomain.
Passo 8: procurar dados locais
No passo 2, Outlook se o administrador implementou uma política para verificar especificamente se o payload de Deteção Automática é uma preferência. Se não houver uma política em posição, mas os passos anteriores não obtêm um payload, o Outlook tenta obter um payload a partir do ficheiro local mesmo sem a definição PreferLocalXML configurada. Se este passo não recuperar um payload, o Outlook avança para o passo 9.
Não existe controlo de política para este passo.
Passo 9: procurar redirecionamentos HTTP
Para este passo, o Outlook envia um pedido para o URL de domínio de Deteção Automática (http://autodiscover.<de domínio>/autodiscover/autodiscover.xml) e testa o redirecionamento de respostas. Se for devolvido um payload XML de Deteção Automática e não um redirecionamento, o Outlook ignora a resposta XML de Deteção Automática real porque foi recuperada sem segurança (http). Se a resposta for um URL de redirecionamento válido, o Outlook segue o redirecionamento e tenta obter um XML de payload a partir do novo URL. Outlook efetuará verificações de certificados para impedir o redirecionamento para URLs potencialmente nocivos neste passo. Se este passo não recuperar um payload, o Outlook avança para o passo 10.
O valor de controlo da política para este passo é o seguinte: ExcludeHttpRedirect.
Passo 10: verificar se há dados SRV
Para este passo, a Outlook faz uma consulta DNS para "_autodiscover._tcp.<nome de domínio>" e percorria os resultados à procura do primeiro registo que utiliza https como protocolo. Outlook, em seguida, tenta obter o payload a partir do URL. Se este passo não recuperar um payload, o Outlook para o passo 11.
O valor de controlo da política para este passo é o seguinte: ExcludeSrvRecord.
Passo 11: procure o O365 como failsafe
Se todos os passos anteriores não devolverem um payload, o Outlook utiliza um conjunto de heurísticas menos restritivo para decidir se uma tentativa final dos pontos finais do O365 é potencialmente útil. Se o Outlook decidir que uma tentativa vale a pena, tenta os pontos finais conhecidos da Deteção Automática do O365, no caso de a conta ser uma conta do O365. Esta tentativa utiliza os mesmos URLs de destino do passo 4 e difere apenas no facto de ter tentado como último recurso e não anteriormente no processo de Deteção Automática.
O valor de controlo da política para este passo é o seguinte: ExcludeExplicitO365Endpoint.
Considerações sobre ITAR
Se o Outlook chegar a este passo e não obtever um payload de Deteção Automática com êxito, são efetuados dois testes para ver se os pontos finais do Office 365 conhecidos devem ser tentados. Primeiro, se a caixa de correio for uma conta de consumidor (por exemplo, outlook.com), é tentado o ponto final conhecido. Segundo, se a caixa de correio estiver determinada a pertencer a um domínio que não tem requisitos de ITAR, é tentado o ponto final bem conhecido. Se a caixa de correio for determinada como comercial e pertencer a um domínio que tem requisitos de ITAR, não é feita nenhuma tentativa para os pontos finais conhecidos Office 365 item. No futuro, o passo 11 pode passar para a mesma lógica que o passo 4 e chamar o Serviço Office 365 Configuração. Quando essa alteração for feita, este artigo será atualizado para refletir o novo passo do processo.
O redirecionamento do processamento do Passo 9 na secção Processo de Deteção Automática é um passo explícito para processar dados que não sejam de redirecionamento de dados. Em qualquer um dos outros passos seguros, para qualquer tentativa de obter o payload XML de Deteção Automática, uma possível resposta do ponto final é uma resposta de redirecionamento. Esta resposta Outlook redirecionamento para um URL novo e diferente para tentar obter o payload. Além disso, os dados de redirecionamento podem conter um endereço de e-mail novo e diferente para utilizar como endereço de destino para a tentativa de Deteção Automática. Outlook considera três respostas separadas como "redirecionar respostas":
-
Um código de estado HTTP (301, 302) com um novo URL
-
Um código de estado HTTP de 200, mas com um payload XML que Outlook para redirecionar para um URL diferente
-
Um código de estado HTTP de 200, mas com um payload XML que Outlook um endereço smtp diferente como endereço de destino.
Nos casos 1 e 2, o Outlook tenta obter o XML de Deteção Automática a partir do novo URL, desde que o protocolo seja https. Os URLs não seletivos (http) não são tentados. Além disso, mesmo que o protocolo no novo URL seja https, o Outlook irá verificar as informações do certificado para fornecer uma medida adicional de segurança.
No caso 3, Outlook todo o processo de deteção automática desde o início. Se todos os passos (1-11) se tentarem sem êxito através do novo endereço de e-mail, o Outlook regressa ao endereço de e-mail original, avança para o passo 5 e continua a tentativa de obter um payload XML com o endereço original.
Exceções Os passos na secção Processo de Deteção Automática são as regras gerais para a forma Outlook obter o payload de deteção automática. Existem várias otimização e tentativas excecionais que podem alterar o processo ligeiramente. Por exemplo, ao criar uma nova conta, o Outlook ignora internamente o passo 3 (verifique se há dados de Último Bom Conhecido (LKG), uma vez que não pode ter uma última entrada boa conhecida. Da mesma forma, se uma tentativa tiver sido ativada devido Outlook um erro com as informações de configuração atuais, então pretende voltar Outlook deteção automática propositadamente e não utilizar Outlook informação LKG porque, provavelmente, as últimas informações boas conhecidas resultaram numa falha.
Controlo da política Os valores da política que são definidos na secção Processo de Deteção Automática podem ser valores de registo baseados em políticas ou valores não baseados em políticas. Quando são implementadas através do GPO ou através da configuração manual da chave de políticas, as definições têm precedência sobre a chave que não é de política.
Chave que não é política: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Chave de Política: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover
Cada valor é do tipo DWORD.
O valor PreferLocalXML difere dos outros valores de controlo como uma definição de 1 conjuntos Outlook para ativo esse passo no processo. Para os valores restantes, uma definição de 1 diz ao Outlook para destivar ou ignorar o passo associado. Por exemplo, definir o valor ExcludeHttpsRootDomain para 1 Outlook não deve efetuar o passo 6 no processo.
Controlos de registo adicionais
Outlook fornece várias opções de configuração baseadas no registo adicionais que podem afetar o processo de Deteção Automática:
Utilizar o serviço Office 365 de Configuração
Chave: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valor: EnableOffice365ConfigService
Predefinição: 0
Dados: defina estes dados DWORD para 1 para forçar Outlook que este ligue para o Serviço Office 365 Deteção Automática para obter os URLs de Deteção Automática adequados.
Definições de tempo de tempo de http
Chave: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valor: Tempo limite
Predefinição: 25 segundos
Mínimo: 10 segundos
Máximo: 120 segundos
Informações: Os tempos de tempo especificados são utilizados como definições do WinHttpSetTimeouts. Os dados especificados são transmitido aos quatro parâmetros da API WinHttpSetTimeouts. Isto potencialmente permite um pedido HTTP que não pode ser atingido ao limite de tempo limite mais rapidamente, o que irá melhorar o desempenho geral. As definições também podem permitir que um pedido HTTP que demova mais do que a predefinição de 25 segundos seja efetuado com êxito ao aumentar a definição de tempo de tempo para um valor superior a 25 segundos.
Controlo do Protocolo Mapi/Http
Chave: HKEY_CURRENT_USER\Software\Microsoft\Exchange
Valor: MapiHttpDisabled
Predefinição: 0
Dados: 1 = O Protocolo está Desativado; 0 = Protocolo está Ativado
Informações: este valor não se encontra na chave de Deteção Automática. Esta é uma definição geral que controla se o Outlook pode tentar ligar ao Exchange através da pilha de protocolos Mapi/Http. A predefinição Outlook 2016 não é de desativar este protocolo. Isto permite ao processo de Deteção Automática adicionar um cabeçalho especial (X-MapiHttpCapability:1) ao processo de deteção para que as definições do protocolo Mapi/Http possam ser avaliadas e processadas.
Controlo de Negociação de Autenticação Legado
Chave: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
Valor: AllowNegoCapabilityHeader
Predefinição: 0
Dados: são adicionados 1 = Cabeçalhos; 0 = Os cabeçalhos não são adicionados
Informações: Tenha em atenção que este valor não está na chave Deteção Automática. Esta definição controla se um cabeçalho de negociação de autenticação é adicionado aos pedidos http. Os conteúdos do cabeçalho dependem das funcionalidades de autenticação do computador cliente. Um cabeçalho de exemplo poderá ser: "X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP". Este valor de registo e o cabeçalho que adiciona raramente são utilizados numa pilha de autenticação moderna e é muito pouco provável que afete o processo de deteção de dados tAodiscover de forma negativa ou positiva.
Tratamento de Erros do Certificado
Chave: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valor: ShowCertErrors
Predefinição: 0
Dados: 1 = Mostrar avisos/erros do certificado; 0 = Não mostrar avisos de certificado
Informações: este valor controla a forma como Outlook lida com erros e avisos de certificados recebidos quando efetua tarefas http. O Outlook poderá anular esta definição em alguns casos (passo 6 na secção Processo de Deteção Automática), mas, no caso geral, se esta definição estiver ativada, o Outlook apresentará uma caixa de diálogo de segurança que apresenta o erro ou aviso do certificado e permite que o utilizador ok ou Cancelar o pedido http. Existem três erros de certificado específicos que o utilizador pode decidir ignorar e que o Outlook o pedido http:
-
WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – existe um problema com a data nas propriedades do certificado
-
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – existe um problema com o nome comum nas propriedades do certificado
-
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – existe um problema com a autoridade de certificação nas propriedades do certificado
Pode encontrar mais informações sobre estes três estados de erro de certificado na WINHTTP_STATUS_CALLBACK de chamadas
Tratamento de Autenticação do Proxy
Chave: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
Valor: AllowOutlookHttpProxyAuthentication
Predefinição: 0
Dados: 1 = Permitir que Outlook lidar com desafios de autenticação de servidores proxy; 0 = falhas de autenticação de servidores proxy de forma silenciosa
Informações: este valor de registo permite o descontração de uma configuração de segurança e é abordado detalhadamente no seguinte artigo na Base de Dados de Conhecimento Microsoft:
3115474 MS16-099: Descrição da atualização de segurança para o Outlook 2010: 9 de agosto de 2016
Deteção automática para outros protocolos
A Deteção Automática como uma funcionalidade também é utilizada pelo Outlook para descobrir e configurar contas Exchange ActiveSync (EAS). O processo de Deteção Automática e a tomada de decisões do EAS estão separados dos passos descritos neste artigo. Por exemplo, a implementação do EAS não implementa a lógica de pontos finais do O365 e não tem um passo que verifica as localizações de SCP. Este artigo tem como âmbito descrever os passos detalhados que o Outlook utiliza para tentativas de Deteção Automática para obter os protocolos baseados em MAPI Exchange.
Referências
As informações legados sobre a deteção automática podem ser encontradas no seguinte artigo na Base de Dados de Conhecimento Microsoft:
2212902 Comportamento inesperado da Deteção Automática quando tem definições de registo na chave \Autodiscover
Para obter mais informações sobre a Deteção Automática, consulte os seguintes artigos da Microsoft:
