Olá Pessoal,
sei que o blog está meio de lado ultimamente, mas acredito ser por uma boa causa…e num futuro, não muito longe, vocês saberão os motivos..
Quero começar esse blog dizendo: SCCM é complicado…
acho que essa é a primeira vez que digo isso desde que o SCCM 2007 foi lançado, mas eu não digo isso por que ele é complicado, mas porque muitos acham isso, mas sem ao menos usar com frequencia…
Então, a frase correta é: SCCM é complicado…se você não sabe o que está fazendo…
Quero aqui compartilhar com vocês o que tenho visto em diversos clientes…
Muitas vezes, vou em um cliente para fazer algo vinculado ao SCCM (como Migração de SO) e me deparo com alguns ambientes:
1- SCCM foi instalado por outra consultoria
2- SCCM foi instalado por uma pessoa que já saiu da empresa
3- SCCM foi instalado por alguem que ainda está na empresa
4- SCCM foi instalado pela empresa em que trabalho (essa é a parte que menos me preocupo, pois conheço a qualidade das pessoas que trabalham aqui comigo, ou que trabalharam, e sei que a empresa possui uma qualidade muito grande, alem de entregar uma vasta documentacao para o cliente)
Antes de fazer qualquer coisa, eu sempre procuro validar a saúde do SCCM, só não faço isso quando o cliente faz por conta própria ou confirma que o SCCM está funcionando. Nesse caso, se ocorrer algum problema durante o meu trabalho relacionado com algo que deveria estar funcionando, o cliente tem que arcar com as consequencias (sei que não é facil dizer para ele, mas é minha obrigação)
Você pode estar se perguntando, mas como faço a verificação da saúde. Óbvio que uso o SCCM HealthCheck Toolkit (http://www.dotnetwork.com.br/pt-br/sccmhealthcheck.aspx).
Depois que as providencias iniciais foram tomadas (validação da saúde e qualquer remediação necessária), eu começo o trabalho e após algumas horas ou dias, sempre pergunto pro cliente, porque foi feito assim?
Impressionante como quase todos os clientes nunca sabem a resposta, a documentação não existe ou está incompleta (óbvio, com exeção da empresa em que trabalho 
)
No meu cliente atual, no primeiro dia perguntei porque eles tinham tantos sites secundários e a resposta foi: não sabemos, a empresa que instalou fez assim. Olhando a documentação tinha uma explicação simples e ao analisarmos a fundo, descobrimos que tinham respondido um questionario, mas muitas das perguntas nem sabiam pra que servia.
Passei um dia então explicando e explicando e no final eles notaram que não precisavam ter 21 sites secundarios, utilização de Distribution Points era o suficiente para eles
Entretanto, ontem, comecei a trabalhar com a parte de OSD e notei diversas coisas interessantes:
1- Não instalaram nenhum hotfix pós-SP2
2- Fizeram diversas alterações no Editor de Task Sequence
3- fizeram a integração com o MDT 2010 Update 01
4- Criaram diversos pacotes do MDT usando o MDT 2010 (copiaram de algum lugar, já que a integração era com o MDT 2010 Update 01)
4- Criaram algumas TS “demo” usando os scripts do MDT 2010
5- Não Instalaram o R2 em todos os sites secundarios (só estou colocando aqui para vocês terem uma idea já que o projeto era para ser com R2, antes de iniciarmos o trabalho fiz o Upgrade pro R3 em todos os servidores, já que o cliente possui licença)
6- As task sequences que migram os dados do usuário estavam salvando os dados do usuario, mas não instalaram o State Migration Point e não estavam usando hardlink
7- A opção de continuar se falhar a captura do profile estava habilitada..(e era o que o cliente iria começar a usar no piloto…ainda bem que cheguei antes disso )…
8- O Backup não estava habilitado, mesmo estando na documentação que iria ser feito
bom..o que quero dizer aqui…
1- se vc for contratado para um projeto, faça apenas o que esta planejado, não fique enchendo de linguiça pois você pode se queimar
2- faça o que vc falou que iria fazer e esta no projeto, não deixe de fazer algo que iria fazer
3- documente se estiver no escopo do projeto, e se for documentar, faça bem feito. Quando eu falo em documentação, tenha a documentação de como instalar e configurar tudo, caso o cliente necessite no futuro
4- precisou fazer algum troubleshooting imprevisto? então documente pois o cliente pode precisar daquela informação num futuro
5- Não comece instalando, faça um projeto e confirme com o cliente pois o projeto é dele e não seu…
bom..acho que é isso por agora…:)
English
Português
Loading ...