Artigo original publicado em 08 de setembro de 2010, terça-feira

Um usuário está fora do escritório por algum motivo – em férias, doente ou em uma licença sabática ou ausência prolongada, ou viajando para um local remoto na empresa, e esquece de definir uma resposta automática, também conhecida como uma mensagem de ausência temporária ou OOF no Exchange/Outlook lingo. Como um administrador do Exchange, você recebe um email do gerente do usuário solicitando que você configure uma OOF para ele.

Nas versões anteriores do Exchange, você precisava acessar a caixa de correio do usuário para conseguir fazer isso. As mensagens de ausência temporária são armazenadas na árvore não IPM da caixa de correio de um usuário junto com outros metadados. Sem acessar a caixa de correio, não é possível modificar os dados dentro dela. Há duas maneiras para um administrador acessar uma caixa de correio:

1. Conceder a si mesmo a permissão de acesso completo a uma caixa de correio para a caixa de correio do usuário.
2. Alterar a senha do usuário e fazer logon como o usuário.

É seguro dizer que qualquer uma dessas opções é potencialmente perigosa. A primeira opção concede ao administrador acesso a todos os dados na caixa de correio do usuário. A segunda opção concede ao administrador acesso a todos os dados que a conta do usuário pode acessar dentro da sua empresa e bloqueia o usuário na sua própria conta (pois o usuário em questão não sabe mais a senha da conta).

No Exchange 2010, é possível configurar as opções de resposta automática para seus usuários sem usar nenhuma das opções acima. Você deve ser um membro de um grupo de funções que tem as funções de gerenciamento Destinatátios de email ou Opções do Usuário.

Configure as opções de resposta automática usando o painel de controle do Exchange

Para configurar uma resposta automática usando o ECP:

1. Em Correio > Opções, selecione Outro usuário (padrão Minha organização).
   
   Figura 1: Selecionar outro usuário

2. Selecione o usuário para o qual deseja configurar a resposta automática

3. Na nova janela, verifique se o nome do usuário é exibido na mensagem de alerta e clique em Diga às pessoas que está de férias
   
   Figura 2: Quando gerenciar outro usuário no ECP, um alerta próximo ao topo da página exibe o nome do usuário que você está gerenciando

4. Na guia Respostas automáticas, configure as opções de resposta automática para o usuário (consulte a captura de tela).

No Exchange 2007, introduzimos o recurso para criar mensagens de ausência temporária diferentes para destinatários externos e internos. Você também pode desativar ou ativar as mensagens de ausência temporária de acordo com o usuário e o domínio remoto nas configurações de Domínio Remoto. Para obter detalhes, consulte a postagem anterior Ausência temporária (OOF) do Exchange Server 2007.

Configure as opções de resposta automática usando o Shell

Esse comando programa respostas automáticas internas e externas de 8/9/2011 a 15/9/2011:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Scheduled –StartTime “9/8/2011” –EndTime “9/15/2011” –ExternalMessage “Mensagem External OOF aqui” –InternalMessage “Mensagem Internal OOF aqui”

Para configurar respostas automáticas para serem enviadas até que sejam desativadas (ou seja, sem uma programação), defina o parâmetro AutoReplyState como Habilitado e não especifique os parâmetros StarTime e EndTime. Para a sintaxe detalhada e descrições do parâmetro, consulte Set-MailboxAutoReplyConfiguration.

Esse comando recupera as configurações da resposta automática para uma caixa de correio.

Get-MailboxAutoReplyConfiguration bsuneja@e14labs.com

Esse comando desativa a resposta automática configurada para uma caixa de correio:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null

Bharat Suneja

Esta é uma postagem de blog traduzida. Encontre o artigo original em Configure Automatic Replies for a user in Exchange 2010

Artigo original publicado na segunda-feira, 06 de fevereiro de 2012

Visão geral

Esta série de duas partes destacará algumas opções de recuperação disponíveis para administradores no caso em que uma ou mais pastas públicas sejam excluídas acidentalmente do ambiente. A primeira parte explicará as opções, enquanto a segunda parte destacará os aspectos arquitetural das pastas públicas que orientam as opções.

Introdução

Em versões mais antigas do Exchange, a recuperação das caixas de correio e dos bancos de dados de caixas de correio era um processo longo e complicado envolvendo backups, servidores de recuperação e trocas para o Active Directory. Versões sucessivas do produto introduziram cada mais funcionalidade na recuperação (recuperação de grupos/bancos de dados de armazenamento, replicação de bancos de dados, etc.), e agora estamos no ponto onde restaurar uma caixa de correio é uma operação aparentemente trivial, e a restauração de um banco de dados da caixa de correio é quase desconhecida. Porém, as caixas de correio não são os únicos dados armazenados nos servidores da Caixa de Correio do Exchange Server 2010 e o procedimento para restaurar pastas públicas e bancos de dados de pastas públicas é muito diferente do procedimento de caixa de correio.

Revisão das Opções de Recuperação

As primeiras duas opções de recuperação estão detalhadas no TechNet ou em qualquer outro lugar do site da equipe do Exchange, portanto eu irei apenas listá-los aqui e mover ir para o objetivo real deste blog.  As opções de recuperação de pastas públicas e bancos de dados de pasta pública no Exchange Server 2010 são como a seguir, do mais fácil ao mais difícil:

1. Recuperar pastas excluídas através do Outlook (detalhado em http://technet.microsoft.com/en-us/magazine/dd553036.aspx).

   Observação: O Exchange Server 2010 Service Pack 2 corrige um problema onde os usuários não podem usar o Outlook para recuperar pastas públicas excluídas. Esta é outra razão para atualizar seus sistemas Exchange Server 2010 para o SP2 o mais rapidamente possível.

2. Recuperar pastas excluídas pelo ExFolders (http://blogs.technet.com/b/exchange/archive/2009/12/04/3408943.aspx).
3. Recuperar pastas através da restauração do banco de dados de pasta pública.

A primeira opção é a mais fácil e óbvia - se um usuário final excluir acidentalmente uma pasta, ele ou ela devem poder recuperar a pasta usando o Outlook. Se isso falhar, um administrador poderá usar o ExFolders para recuperar a pasta. Mas e se estas opções não funcionarem no seu caso? E se o usuário final não perceber que ele ou ela excluiu a pasta e passar um mês? Ou se a sua empresa mudou as configurações de retenção para pastas públicas excluídas e essencialmente excluiu a lixeira?  Como recuperar pastas públicas neste caso?

Opções de Recuperação

No núcleo da recuperação de pasta pública há uma verdade dolorosa: não é possível excluir uma pasta pública da empresa e recuperá-la simplesmente restaurando uma versão antiga de um banco de dados de pasta pública. Se você restaurar um banco de dados de pasta pública do backup e colocá-lo de volta para produção, você verá as pastas públicas apenas até que o servidor receba mensagens de replicação. Porque a hierarquia de pasta pública – a lista de todas as pastas no ambiente – não inclui mias as pastas que foram excluídas, o servidor alvo possui cópias das pastas que, na perspectiva do Exchange, não existem. Assim que esse banco de dados de pasta pública recebe uma atualização de hierarquia, verá que estas pastas públicas não estão presentes na hierarquia e o repositório excluirá a pasta pública novamente. Como não é possível editar a hierarquia através do Console de Gerenciamento de Pasta Pública (ou através do adsiedit.msc), não é possível adicionar manualmente essa pasta pública. Portanto, dada esta limitação, como recuperamos aquela pasta pública?

Considere os seguintes pontos:

• Se você não replicar cada pasta para cada banco de dados, você precisará excluir todos os bancos de dados atuais e recuperar do backup qualquer banco de dados que possui conteúdo único.  Isso funciona apenas se você possui backups recentes, claro, e também exigiria que você exportasse qualquer conteúdo gerado desde o backup, pois você irá excluir todos os bancos de dados existentes. A exclusão é necessária porque se um repositório de pasta pública restaurada recebe a replicação de hierarquia de um repositório de pasta pública existente, todo o exercício é inútil.
• Se você replicar todas as pastas para todos os repositórios no ambiente, é possível excluir todos os repositórios e restaurar apenas um banco de dados, replicando o conteúdo daquele banco de dados para os outros servidores. Novamente,isso depende de todos os bancos de dados terem conteúdo duplicado e você deve excluir todos os bancos de dados existentes antes de restaurar o do backup.
• É possível restaurar um backup de um banco de dados de pasta pública para um ambiente do Exchange isolado, conectar-se ao banco de dados de pasta pública pelo Outlook, exportar todo o conteúdo para uma série de PSTs, criar novas pastas no ambiente de produção com os mesmos nomes das pastas excluídas e importar todo conteúdo. Isto é obviamente um grande processo manual e a maioria dos administradores não desejarão fazê-lo.

Procedimento de Recuperação Recomendado

Ainda bem, há um processo muito mais fácil que pode ser realizado no local e com um mínimo de confusão.

1. Selecione um dos servidores de pasta pública existentes no ambiente. [Usar um servidor existente simplifica um pouco o processo.] Você isolará este sistema dos seus parceiros de replicação, portanto, escolha um sistema que não serve como a fonte de muito conteúdo que precisa ser replicado.
2. Usando o Editor de Registro, defina o valor da chave de registro Replicação (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public- <GUID of Public Store>) para 0 (zero).

   Observação: Você pode precisar criar esta chave DWORD se ela não existir. Está disponível mais informações sobre a chave de Registro Replicação no artigo “A replicação não ocorre em um servidor do Exchange na empresa” (http://support.microsoft.com/kb/812294). Esta chave de Registro também é aplicada ao Exchange Server 2007 e 2010.

3. Restaurar o banco de dados de pasta pública usando o procedimento de restauração normal.
4. Usando um cliente Outlook, conecte-se a uma caixa de correio que usa o banco de dados de pasta pública restaurado como seu repositório de pasta pública padrão (isso é necessário para ver as pastas restauradas). Se você não tiver um banco de dados de correio que usa um banco de dados de pasta pública como padrão, crie um novo banco de dados de correio (recomendado) ou mude um banco de dados de caixa de correio para usar um banco de dados de pasta pública restaurado recentemente.
5. Se necessário, clique no ícone Pastas no canto inferior esquerdo da tela de Navegação e expanda o nó de pastas públicas.
6. Copie cada uma das pastas que deseja restaurar para outro local dentro da hierarquia de pasta pública. Se você está restaurando de toda uma hierarquia, é possível simplesmente pressionar Ctrl e clicar para arrastar a pasta raiz e realizar novas cópias de todas as subpastas. Embora as novas pastas tenham nomes similares aos originais, os IDs da pasta subjacentes (FIDs) são diferentes.
7. Quando você tiver criado cópias de todas as pastas, verifique se as listas do repositório incluem todos os alvos desejados (e reconfigura como adequado).
8. Neste ponto, agora é seguro reintroduzir esse servidor ao ambiente de produção. Para fazer isso, desmonte o banco de dados de pasta pública, exclua a chave de Registro Replicação (ou defina para 1) e remonte o banco de dados.
9. Assim que a hierarquia é replicada para o servidor, as pastas originais irão desaparecer novamente, mas as cópias das pastas serão replicadas para todos os parceiros de replicação.

Você pode precisar adicionar pastas públicas habilitadas por correio de volta nos grupos de distribuição, pois seus endereços SMTP provavelmente serão diferentes daqueles das pastas originais. Os usuários finais também precisarão recriar os favoritos da pasta pública no Outlook.

Resumo

A recuperação da exclusão acidental de pasta pública pode ser difícil, especialmente se você não levar a replicação de hierarquia em conta. Ao restaurar em um ambiente isolado e clonar as pastas a serem restauradas, você pode resolver esta limitação e restaurar o conteúdo faltante. Na próxima entrada do blog eu explicarei a arquitetura subjacente das pastas públicas (incluindo replicação, mudança de números e tabela de estado da replicação) para exibir porque estas etapas são tão necessárias.

John Rodriguez
Engenheiro de Campo Principal
Suporte Principal da Microsoft

Essa é uma publicação localizada. Encontre o artigo original em Recovering Public Folders After Accidental Deletion (Part 1: Recovery Process)

Artigo original publicado na quarta-feira, 14 de dezembro de 2011

Nos últimos meses, houve uma discussão significativa sobre o que é uma manutenção básica do banco de dados e por que ela é importante para os bancos do Exchange 2010. Espero que esse artigo aos responda a essas perguntas

Quais tarefas de manutenção precisam ser executadas no banco de dados?

As tarefas a seguir precisam ser executadas rotineiramente nos bancos de dados do Exchange:

• Compactação do banco de dados
• Desfragmentação do banco de dados
• Soma de verificação do banco de dados
• Correção de página
• Zeragem de página

Compactação do banco de dados

O objetivo primário da compactação do banco de dados é liberar espaço não usado dentro do arquivo do banco de dados (no entanto, deve ser observado que isso não retorna esse espaço ao sistema de arquivos). A intenção é liberar as páginas no banco de dados compactando os registros para o menor número de páginas possível, reduzindo assim o valor de I/O necessário. O mecanismo de banco de dados ESE faz isso pegando os metadados do banco de dados, que são as informações dentro do banco que descrevem as tabelas e, cada tabela, visitando cada página da tabela, e tentando mover registros para páginas logicamente ordenadas.

Manter um espaço magro do arquivo do banco de dados é importante por vários motivos, incluindo:

1. Reduzir o tempo associado ao backup do arquivo do banco de dados
2. Manter um tamanho previsível do arquivo do banco de dados, que é importante para fins de dimensionamento do servidor/armazenamento.

Prior Antes do Exchange 2010, as operações de compactação do banco de dados eram executadas durante a janela de manutenção online. Esse processo produzia um IO aleatório, porque ele percorria o banco de dados e reordenava os registros pelas páginas. Esse processo era literalmente bom demais nas versões anteriores – liberando as páginas do banco de dados e reordenando os registros, as páginas ficavam sempre em ordem aleatória. Combinado com a arquitetura do esquema do armazenamento, isso significava que qualquer solicitação para recuperar um conjunto de dados (como baixar itens dentro de uma pasta) sempre resultava em um IO aleatório.

No Exchange 2010, a compactação do banco de dados foi redesenhada, de forma que a contiguidade é preferível à compactação de espaço. Além disso, a compactação do banco de dados retirada da janela de manutenção online e agora é um processo de segundo plano que executa continuamente.

Desfragmentação do banco de dados

A desfragmentação do banco de dados é uma novidade no Exchange 2010 e também é chamada de OLD v2 e desfragmentação de árvore B+. Sua função é compactar e desfragmentar (tornar sequenciais) tabelas do banco de dados que foram marcadas como sequenciais. A desfragmentação é importante para manter a utilização eficiente dos recursos do disco com o passar do tempo (tornar o IO mais sequencial, e não aleatório) e manter a compactação das tabelas marcadas como sequenciais.

Você pode pensar no processo de desfragmentação do banco de dados como um monitor que supervisiona outras operações da página do banco de dados, para determinar se há trabalho para fazer. Ele monitora todas as tabelas para ver se há páginas livres, e se uma tabela chegar ao limite onde uma porcentagem alta significativa da contagem de páginas da Árvore B+ for livre, ele retorna as páginas livres à raiz. Ela também funciona para manter a continuidade dentro de uma tabela configurada com dicas de espaço sequencial (uma tabela criada com um padrão de uso sequencial conhecido). Se a desfragmentação do banco de dados vir uma digitalização/pré-leitura em uma tabela sequencial e os registros não estiverem armazenados nas páginas sequenciais dentro da tabela, o processo irá desfragmentar essa seção, movendo todas as páginas afetadas para uma nova extensão na árvore B+. Você pode usar os contadores do desempenho (mencionados na seção de monitoração) para ver como o processo de desfragmentação do banco de dados faz um trabalho pequeno depois que o estado estável é atingido.

A desfragmentação é um processo de segundo plano que analisa o banco de dados continuamente enquanto as operações são executadas e depois aciona o trabalho assíncrono quando necessário. Ela é acelerada em dois cenários:

1. O número máximo de tarefas pendentes Isso impede que a desfragmentação do banco de dados faça um trabalho muito grande na primeira passagem, se uma alteração massiva ocorreu
2. Uma aceleração de latência de 100ms Quando o sistema é sobrecarregado, a desfragmentação do banco de dados é iniciada. O trabalho iniciado é executado na próxima vez que o banco de dados passar pelo mesmo padrão operacional. Não há nada que lembre que o trabalho de desfragmentação foi iniciado e volte e o execute assim que o sistema tiver mais recursos.

Soma de verificação do banco de dados

O checksumming do banco de dados (também conhecido como Verificação Online do Banco de Dados) é o processo onde o banco de dados é lido em pedaços grandes e cada página é verificada (quanto à corrupção de página física). O objetivo primário da soma de verificação é detectar corrupção física e liberações perdidas que talvez não estejam sendo detectadas pelas operações de transação (páginas obsoletas).

Com o Exchange 2007 RTM e todas as versões prévias, as operações de soma de verificação ocorriam durante o processo de backup. Isso era um problema para os bancos de dados replicados, pois a única cópia a ser verificada era a do backup. Para o cenário em que a cópia passiva é submetida ao backup, isso significava que a ativa não estava sendo verificada. Portanto, no Exchange 2007 SP1, introduzimos uma nova tarefa opcional de manutenção online, a Soma de Verificação da Manutenção Online (consulte mais informações em Alterações no Exchange 2007 SP1 ESE – Parte 2).

No Exchange 2010, a varredura do banco de dados faz uma soma de verificação do banco e executa as operações após o travamento do Repositório do Exchange 2010. O espaço pode ser vazado devido ao tratamento e a varredura do banco de dados online encontra e recupera o espaço perdido. A soma de verificação do banco de dados lê aproximadamente 5 MB por segundo para cada banco de varredura ativa (cópias ativa e passiva) usando IOs de 256KB . O I/O é 100 por cento sequencial. O sistema no Exchange 2010 foi projetado com a expectativa de que cada banco de dados seja submetido a uma varredura completa a cada sete dias.

Se a varredura demorar mais de sete dias, um evento é registrado no Log do Aplicativo:

ID do evento: 733
Tipo de evento: Informação
Origem do evento: ESE
Descrição: Repositório de informações (15964) MDB01: Tarefa de segundo plano Soma de Verificação do Banco de Dados de Manutenção Online NÃO está finalizando no prazo para o banco de dados 'd:\mdb\mdb01.edb'. Essa passagem começou em 11/10/2011 e tem executado por 604800 segundos (mais de 7 dias) até o momento.

Se demorar mais de 7 dias para concluir a varredura da cópia ativa do banco de dados, a entrada a seguir será registrado no Log do Aplicativo uma vez que a varredura termine:

ID do evento: 735
Tipo de evento: Informação
Origem do evento: ESE
Descrição: Repositório de informações (15964) MDB01 Manutenção do Banco de Dados concluiu uma passagem completa no banco 'd:\mdb\mdb01.edb'. Essa passagem começou em 11/10/2011 e executou por um total de 777600 segundos. Essa tarefa de manutenção do banco de dados excedeu o limite de conclusão de manutenção de 7 dias. Uma ou mais das ações a seguir deve ser tomada: aumentar o desempenho/rendimento do IO do volume que hospeda o banco de dados, reduzir o tamanho do banco de dados e/ou reduzir o IO da manutenção que não seja do banco de dados.

Além disso, um aviso durante o processo também será registrado no Log do Aplicativo quando a tarefa demorar mais de 7 dias para terminar.

No Exchange 2010, agora há duas formas de executar a soma de verificação do banco de dados nas cópias ativas:

1. Executar em segundo plano 24×7 Esse é o comportamento padrão. Ele deveria ser usado para todos os bancos de dados, principalmente os maiores que 1TB. O Exchange verifica o banco no máximo uma vez por dia. Esse I/O de leitura é 100 por cento sequencial (o que facilita no disco) e equivale a uma taxa de varredura de cerca de 5 megabytes (MB)/s na maioria dos sistemas. O processo de varredura tem um único segmento e é acelerado pela latência do IO. Quanto mais alta a latência, mais lenta a soma de verificação do banco de dados, porque ela espera mais pela conclusão do último lote antes de emitir outra varredura em um lote de páginas (8 páginas são lidas de cada vez).
2. Executar no processo de manutenção do banco de dados da caixa postal programado Quando você seleciona essa opção, a soma de verificação do banco de dados é a última tarefa. Você pode configurar por quanto tempo ela executa alterando a programação da manutenção do banco de dados de caixa postal. Essa opção só deve ser usada com bancos de dados com menos de 1 terabyte (TB) de tamanho, que exigem menos tempo para concluir uma varredura completa.

Independente do tamanho do banco de dados, nossa recomendação é utilizar o comportamento padrão e não configurar as operações de soma de verificação contra o banco de dados ativo como um processo programado (isto é, não configurar como um processo dentro da janela da manutenção online).

Para cópias passivas do banco de dados, as somas de verificação ocorrem durante o tempo de execução, operando continuamente em segundo plano.

Correção de página

A correção de página é o processo em que páginas corrompidas são substituídas por cópias saudáveis. Como mencionado, a detecção de uma página corrompida é uma função da soma de verificação do banco de dados (além disso, as páginas corrompidas também são detectadas no tempo de execução, quando armazenadas no cache do banco de dados). A correção de páginas funciona contra cópias do banco de dados altamente disponíveis (HA). A forma como uma página corrompida é corrigida depende de a cópia do banco de dados HA ser ativa ou passiva.

Processo de correção de página

Zeragem de página

Zeragem de página do banco de dados é o processo em que as páginas escolhidas do banco de dados são substituídas por um padrão (zerado) como medida de segurança, o que torna a descoberta dos dados muito mais difícil.

No Exchange 2007 RTM e todas as versões prévias, as operações de zeragem de página ocorriam durante o processo de backup do streaming. Além disso, uma vez que ocorria durante esse processo, esta não era uma operação registrada (por exemplo, a zeragem de página não resultava na geração de arquivos de log). Isso era um problema para os bancos de dados replicados, porque as cópias passivas nunca tinham suas páginas zeradas, e as páginas das cópias ativas só eram zeradas se você realizasse um backup de streaming. Portanto, no Exchange 2007 SP1, apresentamos uma nova tarefa de manutenção online opcional, Zerar Páginas do Banco de Dados durante a Soma de Verificação (para obter mais informações, consulte Alterações no Exchange 2007 SP1 ESE – Parte 2). Quando ativada, essa tarefa zera as páginas durante a janela da manutenção online e registra as operações que seriam replicadas para as cópias passivas.

Com a implementação do Exchange 2007 SP1, há atraso significativo entre quando uma página é excluída e quando é zerada como resultado do processo ocorrido durante uma janela de manutenção programada. Assim, no Exchange 2010 SP1, a tarefa de zeragem da página é agora um evento de tempo de execução que opera continuamente, zerando as páginas normalmente no momento da transação quando uma eliminação definitiva ocorre.

Além disso, as páginas do banco de dados também podem ser lidas durante o processo de soma de verificação online. As páginas-alvo neste caso são:

• Registros excluídos que não puderam ser limpos durante o tempo de execução, devido às tarefas descartadas (se o sistema estiver muito sobrecarregado) ou porque o Repositório travou antes que as tarefas pudessem limpar os dados;
• Tabelas e índices secundários excluídos. Quando esses são excluídos, nós não limpamos seu conteúdo ativamente, portanto a soma de verificação online detecta que essas páginas não pertencem mais a qualquer objeto válido e as limpa.

Para obter mais informações sobre a zeragem de página no Exchange 2010, consulte Entendendo a zeragem de página no Exchange 2010.

Por que essas tarefas não são simplesmente executadas durante uma janela de manutenção programada?

Exigir uma janela de manutenção programada para a zeragem de página, a desfragmentação e a compactação do banco de dados e as operações de soma de verificação online impõe problemas significativos, incluindo o seguinte:

1. A presença de operações de manutenção programadas dificulta o gerenciamento de datacenters 24x7 que hospedam caixas postais de vários fusos horários e possuem pouco ou nenhum tempo para uma janela de manutenção programada. Nas versões prévias do Exchange, a compactação do banco de dados não tinha mecanismos de aceleração e uma vez que o IO é predominante aleatório, ele pode causar uma experiência ruim para o usuário.
2. Os bancos de dados de caixa postal do Exchange 2010 implantados em armazenamento de camada inferior (por exemplo, 7.2K SATA/SAS) têm uma largura de banda de IO efetiva reduzida disponível para que o ESE execute tarefas da janela de manutenção. Isso é um problema porque significa que as latências do IO aumentarão durante a janela de manutenção, impedindo assim que as atividades de manutenção terminem dentro de um período desejado.
3. O uso de JBOD fornece um desafio adicional para o banco de dados em termos de verificação de dados. Com o armazenamento RAID, é comum que um controlador de matriz faça uma varredura em segundo plano de um determinado grupo de discos, localizando e reatribuindo os blocos ruins. Um bloco ruim (também conhecido como setor) é um bloco no disco que não pode ser usado devido a um dano permanente (por exemplo, dano físico infligido nas partículas do disco). Também é comum que um controlador de matriz leia o disco espelhado alternativo se um bloco ruim for detectado na solicitação de leitura inicial. Subsequentemente, o controlador de matriz irá marcar o bloco como "ruim" e gravar os dados em um novo bloco. Tudo isso ocorre sem que o aplicativo saiba, talvez com um leve aumento na latência de leitura do disco. Sem o RAID ou um controlador de matriz, a detecção desses blocos ruins e os métodos de solução não estão mais disponíveis. Sem o RAID, cabe ao aplicativo (ESE) detectar os blocos ruins e solucionar (isto é, soma de verificação do banco de dados).
4. Bancos de dados maiores em discos maiores exigem períodos de manutenção mais longos, para manter a sequência/compactação do banco de dados.

Devido aos problemas mencionados, no Exchange 2010 era crítico que as tarefas de manutenção do banco de dados fossem movidas de um processo programado e executadas continuamente em segundo plano durante o tempo de execução.

Essas tarefas de segundo plano não irão afetar meus usuários finais?

Projetamos essas tarefas de segundo plano para que não sejam aceleradas automaticamente com base na atividade que ocorre contra o banco de dados. Além disso, nossa orientação de tamanhos quanto ao perfis de mensagem levam essas tarefas de manutenção em consideração. No entanto, você deve tomar cuidado ao projetar sua arquitetura de armazenamento. Se você planeja armazenar diversos bancos de dados no mesmo LUN ou volume, certifique-se de que o tamanho agregado de todos os bancos não exceda 2 TB. Isso ocorre porque a manutenção do banco de dados é acelerada pela serialização, com base nos bancos de dados/volumes, e presume que o tamanho agregado não seja maior que 2 TB.

Como posso monitorar a efetividade dessas tarefas de manutenção de segundo plano?

Nas versões prévias do Exchange, eventos no Log do Aplicativo seriam usados para monitorar coisas como a desfragmentação online. No Exchange 2010, os eventos não são mais registrados para as tarefas de manutenção de desfragmentação e compactação. No entanto, você pode usar os contadores de desempenho para rastrear as tarefas de manutenção de segundo plano sob o objeto MSExchange Database ==> Instances:

Você encontrará os seguintes contadores de zeragem da página no objeto MSExchange Database:

Uma confusão de terminologia

Grande parte da confusão está no termo manutenção do banco de dados em segundo plano. Coletivamente, todas as tarefas mencionadas compõem a manutenção do banco de dados em segundo plano. No entanto, o Shell, o EMC e o JetStress se referem à soma de verificação do banco de dados como manutenção do banco de dados em segundo plano, e isso é o que você configura ao ativar ou desativar usando essas ferramentas.

Figura 1: Ativando a manutenção em segundo plano para um banco de dados usando o EMC

Ativando a manutenção em segundo plano para um banco de dados usando o Shell:

Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true

Figura 2: Executando a manutenção do banco de dados em segundo plano como parte de um teste do JetStress

Meu fornecedor de armazenamento recomendou que eu desabilite o soma de verificação do banco de dados como uma tarefa de manutenção em segundo plano, o que devo fazer?

A soma de verificação do banco de dados pode se tornar um fardo do IO se o armazenamento não for projetado corretamente (embora seja sequencial), porque execute IOS de leitura de 256K e gera cerca de 5MB/s por banco de dados.

Como parte da nossa orientação de armazenamento, recomendamos configurar o tamanho da faixa da sua matriz (o tamanho das faixas gravadas em cada disco na matriz; também denominada tamanho do bloco) como 256KB ou mais.

Também é importante testar seu armazenamento com o JetStress e garantir que a operação de soma de verificação no banco de dados seja incluída na passagem do test

No final, se uma execução do JetStress falhar devido à soma de verificação do banco de dados, você tem algumas opções:

1. Não use as faixas  Use pares RAID-1 ou JBOD (que pode exigir alterações arquitetônicas) e obtenha o máximo de benefícios dos padrões de IO sequenciais disponíveis no Exchange 2010.
2. Programe  Configure a soma de verificação do banco de dados para não ser um processo de segundo plano, mas um processo programado. Quando a soma é implementada como um processo de segundo plano, entendemos que algumas matrizes de armazenamento seriam tão otimizadas para o IO aleatório (ou teriam limitações de largura de banda) que não poderiam lidar bem com o IO da leitura sequencial. É por isso que a criamos para que possa ser desativada (movendo assim a operação de soma de verificação para a janela de manutenção).

   Se você fizer isso, recomendamos tamanhos do banco de dados menores. Lembre também que as cópias passivas ainda executarão a soma de verificação do banco de dados como um processo de segundo plano, portanto você ainda precisa considerar esse fato para o rendimento na nossa arquitetura de armazenamento. Para obter mais informação sobre esse assunto, consulte Jetstress 2010 e manutenção do banco de dados em segundo plano.

3. Use um armazenamento diferente ou aprimore suas capacidades  Escolha um armazenamento capaz de atender às práticas recomendadas do Exchange (tamanho de faixa 256KB+).

Conclusão

As alterações arquitetônicas no mecanismo do banco de dados no Exchange Server 2010 aprimoram drasticamente o desempenho e a robustez, mas mudam o comportamento das tarefas de manutenção do banco de dados de versões prévias. Espero que esse artigo o ajude a entender o que é a manutenção do banco de dados em segundo plano no Exchange 2010.

Ross Smith IV
Gerente de programa principal
Experiência do cliente do Exchange

Este é um post de um blog localizado. Encontre o artigo original em Database Maintenance in Exchange 2010

Artigo original publicado na quarta-feira, 07 de novembro de 2012

O que é?

O acesso offline no Outlook Web App para Exchange 2013 permite os usuários utilizarem o Outlook Web App mesmo quando não estão conectados em uma rede.

O acesso offline é uma nova disponibilidade no Outlook Web App nos seguintes navegadores:

• Internet Explorer 10
• Safari 5 ou superior (suportado apenas em Mac desktops)
• Chrome

Para obter mais informações sobre a experiência do usuário offline, consulte Usando o Outlook Web App offline.

Quais dados estão disponíveis offline?

Email

• Os usuários podem ver todas suas pastas e conteúdo em todas as pastas com suporte offline.
• As pastas com suporte offline incluem:
  • Caixa de entrada
  • Rascunhos
  • Qualquer pasta exibida no navegador na última semana
• Para cada pasta com suporte offline, os usuários terão 3 dias de conteúdo ou 150 itens, o que for maior.
• Os anexos não estão disponíveis offline.

Calendário

• Os lembretes irão aparecer para reuniões e agendamentos
• O mês atual e próximo ano do calendário
• Vários calendários não estão disponíveis offline

Pessoas

• Todos os contatos
• Qualquer email do usuário frequente ou enviado recentemente
• O cache de Auto-preenchimento (a lista de nomes correspondentes que aparecem quando alguém é adicionado à mensagem)

Quais ações do usuário são suportadas offline?

Observação: Os usuários não podem pesquisar ou classificar mensagens enquanto estiver offline

Proteger dados

Configurar o acesso offline através de um navegador inicia um processo que copia os dados de caixa de correio localmente em um local de armazenamento de banco de dados da Web. Isto é determinado pelo navegador e é geralmente um arquivo ou um conjunto de arquivos no disco. Por exemplo, no momento que esta publicação foi escrita, os navegadores IE10 e Chrome usaram os seguintes locais de arquivo para seu armazenamento de banco de dados da Web (no Windows):

• Internet Explorer: %systemdrive%\Users\%username% \Local\Microsoft\Internet Explorer\Indexed DB
• Chrome: %systemdrive%\Users\%username% \AppData\Local\Google\Chrome\User Data\Default\databases

Os dados armazenados para uso offline são acessíveis através da conta de usuário do Windows na qual foi habilitada e não são criptografados. Assim como outros arquivos no computador, a melhor forma de protegê-lo é usar criptografia a nível do disco como Bitlocker.

Controles da Política da Organização:

Por padrão, os usuários podem configurar o Outlook Web App 2013 para uso offline. É possível desabilitar a capacidade dos usuários na sua organização usarem o use Outlook Web App offline utilizando os seguintes comandos do Shell de Gerenciamento do Exchange (EMS):

Para definir o acesso offline a uma política de caixa de correio do Outlook Web App, use:

Set-OwaMailboxPolicy –AllowOfflineOn [NoComputers | AllComputers | PrivateComputers]

Para definir o acesso offline para um diretório virtual do Outlook Web App:

Set-OwaVirtualDirectory –AllowOfflineOn [NoComputers | AllComputers | PrivateComputers]

Deep Dive: Como funciona?

Obtendo e armazenando dados de caixa de correio:

O banco de dados local do navegador armazena algum conteúdo da caixa de correio do Exchange. No Internet Explorer, este banco de dados é um padrão da indústria do banco de dados HTML5 IndexedDB. Em navegadores Safari e Chrome, isto é um banco de dados WebSQL. O navegador (não o Outlook Web App) decide onde os dados são armazenados, qual são as cotas e como os dados são por fim atrasados. Quando o Outlook Web App é definido para uso offline, um processo começa a copiar todos os dados do Outlook Web App necessários localmente. Em uma rede de largura de banda alta, este processo frequentemente será concluído em um minuto ou dois. Quando offline é configurado, o processo será executado sempre que o Outlook Web App estiver em uso e certifique-se de qualquer mudança no lado do servidor seja refletida no banco de dados local.

• Quando o Outlook Web App é configurado pela primeira vez para uso offline,
• Na inicialização do Outlook Web App (após ter sido configurado para uso offline)
• Enquanto utiliza o Outlook Web App, sempre que algo na caixa de correio do Exchange mudar

Este processo itera através da caixa de correio do Exchange, obtendo e gravando atualizações no banco de dados local do navegador na seguinte ordem:

1. Os dados precisam atualizar a lista de mensagem atualmente exibida no Outlook Web App
2. Notificações de lembrete do calendário
3. A lista de Caixa de entrada mais atual
4. A lista de mensagens mais atual do resto das pastas suportadas offline
5. Atualizações de pessoas
6. Atualizações de calendário
7. O conteúdo de mensagens na lista atual
8. O conteúdo de mensagens na Caixa de entrada
9. O conteúdo de mensagens no resto de pastas suportadas offline
10. Imagens em linha em qualquer mensagem armazenada localmente
11. Cada item na lista acima é chamado de módulo de sincronização

A quantidade de armazenamento offline que o Outlook Web App usa é vinculado pela cota do banco de dados do navegador. Se o processo atinge uma cota do navegador enquanto copia dados, para e um algoritmo de retorno itera através dos módulos acima na ordem inversa, removendo-os do banco de dados local até que esteja sob a cota.

Figura 1: Modelo de Armazenamento Offline

O que acontece quando o Outlook Web App fica offline

Se a conexão de rede falhar ou é desabilitada enquanto o Outlook Web App estiver em uso, os usuários podem continuar a trabalhar normalmente. Da mesma forma, um usuário pode iniciar o Outlook Web App quando offline, assim como em um avião ou em um café sem WiFi, e use-o normalmente. O Outlook Web App aparecerá sem exigir o login. A melhor forma de chegar ao Outlook Web App quando offline é usando um favorito ou marcação. Quando o Outlook Web App é definido para uso offline, o Internet Explorer oferecerá a opção de criar um favorito. O Favorito torna fácil navegar para o local correto. A única indicação que o aplicativo está funcionando offline será uma marca de data e hora no canto inferior da exibição de email do Outlook Web App indicando a última vez que o Outlook Web App foi atualizado.

Outros locais serão diferentes no Outlook Web App em estado offline vs. online com recursos não suportados offline. Por exemplo, “Criar Regra…” com o clique do botão direito em uma mensagem, mostrará a mesma mensagem de erro que iria exibir se o Outlook Web App não foi configurado para uso offline.

Quando uma ação suportada é realizada enquanto estiver offline (por exemplo, excluir uma mensagem), dentro de um período de milissegundos, a seguinte sequência de eventos ocorre:

• A exclusão será aplicada à exibição, que é armazenada em cache na memória. A mensagem desaparecerá imediatamente
• A exclusão será aplicada à mensagem no banco de dados local, para que mesmo se você permanecer offline em várias sessões do Outlook Web App, o item aparecerá como excluído no Outlook Web App.
• A ação de exclusão será gravada em uma fila que será reproduzida assim que a conectividade com o servidor for restabelecida. Toda atividade de criação/atualização/exclusão offline é armazenada nesta fila, que é armazenada como uma tabela no banco de dados da Web local. O Outlook Web App reproduz esta atividade para o servidor na próxima vez que o Outlook Web App é conectado

Figura 2: Ação Offline e Modelo de Sincronização de Dados

O Outlook Web App determina o status de conectividade da rede com base na resposta de cada solicitação da Web para o Exchange server. Assim que a conectividade da rede é detectada, o Outlook Web App responde a fila de atividade offline rapidamente para o servidor, para que todos os clientes reflitam agora qualquer trabalho realizado offline. Após a fila ser reproduzida e o servidor estar atualizado, o processo para copiar mudanças ou novas mensagens do servidor para o banco de dados do Outlook Web App local começa.

Para armazenar mensagens criadas offline, o Outlook Web App cria uma pasta Outbox na árvore de pastas. Este Outbox é local para sua máquina. Os usuários podem abrir e editar mensagens da pasta Outbox, onde neste ponto elas se tornam rascunhos e são movidas para a pasta Rascunhos até que Enviar ou Salvar seja selecionado. As mensagens criadas e enviadas offline permanecerão no cliente até a próxima vez que o Outlook Web App é aberto e conectado ao Exchange.

Se o usuário obtém a conectividade de rede enquanto estiver trabalhando offline no Outlook Web App, eles podem ser solicitados a fazer o login novamente.

Sara Manning

Esta é uma publicação traduzida. Encontre o artigo original em Acesso offline no Web App 2013

Artigo original publicado na quarta-feira, 12 de setembro de 2012

A equipe do Microsoft Outlook lançou atualizações do Outlook 2010 e 2007 que oferecem aos usuários do Office 365 notificações de expiração de senha. A notificação de expiração de senha avançada será exibida em uma mensagem pop-up (próximo ao relógio do sistema) dentro de um determinado período de tempo antes da senha realmente expirar. Este período de tempo é configurado pelo administrador do inquilino (consulte os links abaixo para obter mais informações). Para usuários cujas senhas já expiraram, o Outlook irá piscar uma mensagem de erro quando os usuários tentarem se conectar as suas caixas de correio. Em ambos os cenários, o Outlook também oferece um link (URL) para atualizar senhas através do navegador. Quando os usuários clicam nestes links, eles são levados para o Portal do Microsoft Online para alterar/atualizar suas senhas.

2745588 Notificação de expiração de senha do Outlook no Office 365

É possível baixar as atualizações do Outlook 2010 e 2007 através dos seguintes artigos da Base de Dados de Conhecimento:

• 2687351Descrição do pacote de hotfix do Outlook 2010 (Outlook-x-none.msp): 28 de agosto de 2012
• 2687336 Descrição do pacote de hotfix do Outlook 2007 (Outlook-x-none.msp): 28 de agosto de 2012

Observação: Para poder instalar estas atualizações, você precisará de permissões do administrador nos computadores do Windows. Entre em contato com seu Administrador Inquilino se não puder instalar as atualizações devido a um problema de permissão. Além disso, nos próximos meses, estas atualizações estão planejadas para serem liberadas através do Microsoft Update.

Vídeos de experiência do usuário do Outlook

O seguinte vídeo oferece uma introdução rápida de um minuto da experiência do usuário do Outlook. (Duração: 55 segundos, menos de um minuto)

O seguinte vídeo demonstra a experiência do usuário do Outlook quando a atualização é instalada e a senha está prestes a expirar. (Duração: 3 minutos e 23 segundos)

O seguinte vídeo demonstra a experiência do usuário do Outlook quando a atualização é aplicada e a senha já expirou. (Duração: 3 minutos e 37 segundos)

Frequência da notificação de expiração da senha

A notificação da expiração de senha anterior (mensagem pop-up próxima ao relógio do sistema) aparecerá uma vez a cada 24 horas na máquina do usuário. Se o mesmo usuário estiver usando o Outlook em várias máquinas, ele verá o mesmo comportamento em todas as máquinas, conforme as notificações são emparelhadas com o perfil de email no Outlook.

Várias contas em um perfil

Em uma situação onde um usuário configurou várias contas do Exchange baseadas em Office 365 em um determinado perfil de email no Outlook, o usuário receberá notificações individuais para estes contas em horários adequados. O número de notificações simultâneas não será limitado, pois esta informação é fundamental para usuários do Outlook.

Outlook e Lync

Se um usuário possui o Outlook e Lync funcionando ao mesmo tempo para se conectar em uma conta do Office 365, ele pode ver duas notificações separadas como autenticação de aplicativos e conectar separadamente para o Serviço do Office 365 e usar recursos independentes para exibir as notificações adequadas. O Lync depende do Microsoft Online Services Sign-In Assistant (‘MOS SIA’), enquanto o Outlook lida com este cenário independente do MOS SIA.

Redefinição de senha

Estas novas atualizações não oferecem qualquer forma dos usuários do Outlook para ajudar na redefinição de senhas, em caso que tenham esquecido. Eles ainda precisam seguir as diretrizes atuais para usuários do Office 365 para recuperar sua senha.

Abaixo estão alguns tópicos de interesse para Administradores Inquilinos.

Como definir configurações de política de senha

Os Administradores Inquilinos podem usar os comandos do PowerShell disponíveis para gerenciar e definir as configurações relacionadas à Política de Senha. Estes comandos também permitem definir o período de tempo para notificações de expiração de senha antecipada que o usuário pode ver no Outlook.

Para obter ajuda com estes comandos, consulte Cmdlets do Windows PowerShell para Office 365 (Consulte os cmdlets: Set-MsolPasswordPolicy e Get-MsolPasswordPolicy)

O seguinte artigo da Base de Dados de Conhecimento oferece instruções com a ajuda de um exemplo sobre como é possível usar os cmdlets do PowerShell para definir parâmetros de política de senha.

2723716 Mensagem de erro ao executar o cmdlet Set-MsolPasswordPolicy no Office 365: "Não é possível concluir esta ação"

Office 365 gerenciado vs. Usuários federados

O Outlook confia principalmente na notificação do sistema do Windows (gerenciado pelo Active Directory e Controlador de Domínio) para expiração de senha em caso de usuários federados usando máquinas de domínio associado. O Outlook exibirá as notificações de expiração de senha apenas para usuários federados não usando as máquinas de domínio associado e sincronizando sua informação do Active Directory com o sistema de gerenciamento de identidade do Office 365.

Para usuários federados, se uma organização implementou um fluxo de trabalho "Alterar Senha" (estendendo sua página de login com um link para a instância do FIM, por exemplo), o link do OWA (Outlook Web App) referido pelo Outlook permitirá o usuário alterar sua senha obtendo-as para sua página de login do OWA baseado em AD FS. Se uma organização não permite qualquer mudança do fluxo de senha de fora/Internet, o usuário precisará utilizar outros meios disponíveis (como chamar seu help desk, usar VPN ou uma máquina de domínio associado, etc.) para alterar sua senha, de acordo com a política de organização.

Para obter mais informações sobre com configurar o acesso ao Outlook Web App, consulte Configurar URLs de Login para o Outlook Web App

Allie Bellew (Equipe Outlook)
Gabe Bratton, Amir Haque (Equipe de Suportabilidade)

Esta é uma publicação traduzida. Encontre o artigo original em Office 365 – Notificações de expiração de senha no Outlook