· Sem comentários

Introdução

WinRM e WinRS são novos no Windows Vista, Windows Server 2003 R2, Windows Server 2008 (e Server 2008 Core). Essas são novas e poderosas ferramentas de linha de comando que oferecem aos administradores de sistema recursos aprimorados de controle remoto e execução remota em máquinas Windows. No entanto, eles precisam ser habilitados primeiro e levará algum tempo para aprender sua funcionalidade. Você está com sorte, este artigo tem tudo que você precisa para começar a usar essas ferramentas hoje mesmo!

O que é o Gerenciamento Remoto do Windows (WinRM)?

O Gerenciamento Remoto do Windows (abreviado como WinRM) é um novo serviço de gerenciamento remoto conveniente para Windows Server 2003 R2, Windows Vista e Windows Server 2008. WinRM é o componente “servidor” deste aplicativo de gerenciamento remoto e WinRS (Windows Remote Shell) é um " cliente" para WinRM executado em um computador remoto na tentativa de controlar remotamente o servidor WinRM. No entanto, devo observar que AMBOS os computadores devem ter o WinRM instalado e habilitado para que o WinRS funcione e receba informações sobre o sistema remoto. WinRM é baseado nos padrões Web Services for Management (WS-Management). Isso significa que o WinRM usa solicitações HTTP (porta 80) e SOAP para fazer o trabalho. A vantagem disso é que as solicitações HTTP podem ser facilmente enviadas através de um firewall. Disso decorrem consequências boas e más: por um lado, será mais fácil controlar um computador remoto através da Internet, mas, por outro lado, será mais fácil para um invasor atacar remotamente o mesmo computador. Outra pequena vantagem de usar a porta 80 é que não há necessidade de abrir outras portas no servidor se as conexões HTTP de entrada já tiverem sido permitidas.

Segundo a Microsoft, o WinRM é “a nova ferramenta da Microsoft para estabelecer uma API baseada em padrões para gerenciamento de sistemas”. Então, se você não estava interessado em aprender sobre essas ferramentas anteriormente, acho que o fato de “é um novo padrão da Microsoft” faz com que valha a pena aprender.

Você já deve estar familiarizado com o banco de dados WMI (Instrumentação de Gerenciamento do Windows). Mas, por precaução, direi que este banco de dados contém todo tipo de informação sobre o hardware e software do computador. Quase todos os aplicativos que gerenciam um sistema Windows descem para o nível de banco de dados WMI para executar todas as tarefas administrativas em um determinado PC.

O WinRM usará o banco de dados WMI para executar tarefas semelhantes àquelas que você pode ter executado com outro software como o VBScript. A vantagem do WinRM é que ele usa HTTP (porta 80), como eu disse, e existe até um código especial que permite ao WinRM dividir conexões de entrada na porta 80 com um componente IIS que já pode estar em execução nessa porta.

WinRM oferece suporte a vários tipos de autenticação para evitar que alguém execute tarefas administrativas em seus clientes e servidores. Claro, você precisa se lembrar que, ao habilitar o WinRM, você está abrindo outro caminho para ataques ao seu sistema. No entanto, como faço para qualquer porta aberta, se a autenticação e a criptografia estiverem configuradas corretamente, pode-se considerar que você tomou todas as precauções razoáveis.

O fabricante do software de gerenciamento do sistema pode já ter planejado usar o WinRM em versões futuras do software, portanto, você já pode estar usando o WinRM por meio de outros aplicativos. No entanto, você mesmo pode usar este componente usando o comando winrm.cmd. Com esta ferramenta CLI, você pode extrair facilmente informações de um banco de dados WMI para qualquer tarefa que você resolver.

Como você verá a seguir, o WinRM possui uma interface de linha de comando com muitas opções. Informações de ajuda sobre o WinRM serão mostradas mesmo se ele não estiver habilitado em seu sistema.

Figura 1: Opções de linha de comando do WinRM

Como habilitar e usar o WinRM?

Se você estiver usando o Windows 2008 Server, o WinRM já estará instalado, mas não estará habilitado por padrão. Esta é uma boa precaução. A maneira mais fácil de verificar se o WinRM está habilitado e rodando em sua máquina é ir até a linha de comando e digitar:

winrm enumerar winrm/config/listener

Se você não receber uma resposta, o WinRM não está em execução. Para configurar o WinRM para iniciar automaticamente e permitir acesso remoto, use o comando configuração rápida do winrm, Por exemplo:

C:\Usuários\Administrador> configuração rápida do winrm O WinRM não está configurado para permitir acesso remoto a esta máquina para gerenciamento.As seguintes alterações devem ser feitas:Crie um ouvinte WinRM em HTTP://* para aceitar solicitações WS-Man para qualquer IP nesta máquina.Fazer essas alterações? sim WinRM foi atualizado para gerenciamento remoto.Criado um ouvinte WinRM em HTTP://* para aceitar solicitações WS-Man para qualquer IP nesta máquina.C:\Usuários\Administrador> Depois de configurar o quickconfig, executei novamente o comando de enumeração com os seguintes resultados: C:\Usuários\Administrador> winrm e winrm/config/listener OuvinteEndereço = *Transporte = HTTPPorta = 80nome de anfitriãoHabilitado = verdadeiroURLPrefix = wsmanCertificado DigitalListeningOn = 10.253.15.98, 127.0.0.1, ::1, fe80::5efe:10.253.15.98%11, fe80::9583:2148:e1ef:6444%10C:\Usuários\Administrador>

Agora eu sei que o WinRM está habilitado.

A propósito, se quiser desabilitar o WinRM, você precisa usar este comando:

winrm excluir winrm/config/listener?IPAdress=*+Transport=HTTP

Para usar o WinRM, todos os nós que se comunicam com ele devem ser membros do mesmo domínio que o nó que executa o WinRM. Se este não for o seu caso, recomendo que você se familiarize com vários cenários de segurança no artigo ‘Gerenciando remotamente seu Server Core usando WinRM e WinRS’.

O que é WinRS e como usá-lo?

WinRS é um acrônimo para Windows Remote Shell. Com o WinRS você pode fazer consultas remotas em máquinas Windows que executam o WinRM. No entanto, não esqueça que sua máquina também precisa estar executando o WinRM para funcionar com o WinRS.

Como você pode ver no diagrama abaixo, vencedoresé uma ferramenta de linha de comando completa com uma grande quantidade de informações de referência sobre como usá-la.

Figura 2: opções de linha de comando do WinRS

Uma das maneiras mais comuns de usar o WinRS é executar comandos em uma máquina remota. Claro, esta comunicação ocorre através do protocolo HTTP (porta 80) (padrão).

Abaixo está um exemplo usando WinRS: Executei os comandos no host localhost. Executei dois comandos: ‘ ‘ ver' E ' diretório C:‘. Em cada caso, foram recebidas informações adequadas em resposta.

Figura 3: Demonstração do comando WinRS

Resultados

WinRM e WinRS são novas ferramentas muito poderosas que os administradores de sistema Windows devem aprender. Pense nas possibilidades de controle remoto com WinRM/WinRS! Você pode instalar programas, alterar configurações, resolver problemas (claro, se o problema não estiver na comunicação em rede). Você pode ir além e conectar o WinRS com um script para executar essas tarefas em vários computadores. Além disso, lembre-se de que, quer você use essas ferramentas ou não, seu software de gerenciamento de sistema logo as utilizará de uma forma ou de outra.

www.windowsnetworking.com

Veja também:

Comentários dos leitores (sem comentários)

Intercâmbio 2007

Se desejar ler as partes anteriores desta série de artigos, siga os links: Monitorando o Exchange 2007 usando o System Manager...

Introdução Neste artigo de várias partes, quero mostrar o processo que usei recentemente para migrar de um ambiente existente do Exchange 2003...

Se você perdeu a primeira parte desta série, leia-a em Usando a ferramenta Analisador de Conectividade Remota do Exchange Server (Parte...

Se você perdeu a parte anterior desta série de artigos, vá para Monitorando o Exchange 2007 usando o System Center Operations Manager...

Gerenciamento remoto do Windows usando WinRM

Na verdade WinRM(ou Gerenciamento Remoto do Windows) e se traduz como “controle remoto Janelas". WinRM– serviço de gerenciamento remoto para sistemas operacionais janelas. Ele foi incluído nos sistemas operacionais desde Vista E Servidor 2008, Para janelas XP E Servidor 2003 ele precisa ser instalado separadamente daqui. WinRM– a parte do servidor da aplicação de controle remoto, à qual é possível conectar-se remotamente usando um cliente Shell remoto do Windows (WinRS).

WinRM baseado em serviço Serviços Web para Gerenciamento (WS-Management) e usa solicitações HTTP (porta 80) ou HTTPS (443) e SOAP para realizar o trabalho. Independentemente do protocolo utilizado, todo o tráfego enviado WinRMé criptografado (a menos que você desative especificamente esta opção). O protocolo de autenticação padrão é Cérbero.

EM Servidor Windows 2008 WinRM instalado, mas (por motivos de segurança) não habilitado por padrão. Para verificar se está funcionando WinRM em nossa máquina, digite na linha de comando winrm enumerar winrm/config/listener

Se não houver resposta, então WinRM não está correndo. Para configurar WinRM para iniciar automaticamente e permitir a conexão remota ao computador, digite o comando configuração rápida do winrm ou controle de qualidade winrm

Para evitar que o WinRM peça confirmação, você pode adicionar a chave à chamada -quieto. Você pode encontrar informações sobre como ajustar a ajuda integrada. WinRM: configuração de ajuda do winrm

Bem, desligue-o WinRM você pode usar este comando:
winrm excluir winrm/config/listener?IPAdress=*+Transport=HTTP

Além disso, todas as configurações necessárias podem ser feitas usando políticas de grupo. Para fazer isso você precisa:

• Configurar um serviço WinRM para início automático
• Permitir conexões com as portas apropriadas (80 e 443) no firewall janelas
• Configurar um item de Política de Grupo Configuração do Computador\Modelos Administrativos\Componentes do Windows\Gerenciamento Remoto do Windows\Gerenciamento Remoto do Windows\Permitir instalação automática de ouvintes (Configuração do Computador\Modelos Administrativos\Componentes do Windows\Gerenciamento Remoto do Windows\Serviço WinRM\Permitir configuração automática de ouvintes). Aqui você precisará especificar os endereços IP a partir dos quais as conexões são permitidas.

Agora vamos prosseguir para o uso. Para conectar-se a um computador remoto, usamos o utilitário WinRS. WinRS– abreviatura de Shell remoto do Windows(ambiente remoto janelas). COM WinRS podemos fazer solicitações remotas para computadores executando WinRM. No entanto, lembre-se de que sua máquina também precisa estar funcionando WinRM trabalhar com WinRS.

Principal forma de usar WinRSé executar comandos em uma máquina remota. O nome do computador é especificado pela chave -r seguido pelo comando a ser executado, por exemplo vencedores – R: SRV2 ipconfig / todosé executado em um computador remoto SRV2 equipe ipconfig/todos

O protocolo padrão para comunicações é http, mas você também pode usar https: winrs -r:https://SRV2 ipconfig /all

Você também pode usar WinRS abra uma sessão interativa em um computador remoto: winrs -r:SRV2cmd.exe

Esta função é semelhante à conexão via telnet, mas use WinRS Definitivamente melhor do ponto de vista da segurança.

Para usar o WinRM, todos os computadores devem ser membros do mesmo domínio. Se este não for o seu caso, você pode tentar diminuir o nível de segurança. Para isso, no computador que queremos acessar, digite os seguintes comandos:

« verdadeiro")

« »}

WinRM definiu winrm/config/client @(TrustedHosts= « Nome do computador" }

onde ComputerName é o computador remoto a partir do qual a conexão será feita.

No computador do qual nos conectaremos, digite:

WinRM set winrm/config/service/auth @(Básico= « verdadeiro")

WinRM definiu winrm/config/client @(TrustedHosts= « »}

WinRM definiu winrm/config/client @(TrustedHosts="Nome do computador" }

onde ComputerName é o computador que iremos gerenciar.

Em seguida, estabelecemos uma conexão usando o comando:

vencedores -r:"Nome do computador" : -você: Domínio \ nome de usuário –p: Senha cmd.exe

onde Domínio\Nome de usuário é uma conta de usuário com direitos administrativos no computador remoto.

Certa vez, tive problemas com o WinRM em dois servidores.

1. SETSPN
Por um lado, o problema era que o SPN do HTTP/<имя сервера>foram registrados para alguma conta de usuário “errada”.

Encontrei essas postagens com o comando
conjuntospn -F -Q */<имя сервера>

Então eu os apaguei com os comandos
setspn -D http/<имя сервера>.<имя домена> <имя домена>\<левая учётная запись>
setspn -D http/<имя сервера> <имя домена>\<левая учётная запись>

Então enable-psremoting -force foi concluído com êxito.

2. PACOTE DE IDIOMA
E no segundo servidor houve um problema complicado, supostamente com o firewall Não foi possível verificar o status do firewall, pesquisou vários sites e descobriu a solução intuitivamente com base na resposta sobre o pacote de idiomas instalado.

Configuração rápida do WinRm
O serviço WinRM já está em execução nesta máquina.
WSManFault
Mensagem
Falha do provedor
WSManFault
Mensagem = Não foi possível verificar o status do firewall.

Número do erro: -2147024894 0x80070002
O sistema não pode encontrar o arquivo especificado.

A resposta afirmou que este erro pode ser resolvido removendo o pacote de idiomas adicional.
Mas eu fiz diferente. Tenho um sistema operacional em inglês com um pacote adicional de idioma russo. Acabei de mudar o idioma da interface para russo.
Painel de controle, opções regionais e de idioma, idiomas e teclados alteraram o idioma da interface de inglês para russo.
Eu fiz logoff e entrei novamente. Abriu o PowerShell e repetiu o WinRm QuickConfig

PS C:\Windows\system32> winrm qc

O serviço WinRM não está configurado para permitir o controle remoto do computador.
As seguintes alterações precisam ser feitas:

Crie um ouvinte WinRM em HTTP://* para aceitar solicitações WS-Man em qualquer um dos endereços IP deste computador.

Faça mudanças? sim

O serviço WinRM foi atualizado para gerenciamento remoto.

Criado um ouvinte WinRM em HTTP://* para aceitar solicitações WS-Man em qualquer um dos endereços IP deste computador.

Foi um sucesso, mas ainda não é suficiente.

Um erro de acesso negado apareceu ao tentar executar comandos remotamente neste servidor de outro computador.

Nova sessão PS: [<имя сервера>] Conectando ao servidor remoto<имя сервера>falhou com a seguinte mensagem de erro: Acesso negado. Para obter mais informações, consulte o tópico de ajuda about_Remote_Troubleshooting.

Então repeti Enable-PsRemoting

PS C:\Windows\system32> Enable-PsRemoting

Configuração rápida do WinRM
Execute o comando Set-WSManQuickConfig para ativar o gerenciamento remoto usando o serviço WinRM neste computador.
Ações necessárias.
1. Inicie ou reinicie (se já estiver em execução) o serviço WinRM.
2. Alterando o tipo de serviço WinRM para "autostart".
3. Crie um ouvinte para aceitar solicitações em qualquer endereço IP.
4. Configure exceções de firewall para tráfego do serviço WS-Management (somente protocolo http).

Continuar?

(o valor padrão é "Y"):a
O serviço WinRM já está configurado para aceitar solicitações no computador.
O serviço WinRM já está configurado para permitir o controle remoto do computador.

Confirmação
Tem certeza de que deseja realizar esta ação?
Executando a operação "Registrar Configuração de Sessão" no objeto de destino "Configuração de Sessão"
"Microsoft.PowerShell32" não encontrado. O comando "Register-PSSessionConfiguration Microsoft.PowerShell32" será executado
-processorarchitecture x86 -force" para criar a configuração da sessão "Microsoft.PowerShell32". O serviço WinRM irá
reiniciado."
[S] Sim - S [A] Sim para todos - A [N] Não - N [L] Não para todos - L [S] Suspender - S [?] Ajuda
(o valor padrão é "Y"):a

Depois disso, o WinRM funcionou como deveria neste servidor.

17/10/2011 Don Jones

Percebi que os criadores do PowerShell eram um pouco preguiçosos, e isso é bom. Eles não queriam codificar o parâmetro -ComputerName para cada comando, então criaram um sistema geral chamado "remoting". Essencialmente, este sistema permite que qualquer comando seja executado em um computador remoto. Você pode até executar comandos diferentes que existem no computador remoto, mas não existem no seu. Isso significa que você não precisa instalar constantemente todos os comandos em sua estação de trabalho. Este sistema remoto é muito eficiente e oferece uma série de recursos administrativos interessantes

Quando comecei a usar o PowerShell, fiquei interessado no comando Get-Service e percebi que ele tinha um parâmetro -ComputerName. Isso não significa que você pode se conectar ao serviço de outros computadores? Depois de fazer uma série de experimentos, descobri que é exatamente isso que diz. Fiquei interessado e comecei a procurar parâmetros -ComputerName de outros comandos. E fiquei chateado quando descobri que havia apenas alguns deles.

O PowerShell fornece dois tipos de comunicação remota: comunicação remota um para um (1:1) e comunicação remota um para muitos (1:n). Antes de falar sobre eles, quero explicar alguns princípios básicos.

Noções básicas de comunicação remota no PowerShell

A comunicação remota do PowerShell funciona de maneira semelhante ao Telnet e outras tecnologias de controle remoto mais antigas. Quando você executa um comando, ele é executado no computador remoto. Tudo o que retorna ao seu computador é resultado deste comando. Ao contrário do Telnet ou do Secure Shell (SSH), o PowerShell usa um novo protocolo de sistema de comunicações chamado Web Services for Management (WS-Management). O protocolo opera sobre HTTP ou HTTP Secure (HTTPS), o que facilita o roteamento através de firewalls se necessário, já que o protocolo utiliza apenas uma porta para estabelecer comunicações. A implementação do WS-Management pela Microsoft vem na forma de um serviço em segundo plano chamado Windows Remote Management. O WinRM é instalado com o PowerShell 2.0 e é executado por padrão em servidores como o Windows Server 2008 R2. No Windows 7 ele é instalado por padrão, mas não está ativado. Você deve ativar o WinRM nos computadores para os quais deseja enviar o comando. O computador que você está fisicamente não precisa executar o serviço WinRM.

Todos os comandos do PowerShell produzem objetos como saída. Quando você executa um comando remotamente, sua saída precisa estar em um formato que possa ser facilmente transmitido pela rede usando HTTP ou HTTPS. Por exemplo, o PowerShell converte automaticamente objetos de saída em arquivos XML que são enviados pela rede. Assim que chegam ao seu computador, eles são convertidos novamente em objetos com os quais o PowerShell pode trabalhar. No entanto, esses objetos convertidos de volta são, na verdade, instantâneos. Eles não podem se atualizar a cada minuto. Assim, se for necessário chegar a objetos que representam processos em execução em um computador remoto, o resultado obtido só será verdadeiro para o período específico de tempo durante o qual esses objetos foram gerados. Valores como memória e uso de CPU não serão alterados. Além disso, você não poderá forçar os objetos convertidos a fazerem nada. Por exemplo, você não pode comandar um objeto para parar. Esta é uma grande limitação da colaboração remota, mas não o impedirá de trabalhar e fazer coisas interessantes.

Existem apenas alguns requisitos básicos para usar um sistema remoto.

• Como o seu computador (também conhecido como computador local) e aquele para o qual você deseja enviar um comando (também conhecido como computador remoto) devem funcionar com o Windows PowerShell 2.0? O Windows XP é uma versão herdada do Windows na qual você pode instalar o PowerShell 2.0. Assim, a versão antiga também pode participar da sessão remota.
• Idealmente, os computadores locais e remotos devem ser membros do mesmo domínio ou membros de domínios confiáveis/confiáveis. Você pode trabalhar com o sistema remoto fora do domínio, mas é difícil e não vou falar sobre isso aqui. Para saber mais sobre esse cenário, consulte o tópico da Ajuda do PowerShell sobre Remote_Troubleshooting.

Revisão do WinRM

Agora vamos passar para o WinRM, já que você precisa definir as configurações deste serviço para iniciar a comunicação remota. Novamente, você só precisa definir as configurações de comunicação remota do WinRM e do PowerShell no computador remoto. Na maioria dos ambientes em que trabalhei, os administradores ativaram a comunicação remota em todos os computadores que executam versões do XP ou posterior. Isto torna possível penetrar em computadores desktop e laptop sem ser notado, o que pode ser muito útil (o que significa que os usuários de tais computadores não saberão o que você está fazendo).

Isso não quer dizer que o WinRM seja especial para o PowerShell. O WinRM pode rotear o tráfego para vários aplicativos administrativos. Essencialmente, o WinRM atua como um despachante. Quando o tráfego chega, o WinRM decide qual aplicativo deve interagir com ele e marca-o com o nome do aplicativo de destino. O aplicativo receptor deve registrar-se no WinRM para que o WinRM possa escutar o tráfego de entrada em seu nome. Em outras palavras, você não só precisa habilitar o WinRM, mas também registrar o Power Shell como um ponto final para o WinRM.

A maneira mais fácil de realizar ambas as tarefas é executar o PowerShell como administrador e executar o comando Enable-PSRemoting. Você pode consultar o manual para outro comando chamado Set-WSManQuickConfig. Não há necessidade de executar o comando. Enable-PSRemoting faz isso para você e também executa diversas outras etapas necessárias para estabelecer comunicação e operação remotas. Essencialmente, o comando Enable-PSRemoting inicia o serviço WinRM, configura-o para iniciar automaticamente, registra o PowerShell como um ponto de extremidade e até define exceções no Firewall do Windows para permitir o tráfego de entrada do WinRM.

Se não quiser passar por todos os computadores para ativar a comunicação remota, você pode usar um Objeto de Política de Grupo (GPO). As configurações de GPO necessárias estão incorporadas aos controladores de domínio do Windows Server 2008 R2. Basta abrir o GPO e ir até a rota Configuração do Computador\

Modelos Administrativos\Componentes do Windows. Na parte inferior da lista, você encontrará configurações de Shell Remoto e Gerenciamento Remoto do Windows (WRM) que você precisa configurar. A seção Ajuda sobre problemas do sistema de comunicação remota (Remote_Troubleshooting) fornecerá instruções detalhadas sobre como fazer isso. Revise as seções Como habilitar a comunicação remota em uma empresa e como habilitar ouvintes usando uma política de grupo na Ajuda.

O WinRM 2.0 (que o PowerShell usa) por padrão usa a porta TCP 5985 para HTTP e a porta 5986 para HTTPS. Isso garante que o WinRM não entre em conflito com servidores Web instalados localmente e configurados para escutar nas portas 80 e 443. Você pode configurar o WinRM para usar portas alternativas, mas não recomendo fazer isso. Se você sair dessas portas, todos os comandos de acesso remoto do PowerShell funcionarão bem. Se você alterar essas portas, sempre terá que especificar a porta alternativa ao executar o comando de acesso remoto. Isso significa que você terá que digitar mais. Se for absolutamente necessário alterar a porta, você pode inserir o comando:

Winrm definiu winrm/config/ouvinte? Endereço=* +Transporte=HTTP @(Porta="1234")

Os números 1234 indicam a porta que você precisa. Aqui, este comando está escrito em várias linhas, mas você precisa inseri-lo em uma linha. O mesmo se aplica a todos os outros comandos descritos no artigo. Se precisar usar HTTPS em vez de http, você pode modificar este comando para configurar uma nova porta HTTPS. Devo admitir que existe uma maneira de definir as configurações do WinRM em computadores locais para usar portas alternativas por padrão. Dessa forma, você não precisa definir constantemente uma porta alternativa ao executar o comando de acesso remoto. Mas vamos trabalhar com as configurações padrão fornecidas pela Microsoft.

Se você se aprofundar nas configurações de GPO no Remote Shell, notará que pode definir, por exemplo, por quanto tempo uma sessão remota permanecerá inativa antes que o servidor a termine; quantos usuários simultâneos podem acessar o servidor remoto ao mesmo tempo; quanta memória e processos cada shell remoto pode usar; O número máximo de shells remotos que os usuários podem abrir ao mesmo tempo. Essas configurações ajudarão a garantir que seus servidores não sejam sobrecarregados por administradores esquecidos. No entanto, por padrão, você precisa ser um administrador para usar a comunicação remota, então não precisa se preocupar com usuários comuns obstruindo seus servidores.

Interação remota 1:1

Com a comunicação remota 1:1, você basicamente tem acesso à linha de comando em um computador remoto. Todos os comandos fornecidos são executados diretamente no computador remoto e você vê os resultados na janela do prompt de comando. É um pouco semelhante ao uso da Conexão de Área de Trabalho Remota, exceto que você está limitado ao ambiente de linha de comando do PowerShell. A comunicação remota do PowerShell usa uma fração dos recursos exigidos pela Área de Trabalho Remota, portanto, tem muito menos impacto em seus servidores.

Para estabelecer uma conexão 1:1 com um computador remoto chamado Server-R2, você precisa executar

Enter-PSSession -Computername Server-R2

Supondo que você tenha habilitado a comunicação remota no dispositivo remoto, o computador esteja no mesmo domínio e sua rede esteja funcionando normalmente, você obterá a conexão necessária. O PowerShell permite que você saiba que atingiu seu objetivo alterando seu prompt de comando para

PSC:\>

A parte informa que tudo o que você faz acontece no Server-R2. Depois disso, você pode executar os comandos que desejar. Você pode até importar quaisquer módulos e adicionar extensões do PowerShell (PSSnapins) que estarão localizadas no computador remoto.

Até as permissões permanecerão as mesmas. Sua cópia do PowerShell será executada com o mesmo token de segurança com o qual foi iniciada. O PowerShell faz isso usando Kerberos, portanto não transmite o nome de usuário e a senha pela rede. Qualquer comando executado no computador remoto será executado com suas credenciais, portanto, qualquer coisa que você tenha permissão para fazer, você poderá fazer. Isto é semelhante ao registo diretamente a partir da consola do computador e à utilização de uma cópia do PowerShell desse computador. É quase assim. Aqui estão algumas diferenças.

• Se você tiver um script do PowerShell para o seu perfil no computador remoto, ele não será executado quando você se conectar usando o sistema de acesso remoto. Simplificando, os perfis são um pacote de comandos executados automaticamente sempre que você abre uma janela do prompt de comando. Eles são usados ​​para baixar automaticamente extensões, módulos e similares.
• Você está limitado pela Política de Execução do computador remoto. Digamos que a política do seu computador esteja definida como RemoteSigned para que você possa executar scripts locais não assinados. Se a política de computador remoto estiver definida como Restrito (a configuração padrão), nenhum script será executado quando você se comunicar remotamente.

Muitos comandos do PowerShell vêm em pares: um faz alguma coisa, o outro faz o oposto. No nosso caso, Enter-PSSession conecta você ao computador remoto e Exit-PSSession fecha essa conexão. Exit-PSSession não requer nenhum parâmetro. Depois de iniciada, a conexão remota é fechada e o prompt da janela do prompt de comando volta ao normal. E se você esquecer de executar o Exit-PSSession? Não se preocupe. PowerShell e WinRM podem descobrir o que você fez e fechar a conexão remota, se necessário.

Quero dar um conselho. Ao se conectar a um computador remoto, não execute Enter-PSSession nele até que esteja totalmente ciente do que está fazendo. Por exemplo, você trabalha na ComputerA. Você se conecta ao Server-R2. Na linha do PowerShell você executa

PS C:\>Enter-PSSession Server-DC4

O Server-R2 agora contém uma conexão aberta com o Server-DC4. Isso cria uma “cadeia remota” que é difícil de rastrear. Além disso, seus servidores ficam sobrecarregados desnecessariamente. Pode haver momentos em que você terá que fazer isso (por exemplo, o Server-DC4 está atrás de um firewall e você não pode acessá-lo diretamente, então você precisa usar o Server-R2 como intermediário). No entanto, a regra geral é esta: tente evitar cadeias remotas.

1:n remoto

Uma das coisas mais legais sobre o PowerShell é a comunicação remota 1:n. Ele permite que você envie comandos para vários computadores remotos ao mesmo tempo – computação distribuída completa. Cada computador executará individualmente o comando e enviará os resultados. Tudo é feito usando o comando Invoke-Command neste formato:

Invoke-Command -ComputerName Server-R2, Server-DC4, Server12 -Command (Get-EventLog Security -Newest 200 | Onde ($_.EventID -eq 1212))

O comando entre chaves externas é enviado para todos os três computadores remotos. Por padrão, o PowerShell pode se comunicar com até 32 computadores ao mesmo tempo. Se você especificar mais de 32 computadores, eles serão enfileirados. Então, quando um computador é desligado, o próximo executa o comando. Se você tiver uma rede realmente rápida e computadores poderosos, poderá aumentar seu número usando o parâmetro de comando ThrottleLimit. Você pode ler sobre como usar esse parâmetro em Invoke-Command na página de Ajuda.

O único parâmetro que você não verá na página de Ajuda deste comando é o parâmetro Command. Como já mostrei, funciona muito bem. O parâmetro Command é um alias ou nome abreviado para o parâmetro ScriptBlock, listado na página Ajuda. Acho mais fácil usar o Command, então costumo usá-lo em vez do ScriptBlock, mas eles funcionam da mesma forma.

Se você leu a página de Ajuda do Invoke-Command com atenção, também notou uma opção que permite especificar um arquivo de script em vez de um comando. O parâmetro FilePath permite enviar o script para computadores remotos; isso significa que você pode automatizar algumas tarefas complexas e fazer com que cada computador faça sua parte no trabalho.

Agora vamos nos concentrar no parâmetro Nome do Computador. No código de exemplo Invoke-Command, eu tinha uma lista separada por vírgulas de nomes de computadores. Se você tiver muitos computadores, talvez não queira digitar seus nomes sempre que se conectar a eles. Em vez disso, você pode criar um arquivo de texto que contenha o nome de um computador em uma linha, sem vírgulas, aspas ou qualquer outra coisa. Por exemplo, se o seu arquivo de texto fosse denominado webservers.txt, você usaria um código como este:

Invoke-Command -Command ( dir ) - ComputerName (Get-Content webservers.txt)

Os parênteses forçam o PowerShell a executar o comando Get-Content primeiro - isso é semelhante a como os parênteses funcionam na matemática. Os resultados de Get-Content são então aninhados no parâmetro -ComputerName.

Também é possível consultar o nome do computador no Active Directory, mas isso é mais complicado. Para encontrar um computador, você pode usar o comando Get-ADComputer, mas não colocará o comando entre parênteses como fez com Get-Content. Por que não? Get-Content produz strings de texto simples, enquanto Get-ADComputer produz objetos do tipo “computador”. O parâmetro -ComputerName espera uma string. Se ele tivesse que receber objetos de computador, não saberia o que fazer com eles. Portanto, se quiser usar Get-ADComputer, você precisa obter os valores da propriedade Name dos objetos do computador. Assim:

Invoke-Command -Command (dir) -ComputerName (Get-ADComputer -Filter * -SearchBase "ou=Sales, dc=company, dc=pri" | Select-Object -Expand Name)

Entre parênteses, os objetos de computador são passados ​​​​para o comando Select-Object, e o parâmetro -Expand é usado para descobrir a propriedade Name desses objetos de computador. O resultado da expressão entre parênteses é um conjunto de nomes de computadores, não de objetos de computador. Os nomes dos computadores são exatamente o que o parâmetro -Computer Name precisa.

Se você não está familiarizado com Get-ADComputer, vamos dar uma olhada no que esse comando faz. O parâmetro -Filter especifica que todos os computadores devem ser incluídos nos resultados, e o parâmetro -Search Base instrui o PowerShell a iniciar a pesquisa de computadores no grupo organizacional de vendas (OU) no domínio company.pri. O comando Get-ADComputer só está disponível no Windows Server 2008 R2 e no Windows 7 após a instalação das Ferramentas de Administração de Servidor Remoto. Nestes sistemas operacionais você executa

Módulo de importação ActiveDirectory

para carregar comandos de serviço de diretório em um shell de comando para que possam ser usados.

Há outra coisa!

Todos esses exemplos foram dados para sessões de comunicação remota ponto a ponto. Se você for se reconectar aos mesmos computadores (ou computador) várias vezes em um curto período de tempo, poderá criar sessões persistentes e reutilizáveis. Isto é muito útil se a conexão exigir credenciais alternativas, um número de porta não padrão ou qualquer outra coisa que exija parâmetros adicionais.

Para criar sessões persistentes, você precisa usar o comando New-PSSession e armazená-las em uma variável para facilitar o acesso. Por exemplo, o código a seguir cria uma sessão remota com três computadores e os armazena na variável $sessions:

$sessions = New-PSSession -ComputerName Um, Dois, Três -Porta 5555 -Credencial DOMÍNIO\Administrador

As sessões remotas fecham automaticamente quando você fecha o shell de comando, mas até então elas podem ocupar memória e algum uso da CPU nos sistemas locais e remotos. Para fechá-los exatamente, você pode usar o comando Remove-PSSession:

$sessões | Remover-PSSession

Quando precisar reabrir sessões, você pode usar o Invoke-Command:

Invoke-Command -Command (dir) -Session $sessões

Ou você pode usar Enter-PSSession:

Enter-PSSession -Session $sessão

Observe que no código Enter-PSSession, apenas uma sessão de comunicação remota é reaberta. A variável de índice 1 informa ao PowerShell que ele deve reabrir uma sessão com o computador chamado Dois (o índice é baseado em zero).

Como podemos ver, há muitos benefícios na comunicação remota do PowerShell. Se você usá-lo, verá o quanto ele expandirá seus horizontes.

Dom Jones ( [e-mail protegido]) é instrutor técnico do PowerShell (www.windowsitpro.com/go/DonJonesPowerShell), autor de mais de 35 livros. Tem o título de MVP da Microsoft

Neste artigo, tentarei explicar como você pode ativar e configurar centralmente o serviço Gerenciamento Remoto do Windows (WinRM) em todos os computadores de destino usando a Política de Grupo. Deixe-me lembrá-lo de que o Gerenciamento Remoto do Windows é um serviço especial que permite aos administradores obter a capacidade de acessar e gerenciar remotamente sistemas operacionais Windows de cliente e servidor (e acho que se você já usou o conjunto de utilitários Microsoft Sysinternals, então você deveria gostar WRM).
Vamos pegar um PC normal com e no qual a função de gerenciamento remoto do Windows não está ativada. Na linha de comando, digite o seguinte comando:

, você deverá ver a seguinte mensagem de erro indicando que o WRM não está instalado:
Falha do WSMan. O cliente não pode se conectar ao destino especificado na solicitação. Número do erro: - 2144108526 0x80338012

Se você precisar configurar o WinRM manualmente em um sistema separado, basta digitar o comando:

Configuração rápida do Winrm

Se precisar configurar o WinRM em um grupo de computadores, você poderá usar configurações especiais de Política de Grupo. A política que nos interessa está localizada na seção: Configuração do Computador -> Políticas -> Componentes do Windows -> Gerenciamento Remoto do Windows (WinRM) -> Serviço WinRM. Os seguintes parâmetros precisam ser ativados:
Permitir configuração automática de ouvintes
Permitir autenticação básica

Na seção de filtro IPv4 indicamos *, o que significa que o computador pode aceitar conexões (e portanto controlar comandos) de qualquer lugar, isso significa que os ouvintes do computador aceitarão solicitações em todas as interfaces IP.


Em seguida, na seção Configuração do Computador -> Políticas -> Componentes do Windows -> Windows Remote Shell, ative o item:
Permitir acesso remoto ao shell


E, finalmente, você precisa definir o tipo de inicialização do Serviço Remoto do Windows como “Automaticamente”. Deixe-me lembrá-lo de que você pode controlar a forma como os serviços são iniciados na seguinte seção de política de grupo: Configuração do computador -> Configurações do Windows -> Configurações de segurança -> Serviços do sistema.


Depois de ativar o WinRM usando a Política de Grupo, verifique o status do serviço no sistema cliente usando o comando familiar:

Vamos garantir que o tipo de inicialização do serviço WinRM esteja definido como automático. Embora na verdade o tipo de lançamento seja “automático com atraso”, porque Por padrão, o serviço WinRM possui um atraso de inicialização definido (parâmetro DelayedAutoStart=1 na ramificação HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinRM).

Agora, após ativar o WinRM usando Política de Grupo, este sistema pode ser gerenciado remotamente usando comandos WinRS. O seguinte comando abrirá um prompt de comando em execução no sistema remoto:

Winrs –r:computador01 cmd

Assim que a janela do prompt de comando aparecer, você poderá executar e ver os resultados de qualquer comando no computador remoto, como se estivesse trabalhando nele localmente. Observe que o WinRM também deve estar ativado no seu computador host.