👪 😄 ⛹🏽 O que é o Windows PowerShell e o que ele come? Parte 5: Acesso a objetos externos 👨🏿‍🤝‍👨🏻 🧕🏾 🐸

Os sistemas operacionais Windows suportam uma variedade de infra-estruturas de objetos. Você pode usar interfaces de programação de aplicativos (APIs) para acessá-las, mas o desenvolvimento de aplicativos completos nem sempre é justificado. O PowerShell possui cmdlets especiais que permitem acessar objetos .NET, COM, WMI (CIM) e ADSI interativamente. Na quarta parte da série, aprendemos o básico com foco nas classes .NET Core e agora queremos aprofundar o tópico e entender os recursos da interação do PowerShell com objetos externos.

Índice:

Trabalhar com JSON, XML e CSV
Trabalhar com WMI e CIM
Trabalhar com objetos COM
Trabalhar com serviço de diretório ADSI
Formatar saída

Trabalhar com JSON, XML e CSV

Nos scripts do PowerShell, você geralmente precisa analisar dados JSON, XML e CSV. Geralmente, essa necessidade surge quando se trabalha com serviços da Internet ou com arquivos de configuração. Alguns administradores tentam analisar dados usando expressões regulares, mas não é necessário fazer esses sacrifícios: o PowerShell possui cmdlets especiais para conversão, além disso, nas duas direções.

O formato JSON permite descrever uma variedade de objetos e, em essência, é uma hashtable que pode ser aninhada. É fácil converter um objeto JSON em um objeto .NET de acordo com o PowerShell. Como os serviços de Internet geralmente fornecem uma linha muito longa em vez de um arquivo formatado de maneira bonita, essa conversão também pode ser útil para trabalhar no modo interativo. No exemplo abaixo, usamos uma variável de texto com várias linhas para descrever o objeto JSON:

$user = @"
{
   "firstName": "Ivan",
   "lastName": "Danko",
   "address": {
       "streetAddress": "Kremlin",
       "city": "Moscow"
   },
   "phoneNumbers": [
       "+7 495 1234567",
       "+7 499 1234567"
   ]
}
"@ | ConvertFrom-Json

O problema inverso é resolvido de maneira semelhante:

$file = Get-ChildItem C:\Windows\System32\notepad.exe
$file.VersionInfo | ConvertTo-Json

A sequência de formato JSON resultante é fácil de enviar para outro aplicativo pela rede. Pode ser, por exemplo, algum serviço RESTful. O trabalho com os cmdlets ConvertFrom-Csv, ConvertTo-Csv e ConvertTo-Xml é construído aproximadamente da mesma maneira, sugerimos que os leitores o estudem independentemente.

Para trabalhar com XML e CSV, precisaremos de outros cmdlets:

Usando essas ferramentas, você precisa entender que a conversão de um objeto binário em um formato de texto economiza apenas o valor de suas propriedades, mas não os métodos. A conversão de dados JSON, XML ou CSV em um objeto .NET usando o PowerShell só é possível se for válida.

Trabalhar com WMI e CIM

O Windows Management Instrumentation (WMI) é uma implementação desenvolvida pela Microsoft e adaptada para Windows do padrão WBEM (Gerenciamento Corporativo Baseado na Web). É baseado na idéia de criar uma solução universal para monitorar o ambiente de informações distribuídas de uma empresa e gerenciar seus componentes. A estrutura de dados do WBEM, por sua vez, é baseada no Common Information Model (CIM), que implementa uma abordagem orientada a objetos para a representação de sistemas de computadores. O desenvolvimento e o suporte adicionais do WMI no Windows foram descontinuados; a Microsoft recomenda o uso de um mecanismo semelhante para gerenciar a infraestrutura - objetos CIM. Para trabalhar com eles, os cmdlets especiais apareceram no PowerShell 3.0, que consideraremos em paralelo com os equivalentes do WMI. Se o código contiver chamadas de cmdlet para trabalhar com o WMI, ele deverá ser reescrito, se possível.

Dentro da estrutura do modelo CIM (também é usado no WMI), os dados do sistema operacional são apresentados na forma de classes com propriedades e métodos. As classes são agrupadas em hierarquicamente ordenadas e logicamente relacionadas por tecnologia de namespace ou área de gerenciamento. Há um espaço para nome raiz raiz que possui subespaços: CIMv2, Padrão, Segurança e WMI. Para identificação inequívoca de uma instância de uma classe (objeto) e descrição do estado do recurso correspondente, são usadas propriedades de classe, que geralmente são somente leitura. Métodos são usados para gerenciar o recurso.

A instância da classe pode ser acessada pelo caminho completo, que possui o seguinte formato:

[\\ComputerName\NameSpace][:ClassName][.KeyProperty1=Value1][,KeyProperty2=Value2]…]

onde
ComputerName é o nome do computador;
NameSpace - espaço para nome;
ClassName - o nome da classe;
KeyProperty1 = Valor1, KeyProperty2 = Valor2 - as propriedades do objeto e os valores pelos quais ele é identificado.

Antes do PowerShell, não existia uma ferramenta WMI simples. Para acessar os objetos, era necessário escrever programas bastante complexos em linguagens de alto nível (C ++, Visual Basic, Java Script) ou estudar o shell WMIC (linha de comando WMI, que também é descontinuada) com seu próprio idioma. Por meio do PowerShell, os objetos WMI são acessíveis ao usuário médio na linha de comando ou nos scripts. Primeiro, conecte-se ao subsistema WMI e obtenha uma lista de classes disponíveis usando o cmdlet Get-WmiObject (também conhecido como gwmi). Para obter uma lista de classes CIM, use o cmdlet Get-CimClass.

Get-CimClass
Get-WmiObject -List

Listamos as classes no computador local, mas você pode se conectar ao controle remoto:

Get-CimClass -ComputerName IP- 
Get-CimClass -ComputerName _

Get-WmiObject -ComputerName IP- -List
Get-WmiObject -ComputerName _ -List

Por padrão, os cmdlets Get-CimClass e Get-WmiObject se conectam ao espaço para nome Root \ CIMV2, que armazena um grande número de classes para gerenciar o sistema. Para alterar o espaço para nome, use o parâmetro -Namespace:

Get-CimClass -Namespace Root
Get-WmiObject -Namespace Root -List

Conhecendo o nome da classe, não é difícil obter instâncias dela. O comando a seguir retorna todas as instâncias do Win32_Service, ou seja, serviços registrados na máquina local:

Get-WmiObject Win32_Service

Como com outros tipos de objetos, uma lista de propriedades e métodos é exibida usando Get-Member. Os métodos de objeto WMI podem ser acessados diretamente ou usando o cmdlet Invoke-WmiMethod. Você também pode usar cmdlets para objetos WMI para classificar, filtrar, agrupar etc.

Get-WmiObject Win32_Service | Get-Member

Para obter objetos CIM (instâncias de classes), use o cmdlet Get-CimInstance. Ao contrário do WMI, os objetos CIM resultantes (objeto resultante ou instâncias de classe) não contêm métodos de classe. Como você não pode extrair diretamente um método, você deve invocar o cmdlet Invoke-CimMethod. Considere a classe Win32_Service - serviços em execução no sistema) e sua instância para o serviço de spooler na máquina local:

Get-CimInstance Win32_service -filter "Name='spooler'"

Vejamos a estrutura do objeto resultante:

Get-CimInstance Win32_service -filter "Name='spooler'" | Get-Member

Neste ponto, os benefícios dos cmdlets para trabalhar com objetos CIM não são óbvios. Eles se referem principalmente ao trabalho remoto em um ambiente distribuído e serão discutidos em detalhes no último artigo da série dedicada à solução de problemas práticos de administração.

Há também um kit de ferramentas específico para WMI: o WQL Query Language (WQL), uma linguagem de consulta semelhante ao SQL. Uma consulta WQL para procurar todas as start-ups ao iniciar um sistema de serviço se parece com isso:

select * from win32_service where startmode="Auto"

No PowerShell, eles são executados da seguinte maneira:

Get-WmiObject -Query 'select * from win32_service where startmode="Auto"'

Trabalhar com objetos COM

Para garantir a interação entre aplicativos no Windows, foi desenvolvida uma tecnologia para vincular e incorporar objetos (Object Linking and Embedding ou OLE). Mais tarde, apareceu a tecnologia OLE Automation, com a ajuda de quais aplicativos clientes de automação poderiam chamar funções de outros aplicativos - servidores de automação. OLE e OLE Automation foram baseados na tecnologia principal do Component Object Model (COM), que oferece um único padrão binário para componentes de software. Objetos criados usando-o e registrados no sistema operacional podem ser usados em outros aplicativos usando arquivos executáveis ou bibliotecas dinâmicas.

Por volta de meados dos anos 90, em vez de OLE, outro termo começou a ser usado - ActiveX. Antes do advento da plataforma .NET, a tecnologia ActiveX era considerada essencial e os objetos COM ainda são usados ativamente para integrar aplicativos ao Windows - muitos produtos da Microsoft e de terceiros são servidores de automação e fornecem acesso a seus serviços por meio deles. Para acessar objetos, o ProgID é usado - um identificador simbólico que é atribuído a eles ao se registrar no registro do Windows. Tem a seguinte forma:

_..

A versão geralmente não é indicada:

_.

Alguns exemplos de ProgIDs disponíveis são: InternetExplorer.Application (aplicativo Internet Explorer), Word.Application (aplicativo Microsoft Word), WScript.Shell (classe Shell do host de scripts do Windows ou modelo de objeto do servidor de scripts do WSH).

Você pode criar uma instância do objeto usando o cmdlet New-Object discutido no artigo anterior e ver sua estrutura usando Get-Member:

$myshell = New-Object -ComObject WScript.Shell
$myshell | Get-Member

Para trabalhar com objetos, propriedades e métodos são usados. Digamos, para criar um atalho na área de trabalho do usuário, você precisa chamar o método CreateShortcut ():

$link = $myshell.CreateShortcut("$Home\Desktop\Home.lnk")

Observe que o atalho também é um objeto COM:

$link | Get-Member

Resta preencher suas propriedades e economizar:

$link.TargetPath = $Home
$link.Save()

Dessa maneira, criamos um atalho na área de trabalho do usuário ativo e agora analisamos o trabalho com serviços de automação externos usando o exemplo do objeto COM Shell.Application. Com ele, você pode automatizar algumas ações no Windows Explorer:

$myshell=New-Object -ComObject Shell.Application

ou para abreviar:

$myshell=New-Object -com Shell.Application
$myshell | Get-Member

O objeto Shell.Application possui alguns métodos diferentes de gerenciamento de janelas. Por exemplo, para exibir o conteúdo de um determinado diretório, Explore () é usado:

$myshell.Explore("c:\")

O sistema de ajuda é chamado usando o método Help ():

$myshell.Help()

Há também três métodos para chamar as caixas de diálogo de pesquisa: FindFiles (), FindComputer () e FindPrinter ().

$myshell.FindFiles()
$myshell.FindComputer()
$myshell.FindPrinter()

Você pode abrir a caixa de diálogo de inicialização do programa usando o método FileRun () e, para chamar a janela de configuração de data / hora, você precisa do método SetTime (). Existem, por exemplo, métodos para acessar a janela de configurações da barra de tarefas, elementos do painel de controle indicando um dos arquivos cpl disponíveis, para gerenciar janelas abertas:

$myshell.MinimizeAll()
$myshell.UndoMinimizeAll()
$myshell.TileHorizontally()
$myshell.TileVertically()

O método Windows () permite acessar a coleção de janelas abertas no Explorer ou no Internet Explorer. Vamos ver as propriedades e métodos disponíveis para esta coleção:

$myshell.Windows() | Get-Member

Existem outros objetos COM úteis, cujo número depende do software instalado no sistema. Era uma vez, a principal ferramenta de automação no Windows era o servidor de scripts WSH, cujo modelo de objeto também inclui objetos COM: projetado para funcionar com as funções de rede do WScript.Network e do WScript.Shell que já mencionamos. Este último não apenas cria atalhos na área de trabalho, com sua ajuda, você pode, por exemplo, exibir janelas de informações com mensagens e botões, alternar entre aplicativos, iniciar programas ou simular pressionamentos de tecla.

Trabalhando com o serviço de diretório ADSI

Em geral, um catálogo refere-se a uma fonte de informações na qual os dados sobre alguns objetos são armazenados. Por serviço de diretório, entendemos parte de um sistema de computador distribuído que permite acessar e manipular objetos armazenados. Um serviço de diretório pode combinar dados sobre objetos de rede e os serviços que os manipulam - representa um único ponto de entrada para interagir com os recursos da rede. Pode haver muitos desses serviços em uma rede heterogênea de computadores: um SAM local (Security Account Manager) para computadores que não são de domínio, Active Directory, etc.

A interação com diferentes serviços de diretório requer ferramentas diferentes, o que cria certos inconvenientes. A partir do Windows 2000, a Microsoft introduziu a tecnologia ADSI (Active Directory Service Interface) unificada para sistemas operacionais que não dependem de um protocolo de acesso à rede específico. Para localizar objetos, um espaço para nome é definido para o diretório. Como serviços de diretório diferentes usam métodos de nomeação diferentes, o ADSI define uma convenção que identifica exclusivamente qualquer objeto. O conceito de cadeias de ligação de duas partes ou ADsPath é introduzido. A primeira parte do nome define o serviço de diretório (provedor ADSI) e a segunda - a localização do objeto no diretório. Aqui estão exemplos de designação de diferentes provedores ADSI:

LDAP: //usado para serviços de diretório baseados em LDAP, incluindo para o Active Directory;

WinNT: // usado para computadores locais.

Não há cmdlets especiais para trabalhar com o ADSI no PowerShell. Em vez disso, o operador de conversão [ADSI] é usado seguido por uma seqüência de caracteres de ligação. Por exemplo, para conectar-se ao usuário Ivanov a partir do domínio test.ru, é necessária a seguinte construção:

$user = [ADSI]"LDAP://CN=Ivanov,DC=TEST,DC=RU"

Para trabalhar com contas locais, você precisará conectar-se ao computador com o nome correspondente (para conectar-se ao computador local, basta usar o ponto em vez do nome):

$computer = [ADSI]"WinNT://."

Por exemplo, crie um novo usuário, Ivanov, na máquina local:

$user = $computer.Create("user","Ivanov")
$user.Put("Description","  PowerShell")
$user.SetInfo()

Agora conecte-se a ele:

$user1 = [ADSI]"WinNT://./Ivanov,user"
$user1.Description

Formatação de saída

O trabalho interativo geralmente exige a exibição de dados. Em outros shells, os próprios comandos e utilitários estão envolvidos na formatação da saída, mas objetos binários retornados por funções e cmdlets geralmente não sabem como fazer isso. No PowerShell, a saída é formatada por quatro cmdlets especiais que alimentam objetos através do pipeline. Informações mais detalhadas podem ser obtidas usando o Get-Help:

Format-Table formata a saída na forma de uma tabela cujas colunas contêm os valores das propriedades do objeto ou os valores calculados. A capacidade de agrupar dados é suportada;

Format-List exibe o objeto como uma lista de propriedades, cada uma das quais é exibida em uma nova linha. A capacidade de agrupar dados é suportada;

Formato personalizadoformata a saída usando uma visualização personalizada;

Format-Wide formata objetos na forma de uma tabela ampla na qual apenas uma propriedade de cada objeto é exibida.

Se nenhum dos cmdlets listados for chamado, o módulo de formatação apropriado ao tipo de dados exibido será usado. As regras de exibição são armazenadas nos arquivos de configuração no formato XML com a extensão .ps1xml, localizada no diretório $ PSHome. Uma lista deles pode ser obtida usando o seguinte comando:

dir $pshome\*format*.ps1xm

A edição manual de arquivos de configuração não é recomendada; é melhor criar seus próprios e incluí-los na lista de arquivos baixados usando o cmdlet Update-FormatData. Se o formatador padrão para o tipo que você deseja não estiver definido, o PowerShell exibirá as propriedades do objeto na tela em uma lista.

Isso conclui a descrição do trabalho com objetos no PowerShell e o artigo final da série será dedicado à resolução de problemas práticos de gerenciamento de um ambiente de informações distribuídas de uma empresa. Nele, todas as ferramentas descritas são úteis para nós. O foco principal será nos objetos CIM e sua comparação com o WMI. Partes anteriores podem ser encontradas nos links abaixo.

1: Windows PowerShell
2: Windows PowerShell
3: ,
4: ,