Olá,

esse é um dos posts não-técnicos com cara de técnicos. Li um post interessantíssimo do criador do PowerShell, Jeffrey Snover, sobre o que chamamos de débito técnico. Débito técnico é aquilo que você sabe que ficou faltando fazer no seu produto, release ou software, mas não fez porque não havia tempo, dinheiro, disposição ou porque precisava ser entregue mesmo.

Ele discute o uso de Drones e a captura de um deles pelo exército iraniano, e porque o débito técnico foi a razão dessa captura. Se tiver que escolher o que dá pra ser feito e o que fazer a coisa certa, escolha a segunda. Faça certo e não espere o problema acontecer.

Pra quem ficou curioso, leia o link abaixo. E se você não é o responsável pelas decisões no seu projeto, repasse para ele.

http://www.jsnover.com/blog/2011/12/18/iranian-drone-hack-and-technical-debt/

Até logo!\

O Windows Installer é o componente utilizado pela Microsoft e recomendado para a criação de instaladores para Windows. Ele é importante na remediação porque alguns dos problemas podem acontecer não por causa de uma aplicação incompatível, mas por um instalador que não funciona completamente.

A determinação do tipo de problema (instalação, tempo de execução) é uma das primeiras tarefas com uma aplicação, seja desktop seja web. O funcionamento do Windows Installer é importante para o diagnóstico, e saber obter informações sobre a instalação, mais importante ainda. Veja a seguir algumas dicas importantes:

Habilitando logs completos

Para poder gerar logs completos de todas as atividades envolvidas durante a instalação, você pode usar um parâmetro da linha de comando que torna possível controlar quais atividades e como elas serão gravadas em disco. O comando msiexec /? mostra todas as opções disponíveis, mas a /L acompanhada do caminho para o arquivo de log (que pode ser relativo) é a mais importante. No exemplo a seguir, o log é gerado com todas as informações (parametro *) e de maneira detalhada (parametro V).

msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"

É possível ainda, usando o parametro ! forçar com que cada linha seja gravada no log de maneira síncrona. Isso é especialmente útil nos casos em que a instalação e o msiexec são interrompidos de maneira abrupta, como uma falha na instalação que derrube o serviço do Windows Installer ou uma tela azul, por exemplo.

Habilitando logs de maneira global

Uma outra dica importante pode ser configurar o serviço do Windows Installer para gerar sempre logs no modo detalhado que foi descrito acima. A maneira mais simples de fazer isso é configurar a chave de registro Logging com o valor VoiceWarmup no registro.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Caso queira saber mais, consulte o link http://support.microsoft.com/kb/314852

Easter Egg Advice: VoiceWarmup são apenas duas palavras que podem ser geradas configurando todas as opções de log... Nada de mais :-)

Por se tratar de uma chave que pode ser controlada por meio de uma GPO, em alguns casos você pode ter de configurar as permissões desta chave para negar escrita a todos usuários, inclusive a conta LocalSystem, para impedir que a GPO volte a chave ao valor original. Se precisar automatizar, lembre-se do utilitário SubInAcl.

Interpretando e lendo logs do Windows Installer

E agora, com os logs, o que fazer?

Se você já tiver tabalhado antes com troubleshooting, apenas leia de trás para frente e procure informações que chamem a sua atenção. Seu bom senso vai ajudar mais que qualquer conselho.

Caso queira aprofundar ainda mais, sugiro a leitura do link a seguir, que contém várias informações sobre como interpretar as mensagens do log, categorias de mensagens, entre outros. Extremamente útil.

http://blogs.technet.com/b/richard_macdonald/archive/2007/04/02/how-to-interpret-windows-installer-logs.aspx

Enfim, por hoje é só. Vamos em breve continuar explicando problemas que podem ser resolvidos investigando MSIs e instalações com falha. Até a próxima!

Olá pessoal,

no TechED desse ano apresentei uma das palestras menores, de 30 minutos, focada apenas em demonstrações. Slide-less, se existe o termo.

Com espaço curto e a possibilidade de fazer apenas demonstrações, minha idéia foi mostrar um pouco de PowerShell (sim, mesmo com mais de 5 anos de vida, pouca gente ainda usa essa ferramenta fantástica) e também de como usar o shell para controlar aplicações na nuvem, fazer a publicação e instalação, bem como iniciar o serviço e alterar o número de instâncias.

Mesmo sem slides, fiz um pequeno resumo do que usei no dia para que quem assistiu possa treinar quando puder. Segue minha lista, copiada diretamente do meu OneNote:

 

Vinicius Canto Xavier @viniciuscanto no twitter

The Joel Test: 12 Steps to Better Code

1. Do you use source control?
1. Can you make a build in one step?
1. Do you make daily builds?
2. Do you have a bug database?
3. Do you fix bugs before writing new code?
4. Do you have an up-to-date schedule?
5. Do you have a spec?
6. Do programmers have quiet working conditions?
1. Do you use the best tools money can buy?
1. Do you have testers?
1. Do new candidates write code during their interview?
2. Do you do hallway usability testing?

Pasted from <http://www.joelonsoftware.com/articles/fog0000000043.html>

Windows Azure Platform PowerShell Cmdlets

http://wappowershell.codeplex.com

Ingredientes

• Azure SDK 1.4 ou superior e todos os pre-requisitos (IIS, etc)
• PowerShell 2.0 (parte do W7 e 2008R2 por padrão)
• ADO.NET Data Services Update for .NET 3.5 SP1
• Windows Identity Foundation Runtime
• Windows Identity Foundation SDK 4.0

Instalação

Módulo vs PSSnapin

Prefira módulo se não houver necessidade do PSSnapin

Makecert

.\makecert -r -pe -a sha1 -n "CN=VCX's Windows Azure Authentication Certificate" -ss My -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 c:\temp\testcert.cer

Comandos usados hoje

• Get-Command
• Get-Member
• Get-Help
• Foreach-Object
• Group
• Select
• Get-Module
• Install-Module
• Get-Command (de novo!)
• New-Deployment
• Get-HostedServices e Get-Deployment
• Move-Deployment (VIP Switch)
• Set-DeploymentConfiguration
• Set-DeploymentStatus

Alguns amigos de trabalho me deram mais algumas dicas após ler o post anterior. Filtrei algumas, especialmente aquelas que usavam executáveis para fazer o serviço… mas uma outra me pareceu bastante viável e mais decente que o CHOICE apresentado anteriormente. Basta criar o VBS a seguir

wscript.sleep 1000

e use no seu bat usando o comando cscript:

cscript.exe wait.vbs //nologo

simples, direto, e que não pode ser cancelado pelo usuário (a não ser por um CTRL+C).

Da série coisas que o Vinicius lembra de cabeça, mas que é bastante difícil encontrar na internet e podem ser úteis um dia:

@choice /T 10 /C yn /D y > null

Se você for salvo por essa dica um dia, comente aqui

…aparecem as lições que devemos aprender. Nos dois links a seguir, técnicos do SmugSmug e do Netflix discutem porque os sitemas deles estiveram entre os que não patinaram, capotaram ou sumiram de vez do ar com a última grande falha nos serviços cloud da Amazon.

Falhas acontecem. Dessa vez foi com a Amazon, mas qualquer um está sujeito ao problema que ocorreu com eles. E ao invés de criticar, melhor tentar entender como evitar isso no futuro do lado de cá. Quase todas as dicas se aplicam também para apps hospedadas em fornecedores de serviços, seja Microsoft, seja Google, seja lá o que for. O arquiteto que é responsável por projetar o sistema resiliente.

http://techblog.netflix.com/2011/04/lessons-netflix-learned-from-aws-outage.html

http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survived-the-amazonpocalypse/

Sejam inteligentes, e nunca testem a profundidade de um rio com os dois pés ao mesmo tempo. Cloud não conserta sistemas mal projetados . Também não é nenhuma bala de prata. É uma ótima ferramenta, mas não deve ser a única.

Oi pessoal,

hoje encontrei uma apresentação antiga do VelocityConf 2010, muito interessante tanto pra infra quanto pra devs. Exatamente do jeito que eu gosto .

A palestra trata de como o time de operações do Facebook trabalha. Pontos que achei interessante:

• O número de engenheiros/usuário e pessoas de operações/usuário é absurdamente pequeno. Eles realmente são eficientes nesse ponto. Talvez comparar com MS e Google não seja interessante, dado que os dados que ele usou possam estar errados… mas ainda assim o número é impressionante.
• De qualquer forma, a própria métrica de devs/usuários e itpros/usuários atendidos é bem legal… não conhecia o conceito. Deve ter vindo do ITIL.
  
• Implantação de mudanças muito bem organizado. E num ritmo frenético. Várias mudanças acontecendo ao mesmo tempo, de forma controlada. Bonus para o sistema de deployment distribuido usando BitTorrent internamente.
• O ritmo de alterações no ambiente é quase igual ao que vemos em alguns clientes, mas com um nível de maturidade muito, mas muito maior.
  
• Monitoramento feito da maneira correta. Vale como exemplo.

Bom, é isso. Espero que gostem.

 

Até logo!

Vinicius

Olá,

Encontrei uma série nova no Channel 9, uma chamada Defrag. Já tem uns 3 videos lá sobre troubleshooting, e um deles trata de troubleshooting do Windows Installer, Windows Update, e um mecanismo bem rápido pra decifrar códigos de erro do Windows no windbg (!error). Quem fala no vídeo é o Gov Maharaj, um cara bastante conhecido no mundo de Application Compatibility.

https://channel9.msdn.com/Shows/The-Defrag-Show/Defrag-003-Win7-Shutdown-Slowdowns-Prob-Step-Recorder-MSI-Failures

[]s,

Vinicius