Feliz 2013 a todos!

Desejo a todos vocês muita paz, amor e saúde pra correr atrás dos sonhos! Que esse novo ano seja repleto de realizações e conquistas!

Meu cordial abraço e Feliz 2013!

Anúncios

Restaurando banco de dados sem o arquivo de log

Um banco de dados do SQL Server 2008 sofreu com a inabilidade de um colaborador, pois é, ele foi apagado.

Conseguimos recuperar somente o MDF, que é o arquivos de dados do SQL Server. Algumas versões atrás do SQL Server, essa recuperação era bem trivial, mas no 2008 levei algumas horas para conseguir um novo banco sem ter o arquivo LDF.

Quando o assunto é banco de dados procuro logo pelo blog do Pinal Dave e achei um post em http://blog.sqlauthority.com/2010/04/26/sql-server-attach-mdf-file-without-ldf-file-in-database/ que auxiliou bastante.

No entanto, as coisas não estavam funcionando muito bem. O problema ocorria quando utilizava o método 2 que o autor indicava, que seria:

CREATE DATABASE TestDb ON
(FILENAME =N’C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf’)
FOR ATTACH_REBUILD_LOG
GO

O SQL Server reportava um erro tentando criar o arquivo de log original buscando as informações no MDF.

Após algumas pesquisas, encontrei no blog do SqlDestiny em http://sqldestiny.com/2011/04/01/attach-a-database-without-log-file-using-for-attach_rebuild_log/ o comentário de um usuário alterando a sentença anterior de FOR ATTACH_REBUILD_LOG para FOR ATTACH_FORCE_REBUILD_LOG, ficando:

CREATE DATABASE TestDb ON
(FILENAME =N’C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf’)
FOR ATTACH_FORCE_REBUILD_LOG
GO

Dessa forma meu banco de dados foi criado e estamos aguardando o próximo desafio.

Abraço.

Como alterar o email principal do usuário no Office 365

Após alguns sinistros com infraestrutura, especificamente, com meus servidores que hospedam o Zimbra, decidi investigar mais a fundo o Office 365 da Microsoft para usar como solução colaborativa.

Sempre fui, e continuo sendo, um fã do Zimbra, mas a possibilidade de utilização da nuvem da Microsoft e todas as vantagens que isso trás foram decisivos.

Como trabalho em uma Instituição de Ensino, tive acesso ao serviço de forma completamente gratuita, caixas postais de 25 GB por usuário, mais antispam, antivírus, arquivamento etc. Inevitável à migração.

Depois até vou escrever um post compartilhando o processo de Federação do domínio que é bem interessante e útil.

Pois bem. Algumas contas durante o processo de sincronização dos meus DCs (Domain Controller) locais com os DCs no Windows Azure apresentaram uma inconsistência no campo chamado “Email principal do usuário”. Nesse local deveria estar armazenado o domínio qualificado, por exemplo, empresa.com.br. No entanto, o valor que estava armazenado era empresa.onmicrosoft.com, que é o domínio criado no Office 365 na hora do cadastro de um novo domínio. E no alias (Outros endereços de email) estava o valor do domínio empresa.com.br, ou seja, os valores estavam invertidos.

O problema dessa inversão de valores é que o email errado (empresa.onmicrosoft.com) aparecia como principal quando a lista de contatos era consultada e eu não queria que o email .onmicrosoft.com fosse publicado nas mensagens.

Como os usuários são todos federados, a mudança necessitava ser feita no AD local. Encontrei então o post de Geert Baeke em http://blog.baeke.info/2012/06/24/office-365-identity-management-with-dirsync-without-exchange-server-on-premises/ que me ajudou bastante.

Estava quase corrigindo o problema, quando o telefone toca, era o suporte da equipe do Office 365 da Microsoft me arguindo a respeito de um chamado que abri. Realmente, no início da manhã, entrei no painel do Office 365 e reportei o problema por chamado. Os caras ligaram!!! Mais do que ligar, o cara sabia exatamente qual era meu problema e prontamente apresentou a solução, que era a mesma do post acima mencionado.

A Microsoft merece um graúdo PARABÉNS!

Vamos aos fatos:

1) Utilizando o ADSI Edit procure pelo objeto (usuário) que necessita fazer a troca de valores dos emails;

2) Clicando o botão direito selecione a opção Propriedades, procure pelo campo proxyAddresses e clique em Edit;

3) Digite: SMTP:usuario@empresa.com.br e clique em Add. SMTP tem que ser maiúsculo;

4) Agora digite: smtp:usuario@empresa.onmicrosoft.com e clique em Add. smtp agora minúsculo;

5) Feche tudo clicando em OK.

Pronto, agora é esperar a replicação. Mas se quiser forças às atualizações, siga os passos:

1) No seu servidor que está com o DirSync (ferramenta de migração do AD local com o Azure) procure pelo arquivo DirSyncConfigShell.PSC1 que deve estar em C:\Program Files\Microsoft Online Directory Sync e clique nele;

2) Uma janela de Power Shell será aberta, digite: Start-OnlineCoexistenceSync;

3) Abra o Forefront Synchronization Service Manager do Forefront Identity Manager 2010 que está em C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell com o nome de miisclient.exe e observe que em Operations o processo estará em execução;

4) Ao final da replicação o usuário no Office 365 estará com os valores corretos.

Obrigado pela atenção e forte abraço.

Como resetar uma VM em XenServer 6.0.2?

Acho que vocês já tiveram um problema de comunicação com o storage do seu XenServer e algumas VMs meio que congelaram. Por mais que você utilize o comando de Force Shutdown ela fica emperrada reportando “Another operation involving the object is currently in progress”.

Geralmente esse é o motivo para realizar o procedimento que vou descrever abaixo, mas se aplica a qualquer outra causa de travamento.

Infelizmente, não lembro das fontes que utilizei, mas assim que achar adiciono os créditos. Vamos lá:

1) Pesquise o UUID da VM que necessita resetar clicando na guia General;

2) Acesse o console do seu XenServer, no meu caso utilizo o 6.0.2, clicando na guia Console;

3) Digite:

list_domains | grep 293da337-ce65-87ff-6ccb-65311420cf6c

Lembre-se de utilizar o seu UUID;

4) O Xen vai retornar uma string e você deve anotar o primeiro valor que corresponde ao domain da sua VM;

5) Digite agora:

/opt/xensource/debug/destroy_domain -domid XX

Onde XX é o valor anotado no item 4 para destruir o domain dessa VM;

6) Aproveitando que você já está com a mão na massa, digite:

xe vm-reset-powerstate vm=”mail.servidor.com.br” –force

Onde mail.servidor.com.br é o nome da sua VM.

É isso. Grande abraço.

Alterando a chave do Windows 8 depois da instalação

No meio dessa semana, procurando por novidades em minha conta do MSDNAA, me deparei com o Windows 8 Professional. Já havia testado a Preview e resolvi atualizar meu Lenovo Z470 com essa ISO. Depois farei um outro post das minha considerações sobre essa versão do Windows 8.

Pois bem, depois de alguns minutos procurando como ativar meu Windows encontrei o site de Steve Sinchak em http://tweaks.com/windows/39026/change-windows-product-key-after-install/ e executei o seguinte procedimento:

1) No novo Iniciar vá digitando Prompt … que ele logo mostrará o “botão” do Prompt de comando, clique o botão direito do mouse sobre ele e escolha a opção que aparece abaixo Executar como Administrador;

2) Com o prompt aberto digite:

slmgr.vbs -ipk 00000-00000-00000-00000-00000

Onde os zeros correspondem a sua chave.

Uma mensagem aparecerá informando da alteração.

3) Depois disso basta digital:

slmgr.vbs -ato

Agora é só utilizar as demais funções que só são habilitadas com a ativação do Windows.

Abraço.

Erro ao criar uma nova VM no XenServer 6.0.2

Recentemente decidi sair do mundo “azul” da VMware e desafiar o XenServer para o dia-a-dia. O fator decisivo para essa mudança foi a nova política do ESXi 5.0 onde passou de 64GB para 32GB de RAM no hospedeiro. Como tenho em minhas lâminas 64GB, não tive escolha.

Embora já tivesse trabalhado com o XenServer 5, o erro que vou abordar não me lembro de ter passado por ele.

Ao criar uma VM utilizando os templates do XenCenter, especificamente do CentOS 6.0 64 bits, ocorria à mensagem:

“INVALID_SOURCE – Unable to access a required file in the specified repository: file:///tmp/cdrom-repo-GiFdAZ/isolinux/vmlinuz.”

Após algumas pesquisas no “pai” Google, encontrei o post de Milind Koyande em http://eitwebguru.com/citrix-xen-vm-boot-error-code-invalid_source-unable-to-boot-from-cddvd/, que relatava um erro similar ao meu. Após algumas adaptações a solução ficou da seguinte forma:

1) No XenCenter selecione a VM que você deseja corrigir e clique na guia General e procure a UUID da mesma;

2) Selecione o seu XenServer no topo do XenCenter e clique na guia Console e tente inicializar sua VM com o comando:

xe vm-start uuid=5ce47d4e-227c-9d1e-4710-21b7c998318e

Lembre-se de trocar a UUID que utilizei no exemplo acima pela sua encontrada no item 1;

3) Você deverá visualizar a mesma mensagem do modo gráfico indicando o problema. Pois bem, com o comando abaixo verifique a política de boot da sua VM:

xe vm-param-list uuid=5ce47d4e-227c-9d1e-4710-21b7c998318e | grep HVM-boot

O seguinte resultado deverá aparecer:

HVM-boot-policy ( RW):
HVM-boot-params (MRW):

Indicando que o parâmetro HVM-boot-policy está vazio. É esse o problema;

4) Para corrigir o problema, entre com o comando:

xe vm-param-set uuid=5ce47d4e-227c-9d1e-4710-21b7c998318e HVM-boot-policy=”BIOS order”

5) Verifique novamente se o parâmetro foi setado com o comando do passo 3. O resultado deverá ser:

HVM-boot-policy ( RW): BIOS order

6) Caso o tudo dado tudo certo, inicialize sua VM novamente com:

xe vm-start uuid=5ce47d4e-227c-9d1e-4710-21b7c998318e

Agora sim!

O bug já foi reportado para a Citrix e vamos aguardar a correção.

Abraço.

Adicionando um segundo volume no VMware Zimbra

Recentemente o volume de mensagens do meu Zimbra 7.1.1 estava quase cheio e para evitar problemas maiores, resolvi pesquisar um pouco sobre a possibilidade de ativar um segundo volume. Tinha feito alguns testes em servidores de teste anteriormente e a coisa tinha rodado direitinho.

Na versão 7 do zimbra não foi diferente funcionou redondo.

Abaixo listo os passos utilizados para incluir esse segundo volume via CLI.

 

Como usuário zimbra :

1) Para criar o volume secundário entre com:

zmvolume -a -n message2 -p /opt/zimbra2/store -t MensagemSecundaria

O sistema de arquivo /opt/zimbra2 está montado em um novo disco.

2) Para verificar os volumes criados:

zmvolume -l

3) Para ativar o volume secundário:

zmvolume -sc -id 3

Na minha lista o id 3 é o do novo volume criado.

4) Para verificar os volumes ativos:

zmvolume -dc

O seu volume deverá aparecer como ativo agora.

 

Como usuário root:

Verifique a existência do diretório 0 criado pelo ZCS no caminho do novo volume:

ls /opt/zimbra2/store

Fique tranquilo que as mensagens salvas no antigo volume estão lá intectas, apenas as novas chegarão no novo volume ativo.

Abraço.