Instalando as funções de servidor de instalação
Instalando as funções de servidor de instalação
Publicado em: 30/6/2006
As seções a seguir descrevem a instalação das funções de servidor de implantação. Elas incluem:
“Compreendendo as funções de servidor de instalação”
“Componentes de pré-requisito”
“Instalando a função de servidor de implantação”
“Configurando a função de servidor Windows DS”
“Instalando a função de servidor de dados”
“Instalando a função de servidor de instalação de aplicativo
Nesta página
Compreendendo as funções de servidor de instalação
Componentes de pré-requisito
Instalando a função de servidor de implantação
Instalando a função de servidor de dados
Instalando a função de servidor de instalação de aplicativo
Compreendendo as funções de servidor de instalação
Várias funções de servidor são necessárias para oferecer suporte ao processo de implantação Lite Touch. Estas são as funções de servidor incluídas:
Servidor de implantação — a origem das imagens de implantação personalizadas
Servidor de dados — o destino dos backups de máquina e dos dados de migração de perfil do usuário
Servidor de instalação de aplicativo — a origem das instalações de aplicativos básicos e suplementares
Servidor do Windows Deployment Services — o mecanismo da inicialização PXE (Pre-Boot eXecution Environment) e também a origem de imagens de instalação genéricas e personalizadas
A maioria dessas funções de servidor concentra-se em compartilhamentos de arquivos. As funções de servidor de implantação, de dados e de instalação de aplicativo executam o serviço de compartilhamento de arquivos para oferecer suporte ao acesso remoto a pastas compartilhadas através de conexões UNC.
A quarta função de servidor, o servidor Windows DS (Windows Deployment Services), também é muito parecida com um servidor de arquivos por armazenar imagens de inicialização e instalação para a implantação. Ela também fornece serviços de inicialização PXE, além de suporte a instalações bare-metal.
Em geral, essas quatro funções de servidor são combinadas em um único servidor de instalação físico. Essa abordagem é útil em laboratórios e para fins de teste. Mas, ela também é útil na produção, já que cada função é basicamente a mesma. Esse servidor de instalação traz como benefícios rápidos tempos de resposta de rede e enormes quantidades de espaço de armazenamento. Em geral, discos SCSI de 300 GB são suficientes para a partição de dados hospedada por esse servidor.
Na produção, você deverá avaliar o número de servidores necessários à implantação com base no número de máquinas a serem implantadas, no local físico dessas máquinas, nos links WAN (rede de longa distância) para a implantação, na capacidade física dos servidores que oferecem suporte à implantação etc. O servidor de instalação pode ser replicado para locais remotos a partir de uma única origem central a fim de minimizar a utilização da WAN. Em locais remotos com pouca disponibilidade de largura de banda, a função de servidor de instalação pode ser hospedada por um computador portátil poderoso, trazido para o local remoto pela equipe de implantação e movido de um local para outro durante a implantação.
No caso de pequenas implantações, um único servidor de instalação pode ser suficiente. Em implantações maiores e distribuídas geograficamente, o servidor de instalação deve ser duplicado em cada local separado por um link WAN. Em vários casos, as organizações decidem manter o servidor de instalação permanentemente oferecendo suporte à distribuição contínua de software e a atualizações do sistema operacional. Quando os servidores de gerenciamento já estão em vigor, a função de servidor de instalação é normalmente combinada com esses servidores para simplificar a implantação.
Como o servidor de instalação tem um forte componente de compartilhamento de arquivos, é recomendável planejar uma única origem para todo o conteúdo do servidor e usar uma metodologia de replicação para atualizar todas as outras cópias desse servidor em todos os outros locais. Isso ajudará a minimizar o tráfego da WAN e reduzirá o impacto da implantação na rede. Várias tecnologias de replicação estão disponíveis, embora você deva usar, de preferência, uma tecnologia que ofereça suporte à replicação compactada, em nível de byte, para replicar somente deltas, e não arquivos inteiros. Estas são algumas tecnologias disponíveis:
O Robust File Copy Utility (Robocopy.exe) do Microsoft Windows Server 2003 Resource Kit Tools — embora seja uma ferramenta sem suporte, ela fornece um bom mecanismo para a replicação de arquivos de origem para vários destinos. Observe que esse utilitário executa replicação em nível de arquivo, ou seja, se apenas um arquivo tiver sido alterado em um arquivo WIM (Windows Imaging Format), todo o arquivo WIM será replicado.
O DFS Replication Service (DFSRS) do Windows Server 2003 R2 — o DFSRS faz parte dos novos recursos do DFS (sistema de arquivos distribuído) do Windows Server 2003 R2. Ele fornece replicação em nível de byte para a sincronização do conteúdo da pasta compartilhada. Para usar o DFSRS, é necessário colocar grupos de replicação em vigor para oferecerem suporte a ele. Isso significa depender do Active Directory para dar suporte aos grupos de replicação. Observe que não é possível usar esses grupos de replicação para implantações de computadores principalmente porque essas implantações dependem do Windows PE, e o Windows PE não interage com o Active Directory nesse nível. Isso significa que é possível usar o DFSRS para replicar dados, mas, depois que esses dados forem replicados, você deverá contar com as tradicionais UNCs para executar a implantação. Além disso, como o DFSRS oferece um modo de implantação de backup centralizado, você poderá contar com ele para coletar dados de backup de locais remotos e armazená-los centralmente de onde poderão ser descarregados para uma fita que fará seu armazenamento permanente. Para obter mais informações sobre o DFSRS, consulte https://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx (em inglês).
Microsoft Systems Management Server 2003 (SMS) — o SMS também é uma maneira de replicar informações de uma origem central para vários destinos. Se tiver o SMS em vigor, você poderá contar com ele para executar essas replicações de uma maneira controlada e agendada. Para obter mais informações sobre o SMS, consulte https://www.microsoft.com/smserver/default.mspx (em inglês).
Microsoft System Center Data Protection Manager 2006 (DPM) — o DPM também fornece recursos de replicação agendados, em nível de byte, embora sua finalidade principal seja capturar backups remotos e replicá-los para um local centralizado. Essa tecnologia é útil no suporte à função de servidor de dados, pois esse servidor é usado para capturar backups de todo o sistema e informações de perfil do usuário das máquinas existentes. Se a sua organização desejar ter repositórios centrais desses backups, de onde eles poderão ser descarregados para uma fita que fará seu armazenamento permanente, o DPM poderá ser útil. Para obter mais informações sobre o DPM, consulte https://www.microsoft.com/windowsserversystem/dpm/default.mspx (em inglês).
Você também pode usar outras tecnologias de terceiros como suporte à replicação. Lembre-se de que elas devem oferecer suporte aos recursos de agendamento, controle de versões, compactação e replicação de deltas. A figura 1 ilustra como diferentes tecnologias de replicação podem ser usadas para oferecer suporte à sincronização dos repositórios de sites remotos. Ela também ilustra como os backups de dados podem ser replicados centralmente para serem descarregados para uma fita.
Figura 1. Requisitos de replicação em implantações geograficamente dispersas
As tecnologias de replicação não são necessárias nos laboratórios de teste, mas devem ser testadas para assegurar que a produção seja executada da forma mais tranqüila possível. Os laboratórios podem usar tecnologias de máquina virtual, como as fornecidas pelo Microsoft Virtual Server 2005 R2, para simular vários servidores de instalação que serão necessários como suporte à implantação. Essa estratégia pode ser usada para testar as replicações dos repositórios de implantação. Consulte o Guia da equipe de recursos de teste para obter mais informações sobre os tipos de teste.
Componentes de pré-requisito
Vários componentes são necessários para oferecer suporte à implantação Lite Touch. São eles:
Active Directory
Um DNS totalmente funcional
Um WINS, se você usar uma nomenclatura de nível inferior em sua rede
DHCP
Virtual Server 2005 R2, se você planejar usar máquinas virtuais para teste
O Windows Automated Installation Kit (WAIK), que inclui o Windows PE versão 2.0
O Microsoft Management Console (MMC) versão 3.0
O Microsoft IIS (Serviços de Informações da Internet) e o Microsoft Windows SharePoint™ Services como suporte à colaboração em equipe
Outros pré-requisitos poderão ser necessários, dependendo do seu ambiente de destino. Consulte o Guia da equipe de recursos de teste para obter mais informações.
Instalando a função de servidor de implantação
A instalação da função de servidor de implantação é um processo simples que consiste em criar um compartilhamento de rede e estruturas de pastas e, em seguida, copiar a mídia e os scripts corretos para um local. Essa função pode ser distribuída — construída em vários servidores físicos — ou colocada no mesmo hardware de outros servidores (por exemplo, a função de servidor de instalação de aplicativo) usados na implantação. Uma opção adequada é a função de servidor Windows DS, pois as duas funções contêm imagens de instalação para a implantação do sistema operacional.
Os arquivos do servidor de implantação são instalados usando o arquivo BDDVista.msi do Windows Installer. Por padrão, os scripts são instalados na pasta Distribution, na unidade com maior espaço, mas você pode selecionar um local diferente, se necessário. Os demais arquivos do Solution Accelerator para BDD Vista serão instalados na pasta C:\Arquivos de programas\BDD Vista.
O Solution Accelerator para BDD Vista exige os seguintes pré-requisitos:
Microsoft .NET Framework versão 2.0
MMC versão 3.0
O arquivo do Windows Installer do BDD Vista instalará o seguinte:
Os scripts e o código do assistente para implantação na estrutura de pastas C:\Arquivos de programa\BDD Vista. Isso inclui a BDD Workbench.
A documentação do Solution Accelerator para BDD na pasta C:\Arquivos de programa\BDD Vista\Documentation.
Uma pasta compartilhada usada como origem ou ponto de distribuição da implantação.
Qualquer ferramenta adicional necessária ao suporte da implantação. Essas ferramentas incluem:
Microsoft Extensible Markup Language (MSXML) 6.0
WAIK, que inclui o Windows PE versão 2.0
USMT versão 3.0
O Enterprise Learning Framework
O System Center Configuration Manager 2007 (SCCM) Task Sequencer que é incorporado aos arquivos de programa do Solution Accelerator para BDD Vista
Observação Várias dessas ferramentas deverão ser personalizadas durante a preparação de sua implantação. Por exemplo, os desenvolvedores responsáveis pela migração de dados do usuário da USMT em seu ambiente prepararão scripts personalizados para a migração. Outro exemplo envolve as imagens personalizadas do Windows Vista ou do Windows XP que serão implantadas. A equipe de recursos do Computer Imaging System prepararão essas imagens, que serão fornecidas para a equipe de implantação e usadas na preparação para a implantação. Essas atualizações talvez não estejam disponíveis até o final da fase Desenvolver para cada equipe.
Consulte o Guia de introdução para executar a instalação do Solution Accelerator para BDD Vista e investigar a estrutura de pastas criada.
Identificando os requisitos de armazenamento dos servidores de implantação
Certifique-se de que você tenha armazenamento disponível suficiente nos servidores de implantação para as imagens que serão usadas pela LTI. Determine o tamanho de cada imagem e o número de imagens necessárias em sua implantação. Com o WIM, a LTI não precisará mais de um grande número de imagens para oferecer suporte a várias configurações de desktop. Isso é possível porque o WIM usa um armazenamento de instância única para armazenar somente uma cópia de qualquer arquivo compartilhado contido nas imagens. Assim, você poderá ter uma única imagem que ofereça suporte a cada HAL (Camada de Abstração de Hardware) exclusiva e necessária nas estações de trabalho destinadas à implantação e que contenha versões de idioma localizadas do sistema operacional (como chinês simplificado ou japonês).
Para fins de planejamento, estime o tamanho de uma imagem entre 500 MB e 4 GB, incluindo os aplicativos. Teoricamente, cada servidor de implantação teria, no mínimo, esse espaço de armazenamento em disco disponível. Para assegurar o êxito total de sua implantação, multiplique esse valor por um fator dois (no mínimo) e defina esse resultado como o seu espaço disponível necessário em cada servidor de implantação.
Fornecendo armazenamento suficiente para os logs de implantação
Os logs de implantação registram o processo para cada estação de trabalho por meio do processo de distribuição de imagem. Determine o espaço de armazenamento necessário aos logs de implantação salvos durante o processo de implantação. Quando você souber o tamanho do espaço de armazenamento necessário, designe as pastas compartilhadas que poderão ser usadas como armazenamentos temporários dos logs de implantação.
Determinando os requisitos de armazenamento para os logs de implantação
Para fins de planejamento, você poderá determinar os requisitos de armazenamento dos logs de implantação para uma única estação de trabalho executando as seguintes etapas:
Execute o processo de atualização no laboratório de teste para determinar o tamanho dos logs de implantação.
Determine o tempo de persistência necessário aos logs de implantação.
Multiplique o tamanho dos logs de implantação de uma estação de trabalho pelo número de estações de trabalho que serão atualizadas simultaneamente.
Determinando o local de armazenamento dos logs de implantação
Após determinar os requisitos de armazenamento dos logs de implantação, determine o local de armazenamento desses logs. Armazene-os em uma pasta compartilhada que esteja conectada às estações de trabalho por uma conexão de banda larga alta.
Configurando a função de servidor Windows DS
As versões anteriores do Solution Accelerator para BDD dependiam do Windows RIS (Serviço de Instalação Remota). Esse serviço foi atualizado e renomeado para dar suporte às implantações do Windows Vista: O novo nome é Windows Deployment Services (Windows DS). O Windows DS oferece suporte completo ao WIM.
Ele é executado no Windows Server 2003 service pack 1 ou no Windows Server, codinome “Longhorn”. No Windows Server, ele é fornecido como uma atualização através do Kit de Instalação Automatizada do Windows ou do Windows Server 2003 R2. Ele é uma função de servidor nativo do Windows Server “Longhorn”.
Se pretender usar os servidores RIS existentes para iniciar o Windows PE ou como ponto de instalação das imagens do Windows Vista, verifique se os servidores foram atualizados para o Windows DS. Os servidores também precisarão de cópias das imagens do Windows Vista quando forem disponibilizados pela equipe de desenvolvimento que os criou. Você pode configurar o serviço Windows DS em cada servidor e, em seguida, usar tecnologias de replicação, conforme discutido anteriormente, para replicar as imagens do Vista para cada servidor de destino.
Se desejar, reveja o Guia da equipe de recursos do Computer Imaging System para obter mais detalhes sobre como preparar os servidores Windows DS. Basicamente, no Windows Server 2003 service pack 1, o processo exige a instalação anterior do RIS e, em seguida, uma atualização para o Windows DS. No Windows Server “Longhorn”, o Windows DS pode ser instalado de forma nativa, selecionando a função de servidor de implantação.
Observação O Solution Accelerator para BDD não fornece diretrizes completas de uso do Windows DS para a implantação das imagens do Windows Vista baseadas no WDSUtil. Para obter diretrizes completas sobre como usar o Windows DS, consulte a ajuda do Windows DS após sua instalação.
Instalando a função de servidor de dados
A instalação do servidor de dados é outro processo simples de criação de um compartilhamento de pastas de rede e de estruturas de pastas. O servidor de dados também pode ser localizado em vários servidores físicos ou colocado junto com outros servidores usados na implantação. Por ser usada para coletar dados do processo de migração de perfil do usuário e do processo de backup de estação de trabalho, essa função de servidor deverá ter um grande volume NTFS dedicado para esse compartilhamento.
Para criar a estrutura necessária, crie uma pasta, por exemplo, drive:\MigrationData (onde drive é a letra da unidade dedicada) e compartilhe a pasta na rede com um nome familiar, por exemplo, \\servername\MigData. Use qualquer nome de pasta e de compartilhamento desejado. Os usuários que realizarem a migração — técnicos ou usuários finais com direitos administrativos na máquina — deverão ter permissões de leitura e gravação nesse compartilhamento. Quando ela for realizada e o compartilhamento de rede for selecionado como destino, o assistente para implantação criará automaticamente uma subpasta nesse compartilhamento, no formato nome_de_usuário\estação_de_trabalho como o local para gravação das informações de migração, dos dados da USMT e das imagens de backup. Considere as permissões de compartilhamento e NTFS cuidadosamente nessas pastas. Permissões impróprias poderão permitir o acesso de usuários não autorizados a dados confidenciais. O uso de Proprietário Criador para aplicar permissões poderá ajudar a diminuir esse risco. Além disso, a USMT versão 3.0 inclui uma opção de criptografia que pode ajudar a proteger os dados.
Essa função de servidor poderá exigir duplicação se você estiver executando uma implantação distribuída geograficamente. Além disso, por ser uma função de servidor de coleta, sua organização talvez queira centralizar todos os backups usando uma das tecnologias de replicação mencionadas anteriormente.
Fornecendo armazenamento suficiente para os dados de migração de perfil do usuário
Determine o espaço de armazenamento necessário aos dados de migração de perfil do usuário salvos pela USMT durante o processo de implantação. Quando esse espaço for determinado, designe o armazenamento local na estação de trabalho ou nas pastas compartilhadas que podem ser usadas como armazenamento temporário dos dados de migração do usuário.
Determinando os requisitos de armazenamento dos dados de migração de perfil do usuário
Para fins de planejamento, avalie os requisitos de armazenamento da migração de perfil do usuário executando as seguintes etapas:
Executando o Scanstate.exe na USMT através da opção de comando /p para estimar o tamanho dos dados de migração de perfil do usuário. A opção de comando /p permite estimar os requisitos de espaço em disco sem realizar a migração. Consulte o Guia da equipe de recursos de migração de perfil do usuário para Business Desktop Deployment para obter mais informações.
Verificando o tamanho do conteúdo das pastas \Documents and Settings\nome_de_usuário. Você também pode realizar uma amostragem aleatória nas estações de trabalho de destino para determinar um espaço médio de armazenamento necessário ao backup da migração de perfil do usuário. Lembre-se de que é possível haver vários perfis (pastas de nomes de usuário) em cada estação de trabalho, portanto, você deverá incluir cada perfil que planeja migrar.
Você também precisará saber quanto tempo os dados de migração de perfil do usuário deverão permanecer armazenados. Armazene os dados de migração de perfil do usuário caso ocorra falha da atualização e você precise reverter a configuração. Após se certificar de uma atualização bem-sucedida, você poderá excluir os dados de migração de perfil do usuário.
Calcule os requisitos de armazenamento dos dados de migração de perfil do usuário multiplicando o tamanho do estado de migração do usuário pelo número de estações de trabalho simultâneas que estiverem sendo atualizadas (tamanho da migração × número de estações de trabalho simultâneas).
Determinando onde armazenar os dados de migração de perfil do usuário
Após determinar os requisitos de armazenamento dos dados de migração de perfil do usuário, especifique o local de armazenamento desses dados. Armazene os dados de migração de perfil do usuário:
- Na estação de trabalho local para diminuir o tempo de implantação do Windows Vista ou do Windows XP e reduzir a utilização da rede (recomendado)
Observação Use essa opção somente no cenário Atualizar Imagem do Computador. Consulte Using the Deployment Wizard (em inglês) para obter mais informações sobre os diversos cenários de implantação com suporte da LTI.
- Em uma pasta compartilhada localizada em um servidor local para oferecer um método consistente de armazenamento dos dados de migração de perfil do usuário ou quando o armazenamento local não estiver disponível
Se decidir armazenar os dados de migração do usuário na estação de trabalho local, designe uma pasta compartilhada na qual o processo LTI poderá armazenar os dados. (Por padrão, o processo tenta armazenar os dados de perfil do usuário no disco rígido local para os cenários Atualizar Imagem do Computador.) Caso não haja espaço em disco suficiente para o perfil do usuário e para uma nova imagem, o processo LTI tentará armazenar as informações em uma pasta compartilhada. A disponibilização da pasta compartilhada como local de armazenamento alternativo torna mais confiável o processo de implantação. Posicione a pasta compartilhada de modo que haja conexão com alta largura de banda entre ela e as estações de trabalho.
Observação Será possível fazer backup dos dados de migração de perfil do usuário quando eles estiverem armazenados em uma pasta compartilhada.
Instalando a função de servidor de instalação de aplicativo
A instalação da função de servidor de instalação de aplicativo envolve a criação de outra série de pastas e compartilhamentos de rede. Uma flexibilidade significativa é permitida para essa função de servidor, que pode ser um servidor distribuído, conforme mencionado para os servidores de dados e de implantação. Novamente, como essa função de servidor é usada para armazenar quantidades significativas de dados na forma de instalações de software, ela deverá ter um grande volume NTFS dedicado para esse compartilhamento.
Um dos métodos consiste em criar uma estrutura de pastas, como drive:\Software Repository (onde drive é a letra da unidade dedicada), compartilhar essa pasta na rede como \\servername\Repository e, em seguida, criar pastas abaixo dela para cada aplicativo, conforme mostrado na tabela 4. Para simplificar, D: será a letra de unidade usada.
Tabela 4. Pastas de servidor de instalação de aplicativo de exemplo
Pasta |
Objetivo |
---|---|
D:\Repository |
Ponto de conexão raiz usado pelas estações de trabalho para instalar aplicativos específicos do usuário |
D:\ Repository\Adobe7 |
Uma pasta usada para armazenar o pacote do Adobe Reader 7 |
D:\ Repository\Project2003 |
Uma pasta usada para armazenar o pacote do Microsoft Office Project 2003 |
Depois que a estrutura for criada, você poderá copiar os pacotes para as pastas apropriadas à medida que elas forem sendo disponibilizadas pela equipe de desenvolvimento responsável pelo empacotamento dos aplicativos. Essa será uma oportunidade ideal para usar as tecnologias de replicação. Certifique-se de que a origem da replicação seja o repositório oficial de empacotamento dos aplicativos concluídos, conforme definido pelas equipes de empacotamento de aplicativos, e estabeleça como destino a origem de produção oficial para todas as instalações de aplicativos. Se estiver executando uma implantação distribuída geograficamente, você poderá usar seu repositório de produção como origem das replicações na rede de produção.