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

Dica para quem usa constantemente um grupo de redes (wifi no trabalho e em casa por exemplo) e não quer usar o recurso de profiles do Vista e Windows 2008 para configurar a rede:

WMIC NICCONFIG WHERE Index=1 CALL EnableStatic ("10.0.0.2"),("255.0.0.0")

WMIC NICCONFIG WHERE Index=1 CALL SetGateways ("10.0.0.8","10.0.0.9"),(1,2)

WMIC NICCONFIG WHERE Index=1 CALL EnableDHCP

Se quiser saber um valor válido para o parâmetro Index, basta digitar WMIC NICCONFIG GET INDEX,CAPTION sem parâmetros.

As mesmas linhas acima funcionam para configurar a rede remotamente. Basta colocar o parâmetro /NODE:nome_ou_ip_do_computador logo após o comando WMIC.

Estes comandos funcionam no CMD e PowerShell, bem como arquivos .bat, .cmd e .ps1. Dá pra colocar também em VBS com algumas modificações.

Abraço pessoal,

Vinicius

Olá,

uma das coisas que eu vou começar a escrever aqui no blog é sobre exames beta. Pra quem não sabe, uma prova beta é uma prova que ainda está sendo testada. Ela pode ser feita gratuitamente, e, caso você seja aprovado, ganhará a certificação da prova oficial correspondente (70-xxx).

Aqui vai a primeira (ou segunda, se considerarmos que eu esqueci de avisar sobre a primeira prova beta que eu fiz), sobre SQL Server 2008. A prova 71-432 TS: MS SQL Server 2008, Implementation and Maintenance, continuará valendo até o final de Julho. O código para registro gratuito no site da Prometric é 943F6.

Fonte: http://www.kodyaz.com/blogs/software_development_blog/archive/2008/07/02/2896.aspx

Pontos cobrados na prova: ttp://www.microsoft.com/learning/en/us/exams/70-432.mspx

Até mais!

Olá pessoal,

estou aqui hoje para agradecer. Agradecer à todo mundo, sejam os leitores do blog, pessoas que contribuem com dúvidas interessantes para que eu escreva aqui, meus amigos que contribuem com idéias, minha família e todos que direta ou indiretamente participam de alguma forma do meu mundo. Obrigado! Foi com a ajuda de vocês que eu continuei ajudando pessoas nos fóruns, listas de emails, grupos de discussão, e, pelo terceiro ano consecutivo, fui premiado pelo programa MVP da Microsoft.

Para quem não conhece o que significa ser um MVP, aqui vai um link muito legal: http://www.microsoft.com/brasil/mvp/overview.mspx

Até logo! E nesse novo ciclo, prometo atualizar o layout do blog, tornar a busca de informações aqui mais fácil e ainda colocar tags de uma forma mais coerente.

 

Vinicius

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!

Dica rápida para quem precisa aplicar um arquivo .REG sem que seja pedida confirmação ao usuário:

 

REGEDIT /S C:\teste\teste.reg

 

Até mais!

Olá,

esta é mais uma das mensagens que eu tento passar em quase todas as vezes que falo em palestras, webcasts, ou conversas com amigos mesmo. Trata-se da necessidade (note o negrito, é de propósito) de se utilizar o Windows como usuário comum, e não como administrador. E mais: corrigir as aplicações problemáticas ao invés de executá-las com credenciais de administrador.

O problema, como já expliquei em outro post, é bem simples: segurança. Se você utilizar o computador como um administrador, qualquer erro cometido (abrir um anexo suspeito vindo por MSN ou e-mail, por exemplo) pode e vai afetar todo o computador. Com um usuário simples, o máximo que um vírus pode fazer é infectar o usuário logado e danificar seus arquivos (na prática, todos que o usuário tem permissão de alteração, incluindo o registro). Somente os seus, sem danificar o computador ou outros usuários. Isso não é 100% seguro, mas diminui bastante o impacto de uma eventual infecção por vírus, além de aumentar as chances de recuperação dos arquivos (já que nenhum executável protegido será alterado).

Bom, mas o que há de novo? Wes Miller, gerente de produto sênior da CoreTrace (além de ex gerente de produto da Winternals Software e da Microsoft), escreveu um ótimo artigo na Technet Magazine deste mês. A matéria, na íntegra, pode ser lida aqui.

E ele é tão categórico quanto eu. Veja um trecho do texto dele abaixo:

 

Why It Matters

So why should you care? Because we, as IT professionals, should begin forcing applications to adjust to least-privileged users, instead of vice versa where applications assume the interactive user owns the system.

Unfortunately, the same policies that allow administrators to write to registry keys also grant any malware run in their user context full access to anything they have not been explicitly denied via access control lists (ACLs). In the world of UNIX, people follow the rule regarding not running as root (the functional equivalent of the Windows Administrator account), mostly because the ecosystem of software that pushes the boundaries of the security model is tiny to nonexistent.

Still, the best thing you can do is to follow that same wisdom and only run as an administrator when it is explicitly required—or better yet, only run individual applications as an administrator. By doing so, you raise that intra-system firewall I mentioned earlier. Then, when malware or spyware attempts to do something it shouldn't, it fails—because it can't write to the registry or file system locations it needs in order to really infect your system (such as installing a service or driver, or installing for all users). In addition, doing so allows anti-malware software to contain malware that it recognizes, without risking the entire system first.

 

Bom, se vocês não acreditaram em mim no primeiro post, acho que este é bem mais convincente =).

Um abraço e até logo!

Olá,

a Microsoft disponibilizou recentemente o segundo CTP (Community Technology Preview) do PowerShell 2.0. Ele já pode ser baixado no link abaixo:

http://www.microsoft.com/downloads/details.aspx?FamilyID=60deac2b-975b-41e6-9fa0-c2fd6aa6bc89&displaylang=en

Já dá pra ver funcionando (e bem) algumas das novidades do v2. Na minha opinião, o destaque fica pro PowerShell Remoting, que permite trabalhar com outros computadores no PowerShell, e pros novos cmdlets para trabalhar com Active Directory.

Pra quem assitiu meu webcast sobre PowerShell e Active Directory, aqui está a surpresa. Eu já estava testando o CTP2 alguns dias atrás, mas não podia divulgar as novidades... mas está aí: agora é possível trabalhar ainda mais facilmente com Active Directory no PowerShell.

A lista completa do que foi alterado pode ser encontrado no link abaixo:

http://blogs.msdn.com/powershell/archive/2007/11/06/what-s-new-in-ctp-of-powershell-2-0.aspx

Até logo!

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á,

faz tempo heim? Faz realmente bastante tempo que eu não escrevo por aqui. O motivo principal foi o aumento na carga de trabalho do Vinicius (agora estou trabalhando pra valer, fazendo estágio em uma grande empresa de tecnologia em SP) e falta de computador mesmo. Tive de ressucitar meu desktop e voltar a trabalhar nele.

Para me redimir, vou começar a postar aqui algumas das dúvidas mais legais que encontrei (e tentei responder) no fórum.

http://forums.microsoft.com/Technet-BR/ShowPost.aspx?PostID=3150152&SiteID=29&mode=1

Esta não tem diretamente a ver com script, mas é, no mínimo, curiosa. Esses dias, uma pessoa perguntou sobre como sincronizar um site FTP com uma pasta no disco local. O usuário disse que já tinha um script que fazia isso com duas pastas, mas precisava "adaptar" pra trabalhar com FTP. Eis que eu encontrei o seguinte link, que resolve o problema dele aparentemente, e sem modificar o script atual:

http://windowsitpro.com/article/articleid/14486/how-can-i-map-to-an-ftp-server-as-a-drive.html

Vale lembrar que, dessa forma, nem do script ele precisa. Xcopy ou Robocopy já fazem isso.

Até a próxima!

Olá,

estou aqui hoje para escrever como resolver um problema não muito comum, mas curioso: como eu faço para apagar um mesmo arquivo (ou o conteúdo de uma pasta inteira) em vários computadores ao mesmo tempo?

Pois bem, se você tiver a lista com o nome dos computadores a serem buscados, você pode usar o seguinte comando no Windows PowerShell:

cat lista.txt | foreach { rm "\\$_\c$\caminho\da\pasta\arquivo.txt" -force }

ou ainda:

cat lista.txt | foreach { rm "\\$_\c$\caminho\da\pasta\*" -force }

ou pelo IP:

2..254 | foreach { rm "\\192.168.0.$_\c$\pasta\arquivo.txt"}

Bom, espero ter ajudado a compreender um pouco como e quando usar o PowerShell para resolver alguns problemas.

Até a próxima!

Olá,

entendo que este não é nem de longe o lugar ideal pra comentar uma notícia dessas, mas pretendo compensar com um post bem interessante sobre Scripting.

Estou escrevendo este post para divulgar um link de um video muito legal do Channel9. Trata-se de uma palestra da Microsoft na Universidade de Illinois para alunos de Ciência da Computação. No video, Eric Traut, engenheiro Microsoft, fala bastante sobre virtualização, tendências e mostra diversas versões do Windows em VMs. O que chamou a atenção no mundo afora foi o fato dele mostrar o MinWin rodando. Várias pessoas chegaram a falar que esse era o Windows 7, mas até onde eu li sobre o MinWin, não tem nada definido ainda. Tem vários outros videos sobre o MinWin e a arquitetura dele no Channel9.

Quem me conhece um pouco sabe do meu "lado negro", que gosta bastante de programação, teoria de sistemas operacionais, C, C++ e Assembly. Coisas que eu aprendi a gostar depois de fazer faculdade e uma disciplina de Sistemas Operacionais II com vários trabalhos...

http://www.acm.uiuc.edu/conference/2007/video/UIUC-ACM-RP07-Traut.wmv

Até logo!

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á,

encontrei um link muito bom revirando meus bookmarks. Na verdade procurava outra coisa, mas acabei clicando no link para ver o que era e encontrei uma pérola: um artigo do Greg Stemp, um dos Scripting Guys (os de verdade, que trabalha na MS e cuida do ScriptCenter) falando sobre como estender o WMI criando suas próprias classes.

http://msdn2.microsoft.com/en-us/library/ms974554.aspx

Não é nada de outro mundo e o exemplo que ele dá para criar uma classe que monitora programas instalados observando uma chave no registro é muito legal. Recomendo para quem já está bom em VBScript e Windows Script Host e quer avançar um pouco mais.

Até logo!

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