Remote Push – SEPM Windows 8

A instalação do cliente do SEPM no Windows 8 não estava funcionando, no Windows 7 funcionava corretamente, no arquivo de LOG de instalação do SEPM no cliente (%temp%\sep_inst.log) encontrei os seguintes erros:

MSI (s) (C4:6C) [10:30:24:553]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (C4:6C) [10:30:24:554]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (C4:6C) [10:30:24:554]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied.  Counter after decrement: -1
MSI (s) (C4:6C) [10:30:24:567]: Destroying RemoteAPI object.
MSI (s) (C4:34) [10:30:24:567]: Custom Action Manager thread ending.
MSI (c) (34:B0) [10:30:24:568]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied.  Counter after decrement: -1
MSI (c) (34:B0) [10:30:24:569]: MainEngineThread is returning 1603

Verificando o serviço “registro remoto” estava com o status de parada, bastou inicializar que obtive sucesso na instalação do SEPM.

Instalação do Cliente do SCCM 2012 – Windows 2003

Ao efetuar a instalação do Cliente SCCM 2012 em máquinas Windows 2003 era apresentado o seguinte erro, no arquivo ccm.log (Os “passos” da instalação do Cliente do SCCM) que se localiza dentro da pasta LOG, no caminho de instalação do servidor SCCM:

---> Unable to connect to WMI (root\ccm) on remote machine "MACHINE_WIN2003", error = 0x8004100e.    SMS_CLIENT_CONFIG_MANAGER
 
No arquivo Ccmsetup.log (Fornece informações sobre as ações na máquina cliente, os passos da instalação)

---> Failed to query BITS 2.5 interface with error 0x80004002    ccmsetup    27/05/2013 14:07:22    3624 (0x0E28)
This operating system does not contain the correct version of BITS. BITS 2.5 or later is required.    ccmsetup    27/05/2013 14:07:22    3624 (0x0E28)

Verificando a versão do BITS estava utilizando a versão 2.0 quando para o funcionamento do SCCM o mínimo é o BITS 2.5, é possível verificar a verão do BITS checando a DLL QMgr.dll que se encontra no caminho %windir%\System32, abaixo mais informações:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa362837%28v=vs.85%29.aspx

Após a instalação da versão 2.5 do BITS a instalação do Cliente do SCCM foi concluída com sucesso, o update pode ser baixado no link abaixo:

http://www.microsoft.com/pt-br/download/details.aspx?id=4933

vSphere Replication

vSphere Replication é uma “feature” que permite a replicação de um VM, para outro local de armazenamento, como um Storage ou disco local, é baseado em um Appliance, foi lançada na versão 5.0 do Vmware, pode ser realizado o download do Appliance no link abaixo:

https://my.vmware.com/web/vmware/details?downloadGroup=VR511&productId=285&rPId=3666

Após o Download o deploy do Appliance é bem simples, pode ser através do vSphere Client ou no Web Client na imagem abaixo estou fazendo o Deploy através do Web Client:

Efetuar as configurações de IP e definir a senha do usuário admin e finalizar as configurações.
No Web Client seleciono a VM que desejo configurar a replicação, neste caso a VM Win7Teste, vou na opção "Actions" - Configure Replication:

 Em Target Site, vou na opção "Add Remote Site", e adiciono o site remoto, este site remoto é um segundo servidor vCenter.

 Será listado todos os datastore disponíveis no site remoto, seleciono o primeiro datastore:

Configurando RPO, a diferença de tempo das VMs, o padrão é 4 horas, ou seja caso a VM de problema às 12:00, eu posso recuperar as informações até as 16:00, caso eu tente recuperar às 17:00 não será possível, pois já foi efetuado a replicação.

Finalizar a configuração, a configuração é bem simples, podemos verificar o status da replicação na aba "monitor" em vSphere Replication, temos a opção de Stop ou Pause na replicação:

Após a conclusão da replicação, podemos recuperar a VM acessando o vCenter de Destino e na Aba monitor "Icoming Replications" vou em Recover...

Live Migration Hyper-V failed

Ao tentar efetuar o Live Migration de uma VM (Win7Teste) entre dois hosts Hyper-V (Server1 e Server2) recebia o erro abaixo:

 --

Virtual machine migration operation failed at migration source.

Failed to establish a connection with host 'Server1': The credentials supplied to the package were not recognized (0x8009030D).

The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication of migration connections and Constrained Delegation is enabled for the host in Active Directory.

[Expanded Information]
Virtual machine migration operation for 'Win7Teste' failed at migration source 'Server2'. (Virtual machine ID 361E903B-7991-4C2B-B810-49E260626CF0)

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host 'Server1': The credentials supplied to the package were not recognized (0x8009030D).

Failed to authenticate the connection at the source host: no suitable credentials available.

--


Para resolver este "problema", é necessário configurar a delegação, através da ferramenta "Active Directory User and Computers", acessar a conta do computador Server1 por exemplo e delegar os serviços cifs e Microsoft Virtual System Migration Service para o computador Server2, conforme print abaixo (também é necessário configurar a delegação do computador Server2):

Estou levando em conta que nas configurações do Hyper-V já está configurado corretamente o Live Migration, após o procedimento abaixo obtive sucesso no Live Migration.
Mais informações:
http://blogs.technet.com/b/matthts/archive/2012/06/10/configuring-kerberos-constrained-delegation-for-hyper-v-management.aspx
http://technet.microsoft.com/en-us/library/jj134199.aspx#BKMK_Step1

Migrar DFS namespace (baseado no domínio)

Cenário, migrar o DFS de um controlador de domínio para outro.
Os usuários acessam os arquivos através do caminho FQDN do domínio, por exemplo: \\contoso.com.br\Public que está “hospedado” no controlador de domínio “DC1”, migrarei para o controlador de domínio “DC2”, preservando todas as informações, como por exemplos as ”folders targets”, abaixo uma imagem que ajuda a compreender melhor o DFS:

Os conceitos do DFS podem ser encontrados na ajuda da ferramenta, não vou entrar em detalhes do funcionamento e nomenclaturas DFS, estou levando em conta que o leitor conhece as definições básicas do DFS.
Conectar no servidor (DC1) e exportar o namespace com o comando dfsutil:

dfsutil /root:\\contoso.com.br\Public /export:export.txt /verbose

Acessar o gerenciador do DFS e apagar o namespace:

Acessar o servidor que hospedará o namespace e adicionar um namespace server (DC2), gerenciador DFS "new namespace":

O nome do namespace deve ser o mesmo, Public:

Baseado em dominio:

Finalizar a criação do namespace.

 Antes de importar o namespace é necessário editar o arquivo exportado e alterar a linha:

Target Server=DC1

Que aponta para o “antigo” servidor, alterando para o “novo” servidor neste caso o DC2:



Target Server=DC2
 
Agora é necessário importar o namespace exportado anteriormente, com o comando:

dfsutil /root:\\contoso.com.br\Public /import:export.txt /set

Pronto a migração foi concluída!.