Windows PowerShellFique assentada!

Don Jones

Conteúdo

A solução
Veja IT em ação
Remoto de um-para-muitos
Colocar IT do seu mental
É o gerenciamento remoto, estilo novo escola

Eu sempre esteve frustrado pela mensagem dupla que vem, às vezes, fora da Microsoft sobre gerenciamento de servidor: ativado um lado, está corretamente dissemos para instalar as ferramentas de gerenciamento em nossos computadores cliente e usar essas ferramentas para gerenciar nossos servidores.Nós não estiver deve para ir para o Centro de dados e até mesmo usar área de trabalho remota é tecnicamente trapaça porque ele é basicamente apenas entrar em Centro de dados sem executar o exame.Por outro lado, entretanto, há muitas tarefas de gerenciamento de servidor que não podem ser executadas facilmente usando ferramentas remotas existentes — alterando os endereços IP ou coisa com a configuração de rede, por exemplo.

Windows PowerShell perguntas e respostas

QUm script do Windows PowerShell pode ser usado como um script de logon?

A Sim, mas pode não haver qualquer ponto ao fazer isso.Você não pode simplesmente arrastar o script para um objeto de diretiva de grupo (GPO) da forma que você pode um arquivo VBScript.Em vez disso, você precisa criar um arquivo em lotes basicamente executa Powershell.exe, passar o parâmetro de linha de comando que informa o script para executar.É estranho.Você também precisará instalar o Windows PowerShell em cada computador onde esse script de logon será executado.No final, tenha em mente que o Windows PowerShell é um pouco mais independente de VBScript ou o shell cmd.exe.Por exemplo, o mapeamento de uma unidade usando o cmdlet New-PSDrive não afetará Windows Explorer — você teria de retorno sobre o comando NET use para mapear uma unidade no Windows, na verdade e se você pretende fazer isso por que não apenas usar um arquivo em lotes tradicional, que é mais fácil incluir em um GPO?

QScripts do Windows PowerShell podem ser agendados?

A absoluta.Na verdade, você será agendar PowerShell.exe (que está localizado na sua pasta % systemroot %, em /WindowsPowerShell) e dê a ele um parâmetro de linha de comando especificando o script que você deseja executar.Certifique-se a tarefa agendada está configurada para utilizar uma conta de usuário que tenha as permissões necessárias para fazer tudo o que o script faz e verifique se a diretiva de execução do shell está configurada para permitir a execução do script (prefiro a diretiva AllSigned me, que significa que seu script precisará ser digitalmente assinado; executar "Ajuda about_signing" no shell para obter detalhes sobre isso).

QExiste uma maneira fácil para trabalhar com permissões de arquivo e pasta no Windows PowerShell?

A se.Você tem comandos Get-ACL e Set-ACL, para começar — Get-ACL é ótimo se tudo o que você precisa fazer for relatório nas permissões.Francamente, usar esses comandos para alterar permissões, na verdade, é impraticável — permissões Windows são bastante complicado e e a programação que você precisa fazer para definir listas de controle (ACLs) de acesso é igualmente complicada.Mas quem diz que você deve usar cmdlets?O shell é ótimo para executar ferramentas de linha de comando mais tradicionais e as várias iterações do cacls.exe (incluindo aqueles como Dsacls para o Active Directory) funcionam muito bem no Windows PowerShell.Eu sempre usá-los ao preciso modificar ou definir permissões de arquivo e pasta.

Configurar uma nova instalação Server Core é outro exemplo excelente.Adição de funções, configurando a rede, até mesmo ativando o Windows devem todas ser feita em uma janela de console local ou através da área de trabalho remota, usando ferramentas de linha de comando.Ferramentas de que existem atualmente são soluções ponto gravado personalizado que lidar com uma única tarefa ou soluções que necessitam de experiência com (WMI).Gosto de WMI, mas Francamente, é muito complexa para a maioria dos administradores de gastar muito tempo aprendizado e portanto, ele geralmente vai não utilizado.

Windows PowerShell tem prometido facilitar tudo isso — fazendo um pouco mais fáceis de lidar com WMI, mas que é mais importante, por tarefas administrativas em mais fácil de usar os cmdlets que corresponde aproximadamente com os utilitários de linha de comando usamos para anos de quebra.Problema do shell é que, além do WMI, é essencialmente um shell local.Muitos dos seus cmdlets de configuração do sistema operacional principal não oferecem qualquer suporte para entrar em contato com um computador remoto.O shell também não resolve um dos problemas mais egregious do WMI: o uso de chamadas de procedimento remoto (RPCs) para conectividade remota.RPCs são uma dor de cabeça em ambientes que usam firewalls locais (e que não esses dias?), inutilizando WMI com freqüência para qualquer tipo de gerenciamento remoto.

A solução

Microsoft foi atento essas limitações por muito tempo, mas ele é obtido algum tempo para todos os corrige o necessário para alinhar-se em um único produto.Esse produto é v2 de Windows PowerShell, que inclui uma nova versão do Windows Remote Management (WRM).Tanto será lançado pela primeira vez no Windows 7 e no Windows Server 2008 R2 e ambos serão pré-instalados nesses sistemas operacionais por padrão.

As tecnologias também estarão disponíveis para versões anteriores do Windows, possivelmente, até consecutivos como Windows XP.Mas como da redação deste artigo, nenhum anúncio oficial foi feito sobre exatamente quais sistemas operacionais mais antigos terão suporte (a mais antiga OS, tarefa da Microsoft mais difícil, porque versões mais antigas podem não tem alguns o necessário principais tecnologias de suporte).

WinRM é realmente a tecnologia de chave que torna possível tudo isso.É uma implementação Microsoft do WS-MAN ou serviços da Web para o gerenciamento e como o nome implica, ele usa HTTP e HTTPS para se comunicar, que significa que é fácil obter o tráfego por meio de um firewall.Diferentemente do RPCs, que inicie em um único ponto conhecido e mova seu conversação para uma porta escolhida aleatoriamente, HTTP e HTTPS utiliza uma única porta — 80 e 443, por padrão, mas configurável se você não gostar dos.WinRM permite que vários aplicativos diferentes para "ouvir" as conexões de gerenciamento de entrada e v2 de Windows PowerShell é um aplicativo capaz de fazer isso.(Pessoalmente, acho que WMI eventualmente pode migrar para usar o WinRM.)

Essencialmente, você sentar-se no computador cliente e peça para fazer uma conexão de shell para um computador remoto.WinRM que ativa no computador remoto, que por sua vez gira uma instância do Windows PowerShell v2 no computador remoto.Essa instância do shell é capaz de executar os comandos e fornecer os resultados ao seu computador.

Veja IT em ação

As versões beta público do Windows 7 foram na primeira vez o mundo em grande poderia experimentar isso: abrir uma sessão do Windows PowerShell no servidor — ou em vários servidores — e execute Enable-PSRemoting para configurar o WinRM e iniciar o serviço WinRM.Em seguida, vá para o computador cliente — também executando o Windows PowerShell v2 — e executa $ sessão = novo PSSession nome_do_computador, fornecendo o nome do servidor configurado apenas para comunicação remota.O cmdlet New-PSSession também pode aceitar credenciais alternativas, se necessário e pode ser informado para usar portas não-padrão se você configurou.

Se você vir uma mensagem de erro longa como a mostrada na Figura 1 , é devido à maneira como o WinRM autentica.Por padrão, ele usa Kerberos, mas em um ambiente fora do domínio (como do computador do laboratório ilustrado), Kerberos não é uma opção.Quando Kerberos não estiver disponível, o WinRM exige o uso de transporte HTTPS, que requer que um certificado SSL seja instalado no computador servidor.Isso é feito para fornecer autenticação mútua entre você e o servidor para que você saiba que estiver conectado à máquina desejados.Até mesmo especificar autenticação Basic ou Digest no parâmetro –auth não ajuda, porque WinRM deseja usar HTTPS para criptografar o tráfego.A solução mais fácil?Estar em um domínio do Active Directory!

A Figura 1 autentica uma mensagem de erro longa como essa pode ocorrer devido a wayWinRM.

Com a sessão ativada, você está pronto para começar a usá-lo.PSSession digite $ sessão conectará você ao vivo, ao servidor remoto.Magicamente, você está digitando em sua instância do Windows PowerShell.Comandos executados interativamente e você verá os resultados imediatamente — não diferentemente SSH ou tecnologias semelhantes, geralmente usadas em computadores UNIX.

Windows PowerShell faz até mesmo alguns de criptografia padrão, portanto, se você não estiver usando HTTPS, você ainda estiver muito seguro contra os bisbilhoteiros.Execute PSSession sair para desanexar o console remoto e retornar ao console local.O shell solicitar alterações mesmo quando você está conectado a um computador remoto, para lembrá-lo onde você está.

Remoto de um-para-muitos

Ser capaz de executar comandos em um computador é ótimo, mas com que freqüência você precisará fazer uma coisa em um servidor?Mais comumente, acho que preciso executar um comando ou um conjunto de comandos, em um monte de computadores.O que usamos até agora no Windows PowerShell v1 é chamado de um-para-um remoting (1: 1), que significa que um único administrador Gerenciando um único computador remoto.Mas o shell também oferece um-para-muitos remoting (1: n), onde um único administrador pode gerenciar vários computadores.O truque é no parâmetro – computername do novo PSSession.

Deixe-me Repita meu comando anterior, mas desta vez eu será realmente soletrar o parâmetro em vez de permitir que o shell suponha que ele: novo PSSession – ComputerName computador.Porque – ComputerName é um parâmetro posicional, não preciso especificar o nome real do parâmetro anteriormente, mas isso agora tornará esse truque mais fácil de entender: $ sessões = novo PSSession – ComputerName (Get-Content c:\names.txt).Supondo que o arquivo C:\names.txt contém uma lista de nomes de computador, um nome de computador por linha, o shell criará uma sessão remota a cada um deles, armazenando a lista inteira de sessões na variável $ sessões.

Por padrão, as sessões são criadas usando qualquer credenciais próprio Windows PowerShell está sendo executado — portanto, minha conta de logon ou uma conta usei com RunAs ao iniciar o shell.Uma palavra de cuidado: se você tiver o UAC (controle de conta de usuário) habilitado, não se esqueça explicitamente comece o shell "como administrador" com o botão direito do mouse em seu ícone.Como alternativa, você pode especificar um nome de usuário diferente para as sessões usando o parâmetro – credential do comando.

Depois de ter essa coleção de comandos, você pode continuar a trabalhar com eles de forma 1: 1: PSSession digite $ sessões [0] irão conectá-lo a instância do shell do primeiro computador, por exemplo.Mas o verdadeiro poder executar um comando em relação a todas elas ao mesmo tempo: Invoke-Command –scriptblock {ipconfig} –session 0 $ sessões.Que executa o comando Ipconfig em cada computador ao qual você tenha conectado a uma sessão e leva os resultados de volta ao seu computador.Realmente será conectar-se a computadores em paralelo, até 32 por vez; você pode alterar esse acelerador de execução em paralelo, usando o parâmetro –throttlelimit.

Colocar IT do seu mental

Claro, às vezes, você irá disparar comandos demorar para ser executado, e pode não desejar sentar-se ao redor aguardando tudo concluir.Em tais casos, por que não permitem que o shell continuar trabalhando em segundo plano?Basta adicionar o parâmetro –AsJob para Invoke-Command, e o shell criará um trabalho de plano de fundo.

Lembre-se de que sua cópia do shell não está realmente fazendo ou quantidade de trabalho; os comandos que você especificou são sendo executados em instâncias remotas do Windows PowerShell.O shell está apenas esperando todos eles concluir e coletar os resultados envie novamente.Os resultados são armazenados como parte do trabalho.Execute Get-trabalho para ver todos os trabalhos atuais e seus status (se eles estiver ainda executando o, por exemplo).Use o trabalho de recebimento para capturar os resultados fora de um trabalho concluído.Portanto, tudo isso teria esta aparência:

$sessions = New-PSSession –computerName (Get-Content c:\names.txt)
$job = Invoke-Command –scriptblock { your command(s) } –AsJob
Get-Job (to check the status)
$results = Receive-Job $job

Você pode, em seguida, exibir resultados de $, filtrá-la, classificá-los e assim por diante. Cada resultado terá informações anexadas a ajudar a verificar qual computador ele veio. Falarei sobre trabalhos de plano de fundo (que podem até mesmo ter sub-jobs que você precisa lidar com) em um artigo futuro.

É o gerenciamento remoto, estilo novo escola

Se esquecer da maneira antiga escola de gerenciamento "remoto" envolvidos caminhada para o Centro de dados ou usando uma área de trabalho remota "trapacear." Recursos de sistema de interação remota do Windows PowerShell v2 são uma maneira eficiente e simples de executar comandos — todos os comandos — em computadores remotos. Embora seja meu foco pessoal no gerenciamento de servidor, essas mesmas técnicas são excelentes para tarefas de gerenciamento da área de trabalho, além disso, o que é um motivo por que o Windows PowerShell v2 é pré-instalado no Windows 7, bem como Windows Server 2008 R2.

Don Jones é co-fundador da Tecnologia concentrarem, onde ele blogs semanais sobre o Windows PowerShell, SQL Server, App-V e outros tópicos. Entrar em contato com ele pelo seu site.