Qual Administrador de Redes nunca passou pela infelicidade de perder um Servidor de Arquivos e ter que recriar diversos compartilhamentos na mão?
Existe uma forma muito simples de fazer um backup de todos os compartilhamentos de um servidor e esta forma é: o Registro do Windows!
Basta abrir o registro (regedit.exe), acessar a chave HKLC\System\CurrentControlSet\Services\LanmanServer e exportar a chave Shares. Pronto! Você acaba de gerar um arquivo .reg que contém as informações de compartilhamento do servidor. Guarde este arquivo em um lugar seguro, trancado a sete chaves.
O interessante é que este arquivo pode ser usado em outro computador, como por exemplo, numa migração física de dados, após o término da cópia dos arquivos para o novo servidor, basta executar o arquivo .reg e reiniciar o serviço Servidor (net stop/start server).
Até a próxima.
terça-feira, 14 de dezembro de 2010
segunda-feira, 13 de dezembro de 2010
Troubleshooting Host Name Resolution
Vai aqui uma dica muito interessante sobre uma "má" prática que a maioria dos Técnicos de TI (eu era um deles!!!) e até Administradores de Rede realizam.
Quando um usuário faz uma chamada ao Help Desk informando não estar acessando o servidor SRV1 e, durante o atendimento, o Técnico de TI descobre que o computador do usuário está resolvendo o IP do servidor SRV1 para um número inválido. Digamos que o IP do servidor SRV1 seja 192.168.0.10 e o computador está resolvendo o IP como 192.168.0.20. Diante dessa situação, qual é a primeira coisa que o Técnico de TI faz???
Se sua resposta foi verificar o Servidor de DNS, parabéns! Você também realiza a "má" prática!
A grande maioria acha que problemas relacionados a resolução de nomes está diretamente ligada ao Servidor de DNS, o que não é verdade. Para melhor esclarecer essa afirmação, vejamos como ocorre o processo de resolução de nome de host, utilizando o exemplo acima do SRV1:
1 - A primeira coisa que o computador do usuário faz é perguntar a si mesmo se ele é o SRV1.
2 - Caso a resposta seja não, o computador do usuário (vamos chamá-lo de CLIENT10) faz uma pesquisa no DNS Client Resolver Cache. E quem diabos é esse DNS Client Resolver Cache? É a cache local do CLIENT10. Ahá! Já volto nesse assunto.
3 - Caso o DNS Client Resolver Cache não resolva, aí sim, o CLIENT10 faz uma pesquisa no Servidor de DNS.
4 - Caso o Servidor de DNS não resolva, o CLIENT10 faz uma pesquisa na cache local do NetBios.
5 - Caso o NetBios não resolva, o CLIENT10 faz uma pesquisa no Servidor WINS.
6 - Caso o Servidor WINS não resolva (ou caso não haja um Servidor WINS na rede), o CLIENT10 faz uma pesquisa utilizando o Broadcast.
7 - Caso o Broadcast não resolva, o CLIENT10 faz uma pesquisa no arquivo local "lmhosts".
8 - Caso o arquivo lmhosts não resolva, o CLIENT10 retorna um erro informando que não conseguiu resolver o IP do servidor SRV1.
Mas espere, no exemplo acima o IP do servidor SRV1 foi resolvido como 192.168.0.20. Eu sei... mas quis apenas listar aqui todo o processo de resolução de nome de host.
Voltando ao nosso exemplo, mais precisamente, o passo 2: DNS Client Resolver Cache. É sobre esse cara que eu queria falar: Quando um nome de host é resolvido, ou seja, obtêm-se o seu IP, essa informação é armazenada localmente em cada computador. E qual é o local onde essa informação é armazenada? No DNS Client Resolver Cache!
Portanto, antes de sair correndo até o Servidor de DNS, verifique o DNS Client Resolver Cache primeiro. O problema pode ser local. Como fazer isso? Abra o Prompt de Comando e digite ipconfig /displaydns. Você verá a cache de hosts resolvidos com seus respectivos IPs. Para limpar a cache local, utilize o comando ipconfig /flushdns.
Vamos agora a uma situação mais "capciosa": Digamos que no DNS Client Resolver Cache do CLIENT10 o IP do SRV1 seja 192.168.0.20 e mesmo depois de executar o comando ipconfig /flushdns, ao executar o comando ipconfig /displaydns o IP continue sendo resolvido como 192.168.0.20, o que você faz??? Servidor de DNS???... Bêêêêê!!! Resposta errada de novo.
"Wadda hell, man?!" Se o DNS Client Resolver Cache já foi limpado e, seguindo a ordem do processo de resolução de nomes, o próximo é o Servidor de DNS, você diz que não é ele? Yep! Tem ainda mais um detalhe a ser observado em relação ao DNS Client Resolver Cache:
Toda vez que o DNS Client Resolver Cache é criado/recriado são adicionados registros como o IP local do computador (127.0.0.1) e os endereços localizados no arquivo hosts... Peraí.. que arquivo é esse? Dentro da pasta %systemroot%\system32\drivers\etc, existe um arquivo chamado hosts. Abrindo com o Bloco de Notas, você tem um arquivo de texto e ao final alguns registros do tipo "host IP", como por exemplo:
127.0.0.1 localhost
É possível que o arquivo "hosts" do CLIENT10 tenha um registro do tipo "192.168.0.20 SRV1" e por isso, o IP do SRV1 esteja sendo resolvido errôneamente.
Phew! Falei muita abobrinha, mas espero que você tenha pego o espírito da coisa: Antes de correr ao Servidor de DNS, verifique o DNS Client Resolver Cache do computador afetado, abrindo o arquivo hosts e limpando a cache local com o comando ipconfig /flushdns.
That's all for now! Espero que tenham gostado dessa dica e, nos vemos na próxima. ^^
Quando um usuário faz uma chamada ao Help Desk informando não estar acessando o servidor SRV1 e, durante o atendimento, o Técnico de TI descobre que o computador do usuário está resolvendo o IP do servidor SRV1 para um número inválido. Digamos que o IP do servidor SRV1 seja 192.168.0.10 e o computador está resolvendo o IP como 192.168.0.20. Diante dessa situação, qual é a primeira coisa que o Técnico de TI faz???
Se sua resposta foi verificar o Servidor de DNS, parabéns! Você também realiza a "má" prática!
A grande maioria acha que problemas relacionados a resolução de nomes está diretamente ligada ao Servidor de DNS, o que não é verdade. Para melhor esclarecer essa afirmação, vejamos como ocorre o processo de resolução de nome de host, utilizando o exemplo acima do SRV1:
1 - A primeira coisa que o computador do usuário faz é perguntar a si mesmo se ele é o SRV1.
2 - Caso a resposta seja não, o computador do usuário (vamos chamá-lo de CLIENT10) faz uma pesquisa no DNS Client Resolver Cache. E quem diabos é esse DNS Client Resolver Cache? É a cache local do CLIENT10. Ahá! Já volto nesse assunto.
3 - Caso o DNS Client Resolver Cache não resolva, aí sim, o CLIENT10 faz uma pesquisa no Servidor de DNS.
4 - Caso o Servidor de DNS não resolva, o CLIENT10 faz uma pesquisa na cache local do NetBios.
5 - Caso o NetBios não resolva, o CLIENT10 faz uma pesquisa no Servidor WINS.
6 - Caso o Servidor WINS não resolva (ou caso não haja um Servidor WINS na rede), o CLIENT10 faz uma pesquisa utilizando o Broadcast.
7 - Caso o Broadcast não resolva, o CLIENT10 faz uma pesquisa no arquivo local "lmhosts".
8 - Caso o arquivo lmhosts não resolva, o CLIENT10 retorna um erro informando que não conseguiu resolver o IP do servidor SRV1.
Mas espere, no exemplo acima o IP do servidor SRV1 foi resolvido como 192.168.0.20. Eu sei... mas quis apenas listar aqui todo o processo de resolução de nome de host.
Voltando ao nosso exemplo, mais precisamente, o passo 2: DNS Client Resolver Cache. É sobre esse cara que eu queria falar: Quando um nome de host é resolvido, ou seja, obtêm-se o seu IP, essa informação é armazenada localmente em cada computador. E qual é o local onde essa informação é armazenada? No DNS Client Resolver Cache!
Portanto, antes de sair correndo até o Servidor de DNS, verifique o DNS Client Resolver Cache primeiro. O problema pode ser local. Como fazer isso? Abra o Prompt de Comando e digite ipconfig /displaydns. Você verá a cache de hosts resolvidos com seus respectivos IPs. Para limpar a cache local, utilize o comando ipconfig /flushdns.
Vamos agora a uma situação mais "capciosa": Digamos que no DNS Client Resolver Cache do CLIENT10 o IP do SRV1 seja 192.168.0.20 e mesmo depois de executar o comando ipconfig /flushdns, ao executar o comando ipconfig /displaydns o IP continue sendo resolvido como 192.168.0.20, o que você faz??? Servidor de DNS???... Bêêêêê!!! Resposta errada de novo.
"Wadda hell, man?!" Se o DNS Client Resolver Cache já foi limpado e, seguindo a ordem do processo de resolução de nomes, o próximo é o Servidor de DNS, você diz que não é ele? Yep! Tem ainda mais um detalhe a ser observado em relação ao DNS Client Resolver Cache:
Toda vez que o DNS Client Resolver Cache é criado/recriado são adicionados registros como o IP local do computador (127.0.0.1) e os endereços localizados no arquivo hosts... Peraí.. que arquivo é esse? Dentro da pasta %systemroot%\system32\drivers\etc, existe um arquivo chamado hosts. Abrindo com o Bloco de Notas, você tem um arquivo de texto e ao final alguns registros do tipo "host IP", como por exemplo:
127.0.0.1 localhost
É possível que o arquivo "hosts" do CLIENT10 tenha um registro do tipo "192.168.0.20 SRV1" e por isso, o IP do SRV1 esteja sendo resolvido errôneamente.
Phew! Falei muita abobrinha, mas espero que você tenha pego o espírito da coisa: Antes de correr ao Servidor de DNS, verifique o DNS Client Resolver Cache do computador afetado, abrindo o arquivo hosts e limpando a cache local com o comando ipconfig /flushdns.
That's all for now! Espero que tenham gostado dessa dica e, nos vemos na próxima. ^^
sexta-feira, 26 de novembro de 2010
Windows Server: A evolução de "um" ponto de vista
Nesses últimos dias (para não dizer meses), tenho lido e assistido muitos materiais sobre o Windows Server 2008 (certificação a vista!). O primeiro contato que tive com a rede Windows foi com o NT 4.0. Do Windows NT 4.0 pulei direto para o Windows Server 2003 sem nem olhar para a cara do Windows 2000 Server. Resultado: foi quase como um reboot tecnológico, pois a idéia era a mesma, só que a tecnologia era completamente diferente. Mas nada que muitas noites ao relento não resolvessem.
Hoje, temos no mercado o Windows Server 2008, já em seu Release 2. O primeiro sistema operacional da Microsoft exclusivo para plataforma 64 bits (tá na hora de trocar o chip!). Uma coisa que me chamou muito a atenção nestes anos de evolução do Windows, foi a evolução do Active Directory. Não só da tecnologia em si, mas da sua relação com o conceito de "Segurança" e, mais atualmente, com o conceito de "TI Verde".
Lá na época do Windows NT 4.0, a preocupação estava somente na identificação de acesso local, ou seja, dentro da minha empresa eu tenho um usuário e uma senha que me dão acesso a certos recursos da rede da minha empresa e só. O mundinho estava resumido ali dentro. Dentro da empresa, haviam apenas os computadores da empresa. Na época em questão, o foco da segurança estava no acesso físico: Fulano podia usar o computador do RH, mas não podia usar o computador do Financeiro. Além disso, o conceito de "Administração de Rede" também estava no jardim de infância: Tínhamos ferramentas para administrar os servidores, mas não os demais computadores, a quem carinhosamente chamamos de Estações de Trabalho. A manutenção e configuração das Estações de Trabalho ocorria in-place, ou seja, o técnico se deslocava até o local onde a Estação de Trabalho estava. Isso até que era bom, pois ajudava a queimar uma gordurinha... Mas essa falta de recursos de administração centralizada das Estações de Trabalho começou a pesar. Então, a Microsoft criou esse "recurso" que faltava e o introduziu em seu novo sistema operacional.
Com o Windows 2000 Server, o Active Directory apresentou uma nova tecnologia chamada "Política de Grupo" (Group Policy). Através dela, passou a ser possível definir políticas (dããã...) de configuração dos Servidores e Estações de Trabalho de forma centralizada, como por exemplo, bloqueio ao Painel de Controle ou alteração do Papel de Parede. Nessa época o foco da segurança começou a olhar para um carinha que estava batendo na porta de todas as empresas: a Internet. A preocupação era fechar todas as portas de entrada. Colocava-se um exército de prontidão na borda da rede vigiando todo o tráfego de entrada e saída. E o "mundinho" começava a ganhar novos territórios...
Lá pela época do Windows Server 2003, com a Internet já consolidada e a idéia da interatividade ganhando seu espaço, os "dispositivos interativos" começaram a ser mais frequentes dentro das empresas. E o exército que antes ficava de prontidão lá na borda da rede começou a se perguntar: "Pois é... estamos aqui vigiando quem entra e quem sai, mas e quem está lá dentro? Será que não está fazendo alguma coisa?". E a segurança que antes só se preocupava com o acesso físico e que depois passou a se preocupar com a borda da rede, agora estava preocupada com a segurança interna também. O vírus que conseguia passar a barreira da borda se disseminava rapidamente dentro da empresa, pois os computadores internos não estavam totalmente protegidos (Hum... será que o surgimento do Windows Firewall no Service Pack 2 do Windows XP foi por acaso?). Mas não eram só os computadores internos: agora haviam também os notebooks pessoais, os PDAs e os adoráveis "pendrives". Todos trafegando livremente dentro da rede corporativa.
E com toda essa "liberdade interna", quem era o doido pra dizer que não podia plugar o notebook na rede: seu Diretor Administrativo não entende bulhufas de informática e trás o notebook e quer que você o configure para acessar a rede corporativa, você teria coragem suficiente para olhar nos olhos dele e dizer: "Não vou fazer, pois seu notebook compromete a segurança da empresa..." Ok, vamos a um caso mais simples: O famoso "estagiário" trás o seu adorado pendrive de casa, pluga no computador da empresa, copia dados confidenciais e vai embora numa boa (porque estagiário sempre leva a culpa de tudo?). Outro caso: O Diretor Financeiro envia uma planilha por e-mail com a contabilidade anual da empresa para o consultor terceirizado e sabe-se lá o que ele vai fazer com essa informação.
Tá.. mas o que tudo isso tem haver com o Active Directory ou com a segurança?... TUDO!!!
Na época do Windows Server 2003, a Microsoft já possuía algumas ferramentas para controlar algumas das situações citadas acima, como o caso do Diretor Financeiro, mas foi com o Windows Server 2008 que tudo se consolidou. Para cada uma das situações apresentadas, o Windows Server 2008 possui uma tecnologia built-in, ou seja, já embutida no próprio sistema operacional. Não precisa fazer nenhum download adicional ou pagar a mais por isso. Basta apenas ativar e configurar:
- No caso do notebook do Diretor Administrativo, a Microsoft lançou uma tecnologia com o Windows Server 2008 chamada Network Access Protection (NAP). Através dela é possível definir regras de conformidade para que os computadores possam acessar a rede corporativa e, caso não atendam a essas regras, são direcionados a uma rede restrita onde poderão ser "remediadas". Por exemplo, se uma regra de conformidade exige que o software antivírus esteja atualizado e o software antivírus do notebook do Diretor Administrativo não estiver, o mesmo não terá acesso a rede corporativa até que atualize o software.
- No caso do estagiário com o pendrive, há uma nova Política de Segurança que controla o uso do pendrive dentro da empresa. Pode-se definir se ele pode ler ou gravar arquivos no pendrive.
- No caso do Diretor Financeiro, a Microsoft já possuía uma tecnologia que no Windows Server 2008 fora integrada ao Active Directory chamada Rights Management Services (RMS). Através dela é possível definir o que determinadas pessoas podem ou não fazer com um documento, planilha ou e-mail. Por exemplo, o Diretor Financeiro poderia definir que o consultor terceirizado poderia apenas abrir e imprimir a planilha e não alterar nenhuma informação. E pode-se ir além disso: ao invés do arquivo ir ao consultor, o consultor pode vir até o arquivo, sem precisar sair de seu escritório. Ahm!? Outra tecnologia que fora integrada ao Active Directory chamada Federation Services (FS), permite que usuários externos tenham acesso a sua rede interna. Existe uma outra tecnologia, mais antiga, que permite tal "integração" entre empresas diferentes chamada de "Relação de Confiança" (Trust Relationship). Só para esclarecer, o AD RMS é mais seguro que a Trust Relationship. Utilizando o AD RMS em conjunto com AD FS, o consultor terceirizado acessaria a planilha internamente, não poderia alterar nada e além disso, eliminaríamos o tráfego de e-mail pois a planilha não precisaria ser enviada a ninguém.
Perceberam como o foco da segurança e da identificação mudaram? O que antes era restrito à empresa passou a ser necessidade fora dela. Antes, o Administrador de Redes tinha controle sobre a informação que circulava internamente, mas perdia esse controle quando ela saía da empresa. Agora não... Com as tecnologias agregadas ao Windows Server 2008, o Administrador de Redes passa a ter mais controle sobre a informação que circula tanto dentro quanto fora da empresa. É como se a barreira que dividia essas fronteiras deixasse de existir.
E tudo isso é apenas uma pequena fatia do bolo. O Windows Server 2008 possui muitas outras tecnologias e funcionalidades para gerenciar a informação da empresa. E como disse anteriormente, todas já inclusas no sistema operacional. Go enable it!
Hoje, temos no mercado o Windows Server 2008, já em seu Release 2. O primeiro sistema operacional da Microsoft exclusivo para plataforma 64 bits (tá na hora de trocar o chip!). Uma coisa que me chamou muito a atenção nestes anos de evolução do Windows, foi a evolução do Active Directory. Não só da tecnologia em si, mas da sua relação com o conceito de "Segurança" e, mais atualmente, com o conceito de "TI Verde".
Lá na época do Windows NT 4.0, a preocupação estava somente na identificação de acesso local, ou seja, dentro da minha empresa eu tenho um usuário e uma senha que me dão acesso a certos recursos da rede da minha empresa e só. O mundinho estava resumido ali dentro. Dentro da empresa, haviam apenas os computadores da empresa. Na época em questão, o foco da segurança estava no acesso físico: Fulano podia usar o computador do RH, mas não podia usar o computador do Financeiro. Além disso, o conceito de "Administração de Rede" também estava no jardim de infância: Tínhamos ferramentas para administrar os servidores, mas não os demais computadores, a quem carinhosamente chamamos de Estações de Trabalho. A manutenção e configuração das Estações de Trabalho ocorria in-place, ou seja, o técnico se deslocava até o local onde a Estação de Trabalho estava. Isso até que era bom, pois ajudava a queimar uma gordurinha... Mas essa falta de recursos de administração centralizada das Estações de Trabalho começou a pesar. Então, a Microsoft criou esse "recurso" que faltava e o introduziu em seu novo sistema operacional.
Com o Windows 2000 Server, o Active Directory apresentou uma nova tecnologia chamada "Política de Grupo" (Group Policy). Através dela, passou a ser possível definir políticas (dããã...) de configuração dos Servidores e Estações de Trabalho de forma centralizada, como por exemplo, bloqueio ao Painel de Controle ou alteração do Papel de Parede. Nessa época o foco da segurança começou a olhar para um carinha que estava batendo na porta de todas as empresas: a Internet. A preocupação era fechar todas as portas de entrada. Colocava-se um exército de prontidão na borda da rede vigiando todo o tráfego de entrada e saída. E o "mundinho" começava a ganhar novos territórios...
Lá pela época do Windows Server 2003, com a Internet já consolidada e a idéia da interatividade ganhando seu espaço, os "dispositivos interativos" começaram a ser mais frequentes dentro das empresas. E o exército que antes ficava de prontidão lá na borda da rede começou a se perguntar: "Pois é... estamos aqui vigiando quem entra e quem sai, mas e quem está lá dentro? Será que não está fazendo alguma coisa?". E a segurança que antes só se preocupava com o acesso físico e que depois passou a se preocupar com a borda da rede, agora estava preocupada com a segurança interna também. O vírus que conseguia passar a barreira da borda se disseminava rapidamente dentro da empresa, pois os computadores internos não estavam totalmente protegidos (Hum... será que o surgimento do Windows Firewall no Service Pack 2 do Windows XP foi por acaso?). Mas não eram só os computadores internos: agora haviam também os notebooks pessoais, os PDAs e os adoráveis "pendrives". Todos trafegando livremente dentro da rede corporativa.
E com toda essa "liberdade interna", quem era o doido pra dizer que não podia plugar o notebook na rede: seu Diretor Administrativo não entende bulhufas de informática e trás o notebook e quer que você o configure para acessar a rede corporativa, você teria coragem suficiente para olhar nos olhos dele e dizer: "Não vou fazer, pois seu notebook compromete a segurança da empresa..." Ok, vamos a um caso mais simples: O famoso "estagiário" trás o seu adorado pendrive de casa, pluga no computador da empresa, copia dados confidenciais e vai embora numa boa (porque estagiário sempre leva a culpa de tudo?). Outro caso: O Diretor Financeiro envia uma planilha por e-mail com a contabilidade anual da empresa para o consultor terceirizado e sabe-se lá o que ele vai fazer com essa informação.
Tá.. mas o que tudo isso tem haver com o Active Directory ou com a segurança?... TUDO!!!
Na época do Windows Server 2003, a Microsoft já possuía algumas ferramentas para controlar algumas das situações citadas acima, como o caso do Diretor Financeiro, mas foi com o Windows Server 2008 que tudo se consolidou. Para cada uma das situações apresentadas, o Windows Server 2008 possui uma tecnologia built-in, ou seja, já embutida no próprio sistema operacional. Não precisa fazer nenhum download adicional ou pagar a mais por isso. Basta apenas ativar e configurar:
- No caso do notebook do Diretor Administrativo, a Microsoft lançou uma tecnologia com o Windows Server 2008 chamada Network Access Protection (NAP). Através dela é possível definir regras de conformidade para que os computadores possam acessar a rede corporativa e, caso não atendam a essas regras, são direcionados a uma rede restrita onde poderão ser "remediadas". Por exemplo, se uma regra de conformidade exige que o software antivírus esteja atualizado e o software antivírus do notebook do Diretor Administrativo não estiver, o mesmo não terá acesso a rede corporativa até que atualize o software.
- No caso do estagiário com o pendrive, há uma nova Política de Segurança que controla o uso do pendrive dentro da empresa. Pode-se definir se ele pode ler ou gravar arquivos no pendrive.
- No caso do Diretor Financeiro, a Microsoft já possuía uma tecnologia que no Windows Server 2008 fora integrada ao Active Directory chamada Rights Management Services (RMS). Através dela é possível definir o que determinadas pessoas podem ou não fazer com um documento, planilha ou e-mail. Por exemplo, o Diretor Financeiro poderia definir que o consultor terceirizado poderia apenas abrir e imprimir a planilha e não alterar nenhuma informação. E pode-se ir além disso: ao invés do arquivo ir ao consultor, o consultor pode vir até o arquivo, sem precisar sair de seu escritório. Ahm!? Outra tecnologia que fora integrada ao Active Directory chamada Federation Services (FS), permite que usuários externos tenham acesso a sua rede interna. Existe uma outra tecnologia, mais antiga, que permite tal "integração" entre empresas diferentes chamada de "Relação de Confiança" (Trust Relationship). Só para esclarecer, o AD RMS é mais seguro que a Trust Relationship. Utilizando o AD RMS em conjunto com AD FS, o consultor terceirizado acessaria a planilha internamente, não poderia alterar nada e além disso, eliminaríamos o tráfego de e-mail pois a planilha não precisaria ser enviada a ninguém.
Perceberam como o foco da segurança e da identificação mudaram? O que antes era restrito à empresa passou a ser necessidade fora dela. Antes, o Administrador de Redes tinha controle sobre a informação que circulava internamente, mas perdia esse controle quando ela saía da empresa. Agora não... Com as tecnologias agregadas ao Windows Server 2008, o Administrador de Redes passa a ter mais controle sobre a informação que circula tanto dentro quanto fora da empresa. É como se a barreira que dividia essas fronteiras deixasse de existir.
E tudo isso é apenas uma pequena fatia do bolo. O Windows Server 2008 possui muitas outras tecnologias e funcionalidades para gerenciar a informação da empresa. E como disse anteriormente, todas já inclusas no sistema operacional. Go enable it!
quarta-feira, 20 de outubro de 2010
MDT 2010
Sem dúvida, uma das tarefas mais tediosas de qualquer Equipe de TI é a distribuição (deploy) do Windows aos computadores de uma empresa:
- CD/DVD de instalação no drive;
- Acompanhar todo o assistente de instalação, respondendo as perguntas que vão aparecendo (nome do computador, fuso horário, senha do administrador, etc.);
- Instalar os drivers dos dispositivos que não foram detectados;
- Instalar os programas que serão utilizados;
- Rodar o Windows Update e aguardar algumas horas até que os megas de atualizações sejam todos aplicados;
- E por fim, desligar o computador, colocar outro na bancada e começar tudo de novo.
Tudo bem, exagerei um pouco... Na bancada talvez tenha espaço para dois ou três computadores e o processo fica um pouco mais rápido... Ou melhor ainda: você põe o estagiário para fazer o serviço, diz que precisa das máquinas no dia seguinte cedo e deixa o infeliz virar a noite para concluir a tarefa. :)
Deixando a brincadeira de lado, o cenário acima não foge muito da realidade de algumas empresas que ainda realizam seus deploys de Windows "na mão". Em alguns casos, por total desconhecimento das soluções e tecnologias que a Microsoft dispõe para tornar essa tarefa um verdadeiro "mamão com açúcar"; e em outros casos, por usarem software não legalizado em seu ambiente corporativo, o que trava a implantação dessas soluções e tecnologias.
É um barato que sai caro: Deixam de investir em licenciamento, sobrecarrega a mão de obra que já é escassa, gasta-se um tempo absurdo para manutenção do equipamento e para melhorar: "é tudo pra ontem!" Se soubessem de todo o "arsenal" que se adquire com apenas uma licença do Windows Server, acho que não pensariam duas vezes. Mas, deixemos esse assunto de lado. Vamos voltar ao deploy do Windows:
É possível automatizar todas as etapas descritas acima de forma que, apenas algumas ou nenhuma delas necessite da interação do Técnico de TI. É isso mesmo que você leu: é possível instalar o Windows, instalar os programas, como Office e Antivírus; e atualizar o Windows sem que o Técnico de TI nem precise chegar perto do computador. :S Esse ambiente de interação zero é chamado de Zero Touch Installation (ZTI). A Microsoft fornece o System Center Configuration Manager (SCCM) como a solução para implantação de um ambiente ZTI em uma rede corporativa. Devido a complexidade e robustez do SCCM, essa solução é mais comumente aplicada em grandes empresas que precisam gerenciar milhares de computadores.
Existe um outro ambiente onde a interação do Técnico de TI com o computador é menor do que o método pré-histórico lá do início do post, chamado de Lite Touch Installation (LTI). Existem diversas soluções para implantação de um ambiente LTI em uma rede corporativa, mas há uma ferramenta da Microsoft excepcional para essa tarefa: o Microsoft Deployment Toolkit (MDT). Vantagem do MDT: é gratuito. Outra vantagem do MDT: demanda menos hardware para sua implantação.
Atualmente na versão 2010, o MDT tem suporte para deploy do Windows 7 e ainda mantém suporte para deploy do Windows XP. Além disso, é possível instalar outros programas (como Office, Leitor de PDF, antivirus, entre outros) que podem ser previamente definidos ou listados ao Técnico de TI para que decida quais serão instalados.Outro recurso é a criação de um banco de drivers que instala automaticamente todo o hardware do computador sem que o Técnico de TI necessite colocar o CD/DVD da placa mãe na unidade local. E pra fechar com chave de outro, o MDT se conecta a um servidor WSUS local para atualização do Windows e demais aplicativos Microsoft. Em resumo, você pega uma máquina Bare Metal (limpa, sem sistema operacional) e termina com uma máquina pronta para uso sem muito esforço. O trabalho de várias horas cai para alguns minutos.
Mas se o seu problema é a migração do Windows XP para o Windows 7, não tem problema: o MDT também realiza essa tarefa e ainda preserva os dados locais do usuário.
O MDT em si, utiliza um CD bootável para que o computador cliente se conecte ao seu ambiente LTI. Mas como na Microsoft tudo gira em torno da "integração" (Amo muito tudo isso), é possível utilizar o serviço WDS do Windows Server 2008 para realizar um boot via placa de rede diretamente no ambiente LTI, sem a necessidade do CD do MDT (PXE boot). Como dizem por aí: "Fala sério!" Tá esperando o que para implantar o MDT? Um passo-a-passo?
Bom... eu estava pensando mesmo em escrever um passo-a-passo, mas achei excelentes materiais, que foram os quais estudei, e ao invés de escrever, vou postar os links aqui para que os interessados trilhem o mesmo caminho. Mas antes disso, gostaria de explicar um assunto relacionado ao deploy do Windows XP que pode ser uma verdadeira pedra no sapato dos marinheiros de primeira viagem.
O Windows XP e a HAL
Hardware Abstraction Layer ou HAL pode ser definida como o meio de comunicação entre o kernel do sistema operacional e a placa mãe/processador do computador. Algo como um "driver". Dependendo da arquitetura da placa mãe e do processador, o Windows XP pode utilizar diferentes tipos de HALs:
Calma... antes que comece a se questionar sobre a inviabilidade deste processo ou se existe algum mecanismo para descobrir a HAL do computador antes do deploy da imagem, preste bem atenção na frase e veja que eu usei o verbo no passado. Existe uma forma de substituir a HAL do computador logo após a aplicação da imagem. Vou postar o link aqui também.
Falem mal, mas falem de mim (by Windows Vista)
Muita gente falou mal do Windows Vista... "Era pesado..." "Era lento..." "bla bla bla..." Eu continuo me mantendo neutro nessa discussão, até porque utilizei-o muito pouco. Na minha empresa ainda reina o Windows XP. Mas nessa discussão, sempre me pergunto se o problema era realmente o Windows Vista ou o hardware utilizado. Sim, porque a maioria quer utilizar um hardware de 3 ou 4 anos atrás para rodar um sistema operacional ou software que foi lançado ontem e quer que o computador funcione bem. Atualização não é só de software não, é hardware também.
E no meio de tantas "reclamações", uma coisa boa: a partir do Windows Vista, o sistema operacional passou a ser independente da HAL. Você pode montar sua imagem de referência em um Intel I7 com 4 GB de RAM e aplicar no seu Pentium III com 1 GB de RAM que o sistema irá funcionar tranquilamente (lógico que observando as plataformas 32 e 64 bits).
Falem mal, mas falem de mim... Deixe de lado o que os outros dizem e procure conhecer a novidades tecnológicas que o Vista trouxe. Lembrem-se que o Windows 7 só existe porque existiu o Windows Vista e que boa parte das tecnologias do Windows 7 foram herdadas do Windows Vista. Deixe de ser "Maria-vai-com-as-outras" e tire suas próprias conclusões. Tenha opinião própria. Isso não é um sermão. É uma dica. ;)
Cala a boca, Chris
Ufa... Chega por hoje, já falei muito para um post só. Mas antes, mais algumas dicas: ^^
Mitch Tulloch fez um material fantástico para o site WindowsNetworking.com sobre deploy do Windows 7. O mesmo guia pode ser utilizado para deploy do Windows XP. O link é:
http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part1.html
Michael Pertersen postou em seu blog o script para substituição da HAL durante o deploy do Windows XP. O script funciona no MDT 2008 mas possui uma incompatibilidade com o MDT 2010. Veja no final da página a discussão sobre esse assunto e como corrigir o problema. O link é:
http://osdeploy.wordpress.com/2009/04/08/handling-hal-switching-during-xp-deployment-no-bsod-0x07-error/
Christiano Mendes (ops... esse sou eu :P) vai deixar aqui algumas dicas extras para incrementar a configuração do MDT:
A segunda linha configura o fuso-horário no Windows XP para Brasília.
A terceira linha configura o fuso-horário no Windows 7 para Brasília.
Durante a captura da imagem de referência do Windows XP, o MDT reportou um erro informando que o Sysprep que eu estava usando estava desatualizado. O motivo era que eu estava usando um CD do Windows XP com o Service Pack 3 já embutido. Mas o que isso tem haver??? Tem haver que a injeção do Service Pack 3 no CD do Windows XP não atualizou o conteúdo do arquivo deploy.cab situado na pasta SUPPORT do CD, ou seja, Sysprep desatualizado. Para resolver esse problema, baixe o arquivo deploy.cab atualizado e substitua o arquivo no "source file" do Windows XP na pasta do MDT. O link é:
http://www.microsoft.com/downloads/en/details.aspx?familyid=673a1019-8e3e-4be0-ac31-70dd21b5afa7&displaylang=en
Caso o autologin falhe durante o deploy da imagem customizada do Windows XP, vá nas propriedades da imagem customizada, edite o arquivo unattended.txt e insira a senha do administrador local que você definiu durante a captura da imagem de referência.
E por hoje é só. Até a próxima.
- CD/DVD de instalação no drive;
- Acompanhar todo o assistente de instalação, respondendo as perguntas que vão aparecendo (nome do computador, fuso horário, senha do administrador, etc.);
- Instalar os drivers dos dispositivos que não foram detectados;
- Instalar os programas que serão utilizados;
- Rodar o Windows Update e aguardar algumas horas até que os megas de atualizações sejam todos aplicados;
- E por fim, desligar o computador, colocar outro na bancada e começar tudo de novo.
Tudo bem, exagerei um pouco... Na bancada talvez tenha espaço para dois ou três computadores e o processo fica um pouco mais rápido... Ou melhor ainda: você põe o estagiário para fazer o serviço, diz que precisa das máquinas no dia seguinte cedo e deixa o infeliz virar a noite para concluir a tarefa. :)
Deixando a brincadeira de lado, o cenário acima não foge muito da realidade de algumas empresas que ainda realizam seus deploys de Windows "na mão". Em alguns casos, por total desconhecimento das soluções e tecnologias que a Microsoft dispõe para tornar essa tarefa um verdadeiro "mamão com açúcar"; e em outros casos, por usarem software não legalizado em seu ambiente corporativo, o que trava a implantação dessas soluções e tecnologias.
É um barato que sai caro: Deixam de investir em licenciamento, sobrecarrega a mão de obra que já é escassa, gasta-se um tempo absurdo para manutenção do equipamento e para melhorar: "é tudo pra ontem!" Se soubessem de todo o "arsenal" que se adquire com apenas uma licença do Windows Server, acho que não pensariam duas vezes. Mas, deixemos esse assunto de lado. Vamos voltar ao deploy do Windows:
É possível automatizar todas as etapas descritas acima de forma que, apenas algumas ou nenhuma delas necessite da interação do Técnico de TI. É isso mesmo que você leu: é possível instalar o Windows, instalar os programas, como Office e Antivírus; e atualizar o Windows sem que o Técnico de TI nem precise chegar perto do computador. :S Esse ambiente de interação zero é chamado de Zero Touch Installation (ZTI). A Microsoft fornece o System Center Configuration Manager (SCCM) como a solução para implantação de um ambiente ZTI em uma rede corporativa. Devido a complexidade e robustez do SCCM, essa solução é mais comumente aplicada em grandes empresas que precisam gerenciar milhares de computadores.
Existe um outro ambiente onde a interação do Técnico de TI com o computador é menor do que o método pré-histórico lá do início do post, chamado de Lite Touch Installation (LTI). Existem diversas soluções para implantação de um ambiente LTI em uma rede corporativa, mas há uma ferramenta da Microsoft excepcional para essa tarefa: o Microsoft Deployment Toolkit (MDT). Vantagem do MDT: é gratuito. Outra vantagem do MDT: demanda menos hardware para sua implantação.
Atualmente na versão 2010, o MDT tem suporte para deploy do Windows 7 e ainda mantém suporte para deploy do Windows XP. Além disso, é possível instalar outros programas (como Office, Leitor de PDF, antivirus, entre outros) que podem ser previamente definidos ou listados ao Técnico de TI para que decida quais serão instalados.Outro recurso é a criação de um banco de drivers que instala automaticamente todo o hardware do computador sem que o Técnico de TI necessite colocar o CD/DVD da placa mãe na unidade local. E pra fechar com chave de outro, o MDT se conecta a um servidor WSUS local para atualização do Windows e demais aplicativos Microsoft. Em resumo, você pega uma máquina Bare Metal (limpa, sem sistema operacional) e termina com uma máquina pronta para uso sem muito esforço. O trabalho de várias horas cai para alguns minutos.
Mas se o seu problema é a migração do Windows XP para o Windows 7, não tem problema: o MDT também realiza essa tarefa e ainda preserva os dados locais do usuário.
O MDT em si, utiliza um CD bootável para que o computador cliente se conecte ao seu ambiente LTI. Mas como na Microsoft tudo gira em torno da "integração" (Amo muito tudo isso), é possível utilizar o serviço WDS do Windows Server 2008 para realizar um boot via placa de rede diretamente no ambiente LTI, sem a necessidade do CD do MDT (PXE boot). Como dizem por aí: "Fala sério!" Tá esperando o que para implantar o MDT? Um passo-a-passo?
Bom... eu estava pensando mesmo em escrever um passo-a-passo, mas achei excelentes materiais, que foram os quais estudei, e ao invés de escrever, vou postar os links aqui para que os interessados trilhem o mesmo caminho. Mas antes disso, gostaria de explicar um assunto relacionado ao deploy do Windows XP que pode ser uma verdadeira pedra no sapato dos marinheiros de primeira viagem.
O Windows XP e a HAL
Hardware Abstraction Layer ou HAL pode ser definida como o meio de comunicação entre o kernel do sistema operacional e a placa mãe/processador do computador. Algo como um "driver". Dependendo da arquitetura da placa mãe e do processador, o Windows XP pode utilizar diferentes tipos de HALs:
- Advanced Configuration and Power Interface (acpipic_up): halacpi.dll, ntoskrnl.exe, ntkrnlpa.exe
- ACPI Uniprocessor PC (acpiapic_up): halaapic.dll, ntoskrnl.exe, ntkrnlpa.exe
- ACPI Multiprocessor PC (acpiapic_mp): halmacpi.dll, ntkrnlmp.exe, ntkrpamp.exe
Calma... antes que comece a se questionar sobre a inviabilidade deste processo ou se existe algum mecanismo para descobrir a HAL do computador antes do deploy da imagem, preste bem atenção na frase e veja que eu usei o verbo no passado. Existe uma forma de substituir a HAL do computador logo após a aplicação da imagem. Vou postar o link aqui também.
Falem mal, mas falem de mim (by Windows Vista)
Muita gente falou mal do Windows Vista... "Era pesado..." "Era lento..." "bla bla bla..." Eu continuo me mantendo neutro nessa discussão, até porque utilizei-o muito pouco. Na minha empresa ainda reina o Windows XP. Mas nessa discussão, sempre me pergunto se o problema era realmente o Windows Vista ou o hardware utilizado. Sim, porque a maioria quer utilizar um hardware de 3 ou 4 anos atrás para rodar um sistema operacional ou software que foi lançado ontem e quer que o computador funcione bem. Atualização não é só de software não, é hardware também.
E no meio de tantas "reclamações", uma coisa boa: a partir do Windows Vista, o sistema operacional passou a ser independente da HAL. Você pode montar sua imagem de referência em um Intel I7 com 4 GB de RAM e aplicar no seu Pentium III com 1 GB de RAM que o sistema irá funcionar tranquilamente (lógico que observando as plataformas 32 e 64 bits).
Falem mal, mas falem de mim... Deixe de lado o que os outros dizem e procure conhecer a novidades tecnológicas que o Vista trouxe. Lembrem-se que o Windows 7 só existe porque existiu o Windows Vista e que boa parte das tecnologias do Windows 7 foram herdadas do Windows Vista. Deixe de ser "Maria-vai-com-as-outras" e tire suas próprias conclusões. Tenha opinião própria. Isso não é um sermão. É uma dica. ;)
Cala a boca, Chris
Ufa... Chega por hoje, já falei muito para um post só. Mas antes, mais algumas dicas: ^^
- Vocês devem ter reparado que usei algumas siglas aqui (WSUS, WDS, PXE, ...) e não expliquei muito bem o que são. Foi prosital. Por quê? Para que vocês pesquisem. Google, Wikipedia ou seja lá onde for. Busquem a informação. Viu um termo que não conhece, corra atrás. Essa dinâmica faz muita diferença entre um profissional de TI que corre atrás e aquele que espera a informação vir até ele.
- Inglês... é *IMPRESCINDÍVEL*. A maioria dos materiais técnicos que você encontrar vão estar em inglês. Tem preguiça em estudar, sinto muito, acho melhor procurar outra profissão.
Mitch Tulloch fez um material fantástico para o site WindowsNetworking.com sobre deploy do Windows 7. O mesmo guia pode ser utilizado para deploy do Windows XP. O link é:
http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part1.html
Michael Pertersen postou em seu blog o script para substituição da HAL durante o deploy do Windows XP. O script funciona no MDT 2008 mas possui uma incompatibilidade com o MDT 2010. Veja no final da página a discussão sobre esse assunto e como corrigir o problema. O link é:
http://osdeploy.wordpress.com/2009/04/08/handling-hal-switching-during-xp-deployment-no-bsod-0x07-error/
Christiano Mendes (ops... esse sou eu :P) vai deixar aqui algumas dicas extras para incrementar a configuração do MDT:
- No arquivo CustomSettings.ini acrescente as seguintes linhas:
- _SMSTSORGNAME=[Nome da Empresa]
- TimeZone=065
- TimeZoneName=E. South America Standard Time
A segunda linha configura o fuso-horário no Windows XP para Brasília.
A terceira linha configura o fuso-horário no Windows 7 para Brasília.
Durante a captura da imagem de referência do Windows XP, o MDT reportou um erro informando que o Sysprep que eu estava usando estava desatualizado. O motivo era que eu estava usando um CD do Windows XP com o Service Pack 3 já embutido. Mas o que isso tem haver??? Tem haver que a injeção do Service Pack 3 no CD do Windows XP não atualizou o conteúdo do arquivo deploy.cab situado na pasta SUPPORT do CD, ou seja, Sysprep desatualizado. Para resolver esse problema, baixe o arquivo deploy.cab atualizado e substitua o arquivo no "source file" do Windows XP na pasta do MDT. O link é:
http://www.microsoft.com/downloads/en/details.aspx?familyid=673a1019-8e3e-4be0-ac31-70dd21b5afa7&displaylang=en
Caso o autologin falhe durante o deploy da imagem customizada do Windows XP, vá nas propriedades da imagem customizada, edite o arquivo unattended.txt e insira a senha do administrador local que você definiu durante a captura da imagem de referência.
E por hoje é só. Até a próxima.
quarta-feira, 15 de setembro de 2010
Como surgiu o Active Directory?
O objetivo principal de uma rede de dados é compartilhar informações. Mas esse compartilhamento requer medidas de segurança a fim de evitar que pessoas não autorizadas tenham acesso a determinadas informações. Essa medida de segurança chama-se “Identidade e Acesso” (Identity and Access ou simplesmente, IDA).
Tendo o conceito em mente, o próximo passo era criar um repositório para armazenar as informações de IDA. Este repositório foi chamado de “Serviço de Diretório de Rede” (Network Directory Services ou mais comumente, Directory Services).
O objetivo do Serviço de Diretório é armazenar, organizar, gerenciar e compartilhar informações e recursos comuns de rede, como: usuários, grupos, computadores, impressoras, pastas compartilhadas, entre outros. Cada um desses recursos citados é considerado como um objeto dentro do diretório. Informações sobre um recurso em particular são armazenadas como atributos daquele objeto.
Um Serviço de Diretório é um componente fundamental para qualquer Sistema Operacional de Rede (Network Operating System ou simplesmente, NOS). É neste contexto que contaremos a história de um desses Serviços de Diretório lançado pela Microsoft, o NT Domains...
Era uma vez, um sistema operacional chamado Windows NT. Apesar de sua sigla significar “Nova Tecnologia” (New Technology), o Windows NT era muito limitado em sua tecnologia.
Sua base de dados de usuários, mais conhecida como SAM (Security Account Manager) não podia exceder um determinado tamanho físico de, aproximadamente, 192 MB (megabytes), e por isso, não podia chegar à casa dos milhões de usuários.
O Windows NT introduziu o conceito de Controlador de Domínio (Domain Controller ou simplesmente, DC). Cabia aos DCs autenticar os usuários (através de um login e uma senha) e prover acesso aos recursos de rede autorizados para aquele usuário. Os DCs se dividiam em PDC (Primary Domain Controller) e BDC (Backup Domain Controller). O PDC era o Highlander da rede (só podia haver um) e os BDCs tantos quantos fossem necessários. Somente o PDC podia gravar alterações na SAM. Os BDCs apenas aliviavam a carga de autenticação. Como somente o Highlander podia alterar a SAM, caso sua cabeça fosse decepada, ninguém mais poderia mexer na SAM. Usuários continuariam sendo autenticados na rede pelos BDCs, mas tarefas como alteração de senha ou criação de novos usuários não poderiam ser feitas.
O Administrador da Rede, dotado de poderes cósmicos, podia promover um BDC para PDC, mas como em todo filme, o mocinho nunca morre, se o PDC original voltasse ao ar, teríamos um problema na rede com dois Highlanders.
Outo problema neste modelo PDC/BDC estava na replicação das alterações: Quanto mais BDCs na rede, mais replicações para o PDC. Geralmente, o PDC possuía hardware mais potente que os BDCs devido a essa demanda de serviço. Quando o Highlander morria e um BDC era promovido, devido ao hardware inferior, o servidor não dava conta do recado.
Os servidores que não eram Controladores de Domínio eram chamados de Servidores Membro (Member Servers). Não era possível promover um Servidor Membro à Controlador de Domínio porque a estrutura da SAM era completamente diferente. A única forma de promoção (Membro para Controlador) ou demoção (Controlador para Membro) era através da reinstalação do servidor.
Como se não bastasse, o NT amarrava tanto a sua base de dados, que não permitia integração com outras aplicações baseadas em servidor, como o SQL Server por exemplo. Com isso, uma pessoa tinha que utilizar um usuário e senha para ser autenticado na rede e outro usuário e senha para acessar o banco de dados.
Em resumo, muita coisa precisava ser melhorada no NT Domains. Foi então que a Microsoft resolveu apostar em outro Serviço de Diretório...
Era uma vez, um grupo de pessoas que formavam a União Internacional de Telecomunicações (International Telecommunication Union – ITU). Esse grupo, espalhado em aproximadamente 130 países, é uma agência das Nações Unidas que age como um fórum para governos que buscam um consenso em questões de telecomunicações globais.
Lá pela década de 80, a ITU lançou um documento chamado “X.500 – Data Network and Open System Communications – Directory”, contendo uma série de recomendações para os Serviços de Diretório. Mas a ITU não definia padrões, apenas recomendava. O órgão responsável pelas padronizações internacionais é a Organização Internacional para Padronização (International Organization for Standardization – ISO).
Uma observação: a sigla ISO não se encaixa no nome International Organization for Standardization, que deveria ser IOS. Isso é porque ISO vem do grego isos e significa “igual”. Este padrão foi adotado para evitar a variação das siglas na tradução do nome International Organization for Standardization: IOS em inglês, OIP em português e assim por diante.
Para padronizar a sua recomendação X.500 a ITU procurou a ISO e esta por sua vez lançou a ISO 9594 “Information Technology – Open Systems Interconnection – The Directory”. O problema do X.500 da ITU era o protocolo de acesso utilizado, o Directory Access Protocol (DAP), que além de consumir muita banda, dependia da pilha do protocolo OSI, que fora pouco adotado devido a sua complexidade.
Pouco tempo depois da padronização do X.500, surgiu um grupo de especialistas com foco voltado para as atividades com a Internet, chamado Internet Engineering Task Force (IETF). Este grupo possui tamanha influência sobre a Internet, que consegue sobrepor padronizações ISO e recomendações ITU a cerca de protocolos de comunicações que acharem úteis, através de documentos chamados Request for Comments (RFCs).
E foi através da RFC 1777 “Lighweight Directory Access Protocol” que surgiu o protocolo LDAP. Durante o seu desenvolvimento, o LDAP foi chamado de Lightweight Directory Browsing Protocol (LDBP), mas foi renomeado quando deixou de ser apenas um protocolo de consulta e incorporou funções de update.
Atualmente, o LDAP se encontra na versão 3, RFC 2251. Não há padronização ISO ou recomendação ITU para o LDAP. Mas devido ao seu baixo consumo de banda e utilização da pilha do protocolo TCP/IP, diversas soluções baseadas na implementação LDAP/X.500 começaram a ser desenvolvidas.
E foi baseada na implementação LDAP/X.500, que a Microsoft lançou seu novo Serviço de Diretório chamado Windows NT Directory Services (NTDS) que, posteriormente, seria conhecido como Active Directory.
Com o Active Directory (AD), a Microsoft deu um salto gigantesco e trouxe novos conceitos, novas funcionalidades e novas tecnologias ao seu Serviço de Diretório. Dentre eles:
- Sua base de dados, agora baseada no modelo X.500, comporta bilhões de objetos;
- O modelo PDC/BDC deixou de existir (sim, o Highlander morreu). No AD, cada Controlador de Domínio consegue ler e gravar na base de dados e replicar as alterações aos demais Controladores de Domínio, utilizando um processo chamado Multi-master replication;
- A promoção ou demoção de um Controlador de Domínio passou a ser realizada sem a necessidade de reinstalação do sistema operacional;
- O acesso às informações do Diretório foi facilitado através de métodos mais simplificados de segurança e interfaces de acesso, o que permitiu maior integração com aplicações baseadas em servidor e a utilização de login único (Single Sign-On – SSO) para acesso a vários serviços de rede.
O Active Directory foi lançado oficialmente em 1999 com o Windows 2000 Server. Já são 11 anos de vida.
Assinar:
Postagens (Atom)