Os arquivos da área de trabalhoInicializando o Windows em rede

Wes Miller

Conteúdo

Como o PXE funciona
Por dentro do RIS
WDS — o início
Outras partes envolvidas
Conclusão

Nos próximos meses, pretendo abordar o WDS (Windows Deployment Services), disponível para o Windows Server 2003 e incorporado ao Windows Server 2008. O WDS pode ser um componente muito importante na sua infra-estrutura de implantação. Por isso, quero garantir que você tenha uma boa base para o debate. Esta

primeira coluna traz detalhes sobre a arquitetura do PXE (Pre-boot eXecution Environment; pronunciado como pixie); a história do RIS (Serviços de Instalação Remota); e também outras tecnologias relacionadas ao PXE usadas na Microsoft.

Quando passei a integrar o grupo principal de sistema operacional do Windows, em 2001, o RIS foi uma das tecnologias que herdei (e fiquei um pouco intimidado em assumi-lo, devido à complexidade e à dependência em relação às implementações do BIOS e ao hardware). Mas foi, juntamente com o Windows® PE, uma das tecnologias que mais apreciei na minha função de gerente de programa.

Lembro-me da primeira vez que instalei o Windows 3.0 — usando um conjunto de disquetes de 3,5". Com o passar do tempo, a instalação tornou-se mais fácil, graças aos CDs inicializáveis (incluídos em algumas versões do Windows 98). Mesmo assim, a instalação sempre exigia algum tipo de mídia local, além de um disco rígido local.

Ao longo dos anos, a capacidade de inicializar o Windows em rede — ou seja, inicializá-lo totalmente via rede, sem precisar de um disco rígido — tem sido uma solicitação constante dos clientes. Embora algumas versões anteriores do Windows tivessem essa capacidade, o Windows NT® nunca teve. E, embora as versões atuais do Windows Server® 2003 e do Windows Server 2008 possam ser inicializadas por meio de um iniciador iSCSI, o processo é muito diferente, por não ser realmente local — requer uma dependência contínua de uma unidade remota, usada como unidade de inicialização.

Pré-configuração de clientes

• Avaliação do processo de pré-configuração do cliente RIS
• Planejamento do aprimoramento da segurança de rede com o uso de clientes pré-configurados
• Computadores clientes pré-configurados
• Instalação remota de sistema operacional

A partir do Windows 2000, a Microsoft começou a desenvolver a tecnologia que, por fim, viria a ser chamada de RIS, e que permitiria a instalação baseada em rede. A meta do RIS era relativamente simples: colocar uma imagem do sistema operacional no disco local do computador de destino usando o PXE.

Como o PXE funciona

A Figura 1 mostra a seqüência de inicialização PXE. O PXE é um protocolo relativamente simples, desenvolvido pela Intel e por outros fornecedores como parte da iniciativa Wired for Management. O PXE é derivado do protocolo DHCP, que deriva, por sua vez, do BootP, sendo tipicamente implementado na NIC (placa de interface de rede). Simplesmente, eis aqui o que acontece:

Figura 1. Seqüência de inicialização PXE (clique na imagem para ampliá-la)

Etapa 1. O BIOS do sistema é inicializado e determina a ordem de inicialização.

Etapa 2. Se a ordem de inicialização colocar o PXE à frente dos discos rígidos, unidades flash ou CD-ROMs, ou então se nenhum desses dispositivos estiver presente, a UNDI (interface de driver de rede universal) será carregada a partir da NIC. A NIC conta com um driver de dispositivo de rede muito pequeno e com uma implementação do protocolo TFTP (algumas implementações do BIOS exigem que os usuários finais pressionem a tecla F12 para fazer a inicialização PXE. Esse comportamento não é padrão e prefiro ter a possibilidade de desativá-lo).

Etapa 3. O sistema começa a fazer uma difusão simples no protocolo UDP, em busca de um servidor DHCP. Essa é, na verdade, a primeira etapa da seqüência de inicialização PXE, denominada Descoberta. Observe que o protocolo usado é o UDP — ou seja, se você ainda não fez isso, precisará dedicar algum tempo a seus roteadores e comutadores, para garantir que todas as comunicações do PXE cheguem ao destino.

Etapa 4. Se um servidor DHCP receber a difusão, responderá de forma adequada, com um endereço IP. Essa etapa é chamada de Oferta. Neste momento, é importante lembrar-se de que o PXE não tem monitoração de estado, e a quantidade de informações de estado exclusivas do sistema que o cliente tem a oferecer neste ponto é muito limitada (o endereço MAC e, se disponível, o GUID do BIOS de gerenciamento de sistema, também conhecido como GUID SMBIOS).

Etapa 5. O cliente, depois de receber o pacote com o endereço IP, declara que precisa de mais informações — especificamente, o endereço do servidor PXE. Ocorre outra difusão, incluindo as informações do servidor DHCP que havia respondido. Neste ponto, é como se o cliente dissesse ao servidor DHCP: "Preciso de mais informações — especificamente, a localização de um NBP (programa de inicialização de rede)." Essa etapa é chamada de Solicitação.

Etapa 6. O servidor PXE responde com o endereço do servidor PXE e a localização do NBP, um executável de inicialização muito pequeno, que precisa ter menos de 32 KB. Essa etapa é chamada de Confirmação. Se você está acompanhando a seqüência, repare que as etapas formam o acrônimo DORA (Discover, Offer, Request, Acknowledge, ou seja, Descoberta, Oferta, Solicitação, Confirmação), o que pode ajudá-lo a memorizá-la.

Se você instalou o Microsoft DHCP e o WDS (ou usou tecnologias de outro fornecedor), a etapa de solicitação não ocorrerá. Na verdade, o pacote original de Oferta do servidor DHCP já inclui a localização do servidor PXE e do programa NBP (isso elimina duas etapas, reduzindo também o tempo necessário).

Etapa 7. O cliente, que tem a pequena pilha de protocolos TFTP mencionada anteriormente, baixa o NBP da localização na rede especificada pelo servidor PXE. O TFTP é um protocolo datado, muito pequeno e sem monitoração de estado. Não foi escolhido por conta da segurança nem do desempenho; por isso, muitos administradores de roteadores o desabilitam por padrão. Ele deve ser habilitado para que o PXE funcione.

Muitas implementações do PXE (inclusive o RIS) incluem a capacidade de solicitar ao usuário que pressione F12 para continuar, neste ponto, mas geralmente isso pode ser desabilitado pelo administrador do servidor PXE. No mês que vem, quando entrar em mais detalhes sobre o WDS, explicarei alguns aprimoramentos que a Microsoft acrescentou ao TFTPD (TFTP Daemon) no WDS para Windows Server 2008, a fim de obter melhor desempenho.

Etapa 8. O NBP é inicializado. No caso do RIS, isso aciona um carregador de inicialização do Windows, que dá início ao processo para levar a implantação adiante. O PXE (pelo menos o atual protocolo em nível de inicialização) não é mais um componente do processo.

É importante lembrar-se de que o PXE (seja com RIS, WDS ou qualquer outra infra-estrutura) não funciona bem em links lentos (pois pode transferir volumes consideráveis de dados) nem em links de alta latência, como satélites (o desempenho da comunicação simplesmente não é suficiente, e talvez nem consiga se manter).

Observe que, no processo de inicialização PXE, quando o cliente envia a solicitação, nenhum elemento pergunta especificamente: "Você é minha mãe?" Simplesmente, não há muitas informações de estado que se possa obter sobre o servidor PXE. O que geralmente ocorre é uma condição de corrida, na qual o primeiro servidor a responder à solicitação do seu cliente sairá vencedor. Algumas coisas podem ajudar a minimizar esse problema:

• Ajuste a velocidade de resposta de um ou outro servidor PXE. A latência da rede e a potência dos servidores afetarão a velocidade de resposta dos servidores. Na verdade, na Microsoft, os servidores usados pela TI eram tão bons que, mesmo se o servidor PXE estivesse no seu escritório, os servidores corporativos algumas vezes saíam vencedores. Nesse caso, basta ajustar o seu servidor PXE local para não ter nenhum tempo limite para os seus clientes pré-configurados.
• Pré-configure os clientes. Isso será muito importante se você manipular seu servidor PXE para responder antes dos outros servidores de TI corporativos. Pré-configurando seus clientes, você permite que o Active Directory® informe ao WDS ou ao RIS que sim, na verdade, "eu sou sua mãe". Observe que o uso do GUID SMBIOS é a forma preferida de identificação exclusiva dos sistemas no Active Directory. No entanto, se não houver um GUID SMBIOS implementado nos sistemas (o que é mais provável em hardware relativamente antigo), você poderá (e precisará) usar um GUID baseado no endereço MAC. Para obter mais informações, consulte a barra lateral "Pré-configuração de clientes".
• Não permita que as comunicações do PXE passem por comutadores ou roteadores; coloque um servidor PXE de cada lado. O aspecto negativo desse procedimento é o alto custo de implementação e de manutenção (cada servidor precisa ter sua imagem mantida).

Os servidores RIS (e agora os WDS), assim como os servidores Microsoft DHCP, precisam ser autenticados em relação à implementação do Active Directory à qual estão associados. O objetivo é reduzir os possíveis problemas causados por servidores PXE não autorizados (como difusões PXE em excesso), permitindo que o Active Directory tenha conhecimento de todos esses servidores.

Observe que essa proteção só se aplica a servidores dos quais o Active Directory tem conhecimento. Se você configurar seu próprio domínio ou um servidor PXE que não seja da Microsoft, não será esse o caso.

Uma vez, na Microsoft, um funcionário excessivamente dedicado configurou um servidor PXE não-RIS com uma implementação sem interação humana. Essa implementação resultou no apagamento completo do disco rígido e na geração de uma nova imagem. Não haveria problema se a implantação tivesse ocorrido em um laboratório isolado (fora da rede). Só que, infelizmente, não foi assim: acabou apagando o disco de um executivo da Microsoft que tinha o PXE antecipado em sua ordem de inicialização, à frente do disco rígido.

Isso não deveria ser um problema, pois a TI da Microsoft sempre exigiu o pressionamento de F12 para fazer a inicialização PXE, mas esse servidor PXE não tinha atraso, prompt para pressionar F12 nem qualquer tipo de notificação. Ou seja, o executivo perdeu mesmo seu computador e todos os dados não protegidos pelo perfil de usuário móvel.

Que essa história sirva para destacar a necessidade de isolar seus servidores PXE, caso você pretenda usar uma implementação sem interação humana, ou pelo menos de exigir o pressionamento de F12.

Por dentro do RIS

Eu herdei o RIS após o lançamento do Windows 2000. O tempo não havia favorecido o Windows 2000 no que se referia ao RIS — e restrições de testes, de desempenho e de outros tipos fizeram com que o RIS para Windows Server 2000 fosse usado somente na implantação do Windows 2000 Professional. Infelizmente, os produtos de servidor não podiam ser implantados via RIS. O Windows 2000 estava disponível somente para computadores x86. Então, mostrou-se um bom ambiente de teste para o RIS, por envolver um único produto em uma única arquitetura. O RIS incluía (e exigia) integração completa com o Active Directory, integrado, por sua vez, ao servidor Microsoft DHCP, e incluía seu próprio TFTPD.

O RIS usa o NBP para continuar o download do TFTP — e obter uma parte suficiente do kernel do Windows para iniciar o processo de instalação (em um certo ponto, quando o Windows já fez a alternância do TFTPD para uma conexão com o servidor baseada no protocolo SMB, o caminho de código literal, na verdade, é compartilhado com uma instalação tradicional, iniciada por disquete, do Windows 2000 ou Windows XP). Após o Windows em modo nativo ter sido inicializado, a instalação do Windows inicia o Assistente OSC (OS Chooser) do RIS.

As telas do OSC são páginas relativamente configuráveis, semelhantes ao HTML 2.0. Têm restrições rígidas e não podem conter imagens ou elementos semelhantes. Na verdade, não podem conter caracteres não-ANSI (o que tornou complicada a implantação de certas localidades do Windows).

O produto final do RIS é um arquivo txtsetup.sif que reside no servidor RIS. Quando o Assistente OSChooser é concluído, o cliente passa por uma "reinicialização suave", mas as localizações do servidor RIS e do arquivo txtsetup.sif são retidas e recarregadas após essa reinicialização. Esse arquivo txtsetup.sif é essencialmente igual a um arquivo unattend.txt, com vários campos adicionais incluídos para ajudar o RIS a concluir o processo de instalação.

O RIS também era capaz de realizar uma instalação muito parecida com a instalação autônoma tradicional (RISetup). Ele tinha uma infra-estrutura baseada em clonagem semelhante ao Sysprep (RIPrep) e, na verdade, compartilhava código com ele. Mas o RIPrep podia também carregar a própria imagem em um servidor RIS.

No entanto, o RIS tinha algumas limitações fundamentais que ganharam visibilidade. A primeira era a ausência de suporte para a implantação de servidores. Alguns vírus, como o Code Red e o Sasser, combinados às complexidades de TI enfrentadas por vários clientes importantes na recuperação da tragédia de 11 de setembro de 2001, levaram-nos a acelerar o desenvolvimento de uma solução para os servidores RIS Windows 2000 existentes, permitindo a implantação do Windows Server. Já estávamos trabalhando nisso para o Windows Server 2003, mas ainda não havia ocorrido um lançamento formal.

Mais detalhes sobre tecnologias relacionadas ao PXE

• Descrição da interação PXE entre cliente PXE, DHCP e servidor RIS
• Planejamento de implantações de sistema operacional iniciadas pelo PXE
• Arquitetura do PXE
• Serviços de Instalação Remota
• Instalação remota de sistema operacional
• Guia passo a passo para a instalação remota de sistema operacional
• Provedor PXE do WDS
• O que são os Serviços de Instalação Remota?
• Serviços de Implantação Automatizada do Windows Server 2003

Em segundo lugar, o RIS não tinha a capacidade de automatizar completamente o Assistente OSChooser, o que foi habilitado mais tarde com o elemento <META ACTION="AUTOENTER">, no Windows Server 2003. Por fim, o OSChooser não funcionava corretamente com caracteres não-ANSI — um ponto fraco importante, destacado por vários clientes fora dos Estados Unidos.

Como resultado, era impossível concluir uma instalação do RIS com um teclado francês, por exemplo. Fazer com que caracteres não-ANSI funcionassem com segurança no nível do BIOS em PCs de todas as partes do mundo era algo extremamente complexo e de difícil realização.

Com o lançamento do Windows Server 2003, acrescentamos formalmente suporte para a arquitetura Intel Itanium e para todas as variantes de servidores do Windows 2000 e do Windows Server 2003. O Windows Server 2003 deu mais um passo adiante, com o suporte para a arquitetura x64.

O RIS tinha também um TFTPD consideravelmente reescrito para aumentar o desempenho. O Windows Server 2003 oferecia suporte à inicialização de até 75 clientes ao mesmo tempo. Tenha em mente que o limite superior é alcançado à medida que o pipe SMB é preenchido com o tráfego da rede para os clientes.

WDS — o início

Quando começamos a trabalhar no RIS para o "Longhorn" (o codinome do que viria a ser o Windows Server 2008), tornou-se claro que precisávamos dar um passo para trás. Como mencionei antes na minha coluna, já vínhamos apostando alto na instalação baseada em imagem (WIM) desde o Windows PE. Como resultado, o princípio fundamental subjacente ao WDS era a implantação baseada em imagem, a partir de uma instância do Windows PE inicializada com o PXE.

Também sabíamos que o Windows Server 2003 seria a plataforma comum para a implantação do Windows Vista®, e que precisaríamos de uma solução "fora de banda" para o nível inferior do WDS. Como resultado, o WDS podia ser executado no Windows Server 2003 SP1 e foi incorporado ao Windows Server 2003 SP2.

Por poder operar como um servidor RIS (modo herdado), um servidor híbrido (modo misto) ou um servidor somente WDS (modo nativo), o WDS permite a migração para implantações formais em estilo WDS, conforme prometido. Já ouvi clientes perguntarem se existe uma forma de instalar o RIS em um sistema Windows Server 2003 SP2. Sim, existe: basta instalar o WDS e executá-lo no modo herdado. A Figura 2 mostra os sistemas operacionais com suporte.

Figura 2. Plataformas com suporte para implantação

O WDS no Windows Server 2003 SP1 e SP2 visava iniciar o processo de migração para o WDS. Como já mencionei, os principais recursos acrescentados ao WDS no Windows Server 2008 foram um TFTPD revisado, o suporte para a inicialização do padrão EFI e, é claro, a implantação baseada em multicast.

Outras partes envolvidas

O ADS (Serviços de Implantação Automatizada) foi criado por outra equipe da Microsoft, com a meta principal de realizar o provisionamento rápido de servidores. O ADS contava com geração de imagens formal baseada em setor, agente de inicialização próprio (menor do que o Windows PE, mas sem contar com toda a sua funcionalidade), TFTPD próprio e multicast muito avançado. As funções incorporadas no ADS foram disponibilizadas, até certo ponto, no SCCM (System Center Configuration Manager), embora não haja paridade total entre os recursos.

O Windows XP Embedded contava com inicialização PXE completa por meio de TFTPD próprio em um RAMDisk, mas não podia ser implantado remotamente dessa forma. A tecnologia foi projetada para dar suporte à inicialização de vários sistemas a partir da mesma imagem de disco, ao mesmo tempo, via PXE.

Conclusão

Em suma, a história é essa. Para saber mais, consulte a barra lateral "Mais detalhes sobre tecnologias relacionadas ao PXE". No mês que vem, me aprofundarei nos fundamentos do WDS. Em seguida, virão colunas sobre os recursos avançados do WDS (multicast e outros) e, por fim, como usar o WDS sem usar o WDS, ou seja, como ir além da experiência existente de WDS/instalação para criar suas próprias técnicas de implantação.

Wes Miller é gerente sênior de produto técnico da CoreTrace (www.CoreTrace.com), em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programa da Microsoft. Entre em contato com ele pelo email technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.