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.

 

 

 

Anúncios

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

 

Backup e Restore Microsoft IAS

Olá Pessoal !

Mais uma vez nos deparamos em como efetuar um backup seguro e obter um restore garantido do Microsoft IAS. Para tal abaixo segue a forma mais simples de obter um arquivo com todas configurações e a forma de efetuar um restore do mesmo.

ias

Backup

netsh aaaa show config >path\file.txt.

Restore

netsh exec path\file.txt

Observação: Este restore funciona tanto num determinado Servidor do qual já possuí o serviço ativo ou até mesmo em outro Servidor, para tal basta instalar o serviço do IAS e posteriormente efetuar o restore com o comando acima.

Referência: http://technet.microsoft.com/en-us/library/cc784607(WS.10).aspx

Espero ter ajudado.

Abraços.

O que é o Application Pool? Como criar ?

Um Pool de Aplicativos define um grupo de um ou mais processos de trabalho (Worker Process), configurado com definições comuns que atendem uma ou mais aplicações atribuídas a este Pool.
Podemos ver abaixo na figura os componentes de um ‘Application Pool’

Cada Application Pool utiliza 1 ou 2 modos de integração .NET (Modo Integrado e Modo Clássico) para executar aplicações ASP.NET. O modo definido para o Application Pool define como será processado qualquer requisição que chegar a este Pool. Como mostra a figura abaixo.

Modo Integrado: Permite que o IIS processe requisições no Application Pool utilizando o “Integrated Pipeline”, isso permite que os módulos do ASP.NET participem do processamento das requisições.

Modo Clássico: Utiliza o pipeline de processamento do IIS 6, inicialmente as requisições são processadas através dos módulos do IIS7, as requisições do ASP.NET são transportadas para o que chamamos de “ISAPI Filter – aspnet_isapi.dll”, o pipeline de processamento do ASP.NET é separado do pipeline de processamento do IIS7, isto é, o fluxo de processamento é muito mais lento do que o Modo Integrado como mostra a figura abaixo.

Ou seja, o processamento de requisições do tipo ASP.Net serão executadas em outro Pipeline e com isso o tempo de execução será maior.

O módulo nativo ou integrado permite uma execução muito mais rápida e eficaz das requisições Web.

Com isso devemos sempre que possível utilizar o modo integrado do IIS7 para ter mais performance e controle em nosso ambiente Web.

 

 

Veremos quais os passos necessários para a criação.

Existem 2 formas de criar um Application Pool pela GUI.

 

1. Voce pode criar um pool manualmente e depois assimilar um site para este pool.

2. Criar um novo site, definir um Application Pool existente, ou criar um novo.

 

Abaixo as 2 maneiras de fazer, veja:

Criando Application Pool manualmente

1. Selecione “Pool de Aplicativos” ou “Application Pool”, clique com o botao direito e em seguida “Adicionar Pool de Aplicativos”.

 

2. Selecione o nome para o Application Pool

3. Selecione a versao do .NET Framework que sera utilizado no Application Pool

4. Selecione o Modo do Pipeline

5. OK

6. Verificando a criação (Selecione “Pool de Aplicativos” > Visualize o painel central)”:

7. Notem que em “Aplicativos” esta igual a “Zero”, isso significa que o Pool que nos criamos nao esta gerenciando nenhum site no momento.

 

Criando o Application Pool de forma “Automatica”

 

1. Clique com o botao direito em cima de “Sites” > Adicionar Sites

 

 

 

2.  Na box “Nome do site” percebam que quando começarem a digitar, automaticamente sera preenchido a box “Pool de Aplicativos”, desta forma quando clicar em “OK” , o POOL sera criado automaticamente, outra opção seria clicar em “Selecionar” e escolher um POOL existente.

3. Apos o preenchimento dos campos clique em “OK”.

4. Verifique a criação (Selecione “Pool de Aplicativos”, notem que em “Aplicativos” o Value agora esta “1″, isso significa que existe um Site associado a este POOL, que no caso foi o que criamos acima.

 

 

Fonte: http://iisbrasil.wordpress.com