Como Usar o Copilot e o ChatGPT para Escrever Scripts PowerShell: Guia para Sysadmins

PowerShell · Copilot · ChatGPT · Prompt Engineering · Automação IT · Microsoft 365

Usar o Copilot ou o ChatGPT para escrever scripts PowerShell pode reduzir o tempo de desenvolvimento de horas para minutos — mas apenas se souber como formular o pedido correctamente. Um prompt mal construído produz scripts que parecem correctos mas falham em produção, não tratam erros, ou têm permissões desnecessárias. Este guia mostra os padrões de prompt que funcionam para sysadmins, como validar o output antes de executar, e os erros mais comuns a evitar.

1. Porque é que o Contexto é a Chave

Um LLM sem contexto é como pedir ajuda a um colega que nunca trabalhou na sua empresa. Sabe PowerShell em geral, mas não sabe se está a trabalhar com Exchange Online ou on-premises, se o ambiente tem MFA activo, se os utilizadores estão em Active Directory ou Entra ID, ou qual a política de execução vigente. O resultado é um script genérico que provavelmente não funciona no seu ambiente específico.

ℹ O que o LLM não sabe sem lhe dizer

A versão exacta do PowerShell, o módulo Exchange (ExchangeOnlineManagement vs. EMS shell), se o tenant tem licenças E3/E5, as permissões do utilizador que corre o script, e as políticas de segurança do ambiente. Fornecer este contexto no início do prompt é a diferença entre um script funcional e um script que falha ao primeiro cmdlet.

Sem contexto Com contexto
“Escreve um script para criar utilizadores no AD” “Escreve um script PowerShell 5.1 para criar utilizadores no AD DS on-premises com Windows Server 2022, usando o módulo ActiveDirectory. O script deve ler de um CSV, criar a password aleatória, forçar alteração no primeiro login, e registar erros num log em C:\Logs\.”
“Script para exportar mailboxes” “Script PowerShell para exportar lista de mailboxes do Exchange Online (módulo ExchangeOnlineManagement v3) com tamanho, última actividade e licença atribuída. Ambiente Microsoft 365 Business Premium. Exportar para CSV com timestamp no nome.”

2. Anatomia de um Bom Prompt para PowerShell

Um prompt eficaz para geração de scripts PowerShell deve ter cinco componentes. Não é necessário escrever um ensaio — basta uma lista de condicionantes que o LLM vai incorporar automaticamente.

1
 Ambiente — versão do PowerShell, módulos disponíveis, sistema operativo do servidor onde corre.
2
 Objectivo concreto — o que o script deve fazer, com exemplos de input e output esperado.
3
 Requisitos de segurança — tratamento de erros (try/catch), logging, confirmação antes de acções destrutivas (-WhatIf, -Confirm).
4
 Limitações — o que o script não deve fazer, permissões que não deve requerer, ou formatos de output a evitar.
5
 Formato de entrega — script com comentários, função reutilizável, ou one-liner para pipeline.
# Template de prompt base — copiar e adaptar

“Escreve um script PowerShell com as seguintes condições:
– Ambiente: PowerShell 7.4, módulo [NomeModulo], Windows Server 2022
– Objectivo: [descrever o que o script deve fazer]
– Input: [ficheiro CSV / parâmetros / pipeline]
– Output: [CSV / log / output no terminal]
– Obrigatório: try/catch em cada operação, logging em C:\Logs\[nome].log, -WhatIf no modo de teste
– Não deve: requerer conta Global Admin, modificar objectos sem confirmação
– Comentários: em português, uma linha por bloco lógico”

3. Exemplos Práticos de Prompts para Tarefas IT Comuns

Exemplo 1 — Gestão de utilizadores no Microsoft 365

# Prompt — Desactivar utilizadores inactivos no M365

“Escreve um script PowerShell para o Microsoft 365 que:
– Use o módulo Microsoft.Graph (versão mínima 2.0)
– Liste utilizadores que não fazem login há mais de 90 dias (SignInActivity)
– Exporte para CSV antes de qualquer acção (modo de auditoria)
– Com o parâmetro -Executar, desactive as contas e bloqueie o login
– Exclua contas de serviço com o prefixo svc- e membros do grupo ‘ServiceAccounts’
– Registe cada acção no EventLog (source: KbaseScript, EventID: 1001)
Permissões mínimas necessárias: User.Read.All, User.ReadWrite.All”

Exemplo 2 — DNS e rede

# Prompt — Verificar registos DNS de múltiplos domínios

“Escreve um script PowerShell 7 que:
– Leia uma lista de domínios de um ficheiro TXT (um por linha)
– Para cada domínio, verifique: A, MX, SPF (TXT), DKIM (selector1._domainkey), DMARC (_dmarc)
– Use Resolve-DnsName com o servidor 8.8.8.8 para evitar cache local
– Compare os registos MX com os esperados para Exchange Online (*.mail.protection.outlook.com)
– Exporte um relatório HTML com semáforo visual (verde/amarelo/vermelho) por domínio e registo”

Exemplo 3 — Helpdesk automação

# Prompt — Reset de password em massa com notificação

“Escreve uma função PowerShell para reset de passwords de utilizadores Active Directory:
– Parâmetros: -Utilizadores (array ou pipeline), -EnviarEmail (switch), -ForcarAlteracao (switch)
– Gera password aleatória de 14 caracteres com maiúsculas, minúsculas, números e símbolos
– Se -EnviarEmail, usa Send-MailMessage (SMTP relay interno) com template HTML em português europeu
– Nunca exibe a password no terminal — escreve em ficheiro encriptado com DPAPI
– Suporte a -WhatIf nativo via [CmdletBinding(SupportsShouldProcess)]
– Output: PSCustomObject com Username, PasswordDefinida, EmailEnviado, Timestamp”

4. Como Validar o Script antes de Executar em Produção

O maior risco de usar LLMs para scripts não é o que o script faz — é o que faz sem que se aperceba. Os modelos não conhecem o seu ambiente específico e cometem erros previsíveis: esquecem-se de erros de autenticação moderna (MFA, OAuth), usam cmdlets deprecados, ou assumem permissões que o utilizador não tem.

Verificação O que procurar Ferramenta
Revisão do código Cmdlets deprecados, hardcoded credentials, ausência de try/catch Leitura manual + Copilot (“revê este script à procura de problemas de segurança”)
Análise estática Boas práticas PowerShell, sintaxe, potenciais bugs Invoke-ScriptAnalyzer (PSScriptAnalyzer)
Teste com -WhatIf O que o script faria sem executar as acções reais -WhatIf em todos os cmdlets que suportam
Ambiente de laboratório Comportamento real em ambiente controlado Tenant de teste M365 ou AD de laboratório
Revisão de permissões Princípio do menor privilégio — o script pede mais do que precisa? Graph Explorer, AD delegation model
# Passo 1 — Analisar o script com PSScriptAnalyzer antes de executar
Install-Module PSScriptAnalyzer -Scope CurrentUser -Force
Invoke-ScriptAnalyzer -Path .\meu-script.ps1 -Severity Warning,Error

# Passo 2 — Executar em modo WhatIf (ver o que faria sem executar)
.\.\meu-script.ps1 -WhatIf

# Passo 3 — Pedir ao LLM para rever o próprio output
# Prompt: “Revê este script PowerShell à procura de:
# – Credenciais hardcoded
# – Cmdlets deprecados (verificar contra documentação 2024+)
# – Ausência de tratamento de erros
# – Permissões desnecessárias
# – Problemas com autenticação moderna (MFA/OAuth)”

⚠ Nunca executar em produção sem testar primeiro

Scripts gerados por LLMs podem parecer correctos e ainda assim conter erros lógicos que só se manifestam com dados reais. Testar sempre em ambiente de laboratório ou com o parâmetro -WhatIf antes de executar em produção.

5. Iterar e Refinar — o Ciclo de Feedback com o LLM

O primeiro script que o LLM gera raramente é o definitivo. O valor real está no ciclo de iteração — pedir melhorias específicas com base no que o script faz ou não faz correctamente.

Situação Prompt de refinamento
O script falha com erro específico “O script produziu este erro: [colar o erro exacto]. Contexto: [descrever o que estava a fazer]. Corrige e explica o que estava errado.”
O script é demasiado lento “O script demora X minutos para Y objectos. Optimiza para processamento paralelo usando ForEach-Object -Parallel (PowerShell 7+). Mantém o logging.”
Precisa de mais tratamento de erros “Adiciona tratamento robusto de erros: try/catch por operação, logging detalhado em ficheiro, e resumo final com contagem de erros/sucesso.”
Precisa de ser reutilizável “Converte em módulo PowerShell com function, help baseado em comentários (Get-Help compatível), e export-modulemember.”

6. Erros Comuns e Como os Evitar

Erro comum Exemplo do problema Como evitar
LLM usa módulo errado Usa MSOnline (deprecado) em vez de Microsoft.Graph Especificar o módulo exacto no prompt: “usa o módulo Microsoft.Graph v2+”
Autenticação básica Usa -Credential com password em texto simples Pedir: “autenticação moderna OAuth/MFA, sem passwords hardcoded”
Sem tratamento de erros Get-ADUser falha silenciosamente Especificar: “try/catch em cada operação, nunca continuar silenciosamente após erro”
Assume permissões de admin Script requer Global Admin quando bastava User Admin Pedir: “usa permissões mínimas necessárias, documenta que permissões são precisas”
Sem confirmação em acções destrutivas Remove utilizadores sem confirmação Pedir: “-WhatIf nativo e confirmação interactiva em acções irreversíveis”

7. Copilot no Microsoft 365 — Integração com VS Code e ISE

Se a organização tem licenças Microsoft 365 Copilot (anteriormente M365 Copilot / GitHub Copilot), a integração directa no VS Code ou no Windows PowerShell ISE permite gerar e refinar scripts sem sair do ambiente de edição.

1
 Instalar a extensão GitHub Copilot no VS Code (requer licença Copilot ou M365 Copilot).
2
 Abrir o ficheiro .ps1 e escrever um comentário descritivo — o Copilot sugere o código automaticamente.
3
 Usar Ctrl+I (Copilot Chat inline) para pedir alterações ao script seleccionado.
4
 Usar o painel Copilot Chat para perguntas de contexto: “O que faz este cmdlet?” ou “Existe uma versão mais eficiente deste bloco?”.
5
 Para scripts mais complexos, descrever o objectivo completo no chat e pedir a estrutura antes de pedir o código.

ℹ Copilot no PowerShell ISE vs. VS Code

O Windows PowerShell ISE não tem suporte nativo a extensões Copilot. Para máximo aproveitamento, usar o VS Code com a extensão PowerShell (ms-vscode.powershell) em conjunto com o GitHub Copilot — é o ambiente recomendado pela Microsoft para scripting moderno.

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário