Restore MAILBOX Exchange 2010

Boa noite pessoal,

Hoje fui surpreendido por uma dúvida de um novo colega que também se tornou minha curiosidade. Já se tem muitos posts sobre o assunto na Internet, mas como a maioria, o “pulo do gato” sempre fica fora, resolvi escrever sobre acrescentando o máximo de detalhes possíveis.

Possíveis Cenários: Uma Caixa de Correio foi excluída indevidamente; Um Mailbox foi corrompido e etc…

Ps. Todos os comando foram executados em laboratório com os cenários acima. Se não tiver um laboratório para testar é extremamente recomendado que se trabalhe somente com o BACKUP, deixando assim, o Mailbox raiz intacto.

Para restaurar uma Caixa de Correio especifica, você terá que ter o backup da mesma.

Realize o Restore do Backup e o isole dos demais Mailbox (isso impede acidentes)

1 – Preparando Backup do Mailbox para Restore’

A- É necessário verificar o estado do seu Mailbox (o meu é denominado W2 o arquivo EDB é W)

B- Via Power Shell (execute com RUN AS)

Vá até a pasta aonde você armazenou o seu restore e execute;

–>> F:\Mailbox\W2> eseutil /mh W.edb

Neste comando você analisa o estado do Mailbox, se ele esta Dirty ou Clean

Dirty = O Mailbox ta sujo e precisa ser limpo para e se preparar para o restore.

Clean = Já esta limpo e pronto para restore;

Em caso de Dirty execute:  –> F:\Mailbox\W2> eseutil /r E01 /I /d

Após receber o resultado execute novamente –> F:\Mailbox\W2> eseutil /mh W.edb para saber o estado do Mailbox.

‘2 – Criando Mailbox Recovery

Nesta etapa será criado e montado o Mailbox com os seu backup.

A – Crie o Mailbox com os seguinte comandos… (esse é o pulo do Gato)

New-MailboxDatabase -Name “Recovery Database” -Server NOME DO SEU SERVIDOR -EDBFilePath “F:\Mailbox\W2\W.edb” -Logfolderpath “F:\Mailbox\W2\Log” –Recovery

Descriminando:

• New-MailboxDatabase = Chamando a criação do Mailbox;
• –Name = Nome da Database;
• –Server = Cita o seu servidor, onde será alocado o Mailbox;
• NOME DO SEU SERVIDOR = Nome do seu servidor, sem aspas ou caracteres especiais;
• –EDBFilePath = Aqui você cita aonde está o seu arquivo .EDB que será usado para montar a Database;
• “G:\Mailbox\Restore\W\W.edb” = Esse é o caminho do meu arquivo .EDB;
• –Logfolderpath = Sintaxe do caminho dos logs (dos seus logs restaurados);
• “G:\Mailbox\Restore\W\Log” = Local do seu Logs;
• –Recovery = Sintaxe de Recovery, ou seja, transformará sua Database em uma Base de recovery. Em todo o seu Mailbox, só é possível uma Database de Recovery.

Depois de base criada, realiza a montagem com o comando — Mount-Database “Recovery Database”.

Restaurando Caixa postal

1 – Execute o comando  — Get-MailboxStatistics –Database “Recovery Database” para saber o que tem dentro do seu Restore.

OBS. Suponho que você excluir por inteiro o usuário do Exchange e AD, então vamos restaurar as informações da Caixa Postal dentro de uma outra conta ativa ou criar a conta do usuário novamente.  Usaremos a conta Willian.Infra para demonstrar.

2 – Recriei o usuário deletado Willian.Infra e faremos o Restore para a sua propria caixa.

F:\>Restore-Mailbox -Identity “Willian.Infra” –RecoveryDatabase “Recovery Database” -RecoveryMailbox “Willian.Infra” -TargetFolder Restore

Descriminando:

F:\>Restore-Mailbox -Identity “Willian.Infra” –RecoveryDatabase “Recovery Database” = Neste você diz que quer restaurar a Caixa Postal do usuário Willian.Infra que esta dentro da Database “Recovery Database”.

 -RecoveryMailbox “Willian.Infra” -TargetFolder Restore = Neste você diz para o Exchange criar a pasta Restore e realizar o recovery dentro dela.

Na pergunta= YES

Pronto, Restore realizado, será criado uma pasta com o nome Restore dentro do usuário Willian.Infra com o backup restaurado.

Lembre-se que todos os comandos possuem suas variações, então, entenda a logica e realize de acordo com o seu ambiente.

Agradeço neste a imensa ajuda do Wadner,  o qual me despertou o desenvolver desse post.

–> Fontes de pesquisa: Guia de Bolso do Administrador Exchange 2010; Tranning Kit 70-662; Technet

Bem, espero ter sido bem claro e objetivo.

#Exchange2010 #Microsoft #Mailbox #Infra #Ajuda #Restore MAILBOX

Migrando File Server

Olá Pessoal.

A pouco tempo tive que realizar a migração de um servidor que comportava a ‘Rules’  Print Server e File Server

Testei varias maneiras em laboratório usando o Migration tools, mas quando parei pra pensar existe uma maneira muito fácil de fazer, usando o amigo de todos Robocopy.

Então vamos lá…

· MIGRANDO FILE SERVER

Pressuponho que você já tenha noções de como acrescentar papeis no servidor e um pouco de administração de Server 2008. Estou usando a versão R2, que para esse tutorial não influencia.

Srv1 = Servidor Origem, dados estão armazenados no disco G:\ IP 192.168.3.100

Srv2 = Servidor Destino, dados serão armazenados no disco E:\Dados. IP 192.168.3.101

1. Adicione os papais de File Server e Print Server ao servidor destino, que iremos chamado de Srv2.

2. Adicione o Srv2 ao domínio. Assim não terá problema de permissão.

3. Defina o tamanho do disco para armazenagem dos arquivos que serão migrados.

a. IMPORTANTE: Não é recomendado que se compartilhe o disco. Ex. Seu servidor origem tem dados os dados soltos no Disco E:\ no novo servidor você acrescentará uma nova pasta a estrutura ficando assim E:\Dados\ARQUIVOS. Dessa forma você ira compartilhar a pasta Dados e não o disco E:\

4. Interrompa o compartilhamento no Servidor origem, que chamaremos de Srv1.

5. Como dito acima usaremos o Robocopy para fazer toda a copia dos dados mantendo as permissões e integridade. Usaremos a seguinte sintaxe no Srv1.

6. Abra o DOS com RUN AS e defina a sintaxe que será usada, a minha foi a seguinte:

a. Robocopy G:\ \\192.168.3.101\E$\Dados /COPYALL  /MIR /R:5 W:2 /TEE /LOG+:C:\MigracaoDados.txt

i. Vamos interpretar o que se refere a sintaxe acima:

1. Robocopy = Chama o parâmetro de copia do Windows Server,  consegue fazer copia usando shadow copie e com inúmeros parâmetros (Lista completa ao final)

2. G:\ = Local dos arquivos de origem, neste caso estão na raiz do G:\

3. \\192.168.3.101\E$\Dados = Destino dos dados. Neste caso esta no Servidor 192.168.3.101 no disco E:\(utilizei o compartilhamento oculto do sistema E$, este é feito automaticamente quando a maquina é adicionada ao domínio) e serão salvos na pasta Dados.

4. COPYALL = Parametro Robocopy que realiza a copia dos arquivos com todos os seus atributos (permissões, flags, metadados e etc…)

5. MIR = Realiza um clone do seu origem para o destino. Como é clone tudo que estive no destino (\\192.168.3.101\E$\Dados) será apagado e escreverá o que tiver no Srv1.

6. R:5 = Significa retransmissão em caso de erro, o numero 5(cinco) define quantas vezes se repetira.

7. W:2 = Significa quanto tempo aguardar para realizar a retransmissão definida no parâmetro R:5, o numero 2 (dois) define o tempo em segundos.

8. TEE = Exibe a copia na tela do DOS. Tipo Matrix. Rsr.

9. LOG+ = Força o comando a salvar um log no caminho especificado C:\MigracaoDados.txt

7. Após a conclusão da copia dos nados, note que todos continuam as mesmas permissões que existia.

8. Agora realize o compartilhamento avançado: Botão direito na pasta -> propriedade -> Sharing -> Advanced Sharing -> marque o check box Sharing this folder, coloque o nome do compartilhamento e clique em permissões. Adicione o grupo AuthenticationUsers e der permissão de Read e Change.

Pronto, assim finalizamos a migração.

DICAS:

o Quando for escrever o Robocopy, utilize primeiro um bloco de notas e depois salve-o em .bat . Assim poderá altera-lo sem precisar reescrever tudo.

o Utilize senhas de Domain Admin

o Deixe o servidor Origem em Stand by por mais ou menos 1 mês, este é o tempo de você fazer backup dele.

Espero que eu tenha ajudado. Abraçoss.!!!

Ah e logo começarei o bloco de posts falando do Vsphere 5.0, WebClient e VM Data Protection

Criando placas virtuais – Hyper-V

Hoje, um colega veio com uma dúvida muito importante e ao mesmo tempo simples de se resolver.

Como se criar uma placa de rede virtual no Hyper-V?

O Hyper-V, assim como a maioria dos vitalizadores possui o esquema de ‘um para um’, ou seja, uma placa de rede física para uma placa de rede virtual.

Abra o gerenciador Hyper-V , no painel AÇÃO , então clique em GERENCIAMENTO DE REDE VIRTUAL. Aparecerá a tela abaixo.

Clique em NOVA PLACA VIRTUAL em então selecione o modo de uso da placa.

Externo: Cria uma placa virtual que utiliza a placa física para se comunicar com o mundo externo.

Interno: Cria-se uma placa virtual que comunica somente com a placa e host físico e demais hosts virtuais.

Particular: Cria uma placa virtual em que sua comunicação fica restrita aos hosts virtuais.

Nota: No nosso caso, vamos criar a placa virtual no modo Externo.

Após selecionar o modelo e clicar em ADICIONAR outra tela ira aparecer, esta é onde você dever dar uma identificação, observação e selecionar qual placa física será virtualizada,

Pronto, sua placa física foi virtualizada e já pode ser associada a qualquer VM.

“Finalmente Mirror–Infra!"

Estudo de Caso…

Na empresa “Contoso.com” existia a necessidade de realizar a implementação de “ Sistema de Contingência" da Aplicação e do Banco, então tal demanda foi levada até o LuanMoreno (http://luanmorenodba.wordpress.com), para que o mesmo nos desse uma solução para o este caso.

Para que essa Contingência fosse possível é necessário uma adaptação da sua rede para dar apoio a tal serviço.

 

Configurações Necessárias – Infraestrutura

 

Para realizar transferências de dados entre as redes (Contoso.com e New York) através de uma estrutura WAN é extremamente necessário se pensar na segurança das informações trafegadas, sendo assim foi criado uma VPN entre os dois pontos através da nuvem fazendo com que ambos se comuniquem através das portas de Mirror (5022), SQL Server e(1433 TCP / 1434 UDP) porta de sessão e também portas de uso dos protocolos Windows ex. Terminal Service, SMB e etc…

Com a comunicação estabelecida partimos para a configuração do Banco, onde todos poderão visualizar no post do LuanMorenoDBA. E neste momento tivemos um grande impacto que nos atrasou bastante, tivemos que enviar (por *FTP) o Backup do Banco Principal para New York e este foi restaurado no Banco Secundário, esse atraso não foi qualquer atraso, foi um atraso de quase uma semana, ou seja, muito atraso. Então aconselho (o que não fizemos, mas deveríamos) que comunique a sua operadora de Link que aumente temporariamente a sua largura de banda de upload, assim se torna mais facíl e menos traumático o envio do Banco e seus determinados logs diários.

*Para garantir a segurança na transferência é aconselhável usar o protocolo SSH ao invés do FTP, existe varias ferramentas que emula essa segurança, recomendo o Bitvise WINSSHD http://www.bitvise.com/download-area.

Durante a implementação do Banco tiremos um outro problema referente ao FQDN na rede de New York que foi solucionado conforme post https://williandrinfra.wordpress.com/2011/03/20/fqdn-e-register-dns/.

Com os Bancos (Contoso.com e New York) sincronizados e comunicação constante entre as bases, fomos para os testes:

Eu juntamente com o  LuanMorenoDBA fiz os seguintes testes:

Roteiros de Testes

1º Query de criação de tabelas – Tempo de resposta: Foi criado no banco primário algumas tabelas. Que levou um tempo médio de 5 a 10 segundos.

2º Inserção de dado 10.000 – Transferência perfeita em um tempo médio de 30 seg.

100.000 – Tempo médio de transferência de 1 a 3 min seg.

1.000.000 – Tempo médio de transferência de 7 a 8 min para replicar no Banco secundário.

3º Update e delete – Feito e replicado para o banco secundário por um tempo médio de 10 à 30 segundos.

4º Criação de objetos – Tempo médio de 15 segundos.

5º Baixar o Servidor Principal – Inserção de dados no Banco primário com o Mirror em stopped.

Comportamento Observado:

Foi inserido 1.000.000 de dados com o mirror em stopped, após a inserção foi dado o comando Failover para voltar o sincronismo dos Bancos, logo se iniciou a transferência de todos os dados  no Banco primário para o secundário. Os Bacos levaram algum tempo para obter o sincronismo total das informações, méida de 30 a 40 minutos, por outro lado em ambas a máquinas não houve stress de periféricos (CPU, Memória, Rede e etc…).

Com total o apoio que tive do LuanMorenoDBA, que por sinal é um ótimo DBA, a implementação do Projeto Mirror Contigência foi um sucesso.

Agora iremos juntos monitorar o ambiente e postaremos toda experiência adquirida.

Veja toda a implementação do Banco no post do LuanMorenoDBA

 

 

FQDN e Register DNS

Olá Pessoal,

Peguei um erro quando estava realizando a implementação do Mirror – SQL, juntamente com o http://luanmorenodba.wordpress.com/. Que se fez da seguinte forma:

Quando o LuanMorenoDBA tentou conexão com as duas bases do SQL, fazendo um point-to-point, o SQL pediu o endereço de servidor mais o FQDN (Fully Qualified Domain Name), porém o servidor no qual hospedará o Mirror-SQL não possui domínio, logo não possuí FQDN.

Sendo assim tentei adicionar um FQDN na “mão” dentro do servidor em:

Adicionei um servidor de sufixo e marquei a caixa para que ele registrasse esse mesmo sufixo no DNS. Mas uma coisa que não tinha notado e que estava estudando sobre agora à pouco. Para adicionar um nome NetBios no DNS é necessário informar ao DNS de Zonas Primaria que usuários fora do domínio podem registar nome de NetBios, o que não estava explicito no meu DNS, mas tal permissão trás certa vulnerabilidade no seu DNS, pois assim, qualquer maquina que souber o Domínio + Endereço ÍP (se seu DNS estiver na frente de um Firewall) + a zona DNS que se deve registrar consegue com sucesso se registar no seu DNS de Zonas Primária.

Caso esteja na mesma rede e Domínio de seu DNS, você consegue se registrar com o seguinte comando DOS ipconfig /registerdns, lembrando que o serviço DHCP já realiza esse registro por você, mas se quiser forçar um registro, esse comando irá lhe ajudar.

Para resolver o problema e não deixar o DNS “aberto” o FQDN da maquina em questão foi retirado e a comunicação realizada por endereço IP + porta TCP.

Até outra oportunidade…

Ferramenta de Gerenciamento Remoto Windows Server 2008 (RSAT)

Olá Pessoal,

Uma coisas que achei muito interessante e que tive bastante dificuldade de obter ajuda, então resolvi postar aqui…

Existe para download (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d) um conjunto de ferramenta chamada de RSAT (Remote Server Administrator Tools). Que vem em forma de atualização para o Windows 7 pela propria Microsoft, que nada mais é que o "Administations Tools" de seu servidro W2k8 na sua maquina local.

Se seu computador estiver em um domiínio, você consegue com facilidade gerenciar os serviços DNS, DHCP, AD, GPO’s e etc… Mas, para realizar alterações nestes Servidores é necessário que você tenha permissão de "domain admin" (caso em que os serviços estejam em um DC (Domain Controler)). Se não possuir permissão mas souber  o “user e password” execute o passo abaixo.:

Pressione a tecla “Shift” e clique com o botão direito do mouse em cima do Serviço Remote que queira utilizar, daí então irá abrir varías opções, sendo uma delas “EXECUTAR COM UM USUÁRIO DIFERENTE”. Quando clicar será exibido a tela de login para autenticação no servidor, as permissões deste usuário serão replicadas para o gerenciador, dessa forma o usuário só executará o que a permissão lhe der direito.

Caso seu computador local não esteja em um domínio você conseguirá gerenciar as ferramentas locais. Também se torna interessante caso se compartilhe o P.C.

Ate mais…