Aqui vai um link bacana de como conseguir elevar a execução de um script VBS via Shell.Application. Isso pode fazer seu script voltar a funcionar no Vista e 7.

http://www.winhelponline.com/articles/185/1/VBScripts-and-UAC-elevation.html

Normalmente eles falham ou por causa do redirecionamento de pastas automático ou por falta de permissões em pastas do sistema. Quem já passou pelo problema de rodar scripts de logon no Vista/Windows 7 vai gostar desse link, mas esta não é a saída. Se seu script de logon falha por falta de permissões, muito provavelmente você está tentando fazer alguma coisa errada lá (e que não deveria estar num script de logon)

Até a próxima!

Olá,

acabei de responder uma pergunta capisciosa no forum sobre o método RegWrite. O usuário queria criar um valor no registro com um backslash (também conhecido como barra invertida: \  )  no nome.

Resposta rápida: não dá. Não com o RegWrite. Saídas rápidas: Classe StdRegProv do WMI, PowerShell, escrever um .REG e executar silenciosamente.

Triste, mas não tem como mesmo. Limitação documentada do RegWrite no artigo http://support.microsoft.com/default.aspx/kb/281309

A razão é simples: o próprio RegWrite usa a \ para separar chaves no registro. Bastava considerar duas barras seguidas como escape, mas isso não foi feito. =(

Até a próxima!

Olá,

frequentemente eu recebo problemas por email para responder. Eu prometo responder na medida do possível (sempre que sobra um tempo, afinal de contas, isso é suporte gratuito =), e quase que sempre eu atraso, com uma ou duas semanas de diferença… mas procuro responder dúvidas das pessoas, mesmo no meu email pessoal.

Para resolver esse problema, estou criando um sistema para envio de dúvidas. Isso vai desafogar meu email (afinal de contas, é um email pessoal =) e agilizar o processo de resposta. Fica mais fácil pra selecionar as melhores dúvidas e colocar aqui. Além disso, é melhor pras próprias pessoas que perguntam, já que elas vão poder verificar nas dúvidas das outras pessoas. Meu blog vai ser reformulado logo logo… aguardem!

Alguns dias atrás recebi a seguinte dúvida:

Oi vinicius, blz

Vc ja me ajudou antes, em várias situações, mais estou aqui novamente te pedindo ajuda..

To precisando de um script vbs, que gere o numero de copias de uma determinada impressora.

Encontrei este script,

' Monitor Print Job Status
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colPrintJobs =  objWMIService.ExecQuery _
    ("Select * from Win32_PrintJob")

Wscript.Echo "Print Queue, Job ID, Owner, Total Pages"

For Each objPrintJob in colPrintJobs
    strPrinter = Split(objPrintJob.Name,",",-1,1)
    Wscript.Echo strPrinter(0) & ", " & _
        objPrintJob.JobID & ", " &  objPrintJob.Owner & ", " _
            & objPrintJob.TotalPages
Next

No entanto o mesmo informa o total de paginas, mas preciso do numero de copias.

ex. um documeto com 6 paginas ele informa.
mas se mandar emprimir 2 copias deste determinado documento ele não informa (ex. 12)

deste ja agradeço
<nome>

O problema me intrigou um bocado. Gostei disso e fui atrás para ajudar o cara. Vejam minha conclusão:

Olá <nome>,

até onde eu vi (http://msdn.microsoft.com/en-us/library/aa394370(VS.85).aspx)  o WMI não possui nenhuma propriedade com o número de cópias. Por outro lado, faz até sentido: o subsistema de impressão do Windows não deve ter controle sobre cópias, já que o que chega pra ele são somente jobs. Tudo que ele sabe é quantas folhas são, de onde veio, pra onde vai, e quantas foram impressas... o conteúdo fica a cargo da aplicação.

Em resumo: a princípio, do ponto de vista do SO, não dá... quem deve ter controle sobre o número de cópias é o programa que pede pra imprimir um documento.

[]s,

Vinicius

Obrigado pela dúvida e até a próxima!

Essa dica vai para todos que estão começando com scripting.

Sempre que encontrar um problema aparentemente inexplicável em um script qualquer, verifique se não há nenhum On Error Resume Next no começo ou no meio do script, antes da rotina que pode estar dando problema.

Pra quem não sabe, o On Error Resume Next é uma instrução que faz com que o VBScript ignore erros e apenas continue na linha seguinte. Ele é muito útil em scripts que possuem tratamento de erros, mas pode esconder problemas no script caso não seja usado com cuidado.

Até a próxima!

Olá,

Aqui vão alguns scripts úteis quando for necessário trocar uma senha para uma conta em um domínio. Três lugares que devem ser checados antes de trocar uma senha (note que não são os únicos) são:

1. Tarefas agendadas (normalmente o backup é feito aqui)
2. Serviços
3. Application Pools do IIS e usuários usados em acesso anônimo

Se alguma tarefa, serviço ou Application Pool estiver rodando com a conta que você precisa alterar a senha, ele com certeza vai deixar de funcionar na próxima vez que for iniciado ou quando precisar de um recurso que precise de autenticação.

Para facilitar na localização destas contas, sugiro um comando e um script:

Localizar todos os serviços e contas que estão sendo usadas neles.

wmic /node:localhost service get displayname, startname

ou no PowerShell:

gwmi win32_service –computerName estacao_ou_ip | sort startname | ft name, startname

Para listar os Application Pools e as contas usadas por eles, use o seguinte script em VBScript. Basta salvar com extensão .VBS e executar. Ele aceita o nome do computador remoto como parâmetro (opcional).

if WScript.Arguments.Count > 0 then
   strComputer= WScript.Arguments(0)
else
   strComputer = "."
end if
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
set colAppPools = objWMI.ExecQuery("Select * from IISApplicationPoolSetting")
for each app in colAppPools
   wscript.echo "AppPoolName: " & app.Name
   wscript.echo "AppPoolUser: " & app.WAMUserName
   wscript.echo
next

As contas usadas para acesso anônimo no IIS também devem ser verificadas:

if WScript.Arguments.Count > 0 then
   strComputer= WScript.Arguments(0)
else
   strComputer = "."
end if
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")

set objDic = CreateObject("Scripting.Dictionary")
set websites = objWMI.ExecQuery("Select * from IISWebServerSetting")
for each website in websites
    objDic.Add right(website.name, len(website.name) - instrrev(website.name,"/")), website.servercomment
next

set colAppPools = objWMI.ExecQuery("Select * from IISWebDirectorySetting")
for each app in colAppPools
    print_obj app
next

set colAppPools = objWMI.ExecQuery("Select * from IISWebVirtualDirSetting")
for each app in colAppPools
    print_obj app
next

sub print_obj(app)
    ini = instr(app.name,"/")
    fim = instr(ini+1, app.name, "/")
    tag = mid(app.name, ini+1, fim-ini-1)
    wscript.echo "SiteName: " & objdic.item(tag)
    wscript.echo "Fullname: " & app.name
    wscript.echo "AppPoolUser: " & app.AnonymousUserName
    wscript.echo
end sub

Não é possível obter contas de usuário usadas em tarefas agendadas usando WMI/at (rodam com conta localsystem) ou pelo schtasks. Essa verificação deve ser manual, abrindo as propriedades de cada uma das tarefas que aparecem na interface (http://www.microsoft.com/technet/scriptcenter/guide/sas_man_lpja.mspx?mfr=true e http://www.microsoft.com/technet/scriptcenter/resources/qanda/sept04/hey0922.mspx). As coisas só mudam no Windows Vista e 2008.

Ah, a troca da senha também pode ser feita via script, claro =). Mas isso é só procurar aqui mesmo no site que já tem pronto.

[]s,

Vinicius Canto

Olá,

esta é engraçada: um simples script em VBS "salva" usuários de computadores HP.

Agora a versão verdadeira: o Service Pack 3 do Windows XP, recém lançado, causou um problema em determinados computadores da HP. O problema é uma incompatibilidade entre um driver e o service pack, provavelmente por falha no código do driver, que fazia com que o micro reiniciasse constantemente.

Um ex-funcionário da MS entrou em cena e lançou, antes da MS e da HP, um "patch" para "corrigir" o problema: um script que usa o VBScript e Windows Script Host que verifica se o computador possui um processador AMD, se possui um driver, e questiona o que o usuário quer fazer, desabilitar ou não o driver.

Mais em http://www.computerweekly.com/Articles/2008/05/19/230735/hp-xp-sp3-users-offered-unofficial-patch-to-solve-reboot.htm

Até mais!

Olá,

nos últimos dias recebi uma dúvida por e-mail muito interessante: como logar as atividades de logon e logoff dos usuário?

A resposta é simples: não precisa. O Windows já possui recursos suficientes para fazer isso nativamente. Basta ativar as diretivas de auditoria de logon e tudo vai pro log de eventos. O trabalho todo então é só centralizar tudo isso e analisar depois. Você pode até criar um script para isso ou usar o LogParser.

Se você não gostou ainda ou não tem muita experiência com log de eventos do Windows, pode criar uma coisa mais simples, usando scripts de logon e logoff. O problema, nesse caso, é a perda de perfomance e os riscos inerentes do uso desta técnica. Você vai entender melhor a seguir.

Nos dois links abaixo, você pode ver uma discussão sobre esse assunto e um link para o site do Robert Mueller, MVP, que apresenta um script em VBScript que escreve hora e local de logon dos usuários em arquivos texto simples.

http://www.tutorials-win.com/ActiveDirectory/monitor-users/

e

http://www.rlmueller.net/Logon5.htm

Note que, no primeiro link, o próprio Robert explica uma terceira alternativa, usando o campo LastLogon que fica no AD. O único problema desse campo é que ele não é replicado para outros servidores, e fica armazenado somente no servidor em que o usuário efetuou logon.

Ok, mas qual o problema de usar um arquivo texto para guardar esse tipo de informação? Segurança. No meu ponto de vista, esta é uma solução simples, para ser utilizada somente em situações pequenas que não necessitam um controle muito rígido dessas informações. Digo isso por uma questão lógica: como é o script de logon que escreve no arquivo TXT e script de logon roda no contexto do usuário logado, podemos concluir que o usuário precisa ter direito de escrita no arquivo. Nem que seja somente Append (adicionar dados no final do arquivo), mas ele tem que ter permissão. Isso abre possibilidade para um usuário mais esperto atacar o sistema de duas formas: 1 - inundando o log com entradas inválidas; 2 - criando entradas inválidas para outros usuários, sem que eles tenham logado no sistema. Tudo bem que existe a diretiva de auditoria de acesso aos objetos, mas ainda assim prefiro a primeira alternativa.

 

Espero ter esclarecido mais um pouco sobre o assunto e até a próxima!

Olá,

vou escrever agora sobre uma dúvida que ocorre com frequência entre profissionais de TI ao administrar servidores e estações: dado um problema, qual a ferramenta mais indicada: o prompt de comandos (COMMAND.COM e CMD.EXE) e os scripts feitos em BAT e CMD ou as ferramentas de script mais recentes, o Windows Script Host e os scripts .VBS e .JS?

A resposta, como sempre, não é imediata: depende. E é sobre isso que eu vou escrever.

A idéia principal é tentar identificar no script se vai ser necessário, em sua maioria, executar outros comandos ou processar dados (usando variáveis e outras tecnologias como o WMI e ADSI, por exemplo). Em um arquivo CMD ou BAT simples, é muito mais simples executar um comando e analisar a saída dele, uma vez que para fazer isso basta digitar a linha de comando num arquivo texto, da mesma forma que você digitaria na linha de comando. Num arquivo VBS ou JS são necessários outros passos adicionais para executar um comando, mas é muito mais simples de se fazer algum processamento com variáveis, como por exemplo, trocar todos os caracteres _ por - em uma string.

Esse tipo de desvantagem não existe no PowerShell. Scripts .PS1 aceitam tanto comandos simples em uma linha quanto possuem recursos avançados de linguagens de programação para manipulação de dados. Isso faz dele uma ferramenta completa.

Caso ainda seja necessário criar scripts multiplataforma ou caso você queira aprender uma única linguagem para utilizar em scripts para Windows e Linux, recomendo estudar a linguagem Ruby. Ela é poderosa e ao mesmo tempo possui uma sintaxe simples, que permite um fácil aprendizado mesmo para quem não domina técnicas de programação.

Espero ter ajudado!

Até logo,

Vinicius

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!

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

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!

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.

• Managing Exchange 2003 with WMI, Part 1
• Managing Exchange 2003 with WMI, Part 2
• Managing Exchange 2003 with WMI, Part 3

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

Mais um post rápido: Descobri como desabilitar o aviso de segurança do XP SP2 (ou seria SP1?) durante a execução de um script neste artigo. O problema é interessante... imagine que um dos seus scripts precisa fazer o download de um programa e em seguida, executá-lo. O XP interrompe o script e mostra uma mensagem perguntando se você quer realmente fazer isso, uma vez que o editor não foi localizado e este é um arquivo "potencialmente perigoso". Daí você dá um Ok e tudo continua... Parece babaca, mas se você tiver um script que faz vários downloads (eu tenho um que faz vários deles), você vai ter que dar Ok em todos, o que torna o trabalho extremamente chato. Pra resolver isso, você só precisa setar uma variável de ambiente que desabilita a checagem: Em VBScript:

set oShell= CreateObject("Wscript.Shell")
set oEnv = oShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1

Pronto, agora tudo funciona novamente! []s, Vinicius Canto

Aqui segue uma das minhas obras primas. Trata-se de um script (WSH + VBScript) que fica rodando em background, monitorando quando alguém insere um dispositivo de armazenamento USB. Quando o usuário insere o dispositivo, o sistema envia um email pro administrador.
Útil, não?

Basta salvar em um arquivo texto com extensão .VBS e rodar. Cuidado com as quebras de linha...

'USB Storage Monitor
'
'Vinicius Canto
'MVP Visual Developer - Scripting
'
'Grupo PET Computagco - Universidade de Sco Paulo - Brasil

'Disabling error messages...
On Error Resume Next


'Main routine
strComputer = "."
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colMonitoredEvents = objWMIService.ExecNotificationQuery("SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE Targetinstance ISA 'Win32_PNPEntity' and TargetInstance.DeviceId like '%USBStor%'")
Do
Set objLatestEvent = colMonitoredEvents.NextEvent
Notifier(objLatestEvent.TargetInstance)
Loop

Sub Notifier(object)
Set objNet = CreateObject("Wscript.Network")

'You can change the function below to perform other actions
SendMailWithoutSSL _
"admin@network.com", _
"USB storage detected on " & objNet.Computername, _
"machine@network.com", _
"The user " & objNet.Username & " connected an USB Storage device on computer.", _
"smtp.network.com", _
25, _
"user", _
"pass"
End Sub




' CDOSYS official documentation:
' http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_cdo_queue_top.asp
'
' by Vinicius Canto
Sub SendMailWithoutSSL(strDestination, strTitle, strFrom, strMessage, strSMTP, intPort, strUsername, strPassword)
set oMessage = CreateObject("CDO.Message")
set oConf = CreateObject("CDO.Configuration")
Set oFields = oConf.Fields



oFields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = strSMTP
oFields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = intPort
oFields.Item("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate") = 1 'cdoBasic: Auth with user and password sent with plain text
oFields.Item("http://schemas.microsoft.com/cdo/configuration/sendusername") = strUsername
oFields.Item("http://schemas.microsoft.com/cdo/configuration/sendpassword") = strPassword
oFields.Item("http://schemas.microsoft.com/cdo/configuration/Smtpusessl") = false
oFields.Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2 '1: Using local SMTP; 2: Using port; 3: Using Exchange
oFields.Update

oMessage.Fields.Item("urn:schemas:mailheader:to") = strDestination
oMessage.Fields.Item("urn:schemas:mailheader:from") = strFrom
oMessage.Fields.Item("urn:schemas:mailheader:sender") = strFrom 'reply-to
oMessage.Fields.Item("urn:schemas:mailheader:subject")= strTitle
oMessage.Fields.Item("urn:schemas:mailheader:x-mailer") = "Vinicius Small Mail System -- by Vinicius Canto "
oMessage.Fields.Update

oMessage.Configuration = oConf

oMessage.TextBody = strMessage
oMessage.Send
End Sub

Esse daí eu fiz a pedido de um amigo meu, Sérgio Dias, MVP e Analista Consultor na área de Segurança da Informação. Aliás, aqui vai o link pro blog dele, que necessita urgentemente de uma atualização: =)
http://msmvps.com/blogs/sdias

O mais legal disso tudo é que não existe nada parecido no mundo ainda. Vou mandar pra tudo quanto é lugar agora... ScriptCenter, Knowledge Base, etc...

Aproveitem...!