LATAM Support Blog https://docs.microsoft.com/archive/blogs/latam/feed.xml Wed, 17 Apr 2019 13:51:24 GMT en-US hourly 1 Exchange Online Protection - Spear Phishing Attack, ASF and ATP https://docs.microsoft.com/archive/blogs/latam/spearphishingenus Wed, 17 Apr 2019 08:27:49 GMT https://blogs.technet.microsoft.com/latam/?p=21835 The attacker would simply create a DNS entry for the external IP address of this website. The webpage is identical to the old "login.microsoftonline.com". After the website is cloned and published, the attacker will build a nice written email with this information. It's important to understand that they usually use spoofs, so these emails are sent similar to the original sender - and this is why we should use features such as SPF/Dkim/DMARC. In the simulation below, I'm adding my webserver to the email, spoofing the sender so they can be tricked by opening and clicking on my email: *As much as I can create a valid clone, published externally and add a real spoof in the attack, I want to keep my Kali Linux Lab in Azure. If you are a Pentester, please let the azure team know in the procedure of creating the VM.     The victim then would access the URL from my email, and the HTTP POST would be added to my webserver DB. How can administrators prevent end users from clicking on these emails? Exchange Online Protection has not only tools that can prevent these emails from arriving, but also features that can prevent end users from accessing the information. 1) ASF Advanced SPAM Filter acts on the SPAM Filter for ExO. It acts by reading the email body and preventing these emails from reaching the /Inbox. For example: This was added as a Spam Confidence Level of 6, due to the "Numeric IP in URL" action. This methodology is commonly used by attackers in order to trick users by clicking on a fake URL.   - ATP (Safe Links) Advanced Threat Protection has become common for larger enterprises. This avoids users from reaching out to unsafe links. When the end user tries to reach out the URL, it's validated by a MS server so we are sure this URL is valid/does not contain a malware, redirect or being used as a phishing endpoint. The end user is alerted and these actions can be monitored by the company admin:         As we can see below, when the website is redirected to a phishing endpoint, we are first routed to ".safelinks.protection.outlook.com": Information received by the end user (language can be customized): Admin reporting for the ATP:   ++++++++++++++++++++++++++++++++++++++++++++++ This is a post translation for the 2015 article written in Portuguese. Today, ATP has evolved, together with multiple Microsoft (and third party) technologies. For Microsoft, I indicate going through the CISO workshop [https://docs.microsoft.com/en-us/office365/securitycompliance/ciso-workshop ], together with the Cybersecurity Reference Architecture (MCRA) for integrated solutions. Other solutions that can help you and your organization to be ready for these attacks: 1) SecureScore can help you (as the admin) to understand your security score for O365. 2) Phishing Simulations (phishing campaigns) are available in O365. This can help to prepare your organization culture.]]> Exchange Online – Planejando Mailbox Moves para Mailboxes com +100GB https://docs.microsoft.com/archive/blogs/latam/migrarover100gb Wed, 31 Oct 2018 13:18:14 GMT https://blogs.technet.microsoft.com/latam/?p=21805 Agradecimentos especiais ao time de suporte da Microsoft – Joao Nascimento, Sergio Duarte & Fabio Baleizao. Aproveitando que irei sair de férias agora no dia 02 de Novembro, irei deixar um post de lembrança para meus amigos do suporte, consultoria e parceiros. Alguns clientes abrem chamados com problemas para migrar mailboxes para a nuvem, com o erro abaixo: 
Error: MigrationPermanentException: Mailbox size 160.96GB (165,457,177,916 bytes) exceeds target quota 100GB (107,374,182,400 bytes).
Em outras palavras, a mailbox source (OnPremises) possui uma database maior do que a quota da mailbox de destino (OnCloud). O problema pode ser simples de ser resolvido, porém o recomendado é sempre planejar antes de executar. Vamos iniciar com o entendimento do ambiente local.

Possuir mailboxes com um quota superior a 100GB seria um best practice?

Pode depender do ambiente. O Exchange 2019 possui um warn limit de mailboxes para 2TB – o que não significa que devemos utilizá-lo desta maneira. Existe um excelente artigo escrito  pelo time de produto sobre este tema, em que a conclusão seria entre 2.5k a 5k mensagens em cada folder e que o que importa realmente seriam os números de emails e não o tamanho em si. Com o tempo, a tecnologia se adapta e inovamos soluções – pessoalmente recomendo seguir a mesma métrica do ambiente online (100GB). Matematicamente falando: um usuário comum pode utilizar um quota de 100GB sem problemas. Tendo uma compreensão que este usuário recebe aprox. 150 emails por dia, com aproximadamente 100KB para cada mensagem teríamos 15MB de dados por dia (5.47GB por ano). Para acomodar 100GB de dados, precisaríamos de ~18 anos (e até lá espero que o custo de disk irá diminuir e o quota aumentar). Consequentemente, os tamanhos de emails seriam maiores – seria uma discussão para outro post. Isto significa que caso o seu usuário alcance o volume de 100GB, existe uma grande chance deste volume ser anormal ; gerado por notificações automáticas de monitoramento ou anti-virus, internal SPAM entre outros.

Possuir mailboxes com um archive quota superior a 100GB seria um best practice?

O mesmo estudo acima segue para quota de archive. A questão seria comparar a utilização. O archive deve ser utilizado para um conteúdo “antigo”, sendo este utilizado apenas pelo usuário dono da mailbox. Conforme explicado no artigo abaixo, especificamente para Exchange Online - O uso de journaling, regras de transporte ou regras de encaminhamento automático para copiar mensagens para uma caixa de correio do Exchange Online com a finalidade de arquivamento não é permitido. A caixa de correio de arquivo morto de um usuário destina-se somente a esse usuário. A Microsoft reserva o direito de negar o arquivamento ilimitado em situações onde a caixa de correio de arquivo morto do usuário é usada para armazenar dados de arquivo morto de outros usuários. https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits Logicamente, para ambientes OnPremises, o quota é customizado pelo administrador que pode optar pelo valor. Seguindo a regra anterior, seria uma boa idéia possuir 50GB de quota para archive (+9 anos de conteúdo). Para coletar informações de sizing, basta executar os comandos: 
Get-MailboxStatistics mailbox | ft DisplayName, TotalItemSize, ItemCount 
Get-MailboxStatistics -archive mailbox | ft DisplayName, TotalItemSize, ItemCount

O que acontece na migração?

Uma mailbox com utilização maior que a quota de serviços do Exchange Online irá falhar na migração, com o erro de “size exceeds target quota”. Isto serve também para a utilização de quota de Recoverable Items e para procedimentos de MailboxRestoreRequest (target mailbox vs. source mailbox size & quota). A quota de Recoverable Items é “separada” da quota da mailbox. Ela é utilizada não apenas por conteúdo recoverable como por exemplo, conteúdo de mailbox audit:  
Storage quota for Recoverable Items folder in primary mailbox (not on hold) 30 GB
   
Storage quota for Recoverable Items folder in primary mailbox (on hold) 100 GB
    Caso o administrador precise aumentar esta quota no ambiente de Exchange Online, disponibilizamos um artigo que explica passo a passo como efetuar esta tarefa.

Como migrar uma mailbox com utilização superior a 100GB?

  • Limpeza. Mitigar problemas de tecnologia também significa entender que “technology is not a panacea”. Ações de sysadmin consistem em ensinar usuários como gerenciar os dados de suas mailboxes – criando rules ou tags para remover conteúdo não utilizado.
  • Caso esta mailbox não possua Archive, a recomendação seria habilitar a funcionalidade do ambiente OnPremises e mover items antigos para o Archive antes da migração. Posteriormente, basta migrar a mailbox + archive.
  • Caso esta mailbox possua archive já com uma utilização próxima ou superior a 50GB, a recomendação seria:
  1. Separar o archive mais “antigo” e aguardar a migração completar para dados da mailbox e do initial archive de 50GB.
  2. Iniciar a migração de dados de archive remanescentes assim que o auto-expand archive habilite auxiliary archives para a mailbox da nuvem (lembrando que esta tarefa pode demorar diversos dias). Lembrando também que o auto-expand deve estar habilitado para a Mailbox Online.
Dos criadores de: Não perca a nova moda, já disponível nas lojas: ]]> Nova plataforma de Blog Posts - Caio Cesar https://docs.microsoft.com/archive/blogs/latam/caioc-new-platform Tue, 23 Oct 2018 10:49:03 GMT https://blogs.technet.microsoft.com/latam/?p=21795 https://c4iocesar.wordpress.com/blog/ No momento, irei criar os posts em ambas as plataformas (WordPress e LATAM Blog). At, Caio Ribeiro Cesar Sr. Technical Advisor - Exchange & Identity Online]]> Horário de verão no Brasil 2018 – Como isso afeta o calendário de clientes do Microsoft Exchange e Office 365 https://docs.microsoft.com/archive/blogs/latam/horario-de-verao-no-brasil-2018-como-isso-afeta-o-calendario-de-clientes-do-microsoft-exchange-e-office-365 Fri, 19 Oct 2018 17:50:18 GMT https://blogs.technet.microsoft.com/latam/?p=21785 Sobre o horário de verão 2018: ==========================================
Conforme última atualização do decreto 6658, o horário de verão brasileiro está definido da seguinte forma:
Horário de verão inicia no primeiro domingo de novembro (dia 04) às 00:00:00
Horário de verão termina no terceiro domingo de fevereiro (dia 17) às 00:00:00
Para suportar estas alterações de horário de verão, a Microsoft disponibilizou desde abril de 2018 as atualizações para as versões de sistemas operacionais suportadas.
Segue abaixo o artigo oficial sobre a atualização;
#  Time zone and DST changes in Windows for Brazil, Morocco, and São Tomé and Príncipe
https://support.microsoft.com/en-us/help/4093753/time-zone-and-dst-changes-in-windows-for-brazil-morocco-and-sao-tome-a
* É possível que outras atualizações tenham substituído esta atualização. Consultar o site do Catalog para ver o último kb válido.

Como esta mudança afeta os clientes de Exchange / Office 365? ==========================================
Os clientes de correio trabalham de maneiras diferentes.
  • Outlook: irá utilizar a informação de fuso horário da máquina local para ajustar as reuniões. Se o Sistema Operacional estiver devidamente atualizado, o Outlook irá mostrar as reuniões com o horário correto.
  • OWA: O cliente OWA utiliza as informações de fuso horário do servidor. Isto significa que usuários do OWA necessitam que a atualização de fuso horário esteja aplicada em todos os servidores Exchange da organização.
  • ActiveSync: O ajuste dos compromissos no calendário dos dispositivos móveis dependem de atualização no S.O. do próprio dispositivo.
* Os servidores do Office 365 já estão atualizados com as últimas definições de horário de verão.

Informações adicionais ==========================================
Ao criar compromissos baseados em Exchange / Office 365, a solicitação da reunião inclui informações do horário de verão do organizador da reunião, ou seja, ao criar uma solicitação de reunião de uma estação de trabalho, o Outlook vai incluir o fuso horário do organizador e informações de quando o horário de verão começa e termina. Neste caso, mesmo que você tenha uma reunião recorrente que foi criada antes de sair a atualização do horário de verão, o cliente de correio tem que ser capaz de recalcular o horário do compromisso baseado nas informações atualizadas do SO da estação de trabalho ou servidor (dependendo do cliente utilizado).
Pode acontecer em alguns casos de compromissos seguirem com a data incorreta, principalmente no período Delta (período de alteração entre a antiga data de horário de verão e a nova data – neste ano de 2018 entre 21 de outubro a 03 de novembro), como se respeitasse o horário de verão de antes da atualização. Para estes casos o melhor é avaliar os compromissos individualmente, o maior motivo para isso acontecer é alguma propriedade do compromisso estar ausente ou corrompida, que pode gerar ainda resultados distintos para o mesmo compromisso se comparados em clientes diferentes como Outlook e OWA.
Para estes casos, a recomendação é rodar a ferramenta Calendar Checking Tool for Outlook (CalCheck) no calendário afetado.
https://www.microsoft.com/en-us/download/details.aspx?id=28786
A ferramenta irá gerar um relatório no formato *.csv. Verifique se o compromisso afetado está listado no relatório. Somente compromissos com erro aparecem no relatório.
Consulte o site abaixo para ver a relação dos erros e as respectivas soluções;
https://support.microsoft.com/en-us/help/2678030/information-about-the-calendar-checking-tool-for-outlook-calcheck

Para confirmar se a atualização do horário de verão foi aplicada no Windows, você pode utilizar o comando abaixo;
Antes do KB instalado:
w32tm /tz
Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias)
[Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)]
[Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:10 D:3 DoW:6)]
 
Após KB instalado:
w32tm /tz
Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias)
[Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)]
[Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:11 D:1 DoW:6)]

Artigos relacionados: ==========================================
# Decreto Oficial com as datas de horário de verão:
https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm
# Horário de verão no Brasil inicia em 04 de Novembro de 2018 (lista de KBs)
https://blogs.technet.microsoft.com/latam/2018/10/17/horario-de-verao-no-brasil-inicia-em-04-de-novembro-de-2018-lista-de-kbs/
# How time zone normalization works in Microsoft Outlook
https://support.microsoft.com/en-us/help/2642044/how-time-zone-normalization-works-in-microsoft-outlook
# Information about the Calendar Checking Tool for Outlook (CalCheck)
https://support.microsoft.com/pt-br/help/2678030/information-about-the-calendar-checking-tool-for-outlook-calcheck
]]> Horário de verão no Brasil inicia em 04 de Novembro de 2018 (lista de KBs) https://docs.microsoft.com/archive/blogs/latam/horario-de-verao-no-brasil-inicia-em-04-de-novembro-de-2018-lista-de-kbs Wed, 17 Oct 2018 15:24:26 GMT https://blogs.technet.microsoft.com/latam/?p=21745 4 de novembro, quando os relógios serão adiantados em uma hora em vários estados do País. A partir desta comunicação, a configuração do horário de verão fica definida como: Inicio do Horário de verão: 04 de Novembro de 2018 (Primeiro domingo de novembro) - Adiado em duas semanas, do dia 21/10 para 04/11 pelo decreto abaixo. Fim do Horário de verão finaliza: 17 de fevereiro de 2019 (Terceiro domingo de fevereiro) Decreto Oficial com as datas de horário de verão: https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm Portanto, as atualizações referentes ao início de horário de verão permanecem as mesmas já disponibilizadas desde abril. Em Abril/18, a Microsoft liberou as atualizações para que as diversas versões de sistemas operacionais suportadas tivessem esta atualização implementada. Time zone and DST changes in Windows for Brazil, Morocco, and São Tomé and Príncipe https://support.microsoft.com/en-us/help/4093753/time-zone-and-dst-changes-in-windows-for-brazil-morocco-and-sao-tome-a A tabela abaixo descreve quais foram os primeiros Monthly Quality Rollups que contem a atualização do horário de verão do Brasil. Como esses Monthly Quality Rollups são cumulativos, qualquer rollup mais recente que esses abaixo contemplam a correção:
OS Release Date Update Rollup KB
1809 - RS5 RS5 RTM RS5 RTM
1803 - RS4 2018.06 B KB4284835
1709 - RS3 2018.04 B KB4093112
1703 - RS2 2018.04 B KB4093107
1607 - RS1 2018.04 B KB4093119
1511 - TH2 2018.04 B KB4093109
Windows 2016 RTM 2018.04 B KB4093111
Windows server 2012 R2 / 8.1 2018.04 C KB4093121
Windows Server 2012 2018.04 C KB4093116
Windows Server 2008 SP2 N/A N/A
Windows Server 2008 R2 / 7 2018.04 C KB4093113
  • Lembrando que os KBs que são Security-only não contém as alterações de horário de verão.
  • O Windows Server 2008 SP2 não tem Monthly Quality Rollups, por esse motivo a única opção é instalar os KBs avulsos abaixo.
Além dos Monthly Quality Rollups descritos na tabela acima, os sistemas operacionais Windows Server 2008 até 2012 R2 e Windows client 7 até 8.1 tem a opção de instalar os KBs individuais abaixo: KB4093753 (Lançado 16/04/2018) KB4130978 (Lançado 17/05/2018 – substitui o KB 4093753) KB4339284 (Lançado 24/07/2018 – substitui o KB 4130978) As mudanças do KB4093753, já foram incluidas nos Monthly Quality Rollups mais recentes, por isso é esperado que você receba mensagens de que o KB avulso não é aplicável caso a máquina já possua os Monthly Quality Rollups mais recentes. Uma forma simples de identificar se a máquina já possui a correção é com o comando w32tm /tz .O comando exibe a diferença do valor antigo (M:10 D:3), para o novo (M:11 D:1): Antes do KB instalado: C:\>w32tm /tz Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias) [Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)] [Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:10 D:3 DoW:6)] Após KB instalado: C:\>w32tm /tz Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias) [Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)] [Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:11 D:1 DoW:6)]   Informações adicionais: A data crítica nessa mudança de horário de verão será o dia 21/10/2018. Os clientes que não instalarem nenhum KB descrito acima, terão o horário de servidores e estações incorretamente adiantados em uma hora na virada do Sábado para o Domingo dia 21/10/2018, pois era a data que o horário de verão estava programado para começar antes do decreto de Dez/2017. https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm  ]]> Mudanças no horário de verão no Brasil para 2018 https://docs.microsoft.com/archive/blogs/latam/mudancas-no-horario-de-verao-no-brasil-para-2018 Wed, 10 Oct 2018 09:44:03 GMT https://blogs.technet.microsoft.com/latam/?p=21705 Edit: O governo cancelou a alteração mencionada nesse post, com isso o início do horário de verão será dia 04 de Abril. Mais informaçoes em https://blogs.technet.microsoft.com/latam/2018/10/17/horario-de-verao-no-brasil-inicia-em-04-de-novembro-de-2018-lista-de-kbs/ --------------------------------------------------------------------

Nos últimos dias recebemos a notícia que o início do horário de verão poderá ser postergado para o dia 18 de Novembro. A partir desta comunicação, a nova configuração de horário de verão ficou definido para:

 

Inicio do Horário de verão:18 de Novembro de 2018 (Terceiro domingo de novembro)

Fim do Horário de verão finaliza:17 de fevereiro de 2019 (Terceiro domingo de fevereiro)

 

A fim de alcançar uma transição perfeita das políticas para a possível alteração do início do horário de verão, e permitir tempo suficiente para implementar as mudanças em produtos e serviços, a Microsoft respeitosamente solicita aos governos que considerem em fornecer, com pelo menos 1 ano de antecedência, o aviso de confirmação oficial do horário de verão (DST) e as mudanças planejadas.

 

Essa também é a recomendação da IANA

https://data.iana.org/time-zones/tz-link.html

"If your government plans to change its time zone boundaries or daylight saving rules, inform tz@iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see "On the Timing of Time Zone Changes" for examples."

Neste momento não há nenhuma publicação oficial (decreto) do governo brasileiro de que o início do horário de verão será alterado. Portanto, qualquer orientação pública oficial ou a eventual correção sobre como acomodar as mudanças de horário de verão nos produtos Microsoft não serão tornados públicos neste momento.

 

O decreto atual ainda informa a data de 04 de Novembro como início do Horário de verão.

https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm

 

Se a data de início do horário de verão for alterada oficialmente, nosso serviço de assistência e equipes de suporte estarão prontos para ajudar nossos clientes em relação a esta mudança. Assim, após a confirmação oficial do governo brasileiro sobre a alteração ou não do início do horário de verão, a Microsoft publicará uma orientação completa aos clientes.

Mais informações sobre configurações de horário de verão no Windows:

Blog Oficial do time de DST (Daylight Saving Time) da Microsoft

https://blogs.technet.microsoft.com/dst2007/

How to configure daylight saving time for Microsoft Windows operating systems

https://support.microsoft.com/en-us/help/914387/how-to-configure-daylight-saving-time-for-microsoft-windows-operating

   ]]> Users cannot login in Stream, error: AADSTS70001: Application 'cf53fce8-def6-4aeb-8d30-b158e7b1cf83' is disabled https://docs.microsoft.com/archive/blogs/latam/users-cannot-login-in-stream-error-aadsts70001-application-cf53fce8-def6-4aeb-8d30-b158e7b1cf83-is-disabled Tue, 02 Oct 2018 14:09:00 GMT https://blogs.technet.microsoft.com/latam/?p=21695 By: Marcela Chitiva Peñaloza. SharePoint Online Support Engineer.


Microsoft Stream —the intelligent video service in Office 365— makes it easy to create, securely share, and interact with video, whether in a team or across your organization. If you have any of these licenses () you can start to use Microsoft Stream.

Some tenants (with plans including Stream) may not have enabled the feature and do not see the Stream tile into the App Launcher, even logging in to Stream portal, appears the following message:


“AADSTS70001: Application 'cf53fce8-def6-4aeb-8d30-b158e7b1cf83' is disabled”


stream


For solve this issue, connect to your Office 365 organization using Office 365 PowerShell ()

Run the following commands:


Connect-MsolService

Import-Module MSOnlineExtended -Force

$MSP = Get-MsolServicePrincipal -AppPrincipalId “cf53fce8-def6-4aeb-8d30-b158e7b1cf83”

Set-MsolServicePrincipal -AppPrincipalId $MSP.AppPrincipalId -AccountEnabled $true


Wait a couple of minutes and try again the login process going to https://web.microsoftstream.com

]]> Office 365 e Active Directory: como os atributos msExchRecipientDisplayType, msExchangeRecipientTypeDetails e msExchRemoteRecipientType são relacionados no ambiente local https://docs.microsoft.com/archive/blogs/latam/office-365-e-active-directory-como-os-atributos-msexchrecipientdisplaytype-msexchangerecipienttypedetails-e-msexchremoterecipienttype-sao-relacionados-no-ambiente-local Thu, 27 Sep 2018 12:26:24 GMT https://blogs.technet.microsoft.com/latam/?p=21665

Olá Pessoal,

Temos visto muitos casos no suporte onde antes de migrar a mailbox localizada no Exchange OnPremises (seja ele 2010, 2013, 2016 ou 2019) o administrador já assinala uma licença para aquele usuario sincronizado.

Quando você assinala uma licença de Exchange Online ao usuário, uma nova mailbox é provisionada na nuvem - caso ainda não haja nenhuma. Isso faz com que muitas vezes a caixa de correio deste usuário fique duplicada (sendo uma na nuvem e uma mailbox no ambiente OnPremises).

O cenário de mailbox duplicada configura um administrador que faz a migração neste cenário. Geralmente, após a migração, o usuário reclama que não localiza nenhuma mensagem, então nesse momento o administrador entre em contato com o time de suporte.

Abaixo, temos uma lista de atributos que ficam no AD local que fazem referencia (ou não) com uma caixa na nuvem. Conforme já conversamos em outro post, o comportamento do autodiscover é utilizar um atributo (TargetAddress) para popular no Exchange local o valor de RemoteRoutingAddress da mailbox - se tal atributo não contem um endereço valido ex: usuario@dominio.onmicrosoft.com , a mailbox não será localizada.

Para isolar o problema de mailbox duplicada, utilizamos o OWA local (ex: https://mail.seudominio.com/owa) e também o OWA do Office365 (https://outlook.office365.com/owa) para visualizar se as mensagens contidas estão diferentes - caso você não consiga efetuar acesso, isso pode indicar que a caixa não está provisionada/habilitada na nuvem ou no local (OnPrem).

Caso o usuario visualize as mensagens corretamente usando o OWA do Office 365 mas não visualiza tais mensagens corretamente no OWA local, você pode então alterar alguns atributos para que o apontamento seja feito para a mailbox localizada na nuvem, - lembrando sempre de ter um backup/ldap dump do usuario no AD antes de realizar qualquer alteração.

Esta alteração consiste em alterar os seguintes campos como mostra o exemplo abaixo indicando uma caixa migrada:

homeMDB -> esse atributo indica ao AD local um banco de dados, se tiver algo populado aqui então sabemos que esse usuário tem a indicação de um banco de dados local;

homeMTA -> esse atributo indica por sua vez um MailTransferAgent local também e caso esteja populado teremos a indicação de fluxo de e-mail realizado por servidores locais;

MsExchMailboxGuid -> a identificação única da caixa de correio – este valor deve ser o mesmo entre OnPremises e OnCloud;

msExchHomeServerName -> indica onde a caixa do usuário está hospedada localmente, novamente se tivermos um valor aqui então sabemos que há um servidor local hospedando a caixa;

msExchRecipientDisplayType -> [verifique os valores adequados no diagrama abaixo]

PSC: lembrando que alterar o atributo msExchRecipientDisplayType direto pelo AD local não é algo suportado.

msExchRecipientTypeDetails -> [verifique os valores adequados no diagrama abaixo]

msExchRemoteRecipientType ->  [verifique os valores adequados no diagrama abaixo]

msExchVersion -> indica qual é a versão atual do Microsoft Exchange;

ProxyAddresses -> smtp:name.lastname@domain.onmicrosoft.com

smtp:name.lastname@domain.mail.onmicrosoft.com

targetAddress -> smtp:name.lastname@domain.onmicrosoft.com -> esse é o endereço do usuário com referencia na nuvem para o AD local, o autodiscover irá procurar o endereço contido aqui caso esse atributo tenha algum valor inserido, sempre deve ser algo como @dominio.onmicrosoft.com ou @dominio.mail.onmicrosoft.com para que o redirect do autodiscover encontre o usuário na nuvem.

 

Um exemplo de como ficaria um usuário que foi criado no ad local, sincronizado com a nuvem e teve sua caixa migrada do Exchange local para o Exchange Online:

homeMDB -> sem valor

homeMTA -> sem valor

MsExchMailboxGuid -> unique identifier, mesmo valor entre o objeto onpremises e online;

msExchHomeServerName -> sem valor

msExchRecipientDisplayType -> -2147483642

msExchRecipientTypeDetails -> 2147483648

msExchRemoteRecipientType -> 4

msExchVersion -> 44220983382016

ProxyAddresses -> smtp:name.lastname@domain.onmicrosoft.com

smtp:name.lastname@domain.mail.onmicrosoft.com

targetAddress -> smtp:name.lastname@domain.onmicrosoft.com

Abaixo temos a tabela de valores para msExchangeRecipientType. Lembrando que estes valores não devem ser alterados manualmente (apenas para informação):

 

Recipient Display Type

Value Name Value
MailboxUser 0
DistributionGroup 1
PublicFolder 2
DynamicDistributionGroup 3
Organization 4
PrivateDistributionList 5
RemoteMailUser 6
ConferenceRoomMailbox 7
EquipmentMailbox 8
ArbitrationMailbox 10
MailboxPlan 11
LinkedUser 12
RoomList 15
SecurityDistributionGroup 1073741833
ACLableMailboxUser 1073741824
ACLableRemoteMailUser 1073741830
SyncedUSGasUDG -2147481343
SyncedUSGasUSG -1073739511
SyncedUSGasContact -2147481338
ACLableSyncedUSGasContact -1073739514
SyncedDynamicDistributionGroup -2147482874
ACLableSyncedMailboxUser -1073741818
SyncedMailboxUser -2147483642
SyncedConferenceRoomMailbox -2147481850
SyncedEquipmentMailbox -2147481594
SyncedRemoteMailUser -2147482106
ACLableSyncedRemoteMailUser -1073740282
SyncedPublicFolder -2147483130
 

Recipient Type Details

Value Name RecipientTypeDetails (Decimal Value)
None 0
UserMailbox 1
LinkedMailbox 2
SharedMailbox 4
LegacyMailbox 8
RoomMailbox 16
EquipmentMailbox 32
MailContact 64
MailUser 128
MailUniversalDistributionGroup 256
MailNonUniversalGroup 512
MailUniversalSecurityGroup 1024
DynamicDistributionGroup 2048
PublicFolder 4096
SystemAttendantMailbox 8192
SystemMailbox 16384
MailForestContact 32768
User 65536
Contact 131072
UniversalDistributionGroup 262144
UniversalSecurityGroup 524288
NonUniversalGroup 1048576
DisabledUser 2097152
MicrosoftExchange 4194304
ArbitrationMailbox 8388608
MailboxPlan 16777216
LinkedUser 33554432
RoomList 268435456
DiscoveryMailbox 536870912
RoleGroup 1073741824
RemoteUserMailbox 2147483648
Computer 4294967296
RemoteRoomMailbox 8589934592
RemoteEquipmentMailbox 17179869184
RemoteSharedMailbox 34359738368
PublicFolderMailbox 68719476736
TeamMailbox 137438953472
RemoteTeamMailbox 274877906944
MonitoringMailbox 549755813888
GroupMailbox 1099511627776
LinkedRoomMailbox 2199023255552
AuditLogMailbox 4398046511104
RemoteGroupMailbox 8796093022208
SchedulingMailbox 17592186044416
GuestMailUser 35184372088832
AuxAuditLogMailbox 70368744177664
SupervisoryReviewPolicyMailbox 140737488355328
 

Remote Recipient Types

Decimal Value Hex Value Value Name
1 0x1 ProvisionedMailbox (Cloud MBX)
2 0x2 ProvisionedArchive (Cloud Archive)
3 0x3 ProvisionedMailbox, ProvisionedArchive (Cloud MBX & Cloud Archive)
4 0x4 Migrated
6 0x6 Migrated, ProvisionedArchive (Migrated MBX & Cloud Archive)
8 0x8 DeprovisionMailbox
16 0x10 DeprovisionArchive
20 0x14 DeprovisionArchive, Migrated
32 0x20 RoomMailbox
36 0x24 Migrated, RoomMailbox
64 0x40 EquipmentMailbox
68 0x44 Migrated, EquipmentMailbox
96 0x60 SharedMailbox
100 0x64 Migrated, SharedMailbox
]]> Não é possivel criar nova reunião através do aplicativo do Outlook para iOS https://docs.microsoft.com/archive/blogs/latam/nao-e-possivel-criar-nova-reuniao-atraves-do-aplicativo-do-outlook-para-ios Tue, 11 Sep 2018 14:48:07 GMT https://blogs.technet.microsoft.com/latam/?p=21625 “Send Meeting Request Failed. Your meeting request '<Meeting Subject>' failed to send. Please contact support for assistance.” Adicionalmente, a exceção a seguir é registrada no log do Exchange ActiveSync para este dispositivo: 
SyncCommand_ConvertRequestsAndApply_Add_Exception :
Microsoft.Exchange.AirSync.SchemaConverter.Common.ConversionException: ExTimeZoneFromRegTimeZoneInfo failed: Specified argument was out of the range of valid values.
Parameter name: Hour
   at Microsoft.Exchange.AirSync.SchemaConverter.Common.TimeZoneConverter.GetExTimeZone(Byte[] timeZoneInformation)
   at Microsoft.Exchange.AirSync.SchemaConverter.XSO.XsoTimeZoneProperty.InternalCopyFromModified(IProperty srcProperty)
   at Microsoft.Exchange.AirSync.SchemaConverter.XSO.XsoDataObject.CopyFrom(IProperty srcRootProperty)
   at Microsoft.Exchange.AirSync.SyncCollection.ConvertClientToServerObjectAndSendIfNeeded(SyncCommandItem syncCommandItem, Boolean sendEnabled)
   at Microsoft.Exchange.AirSync.SyncCollection.ConvertClientToServerObjectAndSave(SyncCommandItem syncCommandItem, UInt32& maxWindowSize, Boolean& mergeToClient)
   at Microsoft.Exchange.AirSync.SyncCommand.ConvertRequestsAndApply(SyncCollection collection)
  Nota: Esse problema afeta os usuários do fuso horário Brasília (UTC-03:00) e é limitado ao Outlook para iOS usando o protocolo ActiveSync. Os usuários hospedados no Office 365 usam o protocolo REST e não são afetados por esse problema. Este problema ocorre porque o valor do atributo TimeZone na requisição de sincronismo é inválido. O problema foi corrigido no código do Outlook e estará disponível na próxima atualização do aplicativo.   É possível contornar o problema alterando o fuso horário no iOS, porém tenha em mente que isso poderá afetar os convidados da reunião uma vez que o horário final estará errado. Recomendamos utilizar o aplicativo nativo ou o cliente Web para gerenciar o calendário até que a correção esteja disponível.]]> Usuários não conseguem se logar ou criar um novo perfil usando o Outlook app para Android https://docs.microsoft.com/archive/blogs/latam/usuarios-nao-conseguem-se-logar-ou-criar-um-novo-perfil-usando-o-outlook-app-para-android Tue, 28 Aug 2018 16:11:50 GMT https://blogs.technet.microsoft.com/latam/?p=21595 Olá Pessoal, Vimos alguns casos no suporte onde usuarios de dominios federados não conseguiam logar em suas contas ou criar um novo perfil do Exchange Online usando o aplicativo Outlook para Android e a mensagem exibida é somente "ocorreu um erro"

• O que acontece é que apesar do aplicativo ser desenvolvido por nós cada dispositivo gerencia suas requests/responses de maneira diferente e o Android é mais exigente na questão de certificados do serviço de federação • Com isso os certificados root e intermediate não podem faltar em suas respectivas pastas como também nao podem estar inseridos em outras pastas, o correto é seguir essa ordem:

• Você pode verificar se o ceritficado publicado nos servidores WAP & ADFS se o endereço (exemplo: adfs.dominio.com.br) não contém corretamente o intermediate e root em suas pastas nos servidores que respondem pelo endereço usando alguns links como https://cryptoreport.websecurity.symantec.com/checker/ ou https://ssltools.digicert.com/checker/views/checkInstallation.jsp (você também pode usar qualquer outro site que verifique a cadeia de certificados no endereço que você inserir (você precisa inserir o endereço do seu serviço de federação que está publicado na internet). Exemplo que pode ser exibido na consulta aos sites descritos acima:

adfs.dominio.com.br You have 1 error Intermediate certificate missing. SHA2 Extended Validation Server CA | Download certificate
Intermediate certificate missing. SHA2 Extended Validation Server CA | Download certificate

• Se você estiver enfrentando esse problema tome as ações de inserir o certificado nos servidores WAP e ADFS nas respectivas pastas corretas e reinicie os servidores.

• Documentado aqui está o contexto do que o erro de codigo 3 significa: https://developer.android.com/reference/android/net/http/SslError.html SSL_UNTRUSTED int SSL_UNTRUSTED The certificate authority is not trusted Constant Value: 3 (0x00000003)

• E aqui está o log do Outlook App analisado pelo time especialista em Outlook para Android onde consta o erro de codigo 3

D 2018-07-20T11:43:27.900+0000 [ci=lkZEpaox7M] main Office365LoginA Authentication error:Code:-11 primary error: 3 certificate: Issued to: CN=adfs.dominio.com.br,O=COMPANHIA DE TI,OU=MS,L=PARANA,ST=CuritibaC=BR; Issued by: CN=Organization Validation CA - SHA256 - G2,O=nv-sa,C=BE; on URL: https://adfs.dominio.com.br/adfs/ls/?login_hint=nome.sobrenome%40dominio.com.br&wfresh=0&wauth=http%3a%2f%2fschemas.microsoft.com%2fws%2f2008%2f06%2fidentity%2fauthenticationmethod%2fpassword&client-request-id=e416db57-b03b-44b4-b280-f33bee6a1592&username=nome.sobrenome%40dominio.com.br&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=estsredirect%3d2%26estsrequest%3drQIIAa1RPW_TQBjO2YmBqlKrSoWOHaiEkOKPc9LmAyQcmbYCh5Cqbeqoi-_Oji-xfcaxL22m_gNQR8TEgtQJVQwI_kGnSCwIxMbUASGxMOL8B5ZXz7M8X--CpMkalNUVoN0Xc9i4C7fqEKpqpVyFVa1cUXW1jCAk5brmYlJ39C3XqSQrC8u977d_Nt9_MC_P_jR_DVfPL4AZjp0s9RuKglkohxQnbMy8VGaeR7ErsywNGBspHh7U1BectTW7_fRJn6Jha9LFpteJ2IZufgRgBsCZAM6FO56DKJMxcwOfPcLjSJ7romQmgG_CUsfIveD8sIRO3WuhFLABjV6Lx_a-xsju3gRPGbfgCe_DILMiEqNwjxO9naHwULXgM456Gke0f_q856tktzXt0Bq3j1qxFW4PEdQmaGeU2bCeWvCwYkPfRyEJLsR1P03jcV7Sians5InigM6DKe4J9p1o4F6KUk5DFn0VwawIrouLN8Hy4lphvXBPUMHfInhbyud78HLtS_bux86bjc9LxeZq4aqknAZVVtsedDcNPWz3vGRz2g0PaqmixKbHjf2DxOCjhHDn6HH3YbWhvZLAlXTDiEjCKPktFT7d-i8P-Ac1 CorrelationId: e416db57-b03b-44b4-b280-f33bee6a1952]]>