Há pouco mais de 1 ano atrás, precisei mover as configurações do servidor de DHCP para um outro box. O backup/restore da interface gráfica tem um problema: Não salva a lista de Reservas.
Pesquisando na net, encontrei esse artigo e meu problema foi solucionado.
quarta-feira, 21 de novembro de 2012
quarta-feira, 14 de novembro de 2012
Criando regras no Outlook via PowerShell
Para preparar este post, usei como referência os seguintes artigos:
http://blogs.technet.com/b/heyscriptingguy/archive/2009/12/16/hey-scripting-guy-december-16-2009.aspx
http://dandarache.wordpress.com/2011/07/25/using-powershell-to-create-rules-in-outlook/
Recentemente, o Administrador de Redes aqui da empresa implementou um novo recurso anti-spam no Servidor de Correio Eletrônico onde o mesmo acrescenta uma tag [SPAM] no início do assunto do e-mail. Ele então me perguntou se havia a possibilidade de criar uma regra no Outlook para mover as mensagens com essa tag para a pasta Lixo Eletrônico.
Só para constar: não trabalhamos com a solução Exchange e nossos usuários utilizam arquivos .PST armazenados localmente em suas estações de trabalho.
Após pesquisar alguns sites, cheguei aos dois acima citados e criei um script em PowerShell que funcionou perfeitamente.
Segue o script:
Vale lembrar que o script não funciona com o Outlook 2003 e inferiores.
Espero que ele sirva a mais alguém assim como me serviu.
Até a próxima.
http://blogs.technet.com/b/heyscriptingguy/archive/2009/12/16/hey-scripting-guy-december-16-2009.aspx
http://dandarache.wordpress.com/2011/07/25/using-powershell-to-create-rules-in-outlook/
Recentemente, o Administrador de Redes aqui da empresa implementou um novo recurso anti-spam no Servidor de Correio Eletrônico onde o mesmo acrescenta uma tag [SPAM] no início do assunto do e-mail. Ele então me perguntou se havia a possibilidade de criar uma regra no Outlook para mover as mensagens com essa tag para a pasta Lixo Eletrônico.
Só para constar: não trabalhamos com a solução Exchange e nossos usuários utilizam arquivos .PST armazenados localmente em suas estações de trabalho.
Após pesquisar alguns sites, cheguei aos dois acima citados e criei um script em PowerShell que funcionou perfeitamente.
Segue o script:
Vale lembrar que o script não funciona com o Outlook 2003 e inferiores.
Espero que ele sirva a mais alguém assim como me serviu.
Até a próxima.
quinta-feira, 12 de julho de 2012
Função genérica para abertura de formulários WinForm
Hoje enquanto me dedicava ao meu projeto (codenome) Ingrid, comecei a desenvolver uma aplicação Windows Form e me deparei com uma situação:
Verificar se um determinado formulário já está aberto ou não. Se estiver, não abra outro novo, apenas selecione-o.
O código para este tipo de verificação é bem simples, mas acaba se tornado bem complexo se você escreve-lo para cada formulário que precisar verificar. Foi então que, após algumas queimas de neurônios, crei uma função genérica que resolve meu problema em apenas uma linha de codificação.
Segue o código da função:
Para abrir/selecionar o formulário, basta a seguinte linha de código:
BÔNUS:
Que tal fechar todos os formulários abertos de uma só vez?
Até a próxima.
Verificar se um determinado formulário já está aberto ou não. Se estiver, não abra outro novo, apenas selecione-o.
O código para este tipo de verificação é bem simples, mas acaba se tornado bem complexo se você escreve-lo para cada formulário que precisar verificar. Foi então que, após algumas queimas de neurônios, crei uma função genérica que resolve meu problema em apenas uma linha de codificação.
Segue o código da função:
BÔNUS:
Que tal fechar todos os formulários abertos de uma só vez?
Até a próxima.
segunda-feira, 28 de maio de 2012
Criando Fonte de Dados através de Diretivas de Grupo
O Caso:
Aqui na empresa utilizamos uma aplicação de terceiros que necessita de uma Fonte de Dados ODBC para configurar a conexão com o banco de dados SQL Server. A princípio, esta configuração era feita manualmente em todos os computadores que utilizavam tal aplicação. Com isso, a cada formatação destes computadores, era necessário a recriação dessa Fonte de Dados.
A Proposta:
Resolvemos utilizar o recurso de Preferências da Diretiva de Grupo (GPP) para automatizar o processo de criação desta Fonte de Dados e reduzir uma atividade da Equipe de Suporte de Campo.
O Problema:
Após criada a GPO, observamos que a mesma não estava sendo aplicada nos computadores alvo. Ao pesquisar o Visualizador de Eventos, encontramos um evento de Aplicativo de ID 4098 com a seguinte descrição:
A Pesquisa:
Após pesquisarmos sobre o código de erro descrito no evento, descobrimos que o Windows possui um "bug" na criação desta GPO: É acrescido um parâmetro a mais no arquivo .XML desta diretiva que causa este erro.
A Solução:
É preciso editar o arquivo manualmente e excluir o parâmetro a mais. Para encontrá-lo é fácil:
Até a próxima.
Aqui na empresa utilizamos uma aplicação de terceiros que necessita de uma Fonte de Dados ODBC para configurar a conexão com o banco de dados SQL Server. A princípio, esta configuração era feita manualmente em todos os computadores que utilizavam tal aplicação. Com isso, a cada formatação destes computadores, era necessário a recriação dessa Fonte de Dados.
A Proposta:
Resolvemos utilizar o recurso de Preferências da Diretiva de Grupo (GPP) para automatizar o processo de criação desta Fonte de Dados e reduzir uma atividade da Equipe de Suporte de Campo.
O Problema:
Após criada a GPO, observamos que a mesma não estava sendo aplicada nos computadores alvo. Ao pesquisar o Visualizador de Eventos, encontramos um evento de Aplicativo de ID 4098 com a seguinte descrição:
O item de preferência usuário 'AplicacaoTerceiro' do objeto de Diretiva de Grupo 'ODBC Aplicacao {CC2F3937-17G8-37F5-C4G1-AABD1013645Z}' não foi aplicado porque falhou com o código de erro: '0x80070057 Parâmetro incorreto.' Esse erro foi suprimido.
A Pesquisa:
Após pesquisarmos sobre o código de erro descrito no evento, descobrimos que o Windows possui um "bug" na criação desta GPO: É acrescido um parâmetro a mais no arquivo .XML desta diretiva que causa este erro.
A Solução:
É preciso editar o arquivo manualmente e excluir o parâmetro a mais. Para encontrá-lo é fácil:
- Acesse a pasta SYSVOL de algum Controlador de Domínio;
- Acesse a pasta [FQDN Domain]\Policies;
- Acesse a pasta da Diretiva do ODBC (para saber qual é a Diretiva correta, basta olhar na descrição do evento, que neste caso, é a pasta {CC2F3937-17G8-37F5-C4G1-AABD1013645Z});
- Acesse a pasta User\Preferences\DataSources (vale lembrar que criamos uma Fonte de Dados de Usuário. Se fosse de Sistema, seria a pasta Machine ou invés da pasta User).
- Na pasta DataSources edite o arquivo DataSource.xml.
- Encontre o parâmetro cpassword="" e apague-o.
- Salve a alteração e pronto.
Até a próxima.
quinta-feira, 29 de março de 2012
Remote Desktop não permite o uso de credenciais salvas
Estava eu hoje criando uma série de atalhos para conexões de Remote Desktop para evitar ficar digitando a senha toda vez que acessava um servidor remotamente e quando fui testá-las recebi a seguinte mensagem:
"Your credentials did not work
Your system administrator does not allow the use of saved credentials to log on to the remote computer [ComputerName] because its identity is not fully verified. Please enter new credentials."
Para contornar essa situação, é preciso fazer um ajuste na política local do computador onde foram criados os atalhos:
"Your credentials did not work
Your system administrator does not allow the use of saved credentials to log on to the remote computer [ComputerName] because its identity is not fully verified. Please enter new credentials."
Para contornar essa situação, é preciso fazer um ajuste na política local do computador onde foram criados os atalhos:
- Abra a política de grupo local (Executar -> gpedit.msc)
- Navegue até Local Computer Policy\Computer Configuration\Administrative Templates\System\Credentials Delegation
- Edite a configuração Allow Delegating Saved Credentials with NTLM-only Server Authentication
- Marque a opção Enabled, clique no botão Show e na janela Show Contents inclua o seguinte valor: TERMSRV/*
- Clique no botão OK para confirmar e fechar todas as janelas.
terça-feira, 7 de fevereiro de 2012
AD Info
Estou compartilhando com vocês uma pequena aplicação que desenvolvi que extrai algumas informações do Active Directory.
Link para download: ADInfo
Vale lembrar que é preciso ter o .NET 4.0 instalado no computador cliente e o usuário precisa ser Administrador do Domínio (óbvio ^^).
Espero que gostem e comentem!
Link para download: ADInfo
Vale lembrar que é preciso ter o .NET 4.0 instalado no computador cliente e o usuário precisa ser Administrador do Domínio (óbvio ^^).
Espero que gostem e comentem!
terça-feira, 31 de janeiro de 2012
O MDT em números: Caso de Sucesso
Há algum tempo atrás escrevi um artigo sobre o MDT (link).
Aproveitei o período de férias coletivas da empresa para atualizar as imagens do Windows utilizadas pelo MDT e, no embalo, resolvi avaliar o tempo gasto para o deploy utilizando os dois processos: manual e MDT.
Antes de apresentar os números, deixe-me mostrar o ambiente que utilizei:
O Computador
Intel Core 2 Duo E4700 2.6 GHz
2 GB RAM
HD 160 GB SATA 7200 RPM
Rede 100 Mbps
Sistemas Operacionais
Windows XP Professional x86
Windows 7 Enterprise x64
Tarefas
No processo manual
No processo manual, tentei representar um deploy utilizando a maneira antiga de se fazer: CD/DVD de instalação, softwares básicos instalados a partir de um servidor local e atualizações do Windows puxadas da Internet.
No processo MDT, utilizei a integração WDS + MDT + WSUS para o deploy. O WDS cuidando do boot via rede (PXE boot), eliminando assim o uso do CD/DVD. O MDT responsável pela aplicação da imagem, ingresso automático ao domínio e instalação dos softwares básicos. E o WSUS para aplicar as atualizações posteriores a Janeiro de 2012.
Enfim, os números
Vamos ao que interessa:
Windows XP Professional x86
No processo manual, o deploy demorou aproximadamente 3:38:00 (três horas e trinta e oito minutos). Neste período, o técnico precisou interagir com o computador por cerca de 26:00 (vinte e seis minutos).
No processo MDT, o deploy demorou aproximadamente 36:00 (trinta e seis minutos). Neste período, o técnico precisou interagir com o computador por cerca de 3:00 (três minutos).
Windows 7 Enterprise x64
No processo manual, o deploy demorou aproximadamente 3:10:00 (três horas e dez minutos). Neste período, o técnico precisou interagir com o computador por cerca de 20:00 (vinte minutos).
No processo MDT, o deploy demorou aproximadamente 43:00 (quarenta e três minutos). Neste período, o técnico precisou interagir com o computador por cerca de 3:00 (três minutos).
No processo manual, o tempo de interação do técnico está distribuído no tempo de deploy, ou seja, assim que o computador encerra uma tarefa, o técnico precisa disparar a outra.
Já no processo MDT, o tempo de interação do técnico ocorre somente no início do processo. O restante do tempo o computador opera de forma autônoma.
Conclusão
Creio que os números falam por si só. Redução de cerca de 80% no processo de deploy com pouquíssima interação do técnico.
Aproveitei o período de férias coletivas da empresa para atualizar as imagens do Windows utilizadas pelo MDT e, no embalo, resolvi avaliar o tempo gasto para o deploy utilizando os dois processos: manual e MDT.
Antes de apresentar os números, deixe-me mostrar o ambiente que utilizei:
O Computador
Intel Core 2 Duo E4700 2.6 GHz
2 GB RAM
HD 160 GB SATA 7200 RPM
Rede 100 Mbps
Sistemas Operacionais
Windows XP Professional x86
Windows 7 Enterprise x64
Tarefas
- Instalar o Sistema Operacional
- Ingressar no domínio
- Instalar softwares básicos
- Office
- Compactador de Arquivos
- Leitor de PDF
- Antivírus
- Atualizar o Windows (Windows Update)
No processo manual
- Foi utilizado um CD/DVD para instalar o Windows (O Service Pack já estava embutido no CD/DVD: SP3 para WinXP e SP1 para Win7).
- Os softwares básicos foram instalados a partir de um servidor local que hospeda tais softwares.
- A atualização do Windows foi feita a partir do site na Internet.
- Foi utilizada uma imagem com as atualizações até Janeiro de 2012 aplicadas.
- Os softwares básicos foram instalados a partir do mesmo servidor local.
- A atualização do Windows foi feita a partir de um servidor WSUS local (Como o Windows já estava atualizado, o que sobrou para ser atualizado foi o Office).
No processo manual, tentei representar um deploy utilizando a maneira antiga de se fazer: CD/DVD de instalação, softwares básicos instalados a partir de um servidor local e atualizações do Windows puxadas da Internet.
No processo MDT, utilizei a integração WDS + MDT + WSUS para o deploy. O WDS cuidando do boot via rede (PXE boot), eliminando assim o uso do CD/DVD. O MDT responsável pela aplicação da imagem, ingresso automático ao domínio e instalação dos softwares básicos. E o WSUS para aplicar as atualizações posteriores a Janeiro de 2012.
Enfim, os números
Vamos ao que interessa:
Windows XP Professional x86
No processo manual, o deploy demorou aproximadamente 3:38:00 (três horas e trinta e oito minutos). Neste período, o técnico precisou interagir com o computador por cerca de 26:00 (vinte e seis minutos).
No processo MDT, o deploy demorou aproximadamente 36:00 (trinta e seis minutos). Neste período, o técnico precisou interagir com o computador por cerca de 3:00 (três minutos).
Windows 7 Enterprise x64
No processo manual, o deploy demorou aproximadamente 3:10:00 (três horas e dez minutos). Neste período, o técnico precisou interagir com o computador por cerca de 20:00 (vinte minutos).
No processo MDT, o deploy demorou aproximadamente 43:00 (quarenta e três minutos). Neste período, o técnico precisou interagir com o computador por cerca de 3:00 (três minutos).
| Windows XP Professional x86 | Processo Manual | Processo MDT | Redução |
| Tempo de Deploy | 3:38:00 | 36:00 | 83% |
| Interação do Técnico | 26:00 | 3:00 | 88% |
| Windows 7 Enterprise x64 | Processo Manual | Processo MDT | Redução |
| Tempo de Deploy | 3:10:00 | 43:00 | 77% |
| Interação do Técnico | 20:00 | 3:00 | 85% |
No processo manual, o tempo de interação do técnico está distribuído no tempo de deploy, ou seja, assim que o computador encerra uma tarefa, o técnico precisa disparar a outra.
Já no processo MDT, o tempo de interação do técnico ocorre somente no início do processo. O restante do tempo o computador opera de forma autônoma.
Conclusão
Creio que os números falam por si só. Redução de cerca de 80% no processo de deploy com pouquíssima interação do técnico.
Assinar:
Postagens (Atom)