Comunidade Brasileira de AD

Instalando o RODC no Windows Server 2008 R2: Server Core

Este artigo irá demonstrar como instalar o RODC (Read Only Domain Controller) em um servidor com o Windows Server 2008 R2: Server Core.

Acredito que nesta altura do campeonato a maioria dos leitores já saibam o que é o RODC, mas só para explicar em poucas palavras para os que ainda não conhecem essa feature do Windows Server 2008, o RODC é um Domain Controller, como os demais, que autentica os usuários e computadores na rede onde ele se encontra, e é ideal para se instalado em escritórios remotos, onde não há uma infraestrutura adequada de segurança para a guarda do servidor.

Antes de instalar o primeiro RODC, precisamos validar alguns pré-requisitos de infraestrutura.

• Nivel de funcionalidade do domínio deve ser Windows Server 2003 ou superior.
• O domínio e a floresta devem ser preparados para o Windows Server 2008, rodando os comandos: 
      adprep /foresprep
      (http://technet.microsoft.com/en-us/library/cc753437(WS.10).aspx)
      adprep /domainprep /gpprep
      (http://technet.microsoft.com/en-us/library/cc754670(WS.10).aspx)
• Adicionalmente deve-se rodar o comando adprep /rodcprep para preparar o domínio Windows Server 2003 para receber o RODC.
      (http://technet.microsoft.com/en-us/library/cc771055(WS.10).aspx)
• Deve haver pelo menos um Domain Controller normal (Não-RODC) rodando o Windows Server 2008 no domínio.
• Aplicar o hotfix (KB944043) nos clientes (Windows XP, Windows Vista RTM) e servidores Windows Server 2003  http://support.microsoft.com/kb/944043/en-us

Validados os pré-requisitos, mãos à obra:

Aqui vale uma observação, existem várias formas para implantar o RODC no domínio, aqui vamos apresentar a opção onde o próprio administrador instalará o RODC; .

Vamos para as atividades necessárias para subir o RODC, usando as credenciais de um administrador do domínio.

1. Instalar o Windows Server 2008 R2, no modo Server Core:
   
2. Configurar os opções básicas do servidor:
   O Windows Server 2008 R2 conta agora com uma ferramenta de configuração chamada SCONFIG que ajuda bastante na hora de realizar as configurações básicas, como Nome da Máquina, IP, DNS, etc…
   Em um outro post, dou várias dicas de configuração do Server Core, se precisar dá uma espiada lá (http://blogs.technet.com/brzad/archive/2009/07/15/instalando-o-hyper-v-no-windows-server-2008-server-core.aspx)
3. Promover o servidor a RODC/Instalar o DNS
   Para promover o servidor a RODC deve-se primeiro preparar um arquivo de respostas para ser usado com o comando DCPromo, uma vez que o Server Core não tem interface gráfica, não há como usar o assistente de promoção do DCPromo.
   
   Abaixo, segue um exemplo de um arquivo de respostas para promover um RODC e também instalar o DNS, copie e cole no notepad e lembre-se de substituir os valores destacados em vermelho:

   [DCInstall]
   ReplicaOrNewDomain=ReadOnlyReplica
   ReplicaDomainDNSName=<NOME.DO.DOMINIO>
   SiteName=Default-First-Site-Name
   InstallDNS=Yes
   ConfirmGc=Yes
   UserDomain=<NOME.DO.DOMINIO>
   UserName=*
   Password=*
   DatabasePath="C:\Windows\NTDS"
   LogPath="C:\Windows\NTDS"
   SYSVOLPath="C:\Windows\SYSVOL"
   PasswordReplicationDenied="Domain Admins"
   PasswordReplicationDenied="Enterprise Admins"
   PasswordReplicationAllowed=None
   DelegatedAdmin="Domain Admins"
   CriticalReplicationOnly=Yes
   SafeModeAdminPassword= <SENHA DO ADMIN LOCAL(MODO DSRM)>  RebootOnCompletion=No   

   Salve o arquivo como RODCInstall.txt

   Execute o comando: dcpromo /unattend:RODCInstall.txt

   Será solicitado o Login e senha de um usuário com privilégios de administrador do domínio.

   Após promovido o RODC, efetue um restart do servidor.

   Isto conclui a instalação do RODC usando a conta do administrador.

Vejamos agora como instalar o RODC com a conta de um usuário comum

1. Instalar o Windows Server 2008 R2, no modo Server Core
   (Idem anterior)
   
2. Configurar as opções básicas do servidor
   (Idem anterior)
   Importante: Para este modo de instalação do RODC o servidor deve permanecer em Workgroup.
   
3. Prepopular o RODC no Active Directory
   3.1 Criar o Site da localidade no Active Directory Sites and Services
   
   Abra o Active Directory Sites and Services, e crie um novo site
   
   
   Defina o nome do site, e associe-o com um Site Link
   
   
   Clique em Ok
    
     
   Neste cenário recomenda-se criar um objeto de subnet e associá-lo ao Site recém criado.
   
   3.2 Pre-popular o RODC no Active Directory Users and Computers
   
   No Active Directory Users and computers, clique com o botão direito em “Domain Controllers” e depois clique em “Pre-create Read-only Domain Controller Account…”
   
   Na tela “Welcome…” clique em Next.
   
   
   Na tela “Operation System Compatibility” clique em Next.
   
   
   Na tela “Network Credentials” clique em Next se você já estiver logado com uma conta que seja administrador do domínio, caso contrário selecione “Alternate credentials” e defina o usuário e senha para executar o wizard.
   
   
   Na tela “Specify the Computer Name” defina o nome de computador que será usado no servidor RODC
   
   
   Escolha o site que você criou no passo 3.1, e clique em Next
   
   
   Selecione os itens opcionais que desejar (Recomenda-se deixar "Dns Server” e “Global Catalog” selecionado) e clique em Next
   
   
   Na tela “Delegation of RODC Installation and Administration” defina o grupo de usuários que será usado para instalar e promover o servidor RODC e clique em Next.
    
   
   Na tela “Summary” reveja as configurações e clique em Next.
   
   
   Para concluir clique em Finish.
    
   
4. Promover o servidor a RODC / Instalar o DNS
   
   Para promover o servidor a RODC deve-se primeiro preparar um arquivo de respostas para ser usado com o comando DCPromo, uma vez que o Server Core não tem interface gráfica, não há como usar o assistente de promoção do DCPromo.
   
   Abaixo, segue um exemplo de um arquivo de respostas para promover um RODC pré-criado no Active Directory e também instalar o DNS, copie e cole no notepad e lembre-se de substituir os valores destacados em vermelho:

   [DCInstall]
   ReplicaOrNewDomain=ReadOnlyReplica
   ReplicaDomainDNSName=<NOME.DO.DOMINIO>
   SiteName=Default-First-Site-Name
   InstallDNS=Yes
   ConfirmGc=Yes
   UserDomain=<NOME.DO.DOMINIO>
   UserName=<NOMDE.DO.DOMINIO>\USUARIO_DELEGADO
   Password=*
   DatabasePath="C:\Windows\NTDS"
   LogPath="C:\Windows\NTDS"
   SYSVOLPath="C:\Windows\SYSVOL"
   CriticalReplicationOnly=Yes
   SafeModeAdminPassword= <SENHA DO ADMIN LOCAL(MODO DSRM)>  RebootOnCompletion=No   

   Salve o arquivo como RODC_Install.txt

   Execute o comando: dcpromo /UseExistingAccount:Attach /unattend:RODC_Install.txt
   
   
   Na tela “Windows Security” preencha a senha do usuário que foi delegado para a instalação do RODC e que faça parte do grupo definido na hora de pré-popular o RODC no Active Directory.
    
   
   Se tudo estiver certo a promoção do RODC deve começar conforme tela abaixo:
    

   Após promovido o RODC, efetue um restart do servidor.

   Isto conclui a instalação do RODC usando a conta de um usuário normal, que foi delegado para instalar e promover o RODC.

1. Pós Instalação (Opcional)
   
   Configuração do PRP(Password Replication Policy)
   Conforme dito no início deste artigo, por padrão o RODC não armazena em cache as senhas dos usuários, com isto, na eventual falha de comunicação entre o RODC e o DC “full” os usuários das localidades onde um RODC for instalado poderão ter problema para efetuar logon.
   
   Para que este comportamento não ocorra, deve-se habilitar o cache das senhas dos usuários da localidade para o respectivo servidor RODC.
   
   A maneira mais segura de fazer isto é criar um grupo de segurança para cada localidade, e habilitar o armazenamento de senha no respectivo servidor RODC apontando este grupo.
   
   Para fazer isto siga os seguintes passos:
   
   A) Crie um grupo de segurança no domínio que identifique bem a localidade, e a finalidade do grupo. (Ex: G_Pwdcache_Remoto poderia ser usado para indicar um grupo global (G), para fazer o cache da senha(Pwdcache) de usuários Remotos, que poderia ser substituido pelo nome da localidade.
   
   B) Abra o Active Directory Users and Computers, expanda a OU Domain Controllers, clique com o botão direito do mouse em cima do servidor RODC e selecione a opção Properties.
   
   
   C) Vá até a guia “Password Replication Policy” 
   
   clique no botão “Add”
   
   
   Selecione a opção “Allow…”, e clique em OK
   
   
   adicione o grupo “G_Pwdcache_Remoto” e clique em OK
   
   
   Atividade opcional:
   De volta à guia “Password Replication Policy”  é possível pre-popular as senhas dos usuários e computadores da localidade na base do RODC, para isso, clique em “Advanced”
   
   Na janela que se abre clique no botão “Prepopulate Passwords”
   
   
   Selecione os usuários/computadores que deseja pre-popular e clique em OK
   
   
   Na tela de confirmação, clique em “Yes”
   
   
   Para validar quais são os usuários/grupos que estão configurados no PRP, abra o prompt de comando e digite o seguinte comando:
   repadmin /prp view <hostname> allow
   substituindo o <hosntame> pelo FQDN do servidor RODC.

Isto conclui a instalação e configuração inicial de um RODC.

Um abraço e até a próxima!

Douglas O. Santos / José Renato Roda

Free E-Book: Introducing Windows Server 2008 R2

Download e-Book: Introducing Windows Server 2008 R2

A última versão do e-book Introducing Windows Server 2008 R2 está disponível para Download.

No livro é apresentada uma visão geral dos seguintes tópicos:

• instalação e configuração
• Hyper-V
• Remote desktop services e VDI
• AD
• File services
• IIS 7.5
• DirectAccess e NAP

[]s.
Ana Paula

O Misterioso Caso dos Registros DNS Apagados

O que aconteceu? Cadê os registros DNS que estavam aqui???…. Talvez, você já tenha passado por isso.

Neste post apresentamos um cenário de configuração dos parâmetros Aging e Scavenge do DNS associados à indisponibilidade de links para replicação de sites remotos. Esta pode ser uma das causas do desaparecimento de registros DNS, sem que haja uma explicação aparente.

Os tópicos I, II e III apresentam informações gerais sobre a configuração e processamento das atualizações dos registros DNS.

No tópico IV e V, o mistério do desaparecimento dos registros é desvendado.

Parte I – Configuração da Zona DNS – Aging e Scavenge

O servidor DNS Windows Server e as zonas DNS podem ser configurados para eliminar os registros desatualizados de forma automática e/ou manual. Durante o processo de scavenge, os registros obsoletos registrados dinamicamente são pesquisados na base do DNS e apagados. O processo de replicação entre os servidores assegura que a zona DNS mantenha a informação mais atualizada a cerca dos serviços.

Para que uma zona DNS seja atualizada pelo processo de scavenge é preciso configurar a zona com a opção “scavenge stale resource records”.

Os parâmetros de configuração da Zona DNS são:

• No-refresh interval: valor default – 7 dias

Período de tempo em que o registro dinâmico permanece na base sem renovar o timestamp do registro. Visa a redução do tráfego de replicação pela renovação do timestamp dos registros. Qualquer outra atualização é permitida, por exemplo, atualização de um endereço IP e é replicada para os demais servidores que hospedam a zona DNS.

• Refresh interval: valor default – 7 dias

Período de tempo em que o timestamp dos registros pode ser atualizado. Assim que o cliente atualiza o timestamp, o período de no-refresh inicia novamente e o registro é replicado para os demais servidores que hospedam a zona DNS. Se o cliente não atualizar o registro durante o refresh interval, o registro é considerado obsoleto e elegível a ser apagado pelo processo de scavenge.

Parte II – Configuração do Servidor DNS

O processo de scavenge em uma zona DNS para eliminação dos registros pode ser realizado pelo servidor DNS de forma manual ou automática.

Importante: Se a zona não estiver configurada com a opção “scavenge stale resource records” nenhum registro será apagado pelo processo de scavenge.

Para configurar o scavenge automático marque a opção “Enable automatic scavenging of stale records” nas propriedades avançadas do servidor DNS.

Parte III – Atualização dos registros DNS

Os registros DNS dinâmicos criados em D1 durante o intervalo de non-refesh (default 7 dias) não atualizam o timestamp. Após esse intervalo, inicia o período de refresh interval (default 7 dias), no qual o registro poderá atualizar automaticamente o timestamp. Caso o timestamp não seja atualizado ao final do intervalo de refresh, o registro é considerado obsoleto, e é candidato a ser apagado quando o processo de scavenge for executado dentro do periodo de scavenging.

Parte IV – Cenário do Desaparecimento dos Registros DNS

Na reconstrução do caso encontramos o seguinte cenário:

• domínio: contoso.com
• 3 DCs/DNS – S01, S02 e S03
• 2 sites – DefaulSite e RemoteSite

O servidor registrou automaticamente no DNS (S01) ip 192.168.10.50 com timestamp D1. Através do mecanismo de replicação do AD, o registro foi atualizado (ou adicionado) a base do AD dos servidores DNS (S02 e S03). Durante o non-refresh interval o timestamp do registro não será atualizado.

Após o non-refresh interval, o servidor pode atualizar o timestamp. Porém o link com o site remoto não está disponível. Por exemplo, o servidor atualiza o registro com timestamp D9. Através do mecanismo de replicação do AD, o timestamp do registro foi atualizado a base do AD dos servidores DNS (S01 e S02), exceto nos servidores que estão em sites remotos sem link (S03).

Quando o processo de scavenge rodar no servidor do site remoto (S03), o registro será considerado obsoleto e apagado (tombstoned = true). Se este processo rodar, por exemplo, em D10, o registro será atualizado com timestamp D10. No servidor S03 timestamp do registro (D10) será mais recente que nos demais servidores (D9). Se o link for reestabelecido antes que o servidor entre no periodo de refresh, o timestamp do servidor no site remoto (S03) prevalece e o registro será apagado (tombstoned) nos demais servidores (S01 e S02) pelo mecanismo de replicação do AD.

Parte V – Configuração do DNS Scavenge para lidar com falhas de replicação

Para lidar com este cenário, a zona DNS precisa ser configurada para que o processo de scavenge rode em um ou dois servidores que estejam bem conectados à rede. É preciso evitar que o processo seja executado em sites remotos suscetíveis a indisponibilidade de links por períodos prolongados.

O utilitário DNSCMD permite que seja feito um ajuste na configuração da zona DNS e os servidores que serão candidatos a remover os registro obsoletos quando o processo de scavenge (manual ou automático) for executado.

http://technet.microsoft.com/en-us/library/cc756116(WS.10).aspx#BKMK_33

Dnscmd zoneresetscavengeservers

Changes the IP address(es) of the server(s) that can scavenge the specified zone.

Syntax

dnscmd [ServerName] /zoneresetscavengeservers ZoneName [ServerIPs]

Parameters

ServerName – Specifies the DNS server the administrator is planning to manage, represented by local computer syntax, IP address, FQDN, or Host name. If omitted, the local server is used.

ZoneName – Identifies the zone to scavenge.

ServerIPs – Lists the IP address(es) of the server(s) that can perform the scavenge. If this parameter is omitted, then all servers hosting this zone can scavenge it.

Remarks

• By default, all servers hosting a zone can scavenge that zone.
• If a zone is hosted on more than one DNS server, this operation can be used to reduce the number of times a zone is scavenged.
• Scavenging must be enabled on the DNS server and zone affected by this operation.

Sample Usage

dnscmd s01 /zoneresetscavengeservers contoso.com 192.168.10.1

Importante

A configuração dos servidores de scavenge para uma zona DNS deve ser feita em um servidor e replicada para os demais.

Com o utilitário DNSCMD podemos verificar a configuração da zona em cada servidor.

Syntax

dnscmd [ServerName] /zoneinfo ZoneName

Referências

How DNS works

http://technet.microsoft.com/en-us/library/cc772774(WS.10).aspx

Don't be afraid of DNS Scavenging. Just be patient.

http://blogs.technet.com/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

[ ]s e um ótimo feriado!!!

Ana Paula M Franco

System Center Virtual Machine Manager R2 – Dicas de Power Shell

No segundo dia de Tech-Ed 2009 eu fiz uma demo de Power Shell e foi uma surpresa muito grande ver que vários profissionais de TI achavam que PS era mais difícil que VBscript e outras importantes ferramentas e o legal foi ver no final (pelo número de fotos da tela da palestra) e pelos feedbacks que o PS agradou e por isso eu postei no meu blog um guia para você começar a trabalhar com o Power Shell e VMM R2.

Acesse o post aqui: http://blogs.technet.com/robsonsilva/archive/2009/09/01/scvmm-r2-dicas-de-power-shell.aspx

 []s

Robson Silva

Comparando C# com PowerShell no Desenvolvimento de Scripts

Windows Server 2008 R2 RTM saiu do forno!!!

A Microsoft anunciou no blog do Windows Server e de Virtualização o lançamento do Windows Server 2008 R2 RTM, e também do Hyper-V Server 2008 R2 RTM (solução FREE de virtualização em servidor Hyper-V).

O que significa RTM?

Significa Release to Manufacturing, e quer dizer que o produto está pronto, recebeu o aval do time de engenheiros da Microsoft, saiu da fase de testes e agora entra em “linha de produção”.

Quando vou poder baixar/instalar esta versão final do Windows Server 2008 R2?

Esta versão estará disponível para download na primeira quinzena de Agosto. Eu arrisco dizer mais ou menos entre o dia 06 e o dia 16 de Agosto, que é a data oficial do lançamento do Windows 7 para alguns canais específicos. Digo isto por que a expectativa é que os dois produtos sejam lançados juntos.

O que muda no Windows Server 2008 R2 RTM?

Isto é assunto para outro tópico mas só para citar algumas coisas e dar um gostinho do que vem por aí:

• Hyper-V and Live Migration – Um dos recursos mais aclamados no R2. Permite mover máquinas virtuais entre servidores físicos sem causar indisponibilidade para os clientes conectados ao servidor.
  
  Dentre outras novidades do Hyper-v destacam-se também:
• suporte para até 64 processadores lógicos
• suporte para até 384 máquinas virtuais
• Melhorias de rede (suporte a redes 1Gb/E e 10Gb/E com suporte a Jumbo Frame, Chimney e Virtual Machine Queue -VMQ)
• Melhorias de disco
• Live Migration entre servidores com processadores diferentes
• Virtualização de desktops
• Adição/Remoção de Storage virtual à quente
• SCONFIG para a configuração no server core
• File Classification Infrastructure – A Infraestrutura de classificação de arquivos permite que você gerencie seus dados baseados em características, incluindo coisas como o tipo de arquivo, credenciais dos usuários e até pelo conteúdo do arquivo. Baseado neste tipo de critério o FCI pode atribuir diferentes restrições de acesso, armazenar em diferentes localizações ou aplicar um esquema de ciclo de vida customizado. Tudo automatizado via política.
• Active Directory and Pervasive PowerShell - 240 novos comandos PowerShell e várias novas consoles de gerenciamento, incluindo uma nova interface para o Active Directory)
• Enhanced Active Directory Recycle Bin – Houveram melhorias na “lixeira” do Active Directory
• Enhanced AD Group Policy – Novas políticas de grupo, especialmente para o gerenciamento do Windows 7.
• IIS 7.5 – A última versão do IIS (Internet Information Server) com ferramentas de gerenciamento atualizadas, bem como novas funcionalidades como suporte a PHP e .NET em instalações no Server Core.
• Server Scalability – O Windows Server 2008 R2 é o primeiro sistema operacional da Microsoft que é puramente 64-bit, e suporta até 256 processadores lógicos em um único servidor, e inclui suporte a tecnologias avançadas de storage com gerenciamento de SAN e discos SSD (Solid State Disc)
• Novidades no Hyper-V

É isso aí… como eu disse, é só para dar um gostinho, tem bem mais novidades vindo com esta versão.

Um abraço!

Douglas O. Santos

Instalando o Hyper-V no Windows Server 2008: Server Core

Criei este procedimento para ajudar aqueles que precisam instalar o Hyper-V em um servidor Windows Server 2008 (Standard/Enterprise) no modo Server Core, que como todos devem saber não tem interface gráfica de administração.

Depois demonstro como preparar o servidor para permitir conexão remota para a administração do Hyper-V através de uma console gráfica instalada em um computador com o Windows Vista.

Importante: A versão R2 do Windows 2008 trará uma ferramenta nova chamada SCONFIG, que facilitará a configuração do servidor e do Hyper-V.  
Veja maiores informações no blog do Jeff Woolsey, que é program manager do Hyper-V na Microsoft. (http://blogs.technet.com/virtualization/archive/2009/07/07/windows-server-2008-r2-core-introducing-sconfig.aspx)

Logon inicial

1. Pressione CTRL + ALT + DEL para logar-se e trocar a senha.Clique em “Other User”. Por padrão a primeira senha é em branco e o usuário se chama “Administrator”. Após logar-se um prompt de comando aparecerá na tela, o que indica que a instalação do Windows está concluída.

Alterando o nome do Servidor

1. Digite HOSTNAME no prompt de comando para obter o nome atual do servidor.

2. Depois digite o comando abaixo substituindo <nome_atual> pelo nome do servidor que você obteve com o comando HOSTNAME.

Netdom /renamecomputer <nome_atual> /NewName:<Nome_Servidor>

3. Reinicie o servidor digitando o comando abaixo:

Shutdown /r /t 0

4. Após reiniciar, para verificar se o nome ficou correto digite novamente o comando HOSTNAME no prompt de comando.

Configurando o IP Fixo da máquina

1. Digite IPCONFIG para obter o nome das interfaces de rede do servidor. Anote o nome da interface a qual você irá configurar.

2. No prompt de comando do Servidor digite o comando abaixo para configurar o IP com os seguintes dados:

ID: <”Nome da interface a ser configurada”>
IP:  <X.Y.W.Z>
Subnet Mask: <M.A.S.K>
Default Gateway: <G.A.T.E>
DNS Server: <D.N.S.S>

netsh interface ipv4 set address  name="Nome da interface a ser configurada" source=static address= X.Y.W.Z  mask= M.A.S.K  gateway= G.A.T.E

Exemplo: Se a interface a ser configurada for a de nome: “Local Area Connection 2” e os dados fossem: IP: 192.168.1.10, SM: 255.255.255.0, GTW: 192.168.1.1, então comando fica assim:

netsh interface ipv4 set address name=" Local Area Connection 2" source=static address=192.168.1.10 mask=255.255.255.0 gateway=192.168.1.1

3. Para configurar o IP do servidor de DNS digite o comando abaixo, onde <ID> novamente é o nome da interface a ser configurada:

netsh interface ipv4 add dnsserver name="Nome da interface a ser configurada"  address= D.N.S.S  index=1

4. Para verificar se a configuração da placa de rede ficou correta, digite IPCONFIG /ALL

5. Se houverem outras placas a serem configuradas, repita os passos 1, 2 e 3 acima para as demais interfaces de rede.

Adicionando o Servidor ao Domínio

1. Para adicionar o servidor ao domínio digite o comando abaixo substituindo <username> pelo nome de um usuário do domínio com privilégio de adicionar computadores ao domínio, e substitua o <Nome_do_dominio>  pelo domínio atual.

netdom join Nome_Servidor /domain: Nome_do_dominio /userd:< username > /passwordd:*

Em seguida digite a senha da conta usada acima.

2. Reinicie o servidor digitando o comando abaixo:

Shutdown /r /t 0

3. Após reiniciar o servidor, logue-se com o usuário administrador do domínio.

Ativando o servidor

1. No prompt de comando digite o seguinte comando:

slmgr.vbs –ato

Se a ativação ocorrer com sucesso, nenhuma mensagem aparecerá na tela.

Aplicando atualizações de segurança

Você precisa aplicar o SP2 do Windows 2008 ou updates de segurança descritos abaixo, em ambos os casos você precisa fazer o download e copiar no servidor para poder instalá-los:

Service Pack 2 (http://www.microsoft.com/downloads/details.aspx?FamilyID=656c9d4a-55ec-4972-a0d7-b1a6fedf51a7&displaylang=en)

OU os cinco updates abaixo(que estão incluídos no Service Pack 2)

KB950050 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f3ab3d4b-63c8-4424-a738-baded34d24ed)
KB956589 (http://www.microsoft.com/downloads/details.aspx?FamilyID=FD44B4E3-2DCC-4299-B345-BC09A9A37B60&displaylang=en)
KB956710 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=fe36823a-7e5a-4262-9bf5-d6b3ae3ad375)
KB956697 (http://www.microsoft.com/downloads/details.aspx?familyid=5EB76BDA-8794-412A-9FD4-1BCCBBC34C82&displaylang=en)
KB956774 (http://www.microsoft.com/downloads/details.aspx?familyid=9EC9DBB9-82AD-4D34-9267-76A0126A8F18&displaylang=en)

Para instalar cada update execute o commando abaixo:

wusa.exe <nome do arquivo.msu> /quiet

Configurando o firewall do servidor para permitir gerenciamento remoto

1. No prompt de comando digite os seguintes comandos:

Para habilitar gerenciamento remoto do Firewall:
netsh advfirewall set currentprofile settings remotemanagement enable

Para habilitar o gerenciamento remoto via MMC das principais ferramentas administrativas:
netsh advfirewall firewall set rule group="Remote Administration" new enable=Yes

Netsh advfirewall firewall set rule group=“Remote Volume Management” new enable=yes

Netsh advfirewall firewall set rule group=“Windows Firewall Remote Management” new enable=yes

Para habilitar o gerenciamento remoto via Terminal Server:
Cscript C:\Windows\System32\ Scregedit.wsf /ar 0

Para habilitar o gerenciamento remoto via Prompt de comando:
WinRM quickconfig

Instalando e Habilitando o recurso HYPER-V

1. No prompt de comando do servidor digite o seguinte comando: (Atenção, o comando é case sensitive)
Start /w ocsetup Microsoft-Hyper-V

Clique em “Yes” para reiniciar o sistema.

Gerenciando remotamente o HYPER-V através do Windows Vista

Após instalado o Rule Hyper-V, você poderá administrá-lo remotamente via um console MMC instalado em um Windows Vista.

Para instalar o MMC no Windows Vista, baixe o instalador de acordo com a plataforma que você está usando (X86 ou X84) nos links abaixo:

KB952627 – Vista 32 bits (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bf909242-2125-4d06-a968-c8a3d75ff2aa)

KB952627  - Vista 64 bits (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=88208468-0ad6-47de-8580-085cba42c0c2)

Se você aplicou o SP2 do Windows Vista, precisará também aplicar o seguinte update no Windows Vista.

KB970203-Vista 32bits (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=551a9b83-241b-4e86-b329-441374ddcf23)

KB970203-Vista 64bits (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d826c426-9690-4ca8-82ba-25f60f1057f6)

Conectando-se ao Servidor Hyper-V remotamente

Após instalada a ferramenta de administração no Windows Vista, abra o console e conecte-se ao servidor Hyper-V:

Abraços,

Douglas O. Santos

Microsoft IT Environment Health Scanner

No site de downloads foi publicada uma ferramenta diagnóstico para avaliação da saúde do Active Directory e da infra-estrutura de rede - Microsoft IT Environment Health Scanner.  A ferramenta com foco em pequenas e médias empresas é recomentada para até 20 servidores e 500 estações.

As informações coletadas são:

• configuração de sites e subnets no AD;
• replicação do AD;
• resolução de nomes DNS;
• configuração de rede dos DCs (Domain Controllers), servidores DNS e Exchange;
• configuração NTP (Network Time Protocol) de todos os DCs;
• saúde dos DCs.

Se algum problema é encontrado, a ferramenta descreve o problema, severidade e alguns links da base do suporte (KB) para ajudar na solução. Os relatórios podem ser armazenados para revisão posterior.

A ferramenta não faz nenhuma alteração na configuração do ambiente e precisa ser executada com as credenciais de Domain Admin. A coleta de informações é realizada através de WMI e utiliza as portas 135, 445 e portas dinâmicas no range 1024 a 1034.

Download:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dd7a00df-1a5b-4fb6-a8a6-657a7968bd11

[]s

Ana Paula M Franco

Contas de Usuário e Grupos Referenciados em Permissões

Certamente você já se perguntou, será que uma determinada conta de usuário ou grupo é referenciado em permissões nos servidores?

O relatório Account References do ADMT – Active Directory Migration Tool – pode ajudar neste cenário. Contém a lista de todas as contas referenciadas nas permissões.

Para gerar o relatório basta selecionar o Reporting Wizard, e seguir o passo a passo até a seleção dos computadores a serem analisados.

Durante o pre-check são realizados os seguintes testes:

usuário é membro do grupo administrador local nos computadores; ping – nome DNS ou NETBIOS do computador; domain membership – se o computador é membro do domínio; server service – testa se o usuário pode ser autenticado na estação; admin$ share – se está disponível e o usuário tem acesso; espaço em disco – 10MB espaço livre ADMIN$ para instalação do agente do ADMT;

Aguarde em outro post, como descobrir quais são as contas referenciadas no IIS e serviços.

[ ]s.
Ana Paula M Franco

Starter GPO

O Windows Server 2008 tem uma nova divisão chamada Starter GPO dentro do Group Policy Management Console (gpmc.msc). Dentro do Starter GPO podemos criar e guardar modelos de Group Policies que podem ser usadas como base para novas GPOs.

Criando um modelo novo:

1) Abra o Group Policy Management Console.

2) Clique com o botão direito em Starter GPO e selecione New.

3) Digite o nome do seu modelo e algum comentário. Clique no botão OK. Você verá que um novo objeto será criado.

4) Clique em cima do novo objeto com o botão direito e selecione Edit. O Group Policy Starter GPO Editor deverá abrir.

5) Faça as modificações para criar o modelo e então feche o Group Policy Starter GPO Editor. Na imagem abaixo, modifiquei para enable o Remove Run From Start Menu, que se encontra em User Configuration >Administrative Template > Start Menu and Taskbar.

Voltando ao Group Policy Management Console, quando expandimos o modelo novo abaixo de Starter GPO, veremos que as modificações feitas no Group Policy Starter GPO Editor serão listadas.

Ao criarmos uma Group Policy nova, teremos a opção de usar o modelo criado. Na imagem abaixo, dei o nome de Run Blocker para meu modelo.

Podemos também exportar e criar cópias de segurança do modelo. Para mais informações, consulte http://technet.microsoft.com/en-us/library/cc753200.aspx

Muito obrigada,

PAULA MAEDA

Migração de Samba para Active Directory

Conseguimos provar em Laboratório que é possível realizar uma migração de um diretório baseado em Linux (Samba) para Active Directory, sem desenvolver nenhum tipo de script para importar as informações de um ambiente para o outro. E melhor, sem gerar impactos para o usuário!

Utilizando a ferramenta ADMT 3.0 conseguimos migrar todos os objetos para o Active Directory, baseado em Windows Server 2003.

Nota: Não conseguimos sucesso na utilização da versão 3.1 da ferramenta ADMT para migrar os objetos do Samba para um Active Directory baseado em Windows Server 2008. Portanto, crie um AD baseado na versão Windows 2003 e use o ADMT 3.0. Após a finalização da migração e término da convivência dos ambientes Samba e AD, atualize o AD para a versão 2008.

Considerações importantes para uma migração aonde o domínio de origem é um Samba emulando um PDC NT:

1. No Samba, deve-se criar um usuário chamado “Administrator”, com as mesmas permissões do usuário “root”, e com a mesma senha do usuário Administrator do domínio de destino;
2. Para que as estações possam ser migradas, a propriedade “DNS Suffix for this Connection” (em Advanced/DNS) deve estar em branco;
3. As senhas dos usuários não podem ser migradas do Samba;
4. O SIDHistory no domínio de destino não pode ser populado (A funcionalidade “tcpipclientsupport” não está disponível no Samba. Com isso, a migração dos SID’s torna-se inviável);
5. Durante a fase de Convivência dos ambientes, devemos manter a Relação de Confiança aonde o Active Directory confia no Samba.

Para contornar o problema da migração dos SID’s, devemos utilizar uma funcionalidade da Ferramenta ADMT que se chama “Conversor de Segurança”. Esta funcionalidade, basicamente, analisa o sistema operacional em busca de permissões atribuídas a usuários do domínio antigo. Os objetos analisados são:

• Arquivos e Pastas
• Grupos Locais
• Impressoras
• Registro
• Compartilhamentos
• Perfis de Usuário
• Direitos de Usuario

Para entender como esta funcionalidade funciona, devemos antes analisar a migração de usuários e grupos. O ADMT, no momento da migração entre domínios, cria um banco de dados local que associa as contas do domínio antigo com as do domínio novo, conforme exemplo abaixo:

OBS: O mesmo princípio vale para os grupos.

No momento da migração de um computador (seja ele uma estação de trabalho ou um servidor de arquivos), o ADMT envia um agente para o mesmo, e com isso, antes de inserir o computador no novo domínio, o agente analisa todos os objetos citados anteriormente. Ao analisar um objeto qualquer:

1. Analisa a sua ACL e coleta os usuários que possuem permissões;
2. Busca no banco de dados do ADMT quem são os novos usuários (do novo domínio) associados a estes usuários do domínio antigo;
3. Espelha as permissões NTFS do usuário antigo ao usuário novo.

Nota: O Conversor de Segurança não funciona para objetos Built-In do domínio antigo (ex: Domain Admins, etc).

Estratégia para Migração

Nesta estratégia, a ordem de migração do ambiente deve ser:

1. Todos os Objetos do Samba para o Active Directory;
2. Migração de todos os Serviços de Rede (Servidores de Arquivos, Aplicações, etc) para o Active Directory;
3. Migração das estações de trabalho.

Fase de Convivência dos 2 Ambientes

Durante esta fase, os usuários continuarão logando em suas estações com os usuários antigos (Samba). Os usuários continuarão acessando os servidores já migrados para o Active Directory normalmente. Isso é possível devido a relação de Confiança existente entre os 2 domínios, conforme a ilustração abaixo:

1. O usuário realiza a autenticação no domínio Samba;
2. O usuário tenta acesso ao servidor que está no domínio Active Directory;
3. O Servidor que recebeu a requisição verifica a credencial do usuário no domínio Samba, via Relação de Confiança;
4. Após verificação das credenciais, o acesso ao Servidor é liberado para o usuário.

Algumas Informações Importantes para a fase de Convivência:

• Qualquer usuário que for criado no ambiente deverá ser criado no domínio Samba, e depois ser migrado para o Active Directory via ADMT;
• Qualquer modificação em membros de grupos deve ser feita no domínio Samba, e depois realizar um “Merge” via ADMT do grupo Modificado;
• Toda migração deve ocorrer com o mesmo servidor ADMT, então recomendamos o Backup regular deste servidor.

Passos Necessários para Realizar a Migração

É importante ressaltar que todos os passos abaixo devem ser testados em laboratório antes de serem implementados em Produção!

1. Criar um usuário “Administrator” no domínio Samba, com a mesma senha do usuário “Administrator” do Active Directory, com as mesmas permissões que o usuário “root”;
2. Criar uma relação de Confiança aonde o Domínio Active Directory confia no domínio Samba;
3. Instalar o ADMT em um servidor que esteja no domínio Active Directory;
4. Migrar Grupos para o Active Directory via ADMT;
5. Migrar Usuários para o Active Directory via ADMT;
6. Migrar Servidores de Arquivos para o Novo Domínio via ADMT;
7. Migrar demais Serviços de Rede para o Novo Domínio Active Directory;
8. Após Migração de todos os serviços de Rede, migrar as estações gradualmente;
9. Após a Migração de todas as Estações, aguardar estabilização do ambiente;
10. Após estabilização, desfazer a Relação de Confiança;
11. Desligue o Servidor Samba!

Abraços;

Guilherme Taliba

Release Candidate do Windows 7 e Windows 2008 Server R2

A Microsoft anunciou hoje a disponibilização das versões RC1 do Windows 7 e do Windows 2008 Server R2 para os beta testers, o build do RC1 é o 7100.

Os novos builds trazem várias novidades em relação ao Beta e com isso alcançam uma marca importante no desenvolvimento dos produtos, que já estão entrando na reta final de testes.

A versão RC1 esta disponível para os assinantes do TechNet Plus e também os beta-testers que fazem parte do programa Microsoft Connect (http://connect.microsoft.com).

Também está disponível para dawnload no TechNet Plus, o Windows Virtual PC Beta com Windows XP Mode Beta que permite executar suas diferentes aplicações de Windows XP no seu Windows 7.

Para baixar os novos builds, acesse:

- Assinantes TechNet Plus : http://technet.microsoft.com/subscriptions/downloads/default.aspx (precisa ser assinante do TechNet Plus)

- Microsoft Connect : http://connect.microsoft.com (precisa ser cadastrado como beta-tester)

Abraços,

Eduardo Zarpelão

Teste de convivência : Exchange e QMail

Ontem conseguimos provar que o Exchange e o Qmail podem conviver utilizando o mesmo nome de domínio, para isso o hub deve processar todas as mensagens.

Para funcionar a convivência:

1. No servidor Exchange: Organization Configuration | hub transport

a. 1. Criar uma entrada em Accepted domain para "contoso.com" e configurá-la para Internal Relay

b. 2. Criar um SMTP Send Connector com Address Space "contoso.com"  que tenha um smarthost apontando para o outro sistema de e-mail (neste caso o Qmail = 10.10.0.1)

2. O usuário do Exchange deve manter dois endereços smtp: em Recipient Configuration | Mailbox,o email address de cada usuário deve conter:

a. Smtp da organização (contoso.com)

b. O endereço do smtp set as reply deve ser o contoso.com

3. Para aceitar o relay do QMail

a. Criar uma Receive Connector: Server Configuration | Hub Transport criar Receive Connector:

i. Nome: Qmail

ii. Local IP 10.10.0.3

iii. Remote IP 10.10.0.1

iv. Permission Groups : Anonymous

4. Para aceitar o smtp dos clientes QMail

a. Entrar em Server Configuration | Hub Transport | Receive Connectors

b. Selecionar o Default SRVExc

c. Em Permissions selecionar a opção Anonumous Users

5. Incluir o usuário do Qmail na Address List do Exchange

a. Receipient Configuration | Mail Contat | New Mail User

6. Para migrar usuários de Mail User para Mailbox User

a. Em Recipient Configuration | Mail Contact selecionar a conta e colocar em disable

b. Em Recipient Configuration | Mailbox incluir o novo usuário

7. Conversão do endereço de email externo

Abraço,

Jose Roda

Entendendo Windows Server 2008 DFS-N através da análise de network traces

Pessoal,

Esta semana o Jose Barreto publicou um artigo muito interessante sobre Windows Server 2008 DFS-N (Distributed File System – Namespaces) através de análise de network traces. O objetivo principal dele foi mostrar a interação entre os clientes DFS-N, um controlador de domínio, um servidor DNS e um servidor de arquivos. Estes traces foram obtidos através do Network Monitor 3.3 beta de um grupo isolado de computadores no domínio.

Veja os detalhes do post (incluindo tabelas, comentários e screenshots das telas) no link :

http://blogs.technet.com/josebda/archive/2009/04/15/understanding-windows-server-2008-dfs-n-by-analyzing-network-traces.aspx

Abraços,

Eduardo Zarpelão

Active Directory Domain Services in the Perimeter Network (Windows Server 2008)

O white paper “Active Directory Domain Services in the Perimeter Network (Windows Server 2008)” foi publicado no Technet.

O documento contempla informações para auxiliar no planejamento e implantação de RODCs (Read-only Domain Controllers) na DMZ:

• considerações relacionadas a segurança e configuração dos RODCs na DMZ;
• configurações de rede dos RODCs;
• compatibilidade de aplicações com RODCs na DMZ;
• passo-a-passo para auxiliar a adição de RODCs.

O artigo apresenta alguns modelos de implementação do AD. Após a leitura, pode ser que você descubra que outros softwares ou ferramentas provêm a solução que a sua empresa precisa, e a implementação de RODCs na DMZ não seja a melhor opção.

Pré-requisitos para RODCs:

• Forest functional level - Windows Server 2003 ou superior (LVR - linked-value replication);
• Domain functional level - Windows Server 2003 ou superior (Kerberos constrained delegation)

Boa Leitura!!
Ana Paula M Franco