Boa notícia para quem gosta de Ruby (eu, por exemplo) e de desenvolvimento web com Rails.

http://yehudakatz.com/2008/12/23/rails-and-merb-merge/

[]s,

Vinicius

Olá,

só por curiosidade: a linguagem Ruby trata automaticamente a conversão de números inteiros normais para uma estrutura de dados de números grandes (big numbers, números que são representados como strings, vetores ou outras estruturas por não "caber" em estruturas comuns).

Precisei calcular 2 ^ 20000, e a linguagem Ruby foi a que resolveu o problema mais rápido. Já tinha ela instalada, não precisei importar/carregar nenhuma biblioteca extra para fazer a conta.

E o resultado é gigante. Veja:

2**20000 = 398… (muitos números)… 376. Pra ser mais preciso, é um número com nada mais nada menos que 6021 dígitos.

Tentei no PowerShell (C#, .Net) e mesmo no R, mas ambos não conseguem fazer a conta nativamente, e retornam +Infinito. Até onde eu sei, .Net não possui mesmo uma biblioteca nativa para cálculos com números grandes. Talvez o R tenha, mas ela deveria ser importada antes do cálculo. Com o Ruby foi simples: resultado = 2**20000.

Até a próxima!

Vejam a seguinte discussão que aconteceu no fórum de Scripts Administrativos do Technet Brasil e trata de uma necessidade do usuário ao trazer informações dos mailboxes dos usuários do Exchange. Gostei muito da dúvida e da resposta. Não foi muito eficiente, mas tá valendo (seria melhor bolar um mecanismo de preferência O(1), como um enum, hash ou vetor para trazer as frases corretas no lugar dos números). Mas serve como exemplo sobre como criar funções para serem usadas no pipeline de processamento do PowerShell.

Thiago Rox:

Olá Pessoal,

Estou rodando um comando simples no PowerShell apenas para trazer as informações das mailboxes dos usuários:

Get-WmiObject -Class Exchange_Mailbox -Namespace ROOT\MicrosoftExchangev2 -ComputerName $computer | select-object MailboxDisplayName,StorageGroupName,TotalItems,Size,StorageLimitInfo | Sort-Object -Descending -Property StorageLimitInfo

Após a execução eu converto para um arquivo HTML.

O problema é que o objeto StorageLimitInfo me tras esses resultados (1,2,4,8,16), que é relacionado ao limite de armazenamento das mailboxes. A pergunta é, como faço para substituir esses valores por uma string relacionado o número pelo status da mailbox?. Ex. Ao invés do resultado 1 escrever BelowLimit

Vinicius Canto:

Olá,

você pode criar uma função:

function parseStatusCode([int] $v) {
if($v -eq 1) {return 'BelowLimit'} ;
.
.
.
}

e depois usar ela no select:

Get-WmiObject -Class Exchange_Mailbox -Namespace ROOT\MicrosoftExchangev2 -ComputerName $computer | select-object MailboxDisplayName,StorageGroupName,TotalItems,Size, @{Name='Status'; Expression{parseStatusCode($_.StorageLimitInfo)}} | Sort-Object -Descending -Property Status

Thiago Rox:

Obrigado, funcionou certinho. Parabéns.

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!

Quem já me viu definindo a sintaxe do Windows PowerShell provavelmente já me ouviu falar “PowerShell é igualzinho C#, mas sem classes”.

Pois bem. Eu estava errado. Eu já sabia que era possível criar assemblies manualmente e importar no PowerShell dinamicamente, mas o que eu não sabia é que ele já suporta isso nativamente, sem precisar compilar absolutamente nada. Isso tudo graças ao comando Add-Type, que cria classes dinamicamente para que você possa usar depois normalmente com o comando new-object.

Vejam um trecho do que o comando get-help add-type –detailed retorna:

NAME
    Add-Type
SYNOPSIS
    Adds a .NET type (a class) to a Windows PowerShell session.
DETAILED DESCRIPTION
    The Add-Type cmdlet lets you define a .NET class in your Windows PowerShell session. You can th
    en instantiate objects (by using the New-Object cmdlet) and use the objects, just as you would
    use any .NET object.  If you add an Add-Type command to your Windows PowerShell profile, the cl
    ass will be available in all Windows PowerShell sessions.
    You can specify the type by specifying an existing assembly or source code files, or you can sp
    ecify source code in line or saved in a variable. You can even specify only a method and Add-Ty
    pe will define and generate the class. You can use this feature to make Platform Invoke (P/Invo
    ke) calls to unmanaged functions in Windows PowerShell. If you specify source code, Add-Type co
    mpiles the specified source code and generates an in-memory assembly that contains the new .NET
     types.
    You can use the parameters of Add-Type to specify an alternate language and compiler (CSharp is
     the default), compiler options, assembly dependencies, the class namespace, and the names of t
    he type and the resulting assembly.

    -------------------------- EXAMPLE 1 --------------------------
    C:\PS>$source = @"
    public class BasicTest
    {
        public static int Add(int a, int b)
        {
            return (a + b);
        }
        public int Multiply(int a, int b)
        {
            return (a * b);
        }
    }
    "@
    C:\PS> Add-Type -TypeDefinition $source
    C:\PS> [BasicTest]::Add(4, 3)
    C:\PS> $basicTestObject = New-Object BasicTest
    C:\PS> $basicTestObject.Multiply(5, 2)
    These commands adds the BasicTest class to the session by specifying source code that is stored
     in a variable. The type has a static method called Add and a non-static method called Multiply
    .
    The first command stores the source code for the class in the $source variable.
    The second command uses the Add-Type cmdlet to add the class to the session. Because it is usin
    g inline source code, the command uses the TypeDefinition parameter to specify the code in the
    $source variable.
    The remaining commands use the new class.
    The third command calls the Add static method of the BasicTest class. It uses the double-colon
    characters (::) to specify a static member of the class.
    The fourth command uses the New-Object cmdlet to instantiate an instance of the BasicTest class
    . It saves the new object in the $basicTestObject variable.
    The fifth command uses the Multiply method of $basicTestObject.
    -------------------------- EXAMPLE 2 --------------------------
    C:\PS>[BasicTest] | get-member
    C:\PS> [BasicTest] | get-member -static
    C:\PS> $basicTestObject | get-member
    C:\PS> [BasicTest] | get-member
       TypeName: System.RuntimeType
    Name                           MemberType Definition
    ----                           ---------- ----------
    Clone                          Method     System.Object Clone()
    Equals                         Method     System.Boolean Equals
    FindInterfaces                 Method     System.Type[] FindInt
    ...
    C:\PS> [BasicTest] | get-member -static
       TypeName: BasicTest
    Name            MemberType Definition
    ----            ---------- ----------
    Add             Method     static System.Int32 Add(Int32 a, Int32 b)
    Equals          Method     static System.Boolean Equals(Object objA,
    ReferenceEquals Method     static System.Boolean ReferenceEquals(Obj
    C:\PS> $basicTestObject | get-member
       TypeName: BasicTest
    Name        MemberType Definition
    ----        ---------- ----------
    Equals      Method     System.Boolean Equals(Object obj)
    GetHashCode Method     System.Int32 GetHashCode()
    GetType     Method     System.Type GetType()
    Multiply    Method     System.Int32 Multiply(Int32 a, Int32 b)
    ToString    Method     System.String ToString()
    Description
    -----------
    These commands use the Get-Member cmdlet to examine the objects that the Add-Type and New-Objec
    t cmdlets created in the previous example.
    The first command uses the Get-Member cmdlet to get the type and members of the BasicTest class
     that Add-Type added to the session. The Get-Member command reveals that it is a System.Runtime
    Type object, which is derived from the System.Object class.
    The second command uses the Static parameter of Get-Member to get the static properties and met
    hods of the BasicTest class. The output shows that the Add method is included.
    The third command uses Get-Member to get the members of the object stored in the $BasicTestObje
    ct variable. This was the object instance that was created by using the New-Object cmdlet with
    the $BasicType class.
    The output reveals that $basicTestObject is an instance of the BasicTest class and that it incl
    udes a member called Multiply.

Enfim... acho melhor definir o PowerShell hoje como um shell interativo de C#, da mesma forma que o Ruby tem o IRB.

Até a próxima!

Olá,

esta foi uma dúvida de um grande amigo meu, que perguntou o seguinte: como eu posso apagar contas de computadores no Active Directory com base em uma lista em um arquivo TXT?

Vamos por partes. Primeiro, monte o arquivo lista.txt como aparece abaixo. Basta colocar os nomes das contas, um abaixo do outro.

_moss_db_vk
_moss_db_vk_teste
_moss_db_vk_teste2

A seguir, crie um arquivo deletar.bat com o seguinte comando:

dsquery user –name %1 | dsrm –q –c –noprompt

Nota: o – que aparece é um hífen, e não um travessão. Cuidado com Ctrl+C e Ctrl+V. E mais: no meu exemplo estou apagando contas de usuário. Mais informações em dsquery /? e dsrm /?

Pronto. Agora basta colocar tudo na mesma pasta e executar o comando a seguir:

for /f %i in ('type lista.txt') do @deletar.bat %i

Nota: se for colocar o comando acima em um arquivo .bat também, substitua %i por %%i.

É claro que esta não é a solução mais rápida. Seria mais interessante trabalhar com enumeração ou conectar aos objetos diretamente usando ADSI (VBScript ou PowerShell, tanto faz). A solução que eu apresentei é um modo rápido no estilo mais quick’n’dirty que existe, e não deve ser utilizado com milhares de contas. Modifique o script ainda para exibir as contas que serão apagadas, para facilitar a localização de eventuais erros (lembrem-se que é o AD isso, não uma máquina virtual qualquer). Isso é só um exemplo, pessoal.

Vão com calma, testem e adaptem pras suas necessidades. Espero não ter que escrever amanhã mesmo sobre como recuperar contas apagadas no AD. =)

Um abraço,

Vinicius

Olá,

depois de muito tempo sem sescrever, resolvi ressucitar meu blog. Peço desculpas e vou mandar, logo de cara, 3 dos ítens que eu coloquei na minha lista de “coisas importantes que precisam ser salvas no blog”.

A primeira delas vai agora. Essa dúvida me chegou por email, e achei curioso porque resolvi um problema similar no serviço meses atrás.

Suponha que você tem um diretório com nomes de arquivo corrompidos. Você só sabe que todos eles são arquivos .png, mas as extensões foram trocadas para nomes aleatórios. Você gostaria então de renomear tudo para .png, de uma vez só.

Usando Windows PowerShell

dir | % {ren $_ ($_.name.substring(0, $_.name.length-4) + '.png' ) }

O primeiro comando, dir, obtém uma lista de arquivos do diretório atual e passa objetos (não texto!) para o próximo comando no pipeline. O próximo então (o % significa foreach-object) executa o bloco (entre { e } ) para cada um dos ítens. Nesse caso, o comando rename passando o nome ($_) e o nome novo ($_.name.substring(0, $_.name.length-4) + '.png' )

Até a próxima!

Olá,

recentemente vi um script submetido ao ScriptCenter que lista os tipos de arquivos existentes em uma determinada pasta.

Este pode ser um recurso muito útil para auditorias, por exemplo. Vejam como é mais simples fazer usando PowerShell:

1. Primeiro, liste os arquivos com o comando DIR (get-childItem, ls, gci, etc.)
2. Agrupar por extensão
3. Ordenar por quantidade

Veja o resultado:

dir c:\teste –recurse | group {$_.extension} | sort count

Até logo!

 

Vinicius

Olá,

vou escrever hoje sobre um problema que me fez trabalhar duas horas a mais ontem testando uma solução caseira.

Um cliente da empresa que trabalho teve um problema e, de uma hora para outra, boa parte das contas do AD teve sua senha expirada. O problema foi simples: alguém configurou por acidente a política de troca de senhas de 90 dias (padrao da empresa) para 30 dias.

Resolver o problema foi fácil. Difícil foi a lógica.

Eu simplesmente abri o AD Explorer e fui caçar a propriedade no objeto dos usuários no AD que eu deveria alterar. Simplesmente não encontrei nenhuma.

O que isso quer dizer? Na prática, não fica no usuário a propriedade que diz se a senha do usuário expirou ou não. A única data relevante que fica armazenada é a data da troca da senha pela última vez (pwdLastSet). O Windows então faz a conta, no momento do logon, para descobrir se o usuário deve ou não trocar a senha naquele instante. Sendo assim, não seria necessário alterar usuário algum, muito menos fazer script para varrer o AD e definir alguma propriedade novamente.

Sendo assim, fiz alguns testes e comprovei minha tese. O único problema que pode ocorrer é o DC demorar demais para puxar novamente a política padrão do domínio, mas é altamente aceitável esse lag.

Isso remonta a seguinte história:

Um navio carregado de ouro, revestido de todo o cuidado e segurança
atravessava o oceano quando, de repente, o motor enguiçou".
Imediatamente, o comandante mandou chamar o técnico do porto mais próximo.
O técnico chegou de helicóptero e trabalhou durante uma semana, porém sem
resultados concretos.
Chamaram então o melhor engenheiro naval do país.
O engenheiro trabalhou três dias inteiros, sem descanso, mas nada
conseguiu.
O navio continuava enguiçado.
A empresa proprietária do navio mandou, então, buscar o maior especialista
do mundo naquele tipo de motor.
Ele chegou, olhou detidamente a casa das máquinas, escutou o barulho do
vapor, apalpou a tubulação e, abrindo a sua valise, retirou um pequeno
martelo.
Deu uma martelada em uma válvula vermelha (que estava emperrada) e guardou o martelo de volta na valise.
Mandou ligar o motor e este funcionou perfeitamente na primeira tentativa.
Dias depois, chegaram às contas ao escritório da empresa de navegação.
Por uma semana de trabalho, o técnico cobrou US$ 700.
O engenheiro naval cobrou, por três dias de trabalho, US$ 900.
Já o especialista, por sua vez, cobrou US$ 10,000.00 pelo serviço.
Atônito com esta última conta, o Diretor Financeiro da empresa enviou um
telegrama ao especialista, perguntando:
"Como você chegou a esse valor de US$ 10,000.00, por cerca de 1 minuto de
trabalho e uma única martelada?".
O especialista, então, enviou as seguintes especificações, no cálculo dos
seus honorários profissionais à empresa :
- Por dar uma martelada........................................ US$ 1.00
- Por saber exatamente onde bater o martelo....... US$ 9.999,00
O que vale, na prática, não é dar a martelada, mas saber onde bater o
martelo.
A martelada você pode até delegar para outro...

Ok, não sou um especialista a ponto de resolver em um minuto o problema… mas a análise toda, incluindo formulação, labs e produção levou apenas duas horas.

Outro dia coloco aqui como eu faria se precisasse de script para isso.

Links:

http://live.sysinternals.com/adexplorer.exe

http://scyllamazzillo.multiply.com/market/item/5

PS: havia sim a possibilidade de todos os campos pwdLastSet dos usuários terem sido alterados propositalmente ou via script, mas não era esse o caso. Se fosse, eu teria que obrigatoriamente usar um script para consertar ou um dsquery | dsmod.

Até logo!

Olá,

estarei apresentando no dia 3 de Outubro um webcast no Technet Brasil sobre as novidades do Vista, novas ferramentas de linha de comando e, mais especificamente, sobre WinRM. Tudo isso como parte da Semana Windows Vista. Fiquei muito feliz por ser convidado mais uma vez, principalmente por poder participar junto com outros feras como Fábio Hara, Julio Battisti e Wesley Fernandes. =)

Link:

http://www.microsoft.com/brasil/technet/eventos/webcasts/windows_vista/default.mspx

Até mais!

Olá,

felizmente, este ano não vou publicar nenhum script para modificar o timezone do Windows para se adaptar ao horário de verão definido no Brasil.

O motivo é simples: a Microsoft resolveu facilitar e vai distribuir esta alteração como um update no Windows Update. Dessa forma, fica bem mais fácil gerenciar (usando WSUS, SMS e SCCM, além de scripts como o simples WMIC QFE por exemplo) nas redes que máquinas estão com o patch aplicado ou não. Ainda mais: empresas podem aplicar isso por GPO, fazendo com que somente algumas filiais recebam o patch (excluindo Amazonas e alguns estados do nordeste, por exemplo).

Segue o link com o patch e maiores instruções:

http://www.microsoft.com/brasil/windows/products/windowsvista/verao.mspx

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

Primeiro, recomendo a leitura do link abaixo. Ao menos vale a pena pra ter uma idéia do que eu vou comentar.

http://www.gossamer-threads.com/lists/python/python/612630

No link acima, há uma discussão sobre qual tecnologia seria interessante aprender. O criador da thread cita também um link que mostra os comentários de um DBA que fez um comparativo. Você pode ver essa comparação no link abaixo:

http://www.simple-talk.com/sql/database-administration/comparing-python-and-powershell-dba-scripting-/

A comparação em si até é legal... para aprender. Tem vários exemplos de como automatizar tarefas com PowerShell e Python.

Agora vamos ao que eu acho disso tudo. Primeiramente, queria deixar bem claro que gosto tanto de Python quanto de PowerShell. São duas ferramentas fantásticas. Gosto muito também de VBScript, JScript, Ruby... até o bom e velho CMD/BAT tem me ajudado bastante ultimamente. São todas ferramentas muito boas, com algumas deficiências, claro... cada uma na sua.

O bom profissioanal de TI, seja ele desenvolvedor ou profissional da área de infraestrutura, deve ter bons fundamentos. E na minha opinião, com bons fundamentos ele é capaz de se virar com qualquer tecnologia. Eu bato na tecla que, por mais que as tecnologias sejam importantes e seja indispensável que você domine algumas delas, sem a base teórica e bons fundamentos sobre computação, você terá muito mais dificuldades para continuar se atualizando. E atualização de conhecimento na nossa área é obrigatório!

Vamos à um exemplo prático: pensem na estrutura de decisão if-then-else. Parece algo básico demais, mas algumas pessoas realmente não entendem direito como montar uma e como encadear várias delas. Essa estrutura é indispensável para desenvolvedores, seja qual for a linguagem. E se a linguagem não tiver esse recurso (sim, existem linguagens que não tem IFs), você pode construir o seu. Para qualquer profissional de TI, compreender uma rotina if-then-else pode ajudar a determinar mais rápido as causas de um problema em um computador, por exemplo. É questão de lógica.

Bom, voltemos ao PowerShell x Python. Não creio que seja possível determinar uma tecnologia melhor. Ambas tem suas vantagens. Python é uma linguagem de programação completa, orientada à objetos, com um conjunto de classes padrõ bem rico e de funcionamento simples. PowerShell é um shell orientado à objetos, que trabalha extensivamente com a combinação de pequenos comandos (cmdlets) através de pipes, variáveis e outros recursos, com o objetivo de facilitar a administração de servidores. Não faz sentido comparar diretamente as duas coisas.

No exemplo do link que eu enviei, o autor compara as duas quanto à capacidade de automação de tarefas administrativas de servidores de bases de dados. Mas ambas possuem recursos que permitem administrar um SQL Server, por exemplo. O que podemos usar como parâmetro para comparar e descobrir qual é melhor? Número de linhas? Eu acredito que não. Eu creio que a facilidade para criar um código dado um conjunto de recursos disponíveis (sejam eles classes ou cmdlets, nesse caso) é a melhor saída, mas medir a "facilidade" é algo subjetivo demais. E o gosto de cada um é influenciado pelo conhecimento que o profissional tem. Para mim, nenhuma das duas é melhor que a outra. Elas foram feitas com propósitos diferentes.

O que eu faço hoje: quando surge um problema, após a análise inicial, escolho se é realmente necessário resolver o problema com scripting e, nesse caso, qual linguagem utilizar. Parece bobeira, mas ultimamente eu tenho escolhido BAT e VBScript na maioria das vezes por precisar que um único script funcione com as configurações padrão do Windows 2000 ou superiores. E é exatamente isso que eu recomendo: aprendam a base, depois as tecnologias. Pense nelas como um leque de ferramentas que você pode escolher para resolver um problema. Escolha a melhor para cada situação.

PowerShell é bem legal... mas VBScript, JScript, C, C++, Python, Ruby, CMD, BAT, Java, C#/VB.Net e Perl também são. =)

No próximo post vou retornar com algumas dicas que eu tenho utilizado ultimamente nas minhas tarefas do dia-a-dia.

Até logo!

Olá,

para os que não estão convencidos ainda do que o PowerShell possibilita, aqui vai mais um exemplo curioso: como enviar mensagens para IM que usam o protocolo XMPP.

http://halr9000.com/article/455

Para quem não sabe, XMPP é um protocolo aberto para Instant Messengers. Em especial, este protocolo é usado pelo Google Talk e pelo Jabber.

Tudo bem, eu concordo: qual é a grande utilidade disso no dia a dia? Pequena... talvez algum script de backup que envie mensagens por IM para administradores, gatilhos anti-roubo de senha de admin local ou coisa do tipo... algum sistema de perguntas/respostas comuns em uma rede ou simplesmente um robô de suporte técnico =). Mas o que é interessante demonstrar é que o PowerShell é capaz de atender as mais diversas necessidades, justamente porque possui muitos recursos e é extremamente fácil de utilizar.

Na minha opinião, atualmente os usos mais interessantes do PowerShell estão entre desenvolvedores que o utilizam para automatizar procedimentos de compilação, montagem, testes unitários e de integração. Em português bem popular: dá pra fazer miséria com ele! Mas não fica só aí. Basta olhar no arquivo do meu blog =).

 

Abraços e até mais!