MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Pageviews 2017: 2661645
Pageviews 2016: 3991973
Pageviews 2015: 2675433
Pageviews 2014: 2664208
Pageviews 2013: 2399409
Pageviews 2012: 3209633
Pageviews 2011: 2730038
Pageviews 2010: 1470924
Pageviews 2009: 64608

Últimos posts

Categorias

Arquivo

Tags

Novo Azure AD Connect

Na semana passada a Microsoft liberou a nova ferramenta para sincronização de AD local com o Azure AD. Essa nova ferramenta tem as mesmas funcionalidades das anteriores DirSync e ADDSync, mas acrescesta facilidade na administração do serviço e acesso aos conectores.

Para baixar e ver detalhes: https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnect/

1-Resumo

Instalação e Upgrade do Dirsync

Para quem já tem o Dirsync ou o ADDSync instalado o Azure AD Connect irá fazer o upgrade e solicitar apenas a credencial do Azure para configurar, mas após o upgrade é possivel alterar facilmente as configurações.

A sequencia abaixo mostra o upgrade, sendo bem simples pedindo apenas as contas online e on-premisse:

2-Upgrade Dirsync

3-Conect

 4-Conect2

 5-Upgrade

Configuração Pós-Instalação

A interface do Azure AD Connect é realizada com ferramentas gráficas acessiveis pelo Menu Iniciar:

6-Iniciar

A ferramenta que torna mais fácil configurar como comentado no inicio do artigo é o Synchronization Service, onde ao abrir já é possivel ver os conectores habilitados, o estado da sincronização, log das ultimas sincronizações e utilitários na lateral:

7-Sinc Service

Por exemplo, para sincronizar manualmente basta clicar sobre uma das conexões e escolher como quer sincronizar (Connectors –> Run):

8-Sincronizarmanual

Visualização, Atualização e Criação de Conectores

Ao clicar em qualquer um dos conectores abre-se um wizard onde podemos alterar os conectores básicos ou criar novos conectores.

O wizard é muito simples e funcional, como mostram as imagens abaixo utilizando o Properties:

9-Conectores1

10-Conectores2

E para criar novos conectores, ao clicar em Create temos criar os diversos tipos de conectores on-premisse ou online utilizando o wizard das imagens acima.

11-Conectores3

Vale a pena fazer o upgrade para quem tem o Dirsync e o AADSync, pois esta nova ferramenta é muito completa e simples facilitando o acesso aos configurações, alterações e log das operações.

Posted: jun 29 2015, 12:18 by msincic | Comentários (0) RSS comment feed |
  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Integrando o System Center Orchestrator 2012 com o Active Directory

Anteriormente já iniciei alguns testes com o Orchestrator e se trata de uma excelente ferramenta (System Center Orchestrator 2012–Introdução)

A Microsoft disponibilizou a poucos dias (21/12/2011) um pacote para integrar tarefas de AD ao Orchestrator e ficou muito bom com tarefas como bloquear/desbloquear usuários e computadores, criar/editar/deletar usuarios, OUs, grupos e todas as outras tarefas conforme o print abaixo mostra a barra de ferramentas do Orchestrator Designer:

27-12-2011 12-18-10

Para instalar estas ferramentas é necessário baixar o pacote em http://www.microsoft.com/download/en/details.aspx?id=28020, fazer a importação do pacote de integração (arquivo com extensão OIP) e distribuir para os servidores desejados. Segue a ordem em que as atividades são realizadas, iniciando com o registro do Integration Pack:

27-12-2011 12-14-21

O passo seguinte é distribuir o Integration Pack para os servidores onde a tarefa será executada, lembrando que não tem a ver com os DCs e sim com os servidores que executam os RunBooks:

27-12-2011 12-15-43

Ao terminar estará registrado no servidor como mostrado abaixo e irá aparecer automaticamente no Orchestrator Design como mostrado na primeira imagem.

27-12-2011 12-16-32

Mais uma interessante funcionalidade a esta ferramenta que irá ser um importante aplicativo na nova familia de produtos System Center 2012.

Posted: dez 27 2011, 12:37 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Virtualizar Domain Controllers–Devo ou não?

Esta pergunta já ouvi inúmeras vezes. Em treinamento, palestras, emails e clientes sempre ouço a pergunta “Porque eu não posso virtualizar o Domain Controller?”

Esta semana em um grande cliente que atendo como consultor da Dell, alguns sites não permitiam logon, o Office Communicator não funcionava e outros problemas. Portanto, acho que este tema é bem apropriado com o crescimento dos ambientes virtualizados.

UPDATE: O Windows Server 2012 introduziu recursos próprios para virtualizar Domain Controllers sem as restrições com o NTP, porem a questão de logar no servidor Hyper-V pode continuar ativa.

Vamos começar com o fato concreto: Ninguem disse que não podem ser virtualizados, e sim que existem fatores a considerar. E é sobre isso que irei escrever.

Posso virtualizar todos os meus Domain Controllers?

Pode, mas terá sérios problemas de segurança e comprometer a réplica se o seu Domain Controller for Windows 2003.

Existem alguns pontos a se considerar ao pensar em virtualizar todos os servidores que podem ser consultados em http://support.microsoft.com/kb/888794/en-us quando vc ainda utilizar DCs com Windows 2000 ou Windows 2003.

Não é a toa que se recomenda ter os FSMOs em servidor fisico, mas falaremos disso daqui a pouco.

Porque virtualizar todos os Domain Controller compromete a segurança?

Neste caso temos duas opções, a primeira deixar o Hyper-V utilizando segurança SAM (local) ou ingressar ele no dominio da VM e as duas podem lhe trazer problemas.

A primeira opção é um sistema de segurança antigo, não baseado em Kerberos e fácil de se quebrar.

A segunda é o risco de ao ter uma queda das VMs ou um desligamento para manutenção ou energia o servidor do Hyper-V não aceitar logon e mostrar a mensagem “No Domain Controllers for Authentication”.

Porque não é recomendado virtualizar FSMOs?

Porque os FSMOs desempenham papeis importantes na estrutura, normalmente é o Global Catalog e tambem o NTP Server.

Caso seja virtualizado as FSMOs o servidor poderá ficar com problemas de sincronização de horários, replicação atrasada, etc.

Se ele estiver em uma VM e esta for desligada por um certo tempo o risco de estar com problemas de USN é maior ainda.

E o pior momento é se o host Hyper-V perder o relógio e atrasar o horário, gerando inconsistencias sérias no AD.

Esta discussão é antiga, desde o inicio do Hyper-V e pode ser acompanhada em http://blogs.technet.com/b/robse/archive/2008/06/16/dc-virtualized-and-external-ntp-servers.aspx

Qual o problema com o NTP Server?

O NTP Server tem a função de ser o sincronizador de horário nos dominios. A principio é feito pelo PDC Emulator.

Maquina fisicas mantem relógio por consultar o RTC (Real Time Clock) na BIOS que é baseado em cristal e após isso o SO passa a usar algoritmos logicos para manter o relógio.

O problema em VMs é que este algoritmo pode ficar comprometido por conta da carga, já que ele não é fisico e sofre interferencia conforme o weight definido para as operações, ou seja, irá atrasar ou adiantar.

Para evitar isso o Hyper-V faz a sincronização usando as Integrations Features, e ai ocorrem as desincronizações e os usuários não conseguem logar, aplicaçoes dão erro, etc.

Ai temos um problema, no documento “Running Domain Controllers in Hyper-V” (http://www.microsoft.com/download/en/details.aspx?id=20164) diz para desligar esta feature dos DCs virtuais.

Por outro lado o blog do PM de virtualização (http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx) diz para não fazer isso.

O problema é muito bem abordado pelo Ben Armstrong e é real. Uma maquina fisica mantem o relógio quando desligada (RTC), mas a virtual não, portanto se todos os DCs forem virtuais e esta opção estiver desabilitada em um desligamento eles irão retornar com o horário em que foram desligados, e quem irá atualizá-los?

Minha Recomendação Final

Siga as práticas do documento “Running Domain Controllers in Hyper-V”, mas sempre tenha um servidor fisico QUE NÃO SEJA O HOST DO HYPER-V.

Configure todas as máquinas, incluindo os hosts do Hyper-V para sincronizar com esta fisica usando Net Time /SetSNTP:<servidor> e assim não terá problema com o relógio, já que o próprio host irá sincronizar com o fisico e consequentemente as VMs com ele.

 

É isso ai, espero ter ajudado e qualquer acrescimo podem me enviar pelos comentários ou email.

Posted: jun 08 2011, 10:17 by msincic | Comentários (2) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: Virtualizaçao
Login