Usando a ferramenta ADMT 3.2 para migrar usuários do AD

O ADMT é uma ferramenta poderosa, serve para migrar objetos entre Florestas\Domínios, neste post vou migrar objetos do tipo usuário.

Neste cenário tenho dois domínios:

Pretendo migrar os objetos contas de usuários, do domínio fabrikan.internal para contoso.internal.
Inicialmente faço o download do ADMT 3.2:

http://www.microsoft.com/en-us/download/details.aspx?id=8377

Um pré-requisito para o ADMT é o SQL Server, é recomendado o SQL Express:

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=25052

Após a instalação iniciar a ferramenta:

Se ao tentaar iniciar o ADMT você receber este erro:

Unable to check for failed actions. :DBManager.IManageDB.1 : Cannot open database "ADMT" requested by the login. The logon failed.

Tem um KB da Microsoft sobre isso, eu obtive este erro ao iniciar o ADMT:
http://support.microsoft.com/kb/2266373









É necessária uma relação de confiança entre os domínios, onde contoso.internal pode se autenticar no domínio fabrikan.internal, mas fabrikan.internal não pode se autenticar em contoso.internal:
As relações de confiaça são realizads através do Active Directory Domains and Trust.

Acessar o ADMT e ir à opção “User Account Migration Wizard”

Seleciono o “Source” que é o domínio que posssui os objetos a serem transferidos, é o “Target” o target é o Domínio receberá os objetos transferidos:

Selecionar os usuários:

Clicar em ADD e selecionar os usuários:

Selecionar onde vou armazenar os objetos:

Tenho a opção de gerar novas senhas ou manter as existentes:

Opções para o estado da conta e SIDs, isso é muito importante, como estou fazendo em um ambiente de teste deixei as opções padrão:

Avançar - avançar.

Completando a migração:

Resultado dois usuários transferidos:

Isso só foi um exemplo, de como transferir contas de usuários, o ADMT é uma ferramenta poderosa, indispensável em cenários onde é necessário transferir objetos do AD.

VMware vCenter Server Appliance

Nas versões anteriores do vSphere (4.1 e abaixo) o vCenter era suportado apenas por Sistemas Operacionais Windows, com a introdução da versão 5 a VMware lançou um “Appliance” do vCenter baseado no Linux, resolvi testar e achei legal a iniciativa da VMware, inicialmente é necessário baixar o Appliance no site da VMware:
https://my.vmware.com/web/vmware/downloads
Após baixar é necessário efetuar o Deploy do Template, no Client do vSphere :
File - Deploy OVF Template...

Efetuar as configurações necessárias.
Após iniciar a VM as informações de acesso estaram disponíveis no console:

A configuração inicial é feita através do navegador, é bem simples, após efetuar as configurações é possível acessar através do Client do vSphere.
Na minha opinião é uma solução bem interessante, principalmente em ambientes pequenas, na verdade é uma solução para ambientes pequenos, mais informações:

http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc_50%2FGUID-25FCBA87-5D2F-4CB6-85D7-88899B4AC174.html

The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine IIS 7

Adicionei uma aplicação (ASP.NET) no IIS 7 (SO Windows 2008 R2), mas ao buscar certos recursos era apresentando o erro abaixo:

System.InvalidOperationException: The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.

Para resolver editei o\os respectivos ApplicationsPools (Opções Avançadas) e habilitei a opção "Enable 32-Bit Applications", habilitando a execução de aplicações 32 bits no ApplicationPool

A Good Time Server could not be located

Ao executar o DCDiag /test:FSMOcheck:

   Running enterprise tests on : meudominio
      Starting test: FsmoCheck
         Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
         A Time Server could not be located.
         The server holding the PDC role is down.
         Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 135
5
         A Good Time Server could not be located.
         ......................... meudominio failed test FsmoCheck

Este ambiente é um ambiente simples, dois controladores de domínio, o que eu fiz foi desregistrar o serviço de tempo do Windows, nos dois controladores de domínio, com os passos abaixo:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

O correto é o PDC sincronizar com um NTP externo, e as máquinas sincronizarem com o PDC da Floresta, as configurações do tempo do Windows ficam na seguinte chave de registro, campo TYPE:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Quando o campo Type tiver o valor NTP significa que a sincronização está sendo feita por um servidor NTP, quando tem o valor NTDS significa que a sincronização está sendo realizada pelo PDC da Floresta.
Resolvi meu problema com o predimento acima, claro isso vai depender do ambiente, em alguns ambientes o procedimento acima vai funcionar, outros não.

Vmware ESXi 5.1 iniciar automaticamente as VMs

Por padrão os hosts Vmware ESXi não iniciam as VMs automaticamente (levando em conta que você não tem o HA habilitado, entre outros recursos), vamos descrever um cenário bem básico, onde o administrador tem apenas um host ESXi, e deseja que as VMs sejam inicializadas automaticamente, caso o host(máquina fisica) seja ligado\reiniciado, para isso basta acessar o host através do VClient e na aba "Configuration" acessar a opção "Virtual Machine Startup/Shutdown", conforme print abaixo:

Basta configurar as opções desejadas, caso acha diversas VMs é bom ficar atento a ordem para inicializar as máquinas. Também é possível configurar o desligamento da máquina.

Unable to connect to the NETLOGON share!

Ao executar a ferramenta dcdiag nos controladores de domínio recebia a seguinte mensagem:

Unable to connect to the NETLOGON share!

O compartilhamento administrativo NETLOGON não estava disponível, isso ocorreu depois de ser efetuado um restore autoritativo do AD, para resolver este problema executei os seguintes procedimentos:

- Parei o serviço de replicação em todos os controladores de domínio.
- No controlador de domínio “principal”, especifiquei o valor D4 na seguinte chave de registro “BurFlags”:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\ BurFlags

Este controlador de domínio replicará as informações para os outros;
- Nos outros controladores de domínio adicionar o valor D2

Para o processo ter sucesso é necessário que exista uma pasta chamada SCRIPTS no seguinte caminho:
%\Windows\SYSVOL\sysvol\seudominio
Nos DCs é necessário que exista duas pastas dentro do “seudominio” Polices e SCRIPTS, se tiver qualquer outra coisa é necessário mover\apagar.
Após estes procedimentos é necessário inicar o serviço de replicação, o processo é iniciar o serviço a partir do controlador de dominio principal, o qual foi especificado o valor D4.
Depois testei novamente o NETLOGON:

 C:\dcdiag /test:netlogons
  Starting test: NetLogons
     ......................... MeuServidor passed test NetLogons

Mais informações:
http://support.microsoft.com/kb/290762

Adprep could not contact a replica for partition DC=DomainDnsZones

Ao executar o comando adprep /rodcprep recebia a seguinte mensagem (Levando em conta que meu dominio é contoso.internal) :

"Adprep could not contact a replica for partition DC=DomainDnsZones,DC=contoso,DC=internal"

Li alguns artigos de como resolver esse problema, mas achei a maioria “complexa”, e com muitos passos, quando fui consultar o DNS observei que a partição DomainDnsZones e ForestDomainZones não estavam presentes, ao consultar através do ADSedit e do ntdsutil a partição estava presente. Um exemplode através do ntdsutil:

C:\Windows\system32>ntdsutil
ntdsutil: Ac in ntds
Active instance set to "ntds".
ntdsutil: partition management
partition management: connections
server connections: Connect to server meuservidor
Binding to meuservidor ...
Connected to meuservidor using credentials of locally logged on user.
server connections: quit
partition management: list
Note: Directory partition names with International/Unicode characters will only
display correctly if appropriate fonts and language support are loaded
Found 5 Naming Context(s)
0 - CN=Configuration,DC=contoso,DC=internal
1 - CN=Schema,CN=Configuration,DC=contoso,DC=internal
2 - DC=contoso,DC=internal
3 - DC=DomainDnsZones,DC=contoso,DC=internal
4 - DC=ForestDnsZones,DC=contoso,DC=internal

Para resolve este problema removi a partição DomainDnsZones e ForestDnsZones, é possível remover a partição através do ntdsutil (delete nc) ou através do Adsedit. Com o Adsedit bastou remover dois registros, primeiramente conectar (Contexto "Configuration"):

 Acessar o caminho:

CN=Partitions,CN=Configuration,DC=contoso,DC=internal

Remover os dois registros DomainDnsZone e ForestDnsZone.

Após isso basta acessar o gerenciador do DNS e criar as partições:

Depois disso recebi a tão esperada mensagem:
C:\adprep /rodcprep
Adprep completed without errors. All partitions are updated. See the ADPrep.log
in directory C:\Windows\debug\adprep\logs\20121207144306 for more information.

An error occurred while processing the log for database 'model'

Utilizo o SCCM 2012, o SCCM utiliza o SQL Server 2008 R2, por algum motivo a database model corrompeu, e o serviço do SQL não iniciava mais, logo não conseguia mais acesso ao gerenciador do System Center, era apresentado o seguinte erro no log:

Erro:

An error occurred while processing the log for database 'model'.  If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.

Uma solução era restaurar o backup, mas como vou restaurar o backup se o serviço não iniciava?. A solução que encontrei foi a seguinte, renomear os aquivos model.mdf e model.ldf e copiei o template da base de dados model (model.mdf e model.ldf) localizados no seguinte caminho:

%caminho_install%Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\Templates

Para o seguinte caminho:

Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

Após o procedimento acima consegui iniciar o serviço do MS SQL normalmente.

Criando uma PSO (Fine-grained password)

Cenário:
Windows Server 2008 R2. Domínio: contoso.internal

Requisitos:
Nível funcional do Domínio Windows 2008 ou superior.

Objetivo:
Criar uma política de senha para o grupo de segurança “HelpDesk”.
Procedimentos:
Abrir a ferramenta adsiedit.msc
Efetuar a conexão:

Acessar o seguinte caminho:
DC=contoso,DC=internal
CN=System
CN=Password Settings Container
Criar um novo objeto msDS-PasswdSettings.
Adicionar os valores desejados.
Em CN atribute valor= Password_Custom – Avançar.
msDS-PasswordSettingsPrecedence valor=10 – Avançar.
msDS-PasswordReversibleEncryptionEnabled valor= FALSE Avançar.
msDS-PasswordHistoryLength valor= 6 Avançar.
msDS-PasswordComplexityEnabled (complexidade de senha) valor=true Avançar.
msDS-MinimumPasswordLength (Tamanho mínimo) valor=15 Avançar.
msDS-MinimumPasswordAge (Tempo mínimo da senha) valor=1:00:00:00 (Um dia) Avançar.
msDS-MaximumPasswordAge (Tempo de vida máximo da senha) valor= 45:00:00:00 (45 dias) Avançar.
msDS-LockoutThreshold valor=5 Avançar.
msDS-LockoutObservationWindow valor=00:00:10:00 Avançar.
msDS-LockoutDuration valor=00:00:15:00 Avançar.
Finalizar.
Abrir Active Directory User and Computers (modo avançado de visualização);
Acessar o seguinte caminho:
System – Password Settings Container, selecionar a “police” criada, ir em “Properties” e adicionar o valor msDS-PSOAppliesTo conforme print abaixo:

Após os procedimentos acima o grupo "HelpDesk" terá uma política de senha diferenciada.

0x80090016: Keyset does not exist

Ao tentar editar\criar uma tarefa agendada no Windows Server 2003 recebia o seguinte erro:

0x80090016: Keyset does not exist

Solução:

* Para o serviço "Task Scheduler".

* Excluir o conteúdo da pasta: "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18"

* Iniciar o serviço "Task Scheduler".