Instalando e Configurando os Clientes do WSUS (pt-BR)

Objetivo

Esse artigo tem como objetivo demonstrar como instalar e configurar os clientes do WSUS de forma rápida e fácil.

Aplica-se a:

  • Windows XP Professional RTM, SP1, SP2 ou versões mais recentes;
  • Windows Vista;
  • Windows 7;
  • Windows Small Business Server 2003, 2005 ou 2008;
  • Windows Server 2003 SP2 ou versões mais recentes;
  • Windows Server 2008 SP1 ou versões mais recentes;
  • Windows Server 2008 R2.

Introdução

Os computadores clientes do WSUS precisam ter uma versão compatível do Automatic Updates (Atualizações Automáticas) para comunicar-se com o servidor WSUS. A instalação do WSUS configura automaticamente o IIS para distribuir a versão mais recente do Automatic Updates (Atualizações Automáticas) para cada computador cliente que se conecta ao servidor do WSUS.

A recomendação é configurar o Automatic Updates (Atualizações Automáticas) através do Active Directory. Você poderá usar um Group Policy Object (GPO) para configurar os computadores clientes, para buscar as atualizações de segurança e patches no servidor WSUS de forma automática. Caso você ainda não tenha o Active Directory em seu ambiente será necessário configurar manualmente uma GPO Local em cada computador cliente.

Nota

Para saber como instalar e configurar o Active Directory consulte o artigo Instalando e Configurando o Active Directory no Windows Server 2008 (pt-BR).

Instalando e Configurando os clientes do WSUS

Nesse artigo iremos configurar passo a passo uma GPO para configurar os clientes WSUS através do Active Directory:

1 – Clique em Start, All Programs, Administrative Tools, Group Policy Management. Será carregada a janela como mostra a figura 1.1.

Figura 1.1

2 – Selecione o local onde as contas dos computadores clientes estão localizadas, para que você possa configurar uma GPO, o qual irá configurar os clientes do WSUS. Nesse artigo iremos criar uma OU com o nome Lab e a abaixo dela serão criadas outras duas OUs, uma com o nome Clientes, o qual contém contas de computadores de clientes e a outra com o nome Servidores, o qual contém contas de computadores de servidores. Existem várias formas para configurar os clientes WSUS, escolha a que melhor se adapte ao seu ambiente. Nesse artigo iremos separar computadores clientes de servidores para criar políticas diferentes de distribuição dos patches, atualizações de segurança e horário de instalação.

3 – Selecione a OU Clientes, e clique com o botão direito e escolha a opção Create a GPO in this domain, and Link it here. Será carrega a caixa de diálogo como mostra a figura 1.2.

Figura 1.2

4 – Na caixa de diálogo New GPO no campo New digite o nome da GPO, como por exemplo, Clientes WSUS e clique no botão OK. A janela do Group Policy Management ficará conforme mostra a figura 1.3.

Figura 1.3

5 – Selecione a GPO Clientes WSUS e clique com o botão direito e escolha a opção Edit. Será carregada a janela conforme mostra a figura 1.4.

Figura 1.4

6 – Expanda o nó Computer Configuration, Policies, Administrative Templates, Windows Componentes, Windows Update. Será carrega a janela como mostra a figura 1.5.

Figura 1.5

Nota

Dependendo da versão do Administrative Template do seu servidor, as opções poderão estar diferentes das apresentas abaixo, porém basicamente todas elas irão configurar o cliente WSUS conforme as opções disponíveis em cada template.

 
7 – No painel da direita de um clique duplo na opção Do not display ‘Install Updates and Shut Down’ option in Shut Down Windows dialog box. Será carrega a caixa de diálogo como mostra a figura 1.6.

Figura 1.6

Esta configuração de política permite você controlar se a opção Install Updates and Shut Down será mostrada na caixa de diálogo Shut Down Windows.

Se você selecionar a opção Enabled, irá ativar esta configuração de política e a opção Install Updates and Shut Down não irá aparecer na caixa de diálogo Shut Down Windows, mesmo se a atualização estiver disponível para ser instalada quando o usuário selecionar a opção Shut Down no menu Start.

Se você selecionar a opção Disabled ou Not Configured para desativar esta configuração de política, a opção Install Updates and Shut Down estará disponível na caixa de diálogo Shut Down Windows se a atualização estiver disponível quando o usuário selecionar a opção Shut Down no menu Start.

8 – Selecione a opção Disabled, clique no botão Apply e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.7.

Figura 1.7

Esta configuração de política permite você controlar se a opção Install Updates and Shut Down é permitida para ser a opção default dentro da caixa de diálogo Shut Down Windows.

Se você selecionar a opção Enabled para ativar esta configuração de política, o usuário que escolher a opção Shut Down, será a opção default dentro da caixa de diálogo Shut Down Windows sem levar em consideração se a opção Install Updates and Shut Down está disponível dentro da lista What do you want the computer to do?

Se você selecionar a opção Disabled ou Not Configured para desativar esta configuração de política, a opção Install Updates and Shut Down será a opção default dentro da caixa de diálogo Shut Down Windows, se a atualização estiver disponível para instalação na hora que o usuário selecionar a opção Shut Down no menu Start.

 

Nota

Esta configuração de política não tem impacto se a opção Do not display Install Updates and Shut Down estiver configurada com a opção Enabled.
 

9 – Selecione a opção Disabled, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.8.

Figura 1.8

Esta configuração de política especifica se o Windows Update irá usar o gerenciamento de energia do Windows para automaticamente acordar o sistema da hibernação, se houver agendado para instalação.

Windows Update só irá automaticamente acordar o sistema se o Windows Update estiver configurado para instalar as atualizações automaticamente. Se o sistema estiver em estado de hibernação quando o tempo de instalação agendada ocorrer e houver para ser aplicado, então o Windows Update utilizará o gerenciamento de energia do Windows para ativar o sistema automaticamente até instalar as atualizações.

Windows update também ativará o sistema e instalará uma atualização se um prazo de instalação ocorrer.

O sistema não vai acordar, a menos que houver para ser instalado. Se o sistema estiver com a bateria, quando o Windows Update acorda-lo, ele não vai instalar atualizações e o sistema retornará automaticamente para hibernação em 2 minutos.

10 – Selecione a opção Enabled, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.9.

Figura 1.9

Esta configuração de política permite você configurar a atualização automática, definir o tipo da atualização, e qual o dia e hora que serão executadas às atualizações.

Se esta configuração de política for ativada você poderá escolher entre os quatros tipos de atualizações disponíveis nesta política. As opções são as seguintes:

  • 2 – Notify for download and notify for install – Se você selecionar essa opção, o cliente deve ser notificado antes do download de qualquer atualização e notificado antes da instalação.
     
  • 3 – Auto download and notify for install – Se você selecionar essa opção, irá permite a atualização automaticamente para os computadores clientes, sendo notificado somente antes da instalação.
     
  • 4 – Auto download and schedule the install – Se você selecionar essa opção, o download de todas as atualizações aprovadas será executado e instalado nos computadores clientes sem intervenção do usuário.
     
  • 5 – Allow local admin to choose setting – Se você selecionar essa opção, os administradores locais poderão usar o Automatic Updates através do Control Painel para selecionar a opção de configuração de sua escolha.
     

Na opção Schedule install day, você define o dia da semana que a instalação das atualizações será agendada para ser instalada.

Na opção Scheduled install time, você define a hora que a instalação das atualizações será agendada para ser instalada.

 

11 – Nesse artigo iremos selecionar a oção 4 – Auto download and schedule the install, que será executada todos os dias às 20:00, porém você poderá escolher entre qualquer uma das outras opções para atender melhor as suas necessidades. Clique no botão Apply e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.10.

Figura 1.10

Esta configuração de política permite que você especifique o nome do servidor WSUS do seu Domínio, o qual os clientes irão fazer o download das atualizações de segurança e patches.

12 – Selecione a opção Enabled para ativar a política, e em seguida no campo Set the intranet update service for detecting updates, digite o nome do servidor WSUS, como por exemplo, http://srv12. Esse é o nome NETBIOS do meu servidor, digite o nome NETBIOS do seu servidor. No campo Set the intranet statistics server, digite o nome do servidor no qual as estações irão atualizar as estatísticas das instalações, como por exemplo, http://srv12.

13 – Clique no botão Apply e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.11.

Figura 1.11

Esta configuração de política especifica as horas que o Windows utilizará para determinar quanto tempo irá esperar antes de verificar se há atualizações disponíveis. O tempo de espera exato é determinado usando o horário especificado aqui. Por exemplo, se esta política é utilizada para especificar uma frequência de detecção de 20 horas, em seguida, todos os clientes para que esta política é aplicada irá verificar se há atualizações em qualquer lugar entre 16 e 20 horas.

Se o status estiver definido como Enabled, o Windows irá verificar se há atualizações disponíveis no intervalo especificado.

Se o status estiver definido como Disabled ou Not Configured, o Windows irá verificar se há atualizações disponíveis no intervalo padrão de 22 horas.

Nota: A política “Specify intranet Microsoft update service location” deverá estar habilitada para que esta política possa surtir efeito.

Nota: Se a política “Configure Automatic Updates” estiver desativada, esta política não terá nenhum efeito.

14 – Selecione a opção Enabled para ativar a política, e em seguida em interval (hours) escolha o intervalo em horas para verificar a atualização. Nesse artigo iremos escolher 12 horas. Clique no botão Apply e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.12.

Figura 1.12

Esta configuração de política permite controlar se usuários não-administrativos receberão notificações das atualizações com base na definição de política Configure Automatic Updates.
     
Se você ativar esta configuração de política, o Windows Automatic Update e Microsoft Update irá incluir os usuários não-administradores ao determinar que o usuário conectado deve receber notificações das atualizações.

Existem duas situações em que o efeito dessa configuração depende do sistema operacional: Ocultar/Restaurar atualizações e Cancelar uma instalação.

No XP: Se você ativar esta configuração de política, os usuários não irão ver uma janela Controle de conta e não precisarão de permissões elevadas para fazer qualquer uma destas tarefas de atualização relacionadas.

No Vista: Se você ativar esta configuração de política, os usuários não irão ver uma janela Controle de conta e não precisam de permissões elevadas para fazer qualquer uma dessas tarefas. Se você não ativar esta configuração de diretiva, os usuários sempre verão uma janela Controle de conta que exige permissões elevadas para fazer qualquer uma dessas tarefas.

No Windows 7: Esta configuração de diretiva não tem efeito. Usuários sempre verão uma janela Controle de conta e exige permissões elevadas para fazer qualquer uma dessas tarefas.

Se você desabilitar ou não configurar essa política, somente os usuários administrativos receberão notificações de atualização.

Por padrão, essa configuração de política está desativada.

Se o Configure Automatic Updates estiver desativado ou não configurado, a política Elevate Non-Admin não terá efeito.

15 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.13.

Figura 1.13

Esta configuração de política permite que você controle se os usuários irão visualizar as mensagens de notificação de software a partir do serviço do Microsoft Update.

Se você ativar esta configuração de política, uma mensagem de notificação será exibida no computador do usuário quando o software apresentado estiver disponível. O usuário poderá clicar na notificação para abrir o aplicativo do Windows Update e obter mais informações sobre o software ou instalá-lo. O usuário também poderá clicar em “Fechar esta mensagem” ou “Mostre-me mais tarde” para adiar a notificação, conforme apropriado.

No Windows 7, essa configuração de política só irá controlar as notificações detalhadas para aplicativos opcionais. No Windows Vista, esta configuração de política irá controlar as notificações detalhadas para aplicativos opcionais e atualizações.

Se você desabilitar ou não configurar esta configuração de política, usuários do Windows 7 não será oferecido mensagens de notificação detalhadas para aplicativos opcionais, e os usuários do Windows Vista não será oferecido mensagens de notificação detalhadas para aplicativos opcionais ou atualizações.

Por padrão, essa configuração de diretiva está desativada.

Se você não estiver usando o serviço Microsoft Update a política Software Notifications não terá efeito.

Se a política Configure Automatic Updates estiver desativado ou não estiver configurado, a política Software Notifications não terá efeito.

16 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.14.

Figura 1.14

Esta configuração de política especifica se as Atualizações Automáticas deverão ser instalar automaticamente certas atualizações que não interrompam os serviços do Windows, nem reinicie o Windows.

Se o status estiver definido como Enabled, as atualizações automáticas irão imediatamente instalar estas atualizações, uma vez que foram baixadas e estão prontas para instalar.

Se o status for definido como Disabled, essas atualizações não serão instaladas imediatamente.

Nota: Se o Configure Automatic Updates estiver desativado, esta política não terá efeito.

17 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.15.

Figura 1.15

Esta configuração de política especifica se as Atualizações Automáticas irão entregar as atualizações importantes e recomendadas do serviço de atualização do Windows Update.

Quando esta política estiver Enabled, as atualizações automáticas irão instalar as atualizações recomendadas, bem como atualizações importantes do Windows Update de atualização do serviço.

Quando Disabled ou Not configured a Atualizações Automáticas continuará a oferecer atualizações importante se ele já estiver configurado para tal.

18 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.16.

Figura 1.16

Esta configuração de política especifica que para completar uma instalação agendada, as Atualizações Automáticas irão aguardar que o computador seja reiniciado por qualquer usuário que estiver conectado, em vez de reiniciar o computador automaticamente.

Se o status estiver definido como Enabled, a Atualizações Automáticas não irá reiniciar um computador automaticamente durante uma instalação agendada se um usuário estiver conectado ao computador. Em vez disso, as atualizações automáticas irão notificar o usuário para reiniciar o computador.

Esteja ciente de que o computador precisarã ser reiniciado para que as atualizações tenham efeito.

Se o status estiver definido como Disabled ou Not configured, as atualizações automáticas irão notificar o usuário que o computador irá reiniciar automaticamente em 5 minutos para concluir a instalação.

Nota: Esta política se aplica somente quando as Atualizações Automáticas estiverem configuradas para executar instalações agendadas de atualizações. Se a política Configure Automatic Updates estiver desativada, esta política não terá efeito.

19 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.17.

Figura 1.17

Esta configuração de política especifica a quantidade de tempo para atualizações automáticas esperar antes de solicitar novamente um restart agendado.

Se o status estiver definido como Enabled, uma reinicialização agendada irá ocorrer o número especificado de minutos após do prompt anterior para reinicialização que foi adiada.

Se o status estiver definido como Disabled ou Not configured, o intervalo padrão é de 10 minutos.

Nota: Esta política se aplica somente quando as Atualizações Automáticas estiverem configuradas para executar instalações agendadas de atualizações. Se a política Configure Automatic Updates estiver desativada, esta política não terá efeito.

20 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.18.

Figura 1.18

Esta configuração de política especifica a quantidade de tempo para atualizações automáticas esperar antes de prosseguir com um restart agendado.

Se o status estiver definido como Enabled, uma reinicialização agendada irá ocorrer se o número especificado de minutos após a instalação estiver concluída.

Se o status estiver definido como Disabled ou Not configured, o tempo de espera padrão é de 15 minutos.

Nota: Esta política se aplica somente quando as Atualizações Automáticas estiverem configuradas para executar instalações agendadas de atualizações. Se a política  Configure Automatic Updates estiver desativada, esta política não terá efeito.

21 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.19.

Figura 1.19

Esta configuração de política especifica a quantidade de tempo para atualizações automáticas aguardar, após a inicialização do sistema, antes de prosseguir com uma instalação agendada que foi cancelada anteriormente.

Se o status estiver definido como Enabled, uma instalação agendada que não ocorreu anteriormente irá ocorrer o número especificado de minutos após o computador ser iniciado da próxima vez.

Se o status for definido como Disabled, uma instalação agendada perdida irá ocorrer com a próxima instalação agendada.

Se o status estiver definido como Not Configured, uma instalação agendada perdida irá ocorrer um minuto após o computador ser iniciado da próxima vez.

Nota: Esta política se aplica somente quando as Atualizações Automáticas estiverem configuradas para executar instalações agendadas de atualizações. Se a polítca Configure Automatic Updates estiver desativada, esta política não terá efeito.

22 – Selecione a opção Enabled para ativar a política, clique no botão Apply, e em seguida clique no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.20.

Figura 1.20

Esta configuração de política especifica o nome ou nomes de grupo-alvo que devem ser usados para receber atualizações do WSUS.

Se o status estiver definido como Enabled, as informações do grupo de destino especificado será enviado para o WSUS que a utilizará para determinar quais atualizações devem ser instaladas neste computador.

Se o WSUS suportar múltiplos grupos alvo, esta política poderá especificar os nomes dos grupos múltiplos separados por ponto e vírgula. Caso contrário, um único grupo deve ser especificada.

Se o status estiver definido como Disabled ou Not Configured, nenhuma informação do grupo alvo serão enviadas para o serviço de atualização do WSUS.

Nota: Esta política se aplica somente quando o serviço de atualização do wSUS deste computador for direcionado para ser configurado para suportar client-side targeting. Se a política Specify intranet Microsoft update service location estiver desativada ou não configurada, esta política não terá efeito.

23 – Selecione a opção Enabled para ativar a política, no campo Target group name for this computer digite o nome do grupo, como por exemplo, Clientes e em seguida clique no botão Apply e no botão Next Setting, para ir para próxima política. Será carrega a caixa de diálogo como mostra a figura 1.21.

Figura 1.21

Esta configuração de política permite gerenciar se as Atualizações Automáticas irão aceitar as atualizações assinadas por entidades que não sejam a Microsoft quando a atualização forem encontradas no WSUS.

Se você ativar esta configuração de política, as Atualizações Automáticas aceitarão as atualizações recebidas por meio de uma atualização do WSUS, se forem assinados por um certificado encontrado no “Trusted Publishers” armazenamento de certificados do computador local.

Se você desabilitar ou não configurar esta configuração de política, as atualizações do WSUS deverá ser assinado pela Microsoft.

Nota: As atualizações de um serviço que não seja o WSUS deve ser sempre assinados pela Microsoft e não são afetados por essa configuração política.

Nota

Após ter configurado todas as políticas do Automatic Updates (Atualização Automática) na OU Clientes, será necessário alguns minutos até que a nova política entre em vigor. Nos computadores clientes configurados com uma GPO baseado no Active Directory, esse tempo será de aproximadamente 20 minutos depois que a política for atualizada (ou seja, após ter aplicado todas as configurações novas ao computador cliente). Por padrão, a GPO é atualizada em segundo plano a cada 90 minutos, com uma diferença aleatória entre 0 e 30 minutos.

Para os computadores clientes configurados com a GPO local, a GPO é imediatamente aplicada e levará aproximadamente 20 minutos para o computador cliente contatar o WSUS.

Depois que a GPO for aplicada, você poderá iniciar a detecção manualmente. Se você realizar essa etapa, não será preciso aguardar 20 minutos para que o computador cliente contate o WSUS.

 

Forçando a Detecção do Servidor WSUS

Para iniciar manualmente a detecção do servidor WSUS, siga os passos abaixo:

1 – No prompt de comando, digite wuauclt.exe /detectnow e pressione Enter, para forçar a deteção do servidor WSUS.

Referências

 

Artigos Relacionados

 

TODOS OS CRÉDITO PARA Luciano Lima
[MVP Enterprise Security]-[MCSA Security]-[MCSE Security]

Anúncios

Curso Online – System Center Operations Manager 2007

Quem ainda não está familiarizado com o nome, o SCOM 2007 é o nome da nova versão do MOM, que como o DPM (Backup), SMS (agora SC Configuration Manager), SC Capacity Planner e outros  módulos que ainda estão por vir, são parte da suite de produtos de gerenciamento operacional do System Center.

Segue o link para acesso ao Technical Walkthrough: http://www.microsoft.com/systemcenter/opsmgr/evaluation/techwalk/course/codebase.html

Está disponível nos TechCenters do Technet (disponível ainda só em inglês) um Technical Walkthrough sobre SCOM 2007. Excelente recurso para aqueles que querem saber mais sobre o produto, como ele está alinhado a estratégia DSI (Dynamic System Initiative) e claro, seu valor agregado.

Como Desabilitar o IPV6 em Microsoft Windows 2008 R2, 7 ou Vista.

Pessoal,

Existe duas formas corretas de se desabilitar o IPV6 no Windows, porém muitos administradores insistem em ir nas propriedades da placa de Rede, OPÇÃO TCP/IPv6 e desmarcar o IPV6, porém não é a forma correta de se fazer isso.

Irei mostrar duas formas de se desabilitar o IPv6.

1) Forma seria seguir os seguintes passos:

Abrir o Registro do Windows (regedit), ir em COMPUTER\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters

Criar um DWORD, clicando com o botão direto do mouse em New DWORD com o nome DisabledComponents, valor hexadecimal em FFFFFFFF.

Após isso basta reiniciar o Windows e pronto, já está desabilitado o IPv6, com isso ao executar um comando ipconfig no DOS (cmd), não irá aparecer o número hexadecimal e informações a respeito do IPv6.

2) Forma seria através do KB 929852 aonde possui os Fix necessários para desabilitar automaticamente.

http://support.microsoft.com/kb/929852/pt-br

 

Pronto, espero ter ajudado. Até a próxima.

 

 

 

Como posso executar um script Em Credenciais Alternate?

Tanto WMI e ADSI fornecem uma maneira para que você possa executar um script com credenciais de segurança alternativo, ou seja, ambos permitem que você especifique um nome de usuário e uma senha em que o script será executado. Além disso, essas duas tecnologias oferecem uma maneira de garantir que este nome de usuário e senha são criptografadas, e são não passou em toda a rede usando o texto claro.
Mais provável que você realmente quer saber é como executar um script com credenciais de segurança alternativo. Vamos começar dando uma olhada em um script WMI que se conecta a um computador remoto ( atl-ws-01 ) e recupera o nome do sistema operacional instalado no computador. Além disso, ele faz isso através da execução sob oAdministrador da conta, que neste exemplo tem uma senha de 4rTGh2 # 1 :

Const WbemAuthenticationLevelPktPrivacy strComputer = 6 = "atl-ws-01" strNamespace = "root \ cimv2" strUser = "Administrador" strPassword = "4rTGh2 # 1" Set objWbemLocator = CreateObject ("WbemScripting.SWbemLocator") Set objWMIService objwbemLocator.ConnectServer = _ (strComputer, strNamespace, strUser, strPassword) objWMIService.Security_.authenticationLevel = WbemAuthenticationLevelPktPrivacy Set colItems objWMIService.ExecQuery = _ ("Select * From Win32_OperatingSystem") para cada objItem em ColItems strComputer Wscript.Echo & ":" & objItem.Caption Próxima

Como você pode ver, começamos criando uma constante chamada WbemAuthenticationLevelPktPrivacy e atribuindo-lhe o valor 6; este valor será usado para criptografar a comunicação entre nosso computador eo computador remoto. Nós, então, definir quatro variáveis ​​- strComputer, strNamespace, strUser e strPassword – que detêm o nome de nosso computador remoto, o namespace WMI que deseja se conectar, a conta de usuário que deseja executar o script abaixo; ea senha para esse usuário conta.

Neste ponto estamos prontos para conectar ao computador remoto usando essas credenciais alternativas. Isso é o que estas linhas de código faz:

Definir objWbemLocator = CreateObject ("WbemScripting.SWbemLocator") Set objWMIService = objwbemLocator.ConnectServer _ (strComputer, strNamespace, strUser, strPassword) objWMIService.Security_.authenticationLevel = WbemAuthenticationLevelPktPrivacy

Começamos criando uma instância do objeto SWbemLocator, e depois chamar o método ConnectServer. ConnectServer é passado quatro parâmetros, o que só acontecerá a correspondem às quatro variáveis ​​que criamos há pouco. Em seguida, definir oSecurity_authenticationLevel propriedade para WbemAuthenticationLevelPktPrivacy, dando-nos uma ligação mais segura entre os dois computadores.

Daquele ponto em diante, o resto do código é o mesmo código WMI anos você conhece e adora.

Uma observação importante: essa abordagem, em que você executar um script com credenciais alternativas, funciona apenas em máquinas remotas. Por alguma razão, WMI não vai deixar você executar um script com credenciais alternativas no seu próprio computador. Vai entender.

Agora vamos dar uma olhada na versão ADSI deste script. Este script de exemplo liga-se à conta de usuário Ken Myer no Active Directory e nos diz se esta conta está desativada. O script se conecta ao Active Directory usando o fabrikam \ Administrador , que tem uma senha de 4rTGh2 # 1 :

Const ADS_SECURE_AUTHENTICATION = 1 = 2 Const ADS_USE_ENCRYPTION strPath = "LDAP: / / cn = kenmyer, ou = Finance, dc = fabrikam, dc = com" strUser = "fabrikam \ Administrator" strPassword = "4rTGh2 # 1" Set objDSO = GetObject ( "LDAP:") Set objUser = objDSO.OpenDSObject Wscript.Echo _ (strPath, strUser, strPassword, _ ADS_USE_ENCRYPTION OU ADS_SECURE_AUTHENTICATION) objUser.AccountDisabled

Neste script, criamos duas constantes (ADS_SECURE_AUTHENTICATION e ADS_USE_ENCRYPTION) para garantir que as informações transmitidas entre o nosso computador eo domínio é criptografada. Em seguida, criamos três variáveis ​​- strPath, strUser e strPassword – que sediar o ADsPath para o objeto que deseja vincular a no Active Directory (neste caso, a conta de usuário Ken Myer); o nome da conta que deseja usar ao ligar a Active Directory; ea senha para essa conta.

Em seguida, ligar para o provedor LDAP; começamos aqui porque o provedor LDAP aceita ligações anônimas. Tendo conectado ao objeto LDAP, podemos então chamar o método OpenDSObject para vincular a conta do usuário Ken Myer. Note-se que devemos passar OpenDSObject quatro parâmetros: a ADsPath ao objeto do Active Directory, o nome do usuário que deseja usar ao conectar ao Active Directory; a senha para essa conta, e as duas constantes que definimos anteriormente. Tal como acontece com WMI, assim que fazer a conexão, o resto do script é o mesmo que qualquer script ADSI outros.

By the way, OpenDSObject também funciona com contas de usuário local; a principal diferença é que você ligar para o provedor WinNT em vez do provedor LDAP (e, claro, o ADsPath será diferente). Aqui estão as linhas relevantes do código de um script que se conecta a um computador local:

strComputer = "WinNT: / / atl-ws-01" strUser = "Administrador" strPassword = "4rTGh2 # 1" Set objDSO = GetObject ("WinNT:") Set objComputer objDSO.OpenDSObject = _ (strComputer, strUser, strPassword, _ ADS_SECURE_AUTHENTICATION OU ADS_USE_ENCRYPTION)

Uma coisa que devemos acrescentar é que nós não recomendamos que você codificar senhas (passwords especialmente Administrator) em seus scripts. Em vez disso, você deve fazer concessões para digitar a senha como um argumento de linha de comando ou através de uma caixa de entrada ou o que funciona melhor para você.

Detalhes sobre a configuração de porta segura WS-Management no Windows 7 e Windows Server 2008 R2

Este artigo fornece alguns detalhes importantes sobre a configuração de porta segura WS-Management no WinRM 2. 0, incluído no Windows 7 e Windows Server 2008 R2. O WinRM pode ser baixado separadamente como parte das Estrutura de gerenciamento do Windows para Windows XP, Windows Server 2003, Windows Vista e Windows Server 2008.

Proteger os detalhes de configuração de porta

  1. Resumo
  2. Comportamento funcional
    1. Novos valores padrão
    2. Ouvintes de compatibilidade
    3. Migração de ouvinte
    4. Alterações específicas do PowerShell
    5. Alterações específicas do WinRM
    6. Trabalhando em ambientes mistos
    7. Regras de firewall
    8. Encaminhamento de eventos

Resumo

Servidores conectados à internet geralmente são configurados para permitir o tráfego de diferentes usuários que garantem a vários níveis de confiança. Expor uma interface de gerenciamento através de portas tradicionais potencialmente expõe os recursos de alteração de sistema importantes para usuários mal-intencionados. Por esse motivo, é mais seguro para expor uma interface de gerenciamento através de uma porta que tratam o tráfego da web.

Para fornecer a configuração padrão mais segura e para diminuir a probabilidade de que um usuário inadvertidamente irá criar um ouvinte de WS-Management nessas portas comuns, a configuração padrão foi alterada no WinRM 2. 0 para um conjunto diferente de portas. Ao atualizar para o WinRM 2. 0, qualquer ouvinte que existe na porta 80 ou 443 serão automaticamente migrado para novas portas de padrão de 5985 para HTTP e 5986 para HTTPS.

Comportamento funcional

Novos valores padrão

As portas padrão usadas ao criar novos ouvintes do WS-Management serão alteradas de 80 para HTTP e 443 para HTTPS para 5985 para HTTP e 5986 para HTTPS.  Todos os ouvintes criados manualmente sem especificar uma porta ou ouvintes criados usando a configuração rápida, irá escutar nessas portas novas. Da mesma forma, as portas padrão usadas ao emitir solicitações do cliente também serão alteradas para novas portas.  Quaisquer solicitações de clientes enviadas sem especificar que uma porta será enviada para essas portas novas.

Ee922665.Important(pt-br,WS.10).gif Importante
Se as portas do cliente padrão estão definidas como algo diferente de 80/443, elas não serão modificadas.

Ouvintes de compatibilidade

Para ajudar a interoperabilidade com computadores que não tenham sido atualizados, foram introduzidas novas definições de configuração para criar ouvintes de compatibilidade nas portas 80 e 443 para HTTP e HTTPS, respectivamente. Essas configurações podem ser ativadas diretamente por meio da chamada de linha de comando WinRM configuration console da seguinte maneira.

  • winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}
  • winrm set winrm/config/service @{EnableCompatibilityHttpsListener="true"}

Os ouvintes de compatibilidade também podem ser habilitados por meio da diretiva de grupo usando as novas configurações em computador administrativa de configuração/modelos/componentes/Windows gerenciamento remoto do Windows (WinRM) / serviço WinRM.

Esses ouvintes de compatibilidade não são diretamente endereçáveis, o que significa que eles não podem ser recuperados via get winrm e suas configurações não podem ser modificadas. Quando enumerados, esses ouvintes serão marcados com a seqüência de caracteres. Source=”Compatibility” para identificá-los, como no exemplo a seguir.

C:\Windows\system32>winrm e winrm/config/listenerListener    Address = *    Transport = HTTP    Port = 5985    Hostname    Enabled = true    URLPrefix = wsman    CertificateThumbprint    ListeningOn = 127.0.0.1, 157.59.85.27, ::1, 2001:4898:0:fff:200:5efe:157.59.85.27, 2001:4898:2b:3:594:e48f:e99a:de17, 2001:4898:2b:3:4c54:7d1e:a5f6:6ea, fe80::100:7f:fffe%11, fe80::200:5efe:157.59.85.27%13, fe80::4c54:7d1e:a5f6:6ea%12Listener [Source="Compatibility"]    Address = *    Transport = HTTP    Port = 80    Hostname    Enabled = true    URLPrefix = wsman    CertificateThumbprint    ListeningOn = 127.0.0.1, 157.59.85.27, ::1, 2001:4898:0:fff:200:5efe:157.59.85.27, 2001:4898:2b:3:594:e48f:e99a:de17, 2001:4898:2b:3:4c54:7d1e:a5f6:6ea, fe80::100:7f:fffe%11, fe80::200:5efe:157.59.85.27%13, fe80::4c54:7d1e:a5f6:6ea%12

Por padrão, essas configurações são definidas como Enabled = False para novas instalações do WinRM 2. 0. Para atualizações, os valores de configuração dependerá da configuração existente. Consulte a seção a seguir para obter mais detalhes.

Migração de ouvinte

A tabela a seguir define as configurações de ouvinte que existem após a atualização para o WinRM 2. 0.

Ouvinte existente Configurações após atualização
Transporte = HTTP

Porta = 80

Novo ouvinte com configurações mesmos criado na porta 5985

o WinRM/config/service/EnableCompatibilityHttpListener = True

“Ativar na compatibilidade ouvinte HTTP” de configuração de diretiva de grupo = ativada

Transporte = HTTP

Porta não está definida para 80

Ouvinte permanecerá inalterado

o WinRM/config/service/EnableCompatibilityHttpListener = False

“Ativar na compatibilidade ouvinte HTTP” de configuração de diretiva de grupo = não configurado

Transporte = HTTPS

Porta = 443

Novo ouvinte com configurações mesmos criado na porta 5986

o WinRM/config/service/EnableCompatibilityHttpsListener = True

“Ativar na compatibilidade Ouvinte HTTPS” de configuração de diretiva de grupo = ativada

Transporte = HTTPS

Porta não definida como 443

Ouvinte permanecerá inalterado

o WinRM/config/service/EnableCompatibilityHttpsListener = False

“Ativar na compatibilidade Ouvinte HTTPS” de configuração de diretiva de grupo = não configurado

Ee922665.Important(pt-br,WS.10).gif Importante
Se as configurações de diretiva de grupo forem habilitadas através de migração/upgrade, em seguida, as reservas de HTTP. sys e certificados SSL são definidos automaticamente. Se um administrador permite que as configurações de diretiva de grupo diretamente essas configurações adicionais também devem ser configuradas por meio da diretiva de grupo.

Alterações específicas do PowerShell

PSSession novo PSSession novo PowerShell cmdlet foi modificado para fazer essas alterações em consideração.  Novo PsSession agora assume dois conjuntos de parâmetros diferentes: ComputerName e ConnectionURI.

  • Quando o parâmetro nome_do_computador definido for especificado, então a configuração de porta do cliente padrão é usada na configuração do WinRM 2. 0, a menos que uma porta for especificada explicitamente.
  • Quando o parâmetro ConnectionUri é passado, em seguida, a seqüência de caracteres será interpretada usando as portas 80 para HTTP e 443 para HTTPS por padrão.

Os cmdlets a seguir WSMan passaram a mesma alteração conforme descrito acima para PSSession de novo.

  • Conectar-se de WSMan
  • Get-WSManInstance
  • Invocar-WSManAction
  • Novo WSManInstance
  • Remover WSManInstance
  • Conjunto de WSManInstance

Alterações específicas do WinRM

A ferramenta de linha de comando WinRM compartilharão o comportamento do cmdlet New-pssession nas seguintes situações.

  • Se um usuário passa o nome de um computador com o winrm cmd linha usando o –r:<Computername> o comutador e WinRM 2. 0 usam o porta HTTP do cliente padrão, 5985 de porta.
  • Se um usuário passa o nome de um computador com o winrm cmd linha usando o –r:<Computername> Alternar e o –UseSSL sinalizador é transmitido, em seguida, o WinRM 2. 0 usará o padrão 5985 de porta a porta HTTPS, do cliente.
  • Se um usuário passa o nome de um computador com o winrm cmd linha usando o –r:<Computername> Alternar e se uma porta é especificada, o WinRM 2. 0 usará a porta especificada.
  • Se um usuário passa a URI de conexão para a linha de comando winrm, como no exemplo –r:http://Mycomputer/wsman , e em seguida, o WinRM 2. 0 irá interpretar o URI usando as portas 80 para HTTP e 443 para HTTPS, por padrão.

Trabalhando em ambientes mistos

Se você tiver um ambiente misto de computadores, onde um número deles têm WinRM 2. 0 instalado e do número não, há algumas situações que exigem ação administrativa para manter a funcionalidade adequada.

  • Se o cliente é atualizado para que as portas padrão são 5985/5986, mas o servidor permanece inalterada e é por ainda escutando as portas 80/443, o cliente deve ser explicitamente especifica portas 80/443 na conexão ou especificar a máquina remota usando um ConnectionUri.
  • Se o sistema operacional cliente tem uma nova instalação do Windows 7 e as portas padrão são 5985 para HTTP e 5986 para HTTPS, mas o servidor não é alterado para que ele ainda está escutando 80/443, a situação é a mesma. O cliente deve especificar explicitamente as portas 80/443 na conexão ou Especifica o servidor remoto usando um ConnectionUri.
  • Se o sistema operacional do servidor tem uma nova instalação do Windows 7 e ele está escutando nas portas 5985 para HTTP e 5986 HTTPS, mas o cliente não é alterado para que suas portas padrão ainda são 80/443, o administrador deve criar explicitamente ouvintes nas portas 80/443.

Regras de firewall

Há duas regras de firewall dentro do mesmo grupo: um para a porta 80 e outra para porta 5985. A tabela a seguir define o status dessas duas regras em vários cenários de atualização.

Regra de firewall da porta 80 Regra de porta 5985
Atualização: regra de porta 80 ativada Habilitado Habilitado
Upgrade: desativado porta 80 regra Desativado Desativado
Nova instalação do WinRM 2. 0 Desativado Desativado
Ee922665.note(pt-br,WS.10).gif Observação
Quando o ouvinte de compatibilidade é ativado, a regra de firewall para a porta 80 será habilitada.

Encaminhamento de eventos

As tabelas a seguir dispor em várias situações que podem ocorrer com o encaminhamento de eventos e as etapas que precisam ser tomada para corrigir problemas em potencial.

Iniciada pelo coletor inscrições de envio/RECEPÇÃO.

Coletores Fonte Inscrições existentes Novas assinaturas
Nova instalação do Windows 7 Nova instalação do Windows 7 Não aplicável O encaminhamento de eventos funciona corretamente.
Nova instalação do Windows 7 O WinRM 1. 1 instalado Não aplicável É necessário especificar a porta 80 para HTTP explicitamente.
Nova instalação do Windows 7 Atualizado para o WinRM 2. 0 Não aplicável O encaminhamento de eventos funciona corretamente.
O WinRM 1. 1 instalado Nova instalação do Windows 7 Atualize inscrições no coletor para adicionar a porta 5985 para HTTPS. É necessário especificar a porta 5985 explicitamente.
O WinRM 1. 1 instalado O WinRM 1. 1 instalado O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.
O WinRM 1. 1 instalado Atualizado para o WinRM 2. 0 O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.
Atualizado para o WinRM 2. 0 Nova instalação do Windows 7 Atualize inscrições no coletor para adicionar a porta 5985 para HTTPS. O encaminhamento de eventos funciona corretamente.
Atualizado para o WinRM 2. 0 O WinRM 1. 1 instalado O encaminhamento de eventos funciona corretamente. É necessário especificar a porta 80 para HTTP explicitamente.
Atualizado para o WinRM 2. 0 Atualizado para o WinRM 2. 0 O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.

Iniciada a origem inscrições de envio com inscrições existentes, especificando o coletor como servidor = <FQDN>

Coletores Fonte Inscrições existentes Novas assinaturas
Nova instalação do Windows 7 Nova instalação do Windows 7 Não aplicável Pode especificar o coletor como servidor = http: / / <FQDN>: 5985 ou servidor = <FQDN>
Nova instalação do Windows 7 O WinRM 1. 1 instalado Não aplicável É necessário especificar o coletor como servidor = http: / / <FQDN>: 5985
Nova instalação do Windows 7 Atualizado para o WinRM 2. 0 Não aplicável Pode especificar o coletor como servidor = http: / / <FQDN>: 5985 ou servidor = <FQDN>
O WinRM 1. 1 instalado Nova instalação do Windows 7 Atualizar informações de coletor da origem para o servidor = http: / / <FQDN> É necessário especificar o coletor como servidor = http: / / <FQDN>
O WinRM 1. 1 instalado O WinRM 1. 1 instalado O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.
O WinRM 1. 1 instalado Atualizado para o WinRM 2. 0 Atualizar informações de coletor da origem para o servidor = http: / / <FQDN> É necessário especificar o coletor como servidor = http: / / <FQDN>
Atualizado para o WinRM 2. 0 Nova instalação do Windows 7 O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.
Atualizado para o WinRM 2. 0 O WinRM 1. 1 instalado O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.
Atualizado para o WinRM 2. 0 Atualizado para o WinRM 2. 0 O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.

Iniciada a origem inscrições de envio com inscrições existentes, especificando o coletor como servidor = http: / / <FQDN>

Coletores Fonte Inscrições existentes Novas assinaturas
Nova instalação do Windows 7 Nova instalação do Windows 7 Não disponível Pode especificar o coletor como servidor = http: / / <FQDN>: 5985 ou servidor = <FQDN>
Nova instalação do Windows 7 O WinRM 1. 1 instalado Não aplicável É necessário especificar o coletor como servidor = http: / / <FQDN>: 5985
Nova instalação do Windows 7 Atualizado para o WinRM 2. 0 Não aplicável Pode especificar o coletor como servidor = http: / / <FQDN>: 5985 ou servidor = <FQDN>
O WinRM 1. 1 instalado Nova instalação do Windows 7 Atualizar informações de coletor da origem para o servidor = http: / / <FQDN> É necessário especificar o coletor como servidor = http: / / <FQDN>
O WinRM 1. 1 instalado O WinRM 1. 1 instalado O encaminhamento de eventos funciona corretamente. O encaminhamento de eventos funciona corretamente.
O WinRM 1. 1 instalado Atualizado para o WinRM 2. 0 Atualizar informações de coletor da origem para o servidor = http: / / <FQDN> É necessário especificar o coletor como servidor = http: / / <FQDN>
Atualizado para o WinRM 2. 0 Nova instalação do Windows 7 O encaminhamento de eventos funciona corretamente. Pode especificar o coletor como servidor = http: / / <FQDN>: 5985 ou servidor = <FQDN>
Atualizado para o WinRM 2. 0 O WinRM 1. 1 instalado O encaminhamento de eventos funciona corretamente. É necessário especificar o coletor como servidor = http: / / <FQDN>: 5985
Atualizado para o WinRM 2. 0 Atualizado para o WinRM 2. 0 O encaminhamento de eventos funciona corretamente. Pode especificar o coletor como servidor = http: / / <FQDN>: 5985 ou servidor = <FQDN>

Etapas para mover um banco de dados DHCP de um servidor Windows 2003 ou 2008 para outra máquina Windows Server 2008

O banco de dados DHCP pode ser movida ou migrou de um servidor Windows Server 2003 para um servidor Windows Server 2008, ou de um servidor Windows Server 2008 para outro. As informações abaixo detalha os passos necessários.

Exportar o banco de dados DHCP de um servidor que está executando o Microsoft Windows Server 2003 ou Windows Server 2008

Para mover um banco de dados DHCP e configuração de um servidor que está executando o Windows Server 2003 ou Windows Server 2008 para outro servidor que está executando o Windows Server 2008:

1. Faça logon no servidor DHCP de origem usando uma conta que seja membro do grupo Administradores local.

2. Clique Iniciar , clique em Executar , digite cmd na caixa Abrir e clique em OK .

3. Digite netsh dhcp server export C: \ dhcp.txt all , e então pressione ENTER .

Nota: Você deve ter permissões de administrador local para exportar os dados.

Configure o serviço do servidor DHCP no servidor que está executando o Windows Server 2008

1. Clique Iniciar , clique em Ferramentas Administrativas , clique em Server Manager . Se necessário reconhecer User Account Control .

2. Em Roles Summary clique em Adicionar Funções , clique em seguida , verifique DHCP servidor e clique emAvançar .

Importar o banco de dados DHCP

1. Logon como um usuário que seja membro explícito do grupo Administradores local. Uma conta de usuário em um grupo que é membro do grupo de administradores locais não funcionará. Se uma conta de administradores locais não existe para o controlador de domínio, reinicie o computador no Directory Services Restore Mode, e usar a conta de administrador para importar o banco de dados como descrito posteriormente nesta seção.

2. Copie o arquivo de banco de dados DHCP exportado para o disco rígido local do Windows Server 2008 baseado computador.

3. Verifique se o serviço DHCP é iniciado no Windows Server 2008 baseado computador.

4. Clique em Iniciar, clique em Executar, digite cmd na caixa Abrir e clique em OK .

5. No prompt de comando, digite netsh dhcp server import c: \ dhcpdatabase.txt all , e então pressioneENTER , onde c: \ dhcpdatabase.txt é o caminho completo e nome do arquivo de banco de dados que você copiou para o servidor.

Nota Quando você tenta exportar um DHCP banco de dados de um controlador de domínio Windows 2000/2003 para um Windows Server 2008 servidor membro do domínio, poderá receber a seguinte mensagem de erro:

Erro ao inicializar e ler a configuração do serviço – Acesso Negado

Nota Você deve ter permissões de administrador local para importar os dados.

6. Para resolver esse problema, adicione o computador Windows Server 2008 servidor DHCP ao grupo Administradores de DHCP no nível empresarial e refazer os passos 4 e 5.

7. Se o “acesso negado” mensagem de erro ocorre depois de adicionar o Windows Server 2008 computador servidor DCHP ao grupo Administradores de DHCP no nível empresarial que é mencionado no passo 6, verifique se a conta de usuário que é atualmente usada para importar pertence ao grupo Administradores local.Se a conta não pertencer a este grupo, adicione a conta a esse grupo, ou faça logon como um administrador local para concluir a importação e refazer os passos 4 e 5.

Autorizar o servidor DHCP

1. Clique em Iniciar, aponte para Todos os Programas, aponte para Ferramentas Administrativas e, em seguida, clique em DHCP.

Nota Você deve estar conectado ao servidor usando uma conta que seja membro do grupo Administradores.Em um domínio do Active Directory, você deve estar conectado ao servidor usando uma conta que seja membro do grupo Administradores corporativos.

2. Na árvore de console do snap-in DHCP, expanda o servidor DHCP novo. Se houver uma seta vermelha no canto inferior direito do objeto do servidor, o servidor ainda não foi autorizado.

3. Botão direito do mouse o objeto de servidor e clique em Autorizar.

4. Depois de vários momentos, botão direito do mouse o servidor novamente e clique em Atualizar. A seta verde indica que o servidor DHCP está autorizado.

Por:  Wayne Melvin

LimitLogin

Faça o download do código deste artigo: LimitLogin.exe (4112 KB)

Sempre necessário para limitar os logins de usuários simultâneos em um Active Directory ® domínio? Sempre quis manter o controle de informações sobre cada login em um domínio? Se assim for, LimitLogin é para você.

LimitLogin é um aplicativo escrito por Yossi Saharon, um especialista em tecnologia Parceiro da Microsoft em Israel, com a ajuda de Ofer Bar, um consultor de desenvolvimento de aplicações. O aplicativo adiciona a capacidade de limitar os logins de usuários simultâneos e manter o controle de todas as informações de login em um domínio do Active Directory. LimitLogin capacidades incluem limitar o número de logins por usuário a partir de qualquer máquina no domínio (incluindo sessões do Terminal Server), exibindo as informações de login de qualquer usuário no domínio de acordo com critérios específicos, fácil gerenciamento e configuração através da integração com o Microsoft Active Directory ® Management Console (MMC) snap-in, a capacidade de apagar e fazer logoff remotamente uma sessão de usuário em linha reta do Active Directory Usuários e computadores MMC snap-in, ea capacidade de gerar relatórios de informações de login nos formatos CSV e XML.

Embora o objectivo principal de LimitLogin é para impor quotas de login simultâneo, ele também pode ser usado apenas como uma solução de captura de dados de login que permite gerenciar o seu ambiente do Active Directory de forma mais eficaz. Você pode configurar todos os usuários no domínio para ter uma quota de login unreachably alta e simplesmente deixar os scripts fazem o trabalho de atualização de seus dados de login, sem atingir a cota que foi definido. As ferramentas de interface do usuário permitem que você definir a cota de login, e você pode fazê-lo por meio de programação usando o código de script de exemplo fornecido com a ferramenta em Bulk_LimitUserLogins.vbs. Você também pode escopo este script para um nível de unidade organizacional. O script padrão é executado em todas as contas de usuário no domínio.

LimitLogin arquitetura é construída em torno de três elementos principais:

Um serviço Web que manipula o processamento de back-end no servidor

Uma partição de diretório de aplicativos que contém as informações de login

Login e logoff scripts VBS

Figura 1 Validando um login de usuário

Quando um usuário faz logon no domínio, o arquivo é executado e llogin.vbs envia dados da máquina host (nome do computador, endereço IP, ID de sessão e autenticação nome DC) para o serviço Web LimitLogin como XML, usando SOAP. O serviço Web usa o contexto do cliente de segurança contra o Active Directory e verifica se este usuário é configurado para LimitLogin e tem uma quota de login na partição de diretório de aplicativos LimitLogin.

Se o usuário não tiver um conjunto quota login, o serviço Web notifica o script que ele deve continuar a fazer login normalmente. Se o usuário tem uma quota de login no lugar, o serviço Web conta o número de logins registrados o usuário tenha recolhido na partição de diretório de aplicativos LimitLogin. Se quota de login do usuário é menor do que o número real de logins registrado no Active Directory, o serviço Web atualiza as informações de login do usuário na partição de diretório de aplicativos LimitLogin e notifica o script de login para continuar o login normalmente. Se quota de login do usuário é igual a ou excede o número de logins registrado no Active Directory, no entanto, o serviço Web notifica o script de login para fazer logoff da sessão atual. Este processo é descrito na Figura 1 .

processo limitlogin

Um processo relacionado acontece com llogoff.vbs quando um usuário faz logoff do domínio.

Enquanto algumas soluções semelhantes requerem SQL Server ™ para o trabalho, LimitLogin usa seu banco de dados do Active Directory. Ele cria uma partição de diretório de aplicativo em um controlador de domínio no domínio para o qual você deseja usar o aplicativo. LimitLogin suporta o Windows 2000 Professional Service Pack 4 e posterior, Windows 2000 Server Service Pack 4 e posterior, Windows XP Professional Service Pack 1 e posterior, e Windows Server ™ 2003. Você pode baixar LimitLogin a partir do link no topo deste artigo.

Referência: http://technet.microsoft.com/en-us/magazine/2005.05.utilityspotlight.aspx