Windows PowerShell 2.0 introduziu uma nova tecnologia poderosa, Remoting, que foi refinada e expandida para PowerShell 3.0. Baseado principalmente em protocolos padronizados e técnicas, Remoting é possivelmente um dos aspectos mais importantes do PowerShell: futuros produtos da Microsoft irão depender dele quase inteiramente para comunicações administrativas através de uma rede.,
infelizmente, Remoting também é um conjunto complexo de componentes, e embora a Microsoft tenha tentado fornecer uma orientação sólida para usá-lo em uma variedade de cenários, muitos administradores ainda lutam com ele. Este “mini e-book” é projetado para ajudá-lo a entender melhor o que é Remoting, como ele funciona, e-mais importante-como usá-lo em uma variedade de situações diferentes.
Note que este guia não é destinado a substituir a miríade de livros existentes que cobrem conceitos básicos Remotores, como o próprio Learn Windows PowerShell em um mês de almoços ( http://MoreLunches.com) ou PowerShell em profundidade., Em vez disso, este guia complementa aqueles fornecendo instruções passo-a-passo para muitos dos casos “edge” em Remoting, e explicando alguns dos comportamentos e requisitos mais incomuns Remoting.
na essência, a Remoting permite-lhe aceder a máquinas remotas através de uma rede e obter dados ou executar código em um ou muitos computadores remotos. Esta não é uma idéia nova, e no passado um número de tecnologias remoting diferentes evoluíram. Alguns cmdlets têm tradicionalmente fornecido suas próprias capacidades remotas limitadas, enquanto a maioria dos cmdlets não suportam remoting por conta própria.,
com PowerShell remoting existe finalmente um ambiente remoting genérico que permite a execução remota para literalmente qualquer comando que possa correr numa PowerShell local. Então, em vez de adicionar capacidades remotoras a cada cmdlet e aplicação, você simplesmente deixá-lo para PowerShell para transferir seu código PowerShell para o(S) Computador (s) alvo, executá-lo lá, e, em seguida, marshal de volta os resultados para você.
ao longo deste eBook, vamos focar na PowerShell remoting e não cobrir capacidades privadas remoting não-padrão incorporadas em cmdlets selecionados.,
Examining Remoting Architecture
As shown in figure 1.1, Powershell’s generic Remoting architecture consists of numerous different, inter-related components and elements.
Figura 1.1: elementos e componentes do PowerShell Remoting
Aqui está a lista completa:
■ Na parte inferior da figura é o seu computador, ou mais propriamente o seu cliente., Aqui é onde você se senta fisicamente, e é onde você iniciará a maioria de suas atividades remotas.
■ o seu computador irá comunicar através do WS-MAN, ou serviços Web para gestão, protocolo. Este é um protocolo baseado em HTTP que pode encapsular uma variedade de diferentes comunicações. Nós ilustramos isso como usando HTTP, que é a configuração padrão da Remoting, mas poderia facilmente ser HTTPS.
■ no computador remoto, na terminologia adequada o servidor (que não se refere ao sistema operativo), o serviço Windows Remote Management (WinRM) funciona., Este serviço está configurado para ter um ou mais ouvintes. Cada ouvinte espera pelo tráfego ws-MAN de entrada em um porto específico, cada um ligado a um protocolo específico (HTTP ou HTTPS), e em endereços IP específicos (ou todos os endereços locais).
■ Quando um ouvinte recebe tráfego, o serviço WinRM procura ver para que ponto o tráfego é destinado. Para nossos propósitos, um endpoint geralmente será lançar uma instância do Windows PowerShell. Em termos PowerShell, um endpoint também é chamado de configuração de sessão., Isto porque, além de lançar PowerShell, Ele pode auto-carregar scripts e módulos, colocar restrições sobre o que pode ser feito pelo Usuário conectando, e aplicar configurações específicas de sessão adicionais não mencionados aqui.
Note Although we show PowerShell.exe em nosso diagrama, isso é para fins de ilustração. PowerShell.exe é a aplicação PowerShell console, e não faria sentido ter isso funcionando como um processo de fundo em um computador remoto. O processo real é chamado Wsmprovhost.exe, que hospeda PowerShell no fundo para conexões Remoting.,
Como você pode ver, um único computador remoto pode facilmente ter dezenas ou mesmo centenas de Pontos finais, cada um com uma configuração diferente. O PowerShell 3.0 define três desses parâmetros por padrão: um para PowerShell 32-bit (em sistemas 64-bit), o PowerShell endpoint padrão (que é 64-bit em sistemas x64), e um para PowerShell Workflow. Começando com o Windows Server 2008 R2, há um quarto endpoint padrão para tarefas de fluxo de trabalho do Gerenciador de servidor.,
activar a remoção
a maioria das versões cliente do Windows, a começar pelo Windows Vista, não activam as ligações externas recebidas por omissão. Versões mais recentes do Windows Server fazem, mas versões mais antigas não podem. Então seu primeiro passo com Remoting normalmente será ativá-lo nos computadores que você deseja receber conexões de entrada. Existem três maneiras de permitir Remoting, e a tabela 1.1 compara o que é alcançável com cada um deles.Tabela 1.,1 Comparing the ways of enabling remoting
Enable-PSRemoting |
Group Policy |
Manually Step-by-Step |
|||
Set WinRM to auto-start and start the service |
Yes |
Yes |
Yes – use Set-Service and Start-Service., |
No |
Yes – use PSSessionConfiguration cmdlets |
Configure Windows Firewall exception |
Yes* |
Yes* |
Yes* – use Firewall cmdlets or Windows Firewall GUI |
Note Existing client versions of Windows, such as Windows Vista, do not permit firewall exceptions on any network identified as “Public”., As redes devem ser “Home” ou “Trabalho/domínio”, a fim de permitir exceções. Em PowerShell 3.0, você pode executar Active-PSRemoting com o switch-Skipnetprofilecheck para evitar este problema.
estaremos habilitando Remoting em nosso ambiente de teste executando Enable-PSRemoting. É rápido, fácil e abrangente; Você também verá a maioria das tarefas manuais realizadas nas próximas seções.
ambiente de ensaio
estaremos a utilizar um ambiente de ensaio consistente ao longo das seguintes secções; este foi criado em seis máquinas virtuais em CloudShare.,com, e está configurado como mostrado na figura 1.2.
Figura 1.2: ambiente de Teste de configuração
Algumas observações importantes:
■ .NET Framework v4 e PowerShell 3.0 está instalado em todos os computadores. A maior parte do que vamos cobrir também se aplica ao PowerShell 2.0.,
■ Como mostrado, a maioria dos computadores tem um nome numérico de computador (C2108222963, e assim por diante); O controlador de domínio para cada domínio (que também é um servidor DNS) tem registros de CNAME com nomes mais fáceis de lembrar.
■ cada controlador de domínio tem um transitário condicional configurado para o outro domínio, de modo que as máquinas em qualquer domínio podem resolver nomes de computador no outro domínio.
■ realizamos todas as tarefas como um membro do grupo Admins domínio, salvo indicação em contrário.
■ criamos um sexto servidor completamente independente que não está em nenhum domínio., Isto será útil para cobrir algumas das situações fora do domínio em que você pode encontrar-se com Remoting.
cuidado ao abrir o PowerShell num computador que tenha o controlo da Conta do utilizador (UAC) activo, certifique-se que carrega com o botão direito no ícone PowerShell e seleccione Executar como administrador. Se a barra de título da janela PowerShell resultante não começar com o administrador: então você não tem privilégios administrativos. Você pode verificar as permissões programaticamente com isto (whoami / all / select-string S-1-16-12288) – ne $null do console PowerShell., Em uma concha elevada verdadeiro é devolvido, caso contrário falso é.
activar a remoção
começámos por executar o Active-PSRemoting em todos os seis computadores. Tivemos o cuidado de garantir que o comando funcionava sem erro; quaisquer erros neste ponto são um sinal de que você deve parar e resolver o erro antes de tentar prosseguir. A figura 1.3 mostra a saída esperada.
Figura 1.,3: resultado esperado do Active-PSRemoting
Nota: irá notar o uso desenfreado de imagens de ecrã ao longo deste guia. Ele ajuda a garantir que eu não faço nenhum erro de digitação ou copiar/colar – você está vendo exatamente o que nós digitamos e executamos.
a execução da configuração do Get-Psssession deve revelar os três ou quatro parâmetros criados pelo Enable-PSRemoting. A figura 1.4 mostra a saída esperada num servidor.
Figura 1.,4: o resultado esperado da configuração do Get-PSSession
Nota: A Figura 1.4 ilustra que você pode esperar que diferentes pontos finais sejam configurados em máquinas diferentes. Este exemplo foi de um computador do Windows Server 2008 R2, que tem menos endpoints do que uma máquina do Windows 2012.vale a pena tirar um momento para testar rapidamente a configuração Remotora. Para computadores que são todos parte do mesmo domínio, quando você está logado como um administrador de domínio desse domínio, Remoting deve “apenas funcionar.”Verifique-o rapidamente, tentando remotear de um computador para outro usando Enter-Psssession.,
nota: em outros ambientes, uma conta Admin do domínio pode não ser a única conta que pode usar Remoting. Se o seu ambiente de trabalho ou casa tem contas adicionais no grupo de Administradores locais como padrão em todo o seu domínio, Você também será capaz de usar essas contas para Remoting.
a figura 1.5 mostra o resultado esperado, no qual também executamos um comando Dir rápido e depois saímos da sessão remota.
figura 1.5: verificação da conectividade remota da empresa.CLIENTA de loc para o controlador de domínio DCA.
cuidado: se você está seguindo em seu próprio ambiente de teste, não avance até que você tenha confirmado conectividade remota entre dois computadores no mesmo domínio. Nenhum outro cenário precisa funcionar agora; vamos chegar até eles nas próximas seções.
tarefas de núcleo Remoting
PowerShell fornece dois principais casos de Uso Remoting., O primeiro, 1-to-1 Remoting, é similar na natureza ao SSH secure shell oferecido nos sistemas UNIX e Linux. Com isso, você recebe um prompt de linha de comando em um único computador remoto. O segundo, 1-a-muitos Remoting, permite que você envie um comando (ou uma lista de comandos) em paralelo a um conjunto de computadores remotos. Há também algumas técnicas secundárias úteis que vamos ver.
1-a-1 Removendo
o comando Enter-Psession liga-se a um computador remoto e dá-lhe uma linha de comandos nesse computador., Você pode executar quaisquer comandos que estejam nesse computador, desde que você tenha permissão para executar essa tarefa. Note que não está a criar uma sessão de logon interactiva; a sua ligação será auditada como um logon de rede, tal como se estivesse a ligar-se à partilha administrativa de C$ do computador. O PowerShell não irá carregar ou processar programas de perfis no computador remoto. Todos os programas que escolher Executar (e isto inclui a importação de módulos de script) só funcionarão se a Política de execução da máquina remota o permitir.,
Enter-PSSession -computerName DC01
Nota: Enquanto estiver conectado a um computador remoto através de Enter-PSSession, seu prompt de alterações e exibe o nome do sistema remoto entre colchetes. Se você personalizou seu prompt, todas as personalizações serão perdidas porque o prompt é agora criado no sistema remoto e transferido de volta para você. Toda a sua entrada de teclado interativo é enviada para a máquina remota, e todos os resultados são enviados de volta para você. Isto é importante de notar porque você não pode usar Enter-Psssession em um script., Se o fizesse, o script ainda funcionaria na sua máquina local, uma vez que nenhum código foi introduzido interativamente.
1-A-Muitos Remotores
com esta técnica, você indica um ou mais nomes de computador e um comando (ou uma lista de comandos separada por ponto-e-vírgula); O PowerShell envia os comandos, via Remoting, para os computadores especificados. Esses computadores executam os comandos, serializam os resultados em XML, e transmitem os resultados de volta para você. Seu computador deserializa o XML de volta em objetos, e coloca-os no pipeline de sua sessão PowerShell., Isto é feito através do comando de Invocação cmdlet.
Invoke-Command -computername DC01,CLIENT1 -scriptBlock { Get-Service }
Se você tiver um script de comandos para executar, você pode ter o Comando Invoke lê-lo, transmite o conteúdo para os computadores remotos, e tê-los executar esses comandos.
Invoke-Command -computername DC01,CLIENT1 -filePath c:\Scripts\Task.ps1
Note que o comando de Invocação irá, por omissão, comunicar-se com apenas 32 computadores de uma vez. Se você especificar mais, os extras irão fazer fila, e o comando Invoce-irá começar a processá-los à medida que terminar os primeiros 32., O parâmetro-ThrottleLimit pode aumentar este limite; o único custo é para o seu computador, que deve ter recursos suficientes para manter uma sessão PowerShell única para cada computador que você está contatando simultaneamente. Se você espera receber grandes quantidades de dados dos computadores remotos, a largura de banda da rede disponível pode ser outro fator limitante.,
Sessions
Quando você executa Enter-PSSession ou Invoke-Command e usar sua parâmetro-ComputerName, de sistema de interacção remota cria uma conexão (ou sessão), faz tudo o que você pediu a ele para e, em seguida, fecha a conexão (no caso de uma sessão interativa criada com Enter-PSSession, o PowerShell sabe que você é feito quando você executar Sair-PSSession). Há algumas despesas envolvidas nessa configuração e destruição, e assim PowerShell também oferece a opção de criar uma conexão persistente – chamada Psssession. Você executa o New-Psssession para criar uma sessão nova e persistente., Então, ao invés de usar o-ComputerName com Enter-Psssession ou invocar-Command, você usa o parâmetro de sessão deles e passa um objeto de Psssession aberto. Isso permite que os comandos reutilizem a ligação persistente que você criou anteriormente.
Quando você usa o parâmetro-ComputerName e trabalha com sessões ad-hoc, cada vez que você envia um comando para uma máquina remota, há um atraso significativo causado pela sobrecarga necessária para criar uma nova sessão. Dado que cada chamada para Enter-Psssession ou invocar-Command configura uma nova sessão, você também não pode preservar o estado., No exemplo abaixo, a variável $test é perdida na segunda chamada:
Quando você usa sessões persistentes, por outro lado, as re-conexões são muito mais rápidas, e como você está mantendo e reutilizando as sessões, elas irão preservar o estado., Então, aqui, a segunda chamada para Invoke-Command ainda será capaz de acessar a variável $teste, que foi instalada, em primeira convocação
Vários outros existem comandos para verificação da sessão de status e recuperar sessões (Get-PSSession), fechá-las (Remove-PSSession), desconecte e reconecte-os (Desligar-PSSession e Reconectar-PSSession, que são novos no PowerShell v3), e assim por diante., No PowerShell v3, você também pode passar uma sessão aberta para Obter-Módulo e Módulo de Importação, permitindo que você veja os módulos listados em um computador remoto (via aberta PSSession), ou para importar um módulo a partir de um computador remoto para o seu computador para implícita remoto. Reveja a ajuda nesses comandos para saber mais.
Nota: Uma vez que você use New-Psssession e crie suas próprias sessões persistentes, é sua responsabilidade fazer a limpeza e fechar e eliminar a sessão quando você terminar com eles., Até que você faça isso, sessões persistentes permanecem ativas, consomem recursos e podem impedir que outros se conectem. Por padrão, apenas 10 conexões simultâneas a uma máquina remota são permitidas. Se você manter muitas sessões ativas, você irá facilmente correr para os limites de recursos. Essa linha demonstra o que acontece se você tentar configurar muitas sessões simultâneas:
PS> 1..10 | Foreach-Object { New-PSSession -ComputerName CLIENT1 }
Remoting Retorna anular a serialização de Dados
Os resultados que você recebe a partir de um computador remoto tem sido serializado em XML e, em seguida, anular a serialização no seu computador., Em essência, os objetos colocados no pipeline do seu shell são retratos estáticos, separados do que estava no computador remoto no momento em que o seu comando terminou. Estes objetos deserializados não possuem os métodos dos objetos originais, e em vez disso só oferecem propriedades estáticas.
Se você precisa acessar métodos ou Alterar Propriedades, ou em outras palavras, se você precisa trabalhar com os objetos ao vivo, basta ter certeza que você faz isso no lado remoto, antes que os objetos sejam serializados e viajar de volta para o chamador., Este exemplo usa os métodos do objeto no lado remoto para determinar o processo de proprietários que funciona muito bem:
uma Vez que os resultados da viagem de volta para você, você não pode chamar os métodos do objeto porque agora você trabalha com “reidratada” objetos que são destacados os objetos vivos e não contêm quaisquer métodos mais:
Serialização e desserialização é relativamente caro. Você pode otimizar velocidade e recursos, certificando-se de que seu código remoto emite apenas os dados que você realmente precisa., Você pode, por exemplo, usar Select-Object e escolher cuidadosamente as propriedades que você deseja de volta em vez de serializar e deserializar tudo.
Enter-Psssession vs. Invoke-Command
muitos recém-chegados irão ficar um pouco confusos sobre remoting, em parte devido à forma como o PowerShell executa scripts. Considere o seguinte, e assuma que o SERVER2 contém um script chamado C:\RemoteTest.,ps1:
Enter-PSSession -ComputerName SERVER2C:\RemoteTest.ps1
Se fosse sentar e digitar estes comandos interactivamente na janela da consola no computador do seu cliente, isto funcionaria (assumindo que a remoting foi configurada, que tinha permissões, e tudo isso). No entanto, se colasses isto num guião e passasses esse guião, não funcionaria. O script tentaria executar C:\RemoteTest.ps1 no seu computador local.
a conclusão prática disto é que Enter-PSSession é realmente para uso interativo por um ser humano, não para uso em lote por um script., Se você queria enviar um comando para um computador remoto, de dentro de um script, invoque-comando é a maneira certa de fazê-lo. Você pode configurar uma sessão com antecedência (útil se você planeja enviar mais de um comando), ou você pode usar um nome de computador se você quiser apenas enviar um único comando. Por exemplo:
$session = New-PSSession -ComputerName SERVER2Invoke-Command -session $session -ScriptBlock { C:\RemoteTest.ps1 }
obviamente, terá de usar alguma precaução. Se essas fossem as duas únicas linhas do script, então quando o script terminou de executar, $session deixaria de existir., Isso poderá desligá-lo (de certa forma) da sessão que está a correr no servidor 2. O que fazes, e mesmo que precises de te preocupar com isso, depende muito do que estás a fazer e como o estás a fazer. Neste exemplo, tudo provavelmente estaria bem, porque o comando Invoke iria “manter” o script local em execução até que o script remoto terminasse e retornasse sua saída (se houver).