PowerShell 2: Corrigido problema de performance com a listagem de atributos

Olá,

algum tempo atrás eu comentei aqui no blog que o PowerShell tinha um pequeno problema de performance com a listagem de arquivos. O problema estava com o format-table, que usava a propriedade Mode para imprimir na tela os atributos dos arquivos. Esta, por sua vez, era gerada usando várias vezes a operação and binária. Um dos atributos em especial (o atributo diretório, que indica se um dado objeto é um diretório ou não)podia ser gerado de outra forma, 33% mais rápida. Basta ler o conteúdo do atributo PSIsContainer ao invés de usar o and.

Enfim... eu reclamei aqui no blog, postei ainda no blog oficial do PowerShell e no do MOW (MVP Admin Frameworks, Holanda se não me engano). Resolvi conferir isso agora e vi que no PowerShell 2 CTP isso foi corrigido e agora a propriedade Mode usa o método get nativo do .Net Framework.

Fantástico! Isso mostra que a Microsoft não é a estrutura engessada que todo mundo imagina. Eles estão sim abertos ao diálogo, sugestões e melhorias. Basta sugerir. Se for bom, entra nos produtos.

E parabéns ao Jeffrey Snover e todo o time do PowerShell! Congratulations guys!

 

Technorati Tags: , , ,

Categorias dessa postagem:

MP3 e PowerShell

Olá,

encontrei alguns exemplos legais de como trabalhar com uma biblioteca chamada TagLib#, que é uma biblioteca que permite manipular metadados em arquivos de audio (MP3, OGG e WMA, por exemplo).

http://huddledmasses.org/editing-media-tags-from-powershell/

Não cheguei a testar, mas parece interessante. Já cheguei a pensar em escrever biblioteca semelhante para trabalhar com MP3 em VBScript, mas desisti ao ver que alguém já tinha feito essa boa ação e colocado o código na Internet.

Editar tags não costuma ser uma tarefa rápida: consiste em abrir, analisar os arquivos, escrever e fechar, salvando as alterações. Pode parecer simples, mas se os algoritmos utilizados não forem eficientes, o trabalho pode ficar mais lento. Converter entre formatos de tag também pode ser um trabalho demorado (computacionalmente falando). Entre todos os meus testes, o software mais rápido que eu encontrei para editar tags foi o MP3Tag, que pode ser obtido aqui: http://www.mp3tag.de/en/

Até mais!

Categorias dessa postagem: ,

Send-SMTPMail: Enviando e-mails via PowerShell

Olá,

a seguir, temos uma ferramenta bastante útil para o PowerShell: como enviar emails via linha de comando.

http://mspowershell.blogspot.com/2007/12/send-smtpmail-update.html

Muito bom, recomendo!

Até mais

Categorias dessa postagem:

SendKeys no PowerShell

Olá,

acabei de encontrar uma ferramenta muito útil do VBScript que não tinha uma correspondência direta com nenhum recurso no PowerShell: o SendKeys.

Para quem não conhece, ele é um dos "canivetes suíços" mais interessantes, já que permite a simulação da digitação de teclas. Dessa forma, ele serve como uma "cola" para conseguir automatizar programas que não suportam automação nativamente. Se não dava para fazer programando um script, ainda podia ser feito simulando teclas no teclado.

Pois bem, agora tem como fazer o mesmo no PowerShell... e de uma forma bem mais legal.

http://huddledmasses.org/window-gui-automation-from-powershell/

Vejam um exemplo:

Select-Window notepad | Send-Keys "%(ea)Testing{Enter}{F5}"

Categorias dessa postagem: ,

Reiniciando processos com VBScript e WMI

Olá,

acabei de desenvolver um pequeno script para reiniciar processos, e resolvi publicar aqui. Fiz porque há um problema intermitente com o meu computador que faz com que o scroll do touchpad pare de funcionar aleatoriamente, sem motivo aparente, após algumas sequencias de hibernação/reinicialização. Não descobri ainda, o motivo, mas fiz um script que contorna o problema, fechando todas as instâncias dos programas responsáveis pelo touchpad e abrindo logo em seguida.

Enfim, esse é um script para relembrar os velhos tempos. Faz um bom tempo que não escrevo nada sobre VBScript, que ainda é e vai continuar sendo uma das principais ferramentas para automação no Windows. O Script abaixo reinicia tudo que começa com ap, o que pode ser visto na query WQL na terceira linha.

set objShell = WScript.CreateObject("Wscript.Shell")
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colProcess = objWMIService.ExecQuery("Select * from Win32_Process WHERE caption LIKE 'ap%'")
for each process in colProcess
processPath = process.ExecutablePath
process.terminate()
objShell.run """" & processPath & """"
next
WScript.echo "Processos reiniciados."

Até logo!

Technorati Tags: ,

Categorias dessa postagem: ,

VT em outros Vaios FZ, AR, etc.

Olá,

mais sobre como habilitar o VT em VAIOs. Agora, o autor da mensagem que eu usei para habilitar o VT no meu VAIO mostrou como ele chegou naqueles endereços que deviam ser alterados.

Em outras palavras: agora ele ensinou o caminho das pedras. Quem tiver um VAIO da sério FZ, CR ou AR, por exemplo, pode agora habilitar o VT em seu note também... basta testar. Tudo que ele fez foi testar, por tentativa e erro, até achar o local onde fica armazenada a opção do VT na NVRAM.

I found the Napa SZ registers by a long process of trial and error. First I made seven files, each having a [0000] -> [0001] value change in one of the seven sections (0000-00FF,0100-01FF, ... , 0600-06FF) and sequentially wrote them to the NVRAM and noted the changes. If a significant change had occured in one of the seven sections, such as a BSOD, indicating that AHCI was enabled, or a change in the VT.iso results, I continued to use a divide and conquer type approach in that section until I had narrowed it down to the right locations. Since the SZ registers are around the 0100-03FF range, you may want to try searching in that area first.

O original pode ser lido no link abaixo:

http://forum.notebookreview.com/showthread.php?p=2679747#post2679747

Categorias dessa postagem:

Jeffrey Snover explica porque criou o PowerShell

Eis um video interessante para quem não entendeu muito bem onde o PowerShell é útil...

Categorias dessa postagem:

Habilitando VT em notebooks VAIO da Sony

Olá,

não gosto muito de fugir do assunto scripting no meu blog sobre scripting. Esse é o principal motivo pelo qual eu penso em criar mais dois blogs, um para assuntos diversos e outro em Inglês. No entanto, esse é um post especial e que merece atenção, principalmente para consumidores que compraram notebooks da Sony.

Adquiri um Sony Vaio no começo deste ano e fiquei muito feliz: meu primeiro notebook, computação móvel (ou computação dependente de tomadas), etc. O notebook em si é muito bom, extremamente rápido, bastante memória, tela legal. No entanto, uma coisa me deixou extremamente chateado: embora o processador do notebook suporte a tecnologia de virtualização por hardware (Intel VT, processador Intel Core 2 Duo T7200), a Sony simplesmente desativa este recurso em todos os seus notebooks. Eu não recomendo Sony Vaio para nenhum Power User. Quem gosta mesmo de computação e usa o computador ao extremo, não compre.

Eu uso o VT simplesmente porque gosto de testar SOs, várias combinações de Windows, máquinas virtuais e scripts. Como eu não estou trabalhando, é uma forma rápida de "criar"e testar scripts em "grandes" ambientes corporativos.

Entrei em contato com o suporte nos EUA e tudo que me disseram é que a Sony não suporta e não vai suportar VT. Cheguei a pedir para conversar com outras pessoas de lá, mas tudo que consegui foi um não. Argumentei que precisava deste recurso, que foi um dos motivos pelos quais eu comprei um T7200 foi esse. Nada de conversa. Empresas que não dão valor aos clientes normalmente dão essa resposta.

Comecei minha busca pela Internet. Pesquisei bastante sobre como funciona o processo de boot, sobre o VT, sobre BIOS e tudo mais. Cheguei a encontrar resultados legais sobre isso, mas nada desenvolvido até então. Dentre as várias possibilidades de alteração, a mais segura é a alteração da NVRAM, que, ao menos em tese, não inutiliza o computador em caso de falha. Tudo que eu precisava fazer era localizar na NVRAM o local onde a BIOS do meu notebook gravaria o valor "VT enabled" e mudar ele pra 1 de alguma forma. Outra alternativa, mais arriscada, seria criar um patch para a BIOS, localizando e pulando a instrução que oculta a opção do VT. Essa alternativa, entretando, pode inutilizar o computador se o patch não for bem feito.

Usando um serviço do Google (Google Alerts), coloquei ele para procurar todos os dias na Internet por "Enable VT VAIO". Hoje veio uma resposta diferente. Alguém conseguiu a primeira solução. Testei e funcionou. Por enquanto, só há resultados válidos para notebooks Sony da série SZ, mas creio que é questão de tempo para aparecer soluções semelhantes para as séries AR, FZ e todos os outros.

Isso mostra o quanto a Sony está errada. Agora sim comprar um Vaio parece ser algo interessante. No entanto, não recomendo Vaios mais justamente pelo descaso do suporte.

Para os menos "computadorizados", resolvi pegar o texto e postar em português. Veja abaixo como ativar o VT no seu Vaio. O original pode ser visto aqui.

Aviso: Embora esta seja uma tarefa simples, eu não me responsabilizo por nenhum problema que venha a ocorrer. Teste por sua própria conta e risco.

Como a maioria de vocês já deve saber, a Sony decidiu por desabilitar o VT por padrão em todos os modelos de VAIO, como pode ser visto no artigo do KB C381809. Aqui vou mostrar como ativar o Intel Virtualization Technology (FAQ) e o AHCI em um VAIO SZ.
Antes de tentar a modificação, certifique-se de que a BIOS no seu SZ está atualizada com a última versão: R0112N0 para notebooks com processadores da série Napa ou R0101S5 para notebooks com o processador Santa Rosa. Se você receber um erro enquanto tentar atualizar a BIOS no XP ou Vista, certifique-se de ter instalado todos os drivers e utilitários da Sony. Isso fará com que o programa que atualiza a BIOS reconheça seu modelo de notebook. Drivers e utilitários para vários modelos podem ser encontrados em threads sobre instalações limpas do Windows neste fórum.

NOTA DO VINICIUS: eu tive que atualizar minha BIOS. Curiosamente, o site da Sony só exibe o update da BIOS PHBSYS-01041231-UN.exe. O link que o autor coloca é de um ftp da Sony do Japão, e o update, o arquivo PHBSYS-01041232-UN.exe é compatível com meu notebook.

Os únicos ítens que você vai precisar, além do notebook, é um drive de disquete e um disquete de inicialização do DOS. Você pode também testar o método usando um CD-R com um disco de inicialização do DOS ou um pendrive bootável. No entanto, eu não testei isso

NOTA DO VINICIUS: Eu testei com um cd bootável com uma imagem do DOS e funcionou. O único problema é lembrar de gravar os programas abaixo no CD ou em uma partição FAT/FAT32 do HD.

Instruções:

  1. Faça o download do programa symcmos e copie-o em seu disco de inicialização. Este programa será utilizado para modificar as configurações da sua Phoenix BIOS. Baixe também um editor de texto para MS-DOS (aqui: DOS text editor) e copie-o para o disco de forma que seja possível editar o arquivo no DOS. NOTA DO VINICIUS: eu copiei a versão de 16 bits do VIM, mas é possível editar no Windows em outro computador também.
  2. Entre na BIOs pressionando F2 durante o startup, ou quando o logo do VAIO aparecer, e resete as configurações padrão de fábrica. Salve e reinicie.
  3. Volte à BIOS e habilite o boot por dispositivos externos. Salve e reinicie. NOTA DO VINICIUS: não é necessário esse passo. Basta pressionar ESC durante o boot e escolher um dispositivo para iniciar o computador. No meu caso, fiz isso e escolhi o CD-Rom.
  4. Inicie usando o disco de inicialização e, no prompt, digite "symcmos -v2 -lDefault.txt", sem aspas. Note que não há espaço entre o parâmetro l (L, minúsculo) e o nome do arquivo. Isto vai criar uma cópia literal da tabela de símbolos da sua NVRAM chamado Default.txt com as opções atuais da sua BIOS.
  5. Use o editor de texto DOS (ou reinicie e altere o arquivo que está no disquete dentro do Windows, com seu editor preferido) para alterar o arquivo gerado Default.txt. Mude as linhas abaixo e salve com algum outro nome no disquete.(como por exemplo, modified.txt):

    Para SZs modelo Napa - BIOS Versão R0112N0

    Para habilitar o AHCI: (015C) [0000] ---> (015C) [0001]
    Para habilitar o VT-x: (0354) [0000] ---> (0354) [0001]

    Para SZs modelo Santa Rosa SZs, mais recentes - BIOS Versão R0101S5
    Para habilitar o AHCI: (0189) [0000] ---> (0189) [0001]
    Para habilitar o VT-x: (02F1) [0000] ---> (02F1) [0001]

    NOTA DO VINICIUS: para quem não entendeu, basta localizar a linha à esquerda e trocar para a linha da direita. Basta trocar o [0000] para [0001]. Easy!
  6. Volte ao prompt (ou inicie o notebook novamente) do DOS e digite "symcmos -v2 -uNameOfModifiedFile", sem aspas, e reinicie. Isto vai gravar as configurações modificadas na NVRAM. Terminado!
  7. Notas:
    Para testar se o AHCI está habilitado, você vai ver uma tela azul quando o Windows XP e Vista. Isso ocorre porque os drivers para AHCI não são instalados no SO por padrão. Você vai precisar instalar os drivers AHCI na sua instalação atual. Use o Google para instruções de como fazer isso no XP ou leia isto para fazer o mesmo no Vista.

    NOTA DO VINICIUS: outra alternativa: não habilite o AHCI no seu notebook. =)

    Para testar o VT-X, faça o download do vt.iso (use o salvar link como no seu navegador) e grave com o IMGBurn. Inicie o micro com este CD e ele vai informar se o VT está habilitado ou não. Você pode também gravar o Securable no Windows e salvar em um CD-R.

    NOTA DO VINICIUS: se você preferir, instale e abra o Microsoft Virtual PC. Na opção ajuda, sobre, você encontra essa informação.

    Se você não tiver um floppy USB, também pode ser possível habilitar o VT-x e o AHCI usando um CD bootável do DOS, mas eu ainda não testei. Você vai ter que gravar no disco as modificações. No entanto, eu tenho somente as configurações do Napa R0112N0 para compartilhar. As configurações padrão do Napa estão anexadas, e você pode ediar por si mesmo. NOTA DO VINICIUS: não é obrigatório gravar no CD não... basta alterar no DOS e gravar diretamente na NVRAM. Foi o que eu fiz.
  8. Para reverter as configurações anteriores, você tem três opções:
    1. Entre na BIOS e resete para as configurações padrão.
    2. Use o comando symcmos e a flag -u flag para escrever as configurações padrão que você salvou anteriormente como Default.txt novamente na NVRAM.
    3. Pior caso, se o seu notebook não passar nem do POST: abra seu notebook  e remova e coloque novamente a bateira da CMOS, que fica localizada perto da placa WLAN.
    Muito do crédito desta descoberta vai para "bfroemel" por postar este método no VMware forum; Eu estou apenas sumarizando aqui e especializando para o SZ da Sony. NOTA DO VINICIUS: o mesmo vale para mim, que só traduzi o howto.

Pronto! VT para todo mundo! E pensem duas vezes ao comprar notebooks de uma empresa que não ouve seus clientes.

Categorias dessa postagem:

Script para Assistência Remota

O colaborador do fórum Wellington Lima publicou em seu blog um script simples e extremamente útil para trabalhar com a assistência remota no Windows Vista. Vejam aqui: http://welingtonlima.spaces.live.com/blog/cns!B5CDE85B04A57348!207.entry

Categorias dessa postagem: ,

VbCrLf, VbCr e VbLf

Olá,

recentemente vi uma pergunta interessante no fórum de scripts do Technet Brasil. Tratava, dentre outras coisas, de assinaturas no Outlook.

Para responder a pergunta, tive que usar um conhecimento curioso: as constantes VbCrLf, VbCr e VbLf. Em C/C++ eles correspondem aos caracteres \r\n, \r e \n.

A primeira boa parte do pessoal conhece. As outras duas, nem tanto. Elas correspondem aos caracteres especiais Retorno de Carro e Quebra de Linha. O Windows usa por padrão os dois para indicar um Enter, mas outros sistemas operacionais não. Isso costuma gerar pequenos problemas de incompatibilidade.

Mais info na Wikipédia: http://en.wikipedia.org/wiki/Line_feed

Até mais!

Categorias dessa postagem:

PowerShell 2.0 CTP

Olá,

saiu hoje o Community Technology Preview (que pode ser considerado algo como um pré-beta) do PowerShell 2.0. Ele pode ser obtido gratuitamente aqui.

Dentre as principais novidades anunciadas, estão o PowerShell Remoting, que permite executar comandos remotamente com facilidade; debug nativo de scripts e cmdlets; mais 3 comandos relacionados ao WMI (esses sim são legais =) ); e um editor gráfico para scripts.

Outro ponto que foi prometido foi uma certa melhoria de velocidade. Eu citei reportei dois problemas de velocidade tempos atrás, e uma sugestão de mudança para o comando get-ChildItem (também conhecido como o bom e velho DIR). Estou baixando o CTP nesse exato momento para testar se fui atendido e colocarei meus testes depois.

Mais uma vez, sugiro aos que não baixaram ainda nenhuma das versões do PowerShell, que baixe e aprenda o mais rápido possível. É o futuro da automação dos recursos no Windows. Se você não quer ficar para trás, aprenda o quanto antes!

Por hoje, é isso.

 

Happy downloading!

Categorias dessa postagem:

2008 Scripting Games: Technet ScriptCenter

Olá,

A equipe do ScriptCenter na Microsoft estará organizando em breve a terceira edição dos "Scripting Games". Trata-se de uma competição em que cada competidor deve resolver um problema usando ferramentas de scripting (no ano passado, foram VBScript e Windows PowerShell).

Não se trata de um campeonato nos mesmos moldes da OBI ou dos problemas do UVA, mas é bem divertido e ótimo para quem quer aprender um pouco mais sobre como controlar o Windows somente com scripts, PowerShell e prompt de comandos. Ao menos no ano passado, havia quatro categorias: PowerShell (Avançado e Iniciante) e VBScript (Avançado e Iniciante). Tem pra todo mundo!

Eu vou participar. E recomendo =)

Até logo!

Categorias dessa postagem: ,

Powershell 2.0 CTP

Olá,

Saiu no blog oficial do time do Powershell mais uma série de posts sobre a próxima versão do Powershell. Resolvi colocar aqui o que eu achei de mais interessante e relevante nessa nova versão:

Note que estas informações não são definitivas, e tem grandes chances de mudar até o final.

  • Powershell 2 é compatível com o 1.1. Nenhum script nem cmdlet precisará ser reescrito.
  • Extensões continuarão a ser .PS1 (ao menos no CTP. Acredito que isso vá mudar até a versão final)
  • Rodará nas versões 32 e 64 bits do Windows XP SP2, Windows Server 2003 SP2, Windows Vista e Vista SP1 e Windows Server 2008. O detalhe está no fato dele exigir o WinRM (implementação da Microsoft para o WS-Management) instalado. Pra quem não sabe, é uma das novas ferramentas para administração de redes. Na prática, é um protocolo baseado em SOAP que permite gerenciar sistemas operacionais local ou remotamente. Note o S no final: Windows, Linux e todos os outros que implementarem o protocolo. Eu vou escrever sobre WinRM aqui ainda, é bem legal e vale a pena aprender.
    • Ainda sobre o WinRM: o Powershell 2 exige o WinRM instalado. Ele não vem por padrão no Windows XP, nem no 2003 nem no Vista. Que eu me lembre, somente o 2008 vem por padrão e o 2003 R2 vem como uma opção do Adicionar/Remover Programas. Isso pode dificultar um pouco o uso dele em grande escala. Isso me permite concluir uma coisa: WMI não está morto, e vai ser útil (e a única saída para alguns problemas) durante um bom tempo.
  • Com o Powershell Remoting, as operações remotas ficam muito mais fáceis. Vi umas demos na Internet e não tive tempo de testar ainda, mas ficou mais tranquilo do que já era fazer uma operação em vários computadores (como por exemplo, varrer a rede e ver quais computadores têm mais de 512 Mb de RAM).
  • Até onde eu sei, alguns problemas de performance foram corrigidos. Eu mesmo encontrei duas coisas que não eram muito velozes no Powershell meses atrás: o problema da chamada de função e o problema da listagem de atributos de arquivo. Até o grande Jeffrey Snover, gerente de projeto do PowerShell. apareceu por aqui =).

Bom, agora é esperar. E quando sair, vou escrever aqui para manter todos informados.

Até a próxima!

Categorias dessa postagem: ,

Webcast sobre Powershell amanhã

Outra notícia muito importante! Estarei ministrando um webcast sobre PowerShell, Scripting e melhorias para administração no Windows Server 2008 amanhã, ao meio dia, no ciclo de webcasts do site TechNet Brasil. Quem gostar ou simplesmente quiser me ver online, pode entrar aqui.

Categorias dessa postagem: ,

PowerShell 2.0: algumas notícias

Olá,

estou, mais uma vez, afastado do meu blog nos últimos dias. O motivo, claro, são minha agenda. Estou envolvido mais uma vez na organização da 10ª Semana da Computação (aka Semcomp) do ICMC, na USP de São Carlos. Ao contrário do ano passado, em que fui presidente da comissão, este ano estou trabalhando somente com o site do evento, além de negociar alguns contatos com patrocinadores e palestrantes.

Mas vim aqui para falar de outra coisa: PowerShell 2.0. Jeffrey Snover, PM do time do PowerShell, deu uma entrevista no site WinIT.com sobre o que vem na versão 2.0. Já é conhecido que uma das coisas que será alterada para a versão 2.0 era a questão da velocidade, que comentei aqui mesmo vários meses atrás. O PowerShell pode ficar incrivelmente lento se você fizer alguma coisa errada (como por exemplo carregar um arquivo de log com alguns gigabytes em uma variável). Veja, na íntegra, a entrevista dele. Você pode ler também a entrevista e mais um monte de coisas legais no próprio site do WinIT.com.

Since TechEd in June, 300,000 more IT shops have downloaded command line scripting language PowerShell, bringing the total to 1.3 million downloads in the last nine months. Small IT shops to large enterprises are using PowerShell to cut hundreds of lines of code down to a single command line. As a result, IT managers are becoming more productive. They are able to complete in a matter of minutes administration tasks that used to take them hours.

Jeffrey Snover, the creator of PowerShell and a Windows Partner Architect at Microsoft, spoke with SearchWinIT.com recently about the scripting language's potential to save time and cut tasks, new third-party tools that use PowerShell and some features that IT shops can expect in the next version, PowerShell 2.0.

SearchWinIT.com: What's next for PowerShell?

Jeffrey Snover: We've been pretty up front that the need of IT admins is [for remotely administering machines]. It's a new model for [remote management] to 10 machines, 100 machines, maybe even 5,000 machines. So basically, 'remoting' will be built into the heart of the PowerShell engine and then exposed as a set of language features and commands versus 'remoting' being done as a bolt-on afterthought. People who in the past were intimidated by 'remoting' or found it difficult will find this simple.

What are some examples of how IT shops are using PowerShell?

Snover: When I was at TechEd, a guy came up to me and said he replaced his 481-line Visual Basic script with a single PowerShell line. He did a hardware inventory across multiple machines and generated a report with a single PowerShell line of code. The reason why is because with PowerShell you get a set of objects, pipe it out to HTML and, voilà, you've got an HTML report.

Another customer came in and brought their scripts with them, and we rewrote their VB script to PowerShell. One of their VB scripts was 750 lines of code, and we replaced it with a 15-line PowerShell script.

Can you give me an example of a tool in PowerShell that will make a real difference for an IT shop?

Snover: The ability to compare objects. You can get a set of objects that are stored in Excel, XML, a database or your hardware configuration as it exists right now. Then using a single line of code, you can compare the objects in those forms against the current running objects that show the difference [between the two]. So I've got a set of XML files that take snapshots of when the system is working. Then I compare them against the current state and show you all the processes that were created since then or used to exist but don't exist now. And you do that with a single line of code. Taking it to another level, you can take the working set and round it to two megabytes and say 'Only show me the working set having changed if it changed by more than two megabytes.' That's incredibly powerful to do with a single-line command.

Some say that learning PowerShell is easy, some say it's not. What is the learning curve?

Snover: IT guys, their hair is on fire. If something doesn't look like a bucket of water, they're not going to address it. That's why Exchange 2007, VMM [Virtual Machine Manager], Desktop Protection Manager have admin GUIs layered on top of PowerShell. So an IT admin can be using PowerShell and not even know it. But, at some point, they may say this GUI doesn't do quite what I want, and they're going to notice that each of these products allows them to see the command-line equivalent for the operation they just did. They can take that command-line equivalent and cut and paste it into a line or into a file and modify it to meet exactly their needs. PowerShell can be the simplest scripting tool out there like Bash in the Unix world, or it can be a very sophisticated tool for the IT guy running the Federal Reserve.

What kind of third-party development are you seeing around PowerShell?

Snover: In some cases, there are people producing PowerShell commands and then making them available so that PowerShell can manage their products. The second is hosting tools. PowerShell is an interactive shell, but that's just one of the hosts. PowerShell is also an embeddable engine like a library that you can plug into anything. There are folks like PowerGui.org. They wrote a GUI that allows people to take commands and expose them as graphical elements in a GUI. Another is PowerShell Analyzer, which is modeled after SQL Query Analyzer, where they've got this Interactive Development Environment, but you have syntax coloring. You can select portions of your script and execute them, or you can execute your whole script. Then you've got PrimalScript, the number one VB scripting IDE, that has PowerShell support as well.

Any well-known application vendors jumping on board?

Snover: We've had quite a few discussions with companies that are doing PowerShell work but aren't public with that yet. With these vendors, we're taking their product as is and then loading in PowerShell and being able to do extensions to make their applications scriptable through PowerShell. You'll have heard of these vendors and [those announcements] will probably be made by early next year I think.

Microsoft has said that all of the admin GUIs in its products would be based on PowerShell by 2009. Where does that stand?

Snover: All the products will have PowerShell available. Whether or not [the product teams] will have converted over their user interface layer on top of that is up to them. That's not required in the 2009 time frame. A bunch of [Microsoft product teams] are doing it, though. It really comes down to the question of were they planning a major rewrite of their GUI.

Where can IT professionals get trained? What resources are available?

Snover: We underestimated the rate of PowerShell adoption and, therefore, the need for training. We knew books would be an important element, so we worked hard with the book vendors, and there are 11 books and another five coming on board. A lot of people are getting trained that way. We also have a number of external partners doing training like Sapien, Desktop Engineering, Ameritech; and Global Knowledge just licensed Sapien's training. There's also a bunch of Microsoft field organizations providing training for the customers they support.

Categorias dessa postagem:

Exchange via Script

Um dos sistemas mais importantes da MS é o Exchange. O que pouca gente sabe é que ele também é um dos que mais podem ser automatizados.

O que significa, na cabeça do Vinicius, "poder ser automatizado" e porque o Exchange é um dos programas que mais podem fazer isso? Bom, essa é uma definição minha, nada séria ou oficial.

Ao menos pra mim, "poder ser automatizado" é a capacidade que um sistema tem de ser instalado, administrado e configurado usando técnicas para automação de tarefas como scripts, linha de comando, diretivas de grupo, etc. Essa característica é boa para se ter uma noção de qual software é bom para ser implantado em grandes ambientes. O motivo é simples: ambientes grandes normalmente são administrados usando essas técnicas para automação devido ao pouco tempo que os administradores possuem para cada recurso administrado. Além disso, sistemas que suportam bem a automação podem ser administrados por um número menor de pessoas, o que, no final, gera uma maior economia para a empresa.

Bom, onde entra o Exchange? Não sei dizer bem o porque, mas o Exchange é um dos sistemas da MS que mais tem suporte à scripting. Além da interface gráfica, ele possui também acesso via WMI, uma API para criação de ferramentas e, agora, Windows Powershell. Aliás, foi o primeiro sistema a criar, usando a API do Powershell, um prompt de comandos com cmdlets específicos.

Bom, para quem gosta de Exchange e quer aprender sobre scripting, encontrei 3 links interessantes que demonstram algumas tarefas usando VBScript e WMI.

Categorias dessa postagem: , , ,

Palestra sobre Windows Powershell

Isso mesmo! Dia 25 de Setembro de 2007 vou ministrar mais um webcast, dessa vez sobre o Windows Powershell. Pra quem não sabe, um webcast nada mais é do que uma palestra via Internet, que pode ser assistida de qualquer canto do mundo.

Minha palestra vai dar uma visão geral do Powershell, com exemplos, dicas e informações para quem tá começando. Recomendo para todo mundo que quiser saber um pouco sobre a ferramenta.

Além disso, foi confirmada hoje minha palestra na Semana da Computação do ICMC, na USP de São Carlos! Não vou decepcionar pessoal!

Segue o link do webcast

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032348375&Culture=pt-BR

e da Semana da Computação:

http://pet.icmc.usp.br/semcomp

Obrigado!

Categorias dessa postagem: , ,

Powershell no curriculum? Comecem a estudar então...

Olá,

encontrei hoje navegando pela Internet uma oferta de emprego um tanto quanto interessante. Para quem não sabe, estou no quarto ano do curso de Ciências da Computação na USP de São Carlos e o próximo ano do meu curso é dedicado inteiramente à um projeto de graduação ou estágio. Eu escolhi o estágio... e agora procuro por uma vaga interessante.

Mas isso não é o motivo do post. O que eu encontrei, pela primeira vez, foi uma vaga que pedia conhecimentos em scripting, incluindo Perl, WSH/VBScript e Powershell.

Vejam vocês mesmos: http://jobs.nwsource.com/texis/jobsearch/rssdetail.html?id=46d8697a4a01b0&rssref=pibiz

Até mais!

Categorias dessa postagem:

Logoff do usuário via script

Olá,

um desconhecido (na verdade ele se chama Reginaldo Costa, mas eu não conheço) me perguntou por email como fazer para forçar o logoff do usuário via script. Encontrei este na Internet e resolvi postar aqui, dado que vários frequentadores deste site sugeriram que eu mesmo já modificasse alguns dos scripts que eu ensino.

A idéia básica é simples: há um script pronto no ScriptCenter que serve para desligar o computador, via WMI (logo, funciona tanto localmente quanto para reiniciar micros remotamente). Ele usa o método Win32Shutdown para fazer o serviço. O que pouca gente sabe é que esse método também pode ser usado para fazer o logoff do usuário. Basta trocar o valor da constante no início do script. Os valores possíveis podem ser encontrados aqui.

Não testei, mas deve funcionar.

Const LOGOFF = 4
strComputer = "127.0.0.1"  'aqui vai no nome do computador ou o IP
Set objWMIService = GetObject("winmgmts: {(Shutdown)}" _
 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
 ("SELECT * FROM Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
 ObjOperatingSystem.Win32Shutdown(LOGOFF)
Next

Categorias dessa postagem: ,

Executar programas em outros computadores com uma linha

Olá,

continuando a meus posts sobre one-liners, segue agora meu comando para executar programas em outros computadores. Uma linha só, no Windows Powershell:

"webserver","isaserver","sqlserver" | % {([wmiClass]"\\$_\ROOT\CIMV2:win32_process").Create("\\appserver\share\update.exe")}

Note que, embora o meu site tenha quebrado a linha em duas, você pode digitar isso em uma só.

No comando acima, eu usei um dos inúmeros aliases do Powershell: o %. % no Powershell é um alias pro commandlet foreach-object. Já usei ele várias vezes no blog, e ele serve para executar um dado bloco de comandos (aquilo que está entre as chaves) para cada um dos ítens que ele recebe pelo pipe. Além disso, em cada execução do bloco, ele substitui a variável $_ pelo ítem atual. É como um for ou foreach em qualquer linguagem de programação.

Caso queira colocar a lista de máquinas em um arquivo .TXT, basta criar um arquivo chamado lista.txt com os nomes ou IPs das máquinas (uma por linha) e usar o comando abaixo:

cat lista.txt | % {([wmiClass]"\\$_\ROOT\CIMV2:win32_process").Create("\\appserver\share\update.exe")}

Até mais!

Categorias dessa postagem: ,

Como modificar o Registro via Script - Parte 3

Eu novamente. Agora, vou abordar um truque que eu poderia ter utilizado em um dos meus scripts recentes. Digo que poderia ter usado porque realmente não usei, acabei optando por utilizar um comando correspondente em WMI. Bom, vou deixar esse meu script (que fiz a pedido de um amigo meu chamado Allan Winckler) pro próximo post.

Abaixo, dou um exemplo que vi essa semana no newsgroup de Powershell da Microsoft:

PS C:\> $server = 'webserver1'
PS C:\> $regHive = [microsoft.win32.registryKey]::openremotebasekey([microsoft.win32.registryhive]::LocalMachine,$server) PS C:\> $regKey = $regHive.OpenSubKey('Software\Microsoft\Windows\currentVersion\Uninstall') PS C:\> PS C:\> PS C:\> PS C:\> $regKey.GetSubKeyNames() AddressBook CNXT_MODEM_HDAUDIO_VEN_14F1&DEV_2BFA&SUBSYS_20030003 Connection Manager DirectAnimation DirectDrawEx DXM_Runtime EvilLyrics

.

.

.

No exemplo acima eu conecto ao Registro da máquina webserver1 e obtenho todas as subchaves da chave HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall. Esta é uma das chaves que indicam quais softwares estão instalados na máquina.

Note que utilizar o Powershell, nesse caso específico, tem uma desvantagem: É necessário algum conhecimento em programação na plataforma .Net. Não é tão trivial para quem está começando... é para isso que existem os exemplos =).

Bom, espero que eu tenha dado alguma idéia das principais formas de se acessar o Registro via script. Existem outras ainda, mas essas são as mais comuns e eficazes.

Até mais!

Categorias dessa postagem: ,

WSH 5.7 - Parte 3

Acabo de testar o update e a versão 5.7.0.16535 funciona da mesma forma que o 5.6 no que se refere à pasta base. Peço então que alguém com um Vista padrão rode o seguinte script e envie para mim, para confirmar (ou não) o que eu disse no último post:

Set objShell = CreateObject("WScript.Shell")

wscript.echo objShell.CurrentDirectory
wscript.echo Wscript.version & " " & wscript.buildVersion

Até mais!

Categorias dessa postagem:

Mais sobre o Windows Script Host 5.7: A saga continua

Escrevi recentemente sobre a versão do WSH do Windows Vista. Perguntei no NG público da MS e Al Dunbar respondeu-me que não havia nenhuma diferença significante, e que o 5.7 era somente o número de versão que vinha com o Vista, nada mais. Como não obtive nenhuma resposta e não há documentação oficial no MSDN ainda, aceitei e não investiguei nada a respeito do WSH 5.7 (até porque não uso o Vista aqui, mas sim o XP, com o WSH 5.6 build 8820).

Hoje, li no NG público da MS uma mensagem do Michael Harris, outra mensagem sobre o 5.7. A MS lançou hoje versões do WSH 5.7 para Windows 2000, XP e 2003. Eu, mais uma vez, tenho motivos para discordar que eles são iguais... até porque não faz sentido lançar o 5.7 para SOs anteriores se o 5.6 que tem neles for igual.

Além disso, outro fato interessante é que algumas pessoas na Internet encontraram uma diferença entre o 5.6 e o 5.7. O diretório padrão ao executar scripts não é mais a pasta onde o script se encontra, mas sim o diretório C:\Windows\System32 (possivelmente porque o Wscript e o Cscript, hosts do WSH, moram lá). Scripts antigos podem começar a falhar a partir de agora, caso o programador não tenha tomado o cuidado de mudar o diretório atual para o mesmo diretório onde o script está. O erro mais comum vai ser o caso de tentar abrir um arquivo na mesma da forma mais simples, passando caminho relativo:

set objFSO = CreateObject("Scripting.FilesystemObject")
set objFile = objFSO.OpenTextFile("teste.txt")

Esse script, até o 5.6, vai tentar abrir o arquivo teste.txt que está na mesma pasta do script. No 5.7, ele vai tentar o teste.txt que estiver na pasta Windows\System32. Logo, se você abre arquivos desta forma, vai ter problemas (eu tive em alguns aqui já).

Download details: Windows Script 5.7 for Windows 2000
http://www.microsoft.com/downloads/details.aspx?familyid=c03d3e49-b40e-4ca1-a0c7-cc135ec4d2be&displaylang=en&tm

Download details: Windows Script 5.7 for Windows XP
http://www.microsoft.com/downloads/details.aspx?familyid=47809025-d896-482e-a0d6-524e7e844d81&displaylang=en&tm

Download details: Windows Script 5.7 for Windows Server 2003
http://www.microsoft.com/downloads/details.aspx?familyid=f00cb8c0-32e9-411d-a896-f2cd5ef21eb4&displaylang=en&tm

Eu baixei o 5.7 e descompactei sem instalar por aqui. Vou tentar alguma engenharia reversa para descobrir o que há nas DLLs, mas posso adiantar uma coisa: a versão dele é a 5.7.0.16535. A do Windows Server 2008 (build 6001), que uso para testes, é a 5.7.0.16510, e retorna o diretório atual corretamente.

Vou testar instalar o update mesmo (build 16535) num XP e ver o que acontece.

Até logo!

Categorias dessa postagem:

Como usar o Process Explorer

Olá,

um dos truques que eu uso sempre que preciso remover algum malware (leia-se vírus, cavalos-de-tróia, spywares e programas do gênero) manualmente é utilizar os softwares escritos pela Sysinternals (agora, Microsoft). Há vários programas úteis, como o Process Explorer, FileMon e RegMon. Estes permitem, nessa ordem, verificar em tempo real o funcionamento dos processos em execução, acessos ao sistema de arquivos e ao registro. Tem ferramenta pra tudo, vale a pena checar.

No entanto, analisar o log dele requer um pouco de prática. Tem que fuçar por um bom tempo o funcionamento dos programas pra se familiarizar com ele e aprender o que é possível de se "enxergar" com esses programas. Sempre me perguntam sobre como usar esses programas, e esse post vai justamente para essas pessoas!

Pra quem quer aprender também, encontrei um link legal. Trata-se do blog do Mark Russinovich, o "pai" desses programas em questão. No linkno fim desse post, ele mostra em detalhes como descobriu um problema curioso sobre compactação de arquivos no Vista.

Ao compactar arquivos com o Vista em uma determinada máquina, uma mensagem de erro estranha ("File not found or no read permission") aparece. Onde estava o problema? Em uma versão específica de um anti-virus que estava instalada lá. Ele descobriu isso logando a atividade dos programas durante a "falha" (é só abrir o Process Explorer, mandar ele capturar os eventos e em seguida reproduzir o bug) e analisando o resultado. Super simples, mas precisa de algum conhecimento extra. Segue o link

http://blogs.technet.com/markrussinovich/archive/2007/08/07/1715181.aspx

Vendo os logs, eu também desconfiaria do AV... mas demoraria muito mais tempo que ele, obviamente. Vale lembrar que eu tenho só 22 anos, o que deve ser mais ou menos o mesmo tempo que ele tem de experiência nessa área. Agora que eu já vi uma vez, saberei analisar um dia da mesma forma. Veja você também, eu recomendo!

O dia que eu souber sobre o Windows do jeito que o Mark sabe, estarei feito =)

Até mais!

Categorias dessa postagem: , , ,

Videos no Zen V Plus: YouTube, Google Video, Channel9...

Olá pessoal,

recentemente ganhei um MP3 Player, um Creative Zen V Plus de 4Gb. Comecei a brincar nele e vi que podia automatizar algumas coisas com scripts, claro. Por enquanto, me preocupei em resolver o problema sobre como converter vídeos (no meu caso, entrevistas do Channel9 e palestras no YouTube e Google Video) para o formato utilizado no meu player.

Pra minha surpresa, o formato que ele lê é simples: AVI sem compressão nenhuma, algo como uma sequencia de arquivos bitmap. Não entendo muito disso e posso estar falando besteira... mas não encontrei nenhuma documentação no site da Creative. Isso chateia porque é filmes pequenos ficam enormes devido à falta de compressão. Testei com um de 50 minutos e ele se transformou em um monstro de 850Mb!

Depois de brigar bastante com o software da própria Creative para converter meus vídeos, encontrei uma solução na Internet de como usar um programinha chamado ffmpeg. O problema é que ele gerava arquivos com a imagem e as cores invertidas. Ainda no mesmo site, há um relato de que ao executar o comando mais uma vez sobre o mesmo arquivo o vídeo normalizava, mas ainda havia o problema do player travar quando se tentava deslocar para uma posição mais à frente (seek).

Em um dos meus testes, descobri como resolver o problema. Agora consigo converter videos perfeitamente, tanto filmes comuns quanto arquivos FLV e WMV também! Descobri quando esqueci acidentalmente do parâmetro -r na segunda vez que executava o ffmpeg. Veja como converter:

ffmpeg -i arquivo.mpg -vcodec rawvideo -acodec adpcm_ima_wav -r 12 -s 128x128 -pix_fmt rgb24 out.avi

ffmpeg -i out.avi -vcodec rawvideo -acodec adpcm_ima_wav -s 128x128 -pix_fmt rgb24 out2.avi

Note que os parâmetros tem que ser os mesmos, basta retirar o frame-rate. Sabendo do comando que funciona, criei um script pra isso, o movie2zen.ps1. Ele recebe como parâmetro o filme e, opcionalmente, o framerate e a resolução. Veja:

Param([string]$input_movie, [int]$rate = 12, [string]$resolution = '128x128')
$tempname = $input_movie + '.temp.avi'
$outname = $input_movie + '.out-zen.avi' 

.\ffmpeg.exe -y -i $input_movie -vcodec rawvideo -acodec adpcm_ima_wav -pix_fmt rgb24 -r $rate -s $resolution $tempname
.\ffmpeg.exe -y -i $tempname -vcodec rawvideo -acodec adpcm_ima_wav -pix_fmt rgb24 -s $resolution $outname
rm $tempname

Agora, para converter um filme:

.\movie2zen filme.mpg

ou ainda

.\movie2zen filme.mpg 15 '128x96'

Para converter uma pasta inteira:

cd c:\filmes-curtos
ls | foreach {.\movie2zen $_}

Note que eu dei antes um CD para a própria pasta para que os filmes gerados saiam na mesma pasta de origem. Meu script apenas gera um segundo arquivo com o sufixo '.out-zen.avi'.

Até a próxima!

PS: Se alguém quiser me ajudar e revisar a versão em inglês que estou fazendo deste tutorial, eu ficarei muitíssimo agradecido! =).

Categorias dessa postagem: , ,

Como modificar o Registro via script - Parte 2

A segunda parte desta série continua falando sobre como modificar o Registro em scripts, mas agora com uma abordagem mais moderna.

O primeiro da fila é o Windows Powershell. Ele possui um Provider específico para trabalhar com o Registro, o que torna possível navegar no registro da mesma forma que você navegaria num diretório, por exemplo. É possível utilizar os mesmos comandos CD e DIR (set-location e get-childItem, na verdade) para entrar e sair das chaves, além do comando get-ItemProperty para obter o conteúdo dos valores e seus dados. Note que um valor não equivale à um arquivo (ou ítem) do sistema de arquivos. Ele corresponde sim à uma propriedade, e por isso não usamos get-ItemProperty para obter os valores, e não o get-Item comum. O get-Item retorna somente subchaves.

Veja um exemplo:

PS HKLM:\> cd HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
PS HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run> dir


   Hive: Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

SKC  VC Name                           Property
---  -- ----                           --------
  0   5 AutorunsDisabled               {LanguageShortcut, RemoteControl, VAIO Update 2, IntelZeroConfig...}
  3   0 OptionalComponents             {}


PS HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run> Get-ItemProperty .


PSPath            : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ru
                    n
PSParentPath      : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
PSChildName       : Run
PSDrive           : HKLM
PSProvider        : Microsoft.PowerShell.Core\Registry
igfxtray          : C:\WINDOWS\system32\igfxtray.exe
igfxhkcmd         : C:\WINDOWS\system32\hkcmd.exe
igfxpers          : C:\WINDOWS\system32\igfxpers.exe
Apoint            : C:\Program Files\Apoint\Apoint.exe
EOUApp            : "C:\Program Files\Intel\Wireless\Bin\EOUWiz.exe"
NvCplDaemon       : RUNDLL32.EXE C:\WINDOWS\system32\NvCpl.dll,NvStartup
VAIO Recovery     : C:\WINDOWS\Sonysys\VAIO Recovery\PartSeal.exe
SonyPowerCfg      : "C:\Program Files\Sony\VAIO Power Management\SPMgr.exe"
ISBMgr.exe        : C:\Program Files\Sony\ISB Utility\ISBMgr.exe
Biomenu           : "C:\Program Files\Protector Suite QL\menusw.exe"
VAIOCameraUtility : "C:\Program Files\Sony\VAIO Camera Utility\VCUServe.exe"
WCULauncher       : C:\Program Files\Sony\SmartWi Connection Utility\WCULauncher.exe
PartSeal          : C:\WINDOWS\Sonysys\VAIO Recovery\PartSeal.exe

PS HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run>

No exemplo acima, eu navego até a chave HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run e listo todos os valores contidos nela. Para quem já conhece um pouco do Registro, sabe que esta é uma das principais chaves (mas não a única) em que ficam os programas executados durante a inicialização do computador. Vírus, trojans e malwares mais simples (para não dizer babacas) se alojam aqui. A remoção, pelo Powershell, pode ser feita então com uma linha (e o comando del).

Observação Importante: Não se assuste se, navegando pelo Registro, começar a observar algumas mensagens de erro. O problema está no fato do Powershell tentar obter o objeto inteiro correspondente à chave de Registro e falha, caso você não tenha permissões adequadas para navegação nas chaves. 

Há ainda várias alternativas, que consistem, por exemplo, na combinação de técnicas apresentadas no artigo anterior com técnicas para execução remota de programas. Basta pegar qualquer uma das técnicas e combinar com o comando PSexec, por exemplo. Vale também criar tarefas agendadas ou executar remotamente também com o WMI, que já foi discutido por mim num post anterior. O céu é o limite.

O próximo post continua sobre Registro. Me empolguei e escrevi um terceiro ítem da série.

Até mais!

Categorias dessa postagem:

Documentação offline do Windows Script Host

Para quem quiser ter a documentação do Windows Script Host offline, para consulta em situações de emergência, indico o seguinte link

http://www.microsoft.com/downloads/details.aspx?FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9

Você pode baixá-lo, copiar o arquivo .CHM que vem junto para um pendrive e resolver seus problemas de uma forma muito mais fácil e rápida!

Até logo,

Categorias dessa postagem:

Como modificar o Registro via Script - Parte 1

Olá,

Este é mais um daqueles meus posts básicos, pra quem tá começando. Vou tratar, nessa série de dois artigos, como trabalhar com o Registro do Windows via script.

O Registro é o "substituto" dos arquivos .INI que existiam nas versões anteriores do Windows. A idéia dele era centralizar toda a configuração do computador, facilitando então o seu acesso, alteração, remoção, além de facilitar backups e outras tarefas administrativas. Mais informações sobre ele podem ser encontradas nesse outro artigo que escrevi, e a seqüência dele.

A partir de agora vou falar sobre como manipular o registro, mas via script.

O Windows Script Host fornece métodos bem simples para ler, escrever e apagar chaves e valores no Registro. São os Métodos RegRead, RegWrite e RegDelete. É possível ler e escrever strings (REG_SZ), expandable-strings (REG_EXPAND_SZ), DWORDs (REG_DWORD) e bitmaps (REG_BINARY). Isso já permite fazer qualquer operação simples no registro, visto que a maioria dos dados lá são ou strings ou binários.

O problema deles começa quando é necessário enumerar os valores de uma chave, enumerar as subchaves, (se você ficou confuso com esses termos, sugiro ler novamente meus posts anteriores sobre o registro. Lá eu falo disso com detalhes) ou então ler/gravar dados binários muito grandes (maiores que 4 bytes) ou multi-strings. Isso não é suportado pelo WSH nativamente. E em parte, isso é perfeitamente aceitável, uma vez que o WSH nasceu junto com o Windows 95 e os inteiros longos e multi-strings no Registro só apareceram no Windows com o Windows 2000.

 A documentação das funções RegRead, RegWrite e RegDelete pode ser encontrada aqui, aqui e aqui.

Para operações mais complexas no registro, temos duas saídas:

  1. Modificar o Registro manualmente usando o Editor de Registro e exportar um arquivo .REG com as alterações necessárias. A seguir, utilize um dos parâmetros da linha de comando do comando Regedit.exe para importar o arquivo .REG. Essa importação pode ser feita mesmo dentro do script, com os métodos Run ou Exec.
  2. Utilizar o comando REG, também pela linha de comando.
  3. Utilizar um script que utiliza o WMI para fazer a tarefa. Embora o WMI resolva os problemas com o Registro que o WSH não consegue resolver nativamente, ele só existe nativamente no Windows 2000 e superiores e no Windows 9x como componente opcional. Além disso, o WMI é naturalmente mais lento que os métodos RegRead, RegWrite e RegDelete.

Ainda sobre o WMI, você pode encontrar exemplos de como manipular o registro nesse link. Praticamente todos usam WMI para obter informações do Registro da máquina local. A vantagem do WMI, nesse caso, é a possibilidade de trabalhar com outros computadores mudando apenas uma linha de código. Normalmente, para executar o mesmo script em outro computador basta alterar a variável strComputer nos scripts do ScriptCenter.

Bom, por hoje é só. Em breve continuo a segunda parte desta série de scripts sobre o Registro.

Categorias dessa postagem:

Windows Script Host 5.7

Surgiu uma pequena dúvida em relação ao Windows Script Host do Windows Vista. Não sei se alguém além do Arthur Aragão e eu reparou que o Vista usa uma versão diferente do WSH.

Procurando na Internet, nenhuma documentação aparente. No MSDN também.

Resolvi então perguntar no public.windows.server.scripting e Al Dunbar respondeu-me dizendo que se trata apenas da versão que existe no Vista. A documentação do 5.6 pode ser usada sem problemas.

Entretanto, na minha humilde opinião, isso deveria estar no MSDN, ainda que fosse pra dizer que a documentação do 5.6 serve.

Até mais!

Categorias dessa postagem: ,

Comentários no Blog

Olá pessoal,

Peço desculpas pelo descuido. Só agora, depois de escrever o último post, que notei que há uns 5 comentários não lidos no blog. Vou responder todos amanhã, assim que eu acordar...

Boa noite!

Categorias dessa postagem:

Alterar Esquema de Força e Usuários Comuns: Como configurar o Windows XP para permitir isso

Boa noite!

Como todos os meus leitores já devem saber, eu sou um daqueles que defende o princípio do menor privilégio (também conhecido como Least-Privilege, nos livros de segurança). Em especial, li recentemente no Writing Secure Code exatamente sobre isso. Fiquei feliz em saber que tudo aquilo que eu sempre comentei é um dos princípios que o autor recomenda.

Além disso, sou um usuário de um tipo raro. Não que isso me torne mais ou menos especial ou inteligente, mas apenas diferente. Eu utilizo meu computador sem ser com uma conta de administrador ou equivalente. Mesmo no meu notebook, que praticamente só eu uso, não utilizo uma conta administrativa. Uso computadores dessa forma há mais de 4 anos, quando entrei na faculdade, sem problemas. Uso a conta de admin somente quando necessário, para instalar algum programa ou biblioteca. Se essa política fosse seguida por usuários em geral, mais da metade dos problemas em seus computadores sequer teria acontecido. Já discuti sobre esta prática em outro post anterior, e recomendo a leitura deste outro site para quem não estiver acreditando em mim.

Recentemente concluí que havia instalado todos os softwares necessários no meu notebook, e resolvi alterar novamente minha conta para ficar com "menos poderes" novamente. O único problema encontrado até o momento foi o Gerenciamento de Energia.

Não sei quanto às versões anteriores, mas o Windows XP teima em não permitir que usuários comuns alterem o esquema atual de energia. Usuários de notebooks são os mais afetados com isso, uma vez que, num notebook, é interessante utilizar diversos esquemas de energia para diversas situações. Eu, por exemplo, tenho 12 esquemas de energia configurados, uma para cada situação. Isso permite utilizar de forma inteligente a bateria do notebook, visando aumentar a vida útil dela e o tempo de uso que ela rende habilitando e desabilitando dispositivos como CD-ROM, Placa de rede, Firewire, diminuindo a intensidade do vídeo, etc.

É até questionável porque ele foi programado desta forma. Eu mesmo acredito que, ao menos na versão cliente do SO (leia-se Windows XP), qualquer usuário deveria poder configurar e definir o esquema de energia que está sendo utilizado no momento. Em servidores isso não faz o menor sentido, além de não ser muito correto do ponto de vista da segurança. Mas em clientes, qual o problema? Enfim...

Hoje, após voltar de uma reunião da Semana da Computação (vou falar dela depois), fiz meu jantar e voltei a pesquisar sobre o assunto. Buscando no Google encontrei um site que eu já conhecia, mas que eu não tinha lido ainda. Ele novamente, o blog Non-Admin, de Aaron Margosis. Ele escreveu um artigo completíssimo sobre porque o XP não permite que os usuários configurem seus sistemas e como contornar isso.

Segundo ele, o problema está no fato da interface gráfica setar ao mesmo tempo a configuração dos esquemas de energia do usuário e do sistema (system-wide, ou seja, algum lugar abaixo de HLKM no registro), quando deveria configurar somente as configurações do usuário. Até daria certo se a configuração padrão da chave do registro em questão permitisse escrita para usuários comuns.

Para permitir então que qualquer usuário comum do XP configure o esquema de energia, faça o seguinte:

  1. Abra o Editor de Registro (também conhecido como Regedit) como administrador. Você pode fazer isso logando com a conta de admin ou com o comando RunAs.
  2. Navegue até a chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ControlsFolder\PowerCfg
  3. Clique com o botão direito na subchave GlobalPowerPolicy e escolha Permissões
  4. Clique no botão Avançado
  5. Clique no botão Adicionar
  6. Digite INTERACTIVE (ou qualquer outro grupo que você queira permitir a configuração. Recomendo o grupo INTERACTIVE porque nele estão todos os usuários que podem logar localmente neste computador), clique em Checar Nomes e em OK
  7. Marque as opções Alterar Valor (Set Value) e Criar Subchave (Create Subkey) e clique em OK.
  8. Repita os passos acima para a subchave PowerPolicies

Ainda assim, recomendo que leia o artigo original. Se você acompanhar os comentários, vai ver que encontraram soluções para outros problemas antigos como o de permitir que usuários comuns cliquem duas vezes no relógio, ou mesmo como implementar essa alteração de permissões no registro utilizando o REGINI, scripts VBS, o programa REGPERM, distribuir por GPOs, etc. Vale um bookmark!

Vale lembrar que o Windows Vista não tem esse problema. Foram feitas várias alterações no controle de energia do SO. Entretanto, continuo não usando o Vista, mas agora por opção. =). Pretendo utilizar em breve Windows Server 2008 ou 2003 R2.

Até a próxima!

Categorias dessa postagem:

Post anterior, versão One-Liner Ruby

One liner é o nome que se dá pros programas ou expressões que usam somente uma única linha. A diversão está em realizar uma atividade relativamente complexa com uma única linha de código.

O blog oficial do time do Windows Powershell tem como slogan "Improving the world one-liner at a time". É uma clara referência aos One-Liners.

Segundo informações da Wikipédia, o termo One-Liner tem duas referências no livro The AWK Programming Language. Nele, o autor explica o nascimento do paradigma One-Liner com seu trabalho do dia-a-dia na administração de antigos sistemas Unix:

The 1977 version had only a few built-in variables and predefined functions. It was designed for writing short programs [...] Our model was that an invocation would be one or two lines long, typed in and used immediately. Defaults were chosen to match this style [...] We, being the authors, knew how the language was supposed to be used, and so we only wrote one-liners.

Bom, agora, meu one-liner para o problema do post anterior, sobre como colocar espaços ou caracteres em todas as linhas de um arquivo. A diferença, nesse caso, está no uso da linguagem Ruby para fazer isso:

ruby -e "File.open('_vimrc'){|fin| File.open('_vimrc2','w'){|fout| fin.readlines.collect{|lin| '  ' + lin}.each{|linout| fout.write linout} }}"

Eu mesmo não sei se está correta a classificação dessa linha como um One-Liner. Ou talvez o one-liner do post anterior não seja um. Minha dúvida está em poder ou não utilizar redirecionamento do shell, por exemplo. Nesse caso, o trabalho maior foi abrir dois arquivos em uma única linha. No entanto, se eu utilizar o próprio shell para abrir e fechar o arquivo, o script em Ruby pode ficar ainda menor.

Até logo,

Categorias dessa postagem: ,

Como adicionar espaços, tabulações ou qualquer outro caractere ao início de todas as linhas de um arquivo texto?

Olá,

embora esse post seja bem explicito (basta ler novamente o título), existem várias saídas para esse problema. Uma delas, e a que eu vou mostrar aqui, é a que usa Windows Powershell:

cat arquivo.txt | foreach {'  ' + $_} >> arquivo2.txt

No entanto, como a lógica é bem simples (ler o arquivo, alterar todas as linhas, gravar novamente), ela pode ser portada pra qualquer outra linguagem (VBScript e Ruby, por exemplo).

Sobrando algum tempo, crio um one-liner em Ruby para fazer a mesma coisa.

Até mais!

Categorias dessa postagem: ,

Powershell Basics: trabalhando com arquivos e pastas

Saiu hoje no ScriptCenter um artigo sobre como trabalhar com arquivos e pastas no Powershell. São abordados temas como cópia de arquivos e pastas usando condições como datas e arquivos modificados, por exemplo.

Muito bom pra quem tá começando e quer aprender um pouco mais, com exemplos.

Segue o link:

http://www.microsoft.com/technet/scriptcenter/resources/begin/ss0707.mspx

Até logo!

Categorias dessa postagem:

Lógica de Programação: porque é importante?

Olá,

acabo de ler um post interessante no blog de um suíço chamado Desmond Lee, sobre como trabalhar com arquivos gigantes (grandes mesmo... imagine um log com mais de 1Gb) no Windows Powershell.

Ao manipular arquivos grandes no Powershell, deve-se tomar certo cuidado. Ele pode facilmente acabar com a memória disponível caso o script seja mal feito.

Onde eu quero chegar com isso? Lógica de programação. Eu sou um dos defensores da idéia de que qualquer pessoa que trabalhe com um computador deveria aprender isso. Em especial os administradores de sistema que, no geral, programam muito mal.

Para ler um arquivo de vários gigabytes de informações seria muito mais simples trabalhar diretamente com VBScript ou mesmo C, que permitem que você abra e acesse posições aleatórias de um arquivo, sem precisar carregá-lo inteiro na memória. Aliás, até mesmo no Powershell é possível fazer isso, mas dá mais trabalho do que chamar o comando get-content. É algo bobo que, quem já programou um dia em qualquer que seja a linguagem, com certeza sabe.

Bom, fica então meu conselho: quando sobrar algum tempo livre, estude algo sobre programação, por mais que pareça inútil na sua área.

Até a próxima!

Categorias dessa postagem:

Ordenando qualquer coisa usando Windows Powershell

Olá,

conforme prometido, estou postando um truque interessante sobre o Powershell. Como vocês já devem ter visto, ele permite que criemos scripts de uma forma completamente diferente do normal, uma vez que ele é um shell que trabalha com objetos e não com texto, como todos os outros prompts de comando e shells. Isso dá toda a flexibilidade dele. O que eu vou mostrar agora é um exemplo disso.

Pense numa lista de arquivos. Isso pode ser obtido com o comando dir facilmente. Agora imagine ordenar esses arquivos por nome:

dir | sort-object 

Isso, por si só, já ordena os arquivos por nome. Agora, ordenando por data de criação.

dir | sort {$_.creationtime}

Perguntas comuns: Vinicius, o que significa o $_? É uma referência que você precisa usar dentro do bloque que o sort-object recebe para indicar o próprio arquivo. Imagine que o dir "pega" vários arquivos do disco, monta uma lista e manda pelo pipe para o próximo comando. O Sort pega os objetos novamente e busca, em cada um, a propriedade creationTime, que é a data de criação dele. Vinicius, e de onde você tirou esse creationTime? Iluminação divina? Não. Powershell mesmo. Você pode listar as propriedades de qualquer objeto no Powershell com o comando get-member ou simplesmente gm. Assim:

dir | get-member

É questão de fazer testes.

Agora o truque: e para não ordenar, ou seja, para embaralhar a lista?

PS > dir | sort {(new-object system.random (date).milliseconds).next()}


    Directory: Microsoft.PowerShell.Core\FileSystem::C:\Documents and Settings\Vinicius Canto


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---          7/6/2007      2:15       4461 _vimrc
d----         26/6/2007     22:57            dwhelper
d-r--         24/6/2007     22:17            Desktop
d-r--         22/7/2006      8:38            Start Menu
-a---         12/6/2007     21:58        143 .rails-plugin-sources
d-r--         28/1/2005     15:04            Favorites
-a---          5/6/2007     13:45          0 The All-American Rejects - Move Along.mp3
-a---          1/7/2007     20:14      18033 _viminfo
-a---          5/6/2007     13:39          0 Outlook Express.lnk
d----         12/6/2007     14:09            Contacts
d---s          2/7/2007      1:44            Cookies

Pronto! O resultado seria esse que aparece logo abaixo do comando. E cada vez que você rodar o comando, vai ter uma lista diferente. No final das contas, não é 100% randômico por dois motivos: 1) Computadores não geram números aleatórios, mas sim pseudo-aleatórios. Isso acontece porque o computador não tem como chutar números e usa uma função matemática que nunca volta no mesmo número (e há provas disso). No entanto, isso não garante a aleatoriedade do número gerado. 2) Com o comando acima, eu sempre crio o objeto Random a cada vez que o comando é executado... isso significa que, com um pouco de sorte, você pode ter a mesma lista se acertar o número de milissegundos. O certo, nesse caso, seria criar o objeto uma linha antes e só chamar o método Next() sempre que precisar do número. Mas para embaralhar uma lista dessas uma única vez, serve.

Ah, um detalhe: isso serve para qualquer lista de objetos no Powershell. Isso inclui lista de nomes, arquivos texto, lista de mailboxes do Exchange, usuários do AD, e aí vai... as possibilidades são infinitas. Veja o exemplo que motivou esse post. Precisei embaralhar o conteúdo de um arquivo texto:

${c:\arquivo.txt} = ${c:\arquivo.txt} | sort {(new object system.random).next()}

 A próxima postagem continua sobre Powershell, mas sobre aliases. Até mais!

Categorias dessa postagem:

MVP 2.0: again!

Olá pessoal,

recebi hoje a notícia que meu título de MVP foi renovado por mais um ano, o que pra mim é uma vitória sem tamanho! Esse é o reconhecimento do trabalho que tenho feito pela comunidade, e devo isso tudo à vocês.

Meus planos este segundo semestre de 2007 e primeiro semestre de 2008 são muito simples: pretendo continuar fazendo a mesma coisa e, se não houver nenhum imprevisto (mais adiante eu explico), poderei até fazer mais. Existem planos, por exemplo, de participar de um ciclo de palestras presenciais com o pessoal do Technet Brasil (fui convidado pelo Danilo no semestre passado, mas não pude ir por pura falta de tempo), tenho planos para lançar meu blog sobre scripting em inglês e aquela antiga idéia de criar um serviço de submissão colaborativa de scripts especificamente para administração. São idéias boas, mas tudo depende do pouco tempo livre que me sobra...

Disse que tempo continua sendo um problema para mim, e não estava mentindo. Como todos devem saber, estudo na Universidade de São Paulo, estou no penúltimo ano do curso e, nesse primeiro semestre, as matérias deram bastante trabalho. Isso sem falar na greve (justa) sobre os decretos mal explicados do governador do estado, que continua com a mesma política de sucateamento do ensino público que vem sendo praticada há mais de 12 anos. Já era hora do movimento estudantil reaparecer, lutar e tentar sair dessa situação... não foi exatamente da maneira ideal, mas foi um passo importante sim. Bom, vou parar por aqui porque isso dá assunto pra outro blog inteiro.

Aos meus leitores, deixo o seguinte recado:

  • Tenho 4 mensagens para responder na fila de comentários postados no blog. Vou responder com calma, assim que possível.
  • Vou voltar a postar mais tópicos sobre scripting à partir do dia 16. Esse é o dia da minha última prova por aqui, se Deus quiser! =)

Para tentar remediar a minha ausência do blog por mais de um mês, vou escrever daqui a pouco sobre um assunto que descobri pouco tempo atrás: como ordenar ou "embaralhar" uma lista (de qualquer coisa) no Windows Powershell.

Até mais e obrigado por tudo pessoal!

Vinicius

Categorias dessa postagem:

Desligar computadores na rede: mais um truque

Olá,

já postei algumas formas de como ligar e desligar computadores aqui no blog. A grande maioria delas envolvia scripts, listas de computadores para serem desligados e tudo mais. O que eu vou apresentar agora é um velho conhecido, o comando shutdown, nativo desde o Windows XP se não me engano, mas presente no Resource Kit desde o Windows 2000. Corrijam-me se eu estiver enganado quanto às versões.

O comando shutdown permite desligar computadores pela linha de comando. O que poucas pessoas conhecem é o parâmetro -i, que mostra uma interface gráfica. Nela, é possível configurar como vai ser o desligamento, listas de computadores, tempo limite e uma opção para documentar o motivo do desligamento.

A grande facilidade é poder copiar e colar uma lista de computadores na janela. Pode ser mais rápido do que criar um script se você precisar desligar determinados computadores uma única vez. Essa dica retoma uma velha discussão: vale a pena fazer script sempre? Eu digo que não.

Scripts não são a panacéia dos administradores e nem sempre são a melhor escolha. Como eu comentei, pode não ser necessário criar um script para desligar uma lista de computadores. Por outro lado, se você repetir essa tarefa, eu recomendaria pensar em um script para trabalhar por você. Seres humanos são capazes de pensar... e não é interessante desperdiçar tempo com tarefas repetitivas.

Bom, por hoje é só. Experimente o shutdown -i ao menos uma vez para ver do que ele é capaz.

Até logo!

Categorias dessa postagem:

Executar programas com Windows Script Host

Olá,

numa das minhas caminhadas pela internet (e o MSDN) encontrei mais uma forma de executar programas em arquivos .VBS, sem ser os métodos Exec e Run do próprio WSH e o método Create da classe Win32_Process do WMI.

Na verdade, já conhecia o truque. Só havia esquecido dele, uma vez que usei uma única vez na vida.

function fnShellExecuteVB()
dim objShell
set objShell = CreateObject("Shell.Application")
objShell.ShellExecute "notepad.exe", "", "", "open", 1
set objShell = nothing end function
fnShellExecuteVB

Segue a fonte: http://msdn2.microsoft.com/en-us/library/ms630455.aspx

Até mais!

Categorias dessa postagem:

Powershell Tutorial: para iniciantes, mas promete...

Olá,

encontrei hoje, navegando pelo CodePlex, outra página bastante interessante. Trata-se de um guia para iniciantes em Windows Powershell. Ele é desenvolvido continuamente pela comunidade, no formato Wiki. Isso é bastante interessante porque permite que o guia evolua com a ajuda das pessoas, que podem escrever livremente conforme seus conhecimentos.

A própria página diz que o guia é para iniciantes... mas eu creio que esse projeto vai longe e que logo logo vai parecer mais com um guia avançado do que com um simples guia para iniciantes.

Segue o link: http://www.codeplex.com/PsObject/Wiki/View.aspx?title=PSH%20Community%20Guide&referringTitle=Home

Até mais!

Categorias dessa postagem:

Monitorar drive A

Olá,

vez ou outra encontro no fórum uma pessoa perguntando sobre como monitorar o drive A:, procurando por arquivos. Criei um script (adaptando um velho conhecido do site do ScriptCenter) para demonstrar algumas coisas:

strComputer = "."
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &  strComputer & "\root\cimv2")
set colMonitoredEvents = objWMIService.ExecNotificationQuery("SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE Targetinstance ISA 'CIM_DirectoryContainsFile' and TargetInstance.GroupComponent= 'Win32_Directory.Name=""a:\\\\""'")

Do
 Set objLatestEvent = colMonitoredEvents.NextEvent
 Wscript.Echo objLatestEvent.TargetInstance.PartComponent
 Wscript.sleep 100
Loop

Este script pode até enviar emails para o administrador quando algum usuário copiar um arquivo para seu drive a:. Bastaria trocar a linha em negrito pela chamada da função SendEmailWithoutSSL de um outro script meu, que monitora quando usuários plugam dispositivos de armazenamento USB e que está publicado aqui mesmo no blog.

Parece legal, mas esse script possui alguns problemas:

  • Ele utiliza eventos do WMI para monitorar o drive, de 10 em 10 segundos. A idéia é boa, mas um arquivo copiado nesse intervalo passaria despercebido pelo sistems. Diminuir esse intervalo por outro lado, tornaria o sistema como um todo mais lento.
  • Ver a lista de arquivos do drive A: faz barulho. =)
  • Copiar para disquete nada resolve nos dias de hoje, com emails de mais de 2gb de armazenamento.

Diante desses problemas, eu sugiro sair por outro lado: proibir o acesso ao drive A: via GPO. É mais simples e eficaz.

Dessa vez, a saída por scripting não é a mais viável.

Até mais!

Categorias dessa postagem:

Ruby no Windows novamente

Um detalhe importante sobre o comportamento padrão dos arquivos-fonte em Ruby, no Windows:

  • Arquivos .RB, quando recebem um duplo clique, são executados com o comando ruby <nome do arquivo> em uma janela do prompt de comandos, da mesma forma que fazemos quando digitamos.
  • Arquivos .RBW são exatamente iguais, são executados em segundo plano, da mesma forma que os arquivos .VBS. Mensagens de erro não são exibidas, cuidado.

Até mais!

Categorias dessa postagem:

Como usar Ruby para administrar estações Windows: Ruby + WMI = mais tempo de sobra para o administrador aprender outras coisas novas

Olá,

conforme prometido, estou postando sobre Ruby. Mas, diferentemente dos 90% da Internet que fala de Ruby voltado para Web, vou exemplificar como usá-lo para administração de sistemas Windows, que é mais minha praia.

Primeiro, uma introdução: Ruby é o nome de uma linguagem de programação interpretada, semelhante ao Python (quem usa as duas vai querer me bater por escrever isso, mas no final as duas são parecidas sim). Ela é totalmente orientada à objetos, e é legal para quem está aprendendo esse paradigma, assim como Java e C#. Ela possui recursos modernos e é extremamente simples de se programar. Basta ter algum background em programação, claro.

No entanto, por ser interpretada acredito, é bem útil para administração de sistemas. Do outro lado do muro, vários administradores do mundo Unix/Linux usam linguagens desse tipo com bastante sucesso para automatizar tarefas que fazem com frequência, como backup, por exemplo. Nesse time de linguagens, as mais famosas são as de Shell (Bash, sh, ksh) e de scripting/interpretadas (Python, Perl e Ruby, que citei acima). Eu particularmente não tenho problema nenhum em programar em nenhuma delas, embora não conheça todas elas a fundo. São relativamente simples. Uma vez aprendida uma, aprender outra se torna fácil. O problema, como Jeffrey Snover descreve no blog dele, é que não há uma sintonia muito grande entre elas e entre as outras ferramentas. É possível trabalhar com todas ao mesmo tempo, mas a interface entre elas e os comandos nativos precisa ser estudada antes de se criar um script um pouco maior. Esse é um dos diferenciais do Windows Powershell, que trabalha com OO e o framework do .Net diretamente na linha de comando.

Pois bem, eu acredito que dê para trabalhar tranquilamente com Ruby em um ambiente misto, com Windows 98, 2000 e XP. É uma saída interessante, uma vez que nesses SOs, a versão do VBScript/WSH é diferente, e algumas ferramentas (ADSI e WMI, por exemplo) não são suportadas igualmente neles. A principal vantagem, ao meu ver, é que o interpretador dessa linguagem não precisa sequer ser instalado, e pode rodar facilmente em um compartilhamento na rede.

Vamos ao meu exemplo. No script abaixo, eu consigo acessar o WMI do computador usando Ruby para desligar o mesmo. Para fazer isso rodar em vários computadores, basta modificar a linha de conexão ao WMI (mérito do WMI, claro).

require 'win32ole'
wmi = WIN32OLE.connect 'winmgmts://./root/cimv2'
so = wmi.ExecQuery 'select * from win32_operatingsystem'
arrSO = Array.new
so.each {|item| arrSO.push item}
arrSO.first.win32shutdown 6
#esse 6 é o código da operação... equivale à forced_reboot e pode ser encontrado aqui

Bom, é isso. Basta salvar com extensão .rb e executar com o comando ruby <nome do arquivo>

Até mais!

Categorias dessa postagem:

Ruby on Windows

Achei um blog interessante sobre como trabalhar com programação em Ruby no Windows. Em breve, postarei um exemplo sobre como usar todos os recursos que o Windows tem com a linguagem Ruby, voltado para administração de sistemas com scripting.

Segue o link:

http://rubyonwindows.blogspot.com/

Até mais!

Categorias dessa postagem:

Apagar arquivos de determinadas extensões usando apenas o Windows Powershell - HOWTO

Olá,

Vou postar agora a solução para um problema que aparece nos grupos de notícias/fóruns/listas de email a cada 15 ou 30 dias. É um problema tão recorrente que esta é a terceira vez que escrevo sobre isso. Tenho uns dois scripts em VBScript publicados em algum lugar com a solução também.

Para mostrar como é fácil mexer com Windows Powershell, vou fazer um how-to de como pensar num script pra ele:

Primeiramente, vamos listar os arquivos de um local qualquer. Isso, com o Powershell, pode ser feito da seguinte forma:

dir \\192.168.0.1\c$

Simples. Basta usar o compartilhamento administrativo. Agora, vamos adicionar duas coisas: listagem recursiva, em todas as subpastas, e também que o script não exiba nenhuma mensagem de erro caso não consiga listar algum dos arquivos.

dir \\192.168.0.1\c$ -recurse -errorAction silentlyContinue

Agora, vamos filtrar somente para os que possuem extensão .MP3:

dir \\192.168.0.1\c$ -recurse -errorAction silentlyContinue | where {$_.extension -eq '.mp3'}

Vale lembrar que $_ é a variável que representa cada um dos arquivos dentro do bloco que o where-object analisa. Ele vai pegar todos os arquivos que sairem do comando dir, e passar somente os que tiverem extensão .MP3. Agora, vamos deixar mais genérico: quero que sejam várias extensões. Isso precisará de mais linhas:

$h = new-object System.Collections.Specialized.StringCollection
$h.Add('.mp3')
$h.Add('.avi')
$h.Add('.iso')
dir \\192.168.0.1\c$ -recurse -errorAction silentlyContinue | where {$h.contains($_.extension)}

Notem que eu usei, para facilitar, um objeto da classe StringCollection do .Net. Dá pra fazer de outras 6x10^23 formas diferentes, e eu achei que essa era a mais didática. Um StringCollection nada mais é do que uma estrutura para armazenamento de Strings, onde só me interessa saber se uma dada string já está lá ou não. Agora, vamos apagar os arquivos.

$h = new-object System.Collections.Specialized.StringCollection
$h.Add('.mp3')
$h.Add('.avi')
$h.Add('.iso')
dir \\192.168.0.1\c$ -recurse -errorAction silentlyContinue
| where {$h.contains($_.extension)}
| foreach {rm $_ -whatIf}

Fiz duas coisas: quebrei a última linha em 3 para facilitar a leitura, e adicionei mais um comando nessa linha, o comando foreach. Ele executa o bloco para cada arquivo recebido pelo pipe. Para testar, coloquei o parametro -whatIf, que, ao invés de apagar, mostra as ações que vão ser tomadas pelo Powershell. Isso é útil para testar sem tomar nenhum susto antes de colocar em produção. Agora a parte mais legal: vamos fazer isso para várias máquinas. Basta colocar o IP ou nome delas num arquivo texto qualquer, uma em cada linha:

ts-server
webserver
192.168.0.17
127.0.0.1

E listar esse arquivo, fazendo algumas modificações:

$h = new-object System.Collections.Specialized.StringCollection
$h.Add('.mp3')
$h.Add('.avi')
$h.Add('.iso')
foreach ($machine in (cat lista-arquivos.txt)){
dir ('\\'+ $machine + '\c$') -recurse -errorAction silentlyContinue
| where {$h.contains($_.extension)}
| foreach {rm $_}
}

Fácil, não? Com Powershell é tudo muito intuitivo. Basta montar seu script com calma.

Até a próxima!

Categorias dessa postagem: ,

A verdade sobre o horário de verão

Como já comentei algumas vezes aqui, dados sobre como mudar o horário de verão existem aos montes. No entanto, várias delas são soluções que não levam em conta os procedimentos-padrão, segurança e outros ítens.

Só para citar como exemplo, já vi artigos de gente conceituada (não, não vou citar nomes nem links) dizendo que é interessante modificar as permissões padrão de chaves no registro, ou mesmo dar direito aos usuários para alterar a configuração do relógio. Isso sem falar naqueles que recomendam executar a rotina que faz a alteração como um script de logon com uma senha de admin embutida (!).

Bom, para resolver isso, a MS lançou (algum tempo atrás, mas vi no blog do Paleo só hoje) um artigo sobre como mudar o horário de verão usando várias formas, e uma delas é por um script VBS muito bem escrito.

Link aqui: http://support.microsoft.com/Default.aspx?kbid=317211

Ambos servem como guia definitivo para esse problema, vale a pena ler. Esses valem pra 2006-2007, mas só precisa trocar o valor de uma variável para ele funcionar para outro ano.

 

Até mais!

Vinicius

Categorias dessa postagem:

Como obter todos os endereços MAC da sua rede

Vejam que legal:


1..255 | foreach {
"Pegando MACs da máquina 10.10.10.$_";
Get-WmiObject -computer $('10.10.10.' + $_) win32_networkadapter -filter "adaptertype = 'Ethernet 802.3'"
| ft -hideTableHeaders name, macaddress

Acabei de postar isso em resposta à uma pergunta na lista MCPdx, que eu ajudo a moderar.

Ah, esqueci de dizer: este código funciona no Windows Powershell!

Até mais!

Categorias dessa postagem: , ,

Incluindo outros arquivos com VBScript: ScriptControl e arquivos .WSF

Olá,

recentemente respondi uma dúvida interessante no Fórum do Technet Brasil. Um usuário perguntou se era possível incluir código de outro script em um script .VBS. Respondi inicialmente que sim, e mandei um código meu, que usei em um pseudo-sistema que criei para "emular" um perfil em um ambiente configurado com perfil móvel obrigatório.

O código que enviei está logo abaixo:


'para carregar seu vbs, apenas use essa funcao
sub load(strfile)   'strfile é a string com o nome do arquivo
  Set f = fso.OpenTextFile(strfile)
  constantes =   f.ReadAll
  f.close
  execute constantes
end sub


'rotina principal
load("z:\scripts\config\config.txt")

É simples. Eu criei a função load, que recebe um caminho de arquivo, abre, lê o conteúdo inteiro dele e o executa. Só isso. Aparentemente, deveria funcionar...

Depois de muito testar, descobri que eu estava errado. Eu não sabia que meu código não funcionava com qualquer tipo de instrução, uma vez que meu sistema usava somente definição de constantes, e não com execução de código propriamente dito, que era o que o usuário pediu.

Diante disso, me retratei e disse que a única saída era usar arquivos WSF, que nada mais são do que arquivos de script, mas em formato XML. Ele fornece algumas funcionalidades interessantes, mas como leva mais tempo pra escrever um XML do que um arquivo simples em VBScript, acabo por usar sempre a segunda opção. Veja mais informações sobre os arquivos WSF aqui.

Hoje, lendo artigos sobre Powershell, me deparei com um recurso interessante: o Script Control. Ele foi criado inicialmente para permitir que programadores adicionassem recursos de scripting nas suas aplicações. O que eu percebi é que ele pode ser usado tanto no Powershell para executar código VBScript diretamente quanto no próprio VBScript para importar arquivos .VBS. Curioso, não?

Veja mais informações nos dois links abaixo:

http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/inputbox.mspx

http://www.microsoft.com/mind/0799/script/script.asp

Respondendo à pergunta do Fórum: é possível sim, e de uma forma rápida!

Até mais!

Categorias dessa postagem: , ,

Livro gratuito sobre Powershell

Aqui vai uma ótima dica pra quem está afim de aprender mais sobre a próxima geração da linha de comando no Windows

Trata-se de um livro que foi traduzido para o Inglês e publicado gratuitamente na internet. Não li ainda, mas recomendo.

Recentemente, li dois livros sobre o Windows Powershell. O primeiro deles, chamado Monad (O'Reilly), e o segundo, do Lee Holmes, outro MVP. Ambos muito bons, com um destaque para o segundo, que é mais prático. O primeiro tem mais conceitos, bons exemplos, mas foi lançado antes do Powershell, quando ele ainda se chamava Monad.

Futuramente, vou escrever meu livro sobre Powershell... em português.

Até mais!

Categorias dessa postagem: ,

Powershell on Linux?

Olá

Depois de algum tempo sem escrever nada, voltei. E com uma notícia curiosa: nasceu um projeto para fazer algo parecido com o que o Powershell faz, mas no Linux: libmsgque

Não creio que seja impossível... mas tem um ponto que eu gostaria de comentar: O Linux já possui várias ferramentas para administração via linha de comando, com várias ferramentas boas (e várias com versões Win32!). O problema é a falta de integração entre elas, o que foi resolvido no Powershell com o uso da orientação a objetos diretamente no Shell. Dá pra fazer igual, mas vai levar bastante trabalho se o Linux-Powershell não usar nenhum framework por baixo, como o .Net ou mesmo as classes do Java, Python ou Ruby.

Bom, assim que uma versão final for lançada, vou testar. Interoperabilidade é tudo!

Até mais!

Categorias dessa postagem: ,

Arquivos com WMI e CIM_DataFile: Como apagar arquivos em outro computador com 3 linhas de código

Aqui vai uma forma super simples de procurar um arquivo em um computador remoto e apagá-lo. Isso mostra como o WMI é flexível e pode resolver problemas rápidos do dia-a-dia de qualquer administrador:

pc = "webserver"
Set refFile = GetObject("winMgmts://" & pc  & "/CIM_DataFile.Name='k:\BOOTEX.LOG'")
refFile.delete

Basta salvar como VBS e trocar a variável pc. Simples, não?

Obviamente, esse é só um exemplo... a idéia seria colocar isso dentro de um If pra testar se o arquivo existe, um loop pra executar em vários computadores, um log de erros/atividades... mas essa parte é fácil.

Até mais!

Vinicius

Categorias dessa postagem:

Como executar programas em outro computador

Olá,

Este post tem um assunto que eu me interesso bastante. Como executar comandos em outro computador?

Uma das primeiras coisas que eu aprendi quando comecei a estudar scripting foi essa... na época, usando somente o Windows Script Host.

Executar um programa remotamente pode servir para várias coisas... desde instalação de software, atualização de antivirus ou mesmo execução de um script que não suporta ser executado remotamente: você copia ele para a outra máquina e faz com que ele seja executado localmente.

Existem várias formas de se fazer isso... e as mais recomendadas, ao menos sob o meu ponto de vista, é a execução remota via WMI e usando o utilitário PSExec (da Sysinternals, freeware). Costumo usar mais a primeira, que existe em todos os computadores com WMI instalado (leia-se W2k ou superior).

O problema de ambos é o mesmo: não dá pra criar processos interativos. Todos rodam sob as credenciais do usuário que roda o script (ou em outra caso seja especificado no script), mas em segundo plano. A saída então é apelar para um truque, postado pelos Scripting Guys na coluna Hey, Scripting Guy: usar tarefas agendadas para fazer isso. Veja o link:

http://www.microsoft.com/technet/scriptcenter/resources/qanda/sept05/hey0906.mspx

Esse post teve origem em uma discussão interessante no fórum do Technet Brasil. Um dos colaboradores no fórum fez uma pergunta, nós do fórum acabamos demorando para responder, ele perguntou novamente e eu interpretei erroneamente que ele estava cobrando a gente... o que não é muito interessante quando se trata de um trabalho voluntário como o nosso. No fim das contas, conheci outro moderador, imagino que tenha resolvido a dúvida dele e aprendemos os dois um pouco mais sobre scripting, WMI e como iniciar processos (e apresentações do PowerPoint) remotamente.

Abraços à todos,

 

Vinicius Canto

Categorias dessa postagem:

Variáveis de Ambiente: detalhe importante

Acabo deresponder uma pergunta no fórum interessantee, sobre variáveis de ambiente. Naquele caso, o usuário queria criar uma variável de ambiente e rodar um programa que usa ela, mas o programa só pegava o valor correto na segunda execução.

Não encontrei nada documentado até agora, mas testes que eu fiz com o script abaixo, que serve justamente para criar variáveis de ambiente no computador, não grava a variável até ser terminado. O script em si é o mesmo que o Laerte criou, mas com um sleep no meio do caminho para atrasar a execução do script. Veja:

Set ObjShell = wscript.createobject("wscript.shell")
Set oEnv = ObjShell.Environment("User")
oEnv("variavel")= "valor da variavel"
Wscript.sleep 1000*10
ObjShell.Run "notepad"

Se você executar, vai ver que, se abrir as propriedades do Meu Computador e procurar pela variável de ambiente, não vai encontrar ela até que o notepad seja aberto e o script termine.

A saída então, nesse caso, foi sugerir criar dois scripts: um com o código principal, e outro que serve somente para gravar a variável de ambiente necessária.

Ao menos, é o que eu posso ajudar até agora... vou checar isso

 

Até mais,

Vinicius Canto

Categorias dessa postagem: