Para enviar os e-mails basta preencher os campos do vbscript com os dados do seu ambiente. O script está comentado e é auto-explicativo. Basta alterar os dados, salvar e dar um duplo clique para enviar.
Conclusão
Esse documento mostra como enviar e-mails de uma lista pré-definida de forma simples e funcional utilizando vbscript e banco de dados MS Access.
BAIXE EM PDF
Autores:
Tiago Vieira Ferreira de Souza éidealizador do site Portal Tecnologia, atua desde 2004 como Administrador de Redes, com foco em tecnologias Microsot. Formado em Tecnologia em Redes de Computadores, MCP Windows Server 2003, MCTS Windows Vista.
Site: http://www.portaltecnologia.net/
E-mail: contato@tiagosouza.net
Marcelo Ramos Borges de OliveiraéMCP na plataforma .NET desde 2007, atua a aproximadamente 10 anos no mercado de TI. Atualmente é Gerente de TI em empresa de médio porte com foco em Desenvolvimento Web. Site: http://www.marceloramos.net/Blog
E-mail: mramos.oliveira@gmail.com
Se você tiver qualquer versão beta do SP2 instalada, desinstale-a antes da instalação
* Use o miniaplicativo “Programas e Recursos” do Painel de Controle e selecione “Exibir atualizações instaladas” na parte superior esquerda do painel de tarefas. Em Windows, procure KB94846
É necessário ter uma cópia original do Windows Server 2008 com SP1 ou Windows Vista com SP1 instalada no computador antes de instalar o SP2
* Windows Server 2008 lançado com o código do Service Pack 1 incluído
* O SP2 é o primeiro Service Pack pós-lançamento para o Windows Server 2008
Recomendações
Se “vLite” foi usado para personalizar sua instalação do Windows Vista, talvez você tenha removido componentes do sistema necessários que impedem a instalação do Service Pack 2. Consulte KB 968279 para obter detalhes adicionais antes de instalar o Service Pack 2.
As versões beta do Windows Server 2008 SP2/Windows Vista SP2 são softwares que funcionam por tempo limitado que devem operar até 1o de junho de 2010. Se você instalou versões beta do Windows Server 2008 SP2/Windows Vista SP2, é altamente recomendável que você as desinstale antes de 1o dejunho de 201.
Como impedir múltiplos logons em uma rede com Active Directory
Introdução
O processo que vamos descrever aborda como impedir que o usuário possa se logar em mais de uma estação de trabalho com o mesmo login de rede do domínio.
Não se trata do recurso do Active Directory (Fig1) onde podemos limitar o login a uma ou mais estações, pois nesse caso o bloqueio fica limitado a uma lista pré-definida de máquinas (Fig2). A grande desvantagem é que caso seja necessária a troca de máquinas, geraria trabalho manual para o administrador de rede, que teria que alterar a lista a cada vez que isso acontecesse.
Fig1 – Propriedade de Account do Active Directory
Fig2 – Lista com computadores
Esse documento tem como finalidade explicar como limitar mais de um login em qualquer máquina da rede de forma automática, não havendo necessidade de associar determinada máquina a um usuário específico. Para isso vamos utilizar o Active Directory, GPOs (Group Policiy Objects), Scripts de Logon e Logoff e banco de dados SQL Express.
Pré-requisitos
Active Directory com domínio previamente configurado
Estações Windows 2000 ou superior
SQL Express (ferramenta gratuita, podendo ser instalada no mesmo servidor que hospeda o Active Directory. Em nosso exemplo trabalhamos com a versão 2005)
GPMC (Group Policy Management Console – ferramenta gratuita para edição de políticas de grupo)
Scripts de Logon, Logoff e SQL
Para baixar os scripts de Logon, Logoff e SQL, clique no link abaixo. Os scripts estão comentados para facilitar o entendimento.
Nos scripts login.vbs e logoff.vbs, onde aparece a string de conexão com o banco de dados, será preciso trocar os *** pelos dados reais de seu ambiente.
Password = Senha do usuário configurado no campo User ID
Data Source = Nome do servidor ( Geralmente MAQUINA\SQLEXPRESS onde MAQUINA é o nome do servidor onde foi instalado o SQL Express )
Compartilhando os Scripts
Vamos trabalhar com dois vbscripts, um de Logon e outro de Logoff. Eles devem ficar em um local da rede que o usuário tenha acesso de execução, para isso sugerimos manter o padrão do Active Directory e utilizar o NETLOGON para esse fim.
Criação das GPOs
Vamos iniciar pela criação das GPOs com os scripts de Logon e Logoff. Para realizar este procedimento iremos utilizar o console de edição de políticas GPMC (Group Policy Management Console).
1 – Vamos abrir o GPMC para criarmos e editarmos nossa policie de scripts de logon e logoff. Clique em start > run > e digite “gpmc.msc” (sem as aspas)
2 – Vamos escolher em qual Unidade Organizacional vamos linkar a policy, clicamos com o botão direito em cima dela e selecionamos a opção “Create and Link a GPO Here…”
3 – Com o editor de policies aberto vamos expandir: User Configuration > Windows Settings > selecionar Scripts (Logon/Logoff)
4 – Vamos iniciar dando um duplo clique em Logon. A janela de configuração irá se abrir e vamos clicar em Add e passar o caminho do compartilhamento criado no NETLOGON, no nosso exemplo \\SC-0000001\NETLOGON\LogonUnico\Login.vbs
5 – Vamos agora abrir o Logoff e fazer o mesmo procedimento, só que agora buscando o script de logoff no mesmo compartilhamento \\SC-0000001\NETLOGON\LogonUnico\Logoff.vbs
6 – Pronto, a política já está criada. Podemos forçar sua execução com o comando “gpupdate /force”.
SQL Express
O controle dos usuários logados é feito através de um registro incluído no banco de dados assim que ele efetua o logon (login.vbs).
Será necessário:
- Instalar o SQL Express
- Criar um banco de dados e nomeá-lo como LOGON
- Criar a tabela USUARIOS ( LogonUnico.sql )
Banco e ferramentas de administração podem ser encontrados nos links abaixo:
O único problema encontrado foi nas sessões de terminal services. Quando há queda ou congelamento da sessão não é executado o logoff que por sua vez não limpa o registro do usuário na base.
Para limpar o registro manualmente execute no SQL um dos seguintes comandos:
/* DELETANDO REGISTRO POR USUARIO */
DECLARE @USUARIO VARCHAR(30)
SET @USUARIO = ‘USUARIO’ — COLOQUE O NOME DO USUARIO AQUI
DELETE FROM DBO.USUARIOS WHERE USUARIO = @USUARIO
/* DELETANDO REGISTRO POR MAQUINA */
DECLARE @MAQUINA VARCHAR(30)
SET @MAQUINA = ‘MAQUINA’ — COLOQUE O NOME DA MAQUINA AQUI
DELETE FROM DBO.USUARIOS WHERE MAQUINA = @MAQUINA
/* DELETANDO TODOS OS REGISTROS */
DELETE FROM DBO.USUARIOS
Conclusão
O procedimento adotado nesse documento é uma alternativa simples aos softwares de mercado, pagos ou não, como LimitLogin da própria Microsoft. Não existe ferramenta de monitoria, ficando a manutenção e melhoria do processo por conta de cada administrador.
Autores:
Tiago Vieira Ferreira de Souza éidealizador do site Portal Tecnologia, atua desde 2004 como Administrador de Redes, com foco em tecnologias Microsot. Formado em Tecnologia em Redes de Computadores, MCP Windows Server 2003, MCTS Windows Vista.
Site: http://www.portaltecnologia.net/
E-mail: contato@tiagosouza.net
Marcelo Ramos Borges de OliveiraéMCP na plataforma .NET desde 2007, atua a aproximadamente 10 anos no mercado de TI. Atualmente é Gerente de TI em empresa de médio porte com foco em Desenvolvimento Web. Site: http://www.marceloramos.net/Blog
E-mail: mramos.oliveira@gmail.com
Li uma matéria agora na PC World sobre o SP2 do Windows Vista. Segue abaixo.
Uma atualização e tanto
O Windows Vista SP2 inclui inúmeras mudanças ao sistema operacional. Veja abaixo as principais delas e o que elas irão fazer por você:
Permite a gravação de dados em discos Blu-ray
Acrescenta ao seu sistema o pacote de funcionalidade wireless do Vista, o qual proporciona suporte à tecnologia Bluetooth mais recente – versão 2.1 – bem como para o protocolo Wi-Fi Windows Connect Now (WCN)
Melhora o desempenho de redes Wi-Fi ao retornar do estado de dormência do sistema operacional
Melhora a funcionalidade e desempenho da barra de feeds RSS
Incorpora a mais recente versão do motor de busca no desktop, a Windows Seach 4
Diminui a necessidade de recursos para executar gadgets do sidebar
Melhoria geral de desempenho e ajustes finos do sistema operacional
Espera-se que o Windows Vista SP2 também entregue melhorias que ainda estão sendo desenvolvidas pela Microsoft, entra as quais vale citar:
Suporte a CPUs de 64-bits da Via Technologies
Introdução da tecnologia exFAT para suporte à manipulação de arquivos grandes e do sistema UTC para sincronismo de arquivos entre times zones diferentes
Melhoria do sistema de gerenciamento de energia em cerca de 10%
Adicionalmente, com o SP2 do Vista, a Microsoft corrige alguns bugs remanescentes, como os que tornam lento do desligamento do computador e erros da falha geral.
Pré-requisito
Para instalar o Service Pack 2 do Vista é necessário ter feito a atualização do sistema para o Vista SP1, uma vez que este beta não é cumulativo.
Coisas que podem ainda não funcionar
A Microsoft é famosa por entregar betas de Services Packs com problemas e muitas vezes são necessários inúmeros hotfix para que tais bugs sejam solucionados. Esta é mais uma razão clara para que os usuários comuns aguardem a liberação da versão final do SP2 do Vista antes de mergulhar de cabeça neste beta.
Um Service Pack melhor
É preciso fazer um elogio. A Microsoft de fato avançou com este beta que deve funcionar melhor que em versões passadas. É o primeiro SP que irá funcionar tanto no cliente (Vista) quando no servidor (Windows Server 2008) em um único pacote de atualização. Menos lixo inútil
O SP2 também inclui o que a Microsoft vem chamando de ferramenta de limpeza do Service Pack (Service Pack Clean-up Tool). Ela será responsável por eliminar do computador do usuário quaisquer resquícios de versões antigas de arquivos que foram atualizados pelo SP2. Com isso, o sistema deverá ficar livre de uma série de arquivos desatualizados que costumam entupir o computador gastar preciosos megabytes do disco rígido.
–
Tiago Souza
No último artigo explicamos o processo de encaminhamento para resolução de nomes, os servidores configurados como Forwarder. Agora vamos falar sobre outro tipo de encaminhadores, Conditional Forwarding, ou como alguns conhecem em português, encaminhadores condicionais.
Conditional Forwarding
O processo é parecido com o de encaminhamento, mas nesse caso você deve configurar não somente o endereço IP do encaminhador, mas deve associar o nome do domínio DNS que é autoridade para a zona juntamente com o endereço IP. O exemplo abaixo mostra como funciona o processo de encaminhadores padrão, vamos analisar primeiro para ver a diferença.
Processo de Forwarder:
Processo de Conditional Forwarder:
Percebam que o nome de domínio DNS está associado ao endereço IP.
Esse processo é comumente usado em casos de fusão de empresas que estão separadas fisicamente, parceiros de negócios, onde uma precisa consultar os registros na intranet da outra e vice versa. Nesse caso é só configurar o serviço de conditional forwarding em cada uma das empresas parceiras. Seu servidor DNS que está configurado para fazer conditional forwarding para seu parceiro não utiliza recursão, o processo para antes de chegar aos root hints, o que agiliza a resolução.
Você elimina a necessidade de se ter zonas secundárias. As Stub Zones também tem um efeito semelhante, mas explico no próximo artigo.
Como configurar
Para configurar o servidor como conditional forwarding precisamos obter o nome do domínio e o endereço IP do servidor DNS de destino.
Vamos usar como exemplo o domínio “portaltecnologia” novamente. Precisamos descobrir o nome do servidor autoritativo para esse domínio e associar o endereço IP na guia Forwarders do console DNS.
1 – Vamos abrir o console DNS (dnsmgmt.msc)
2 – Vamos pedir propriedades de servidor
3 – Vamos até a aba Forwarders
4 – Vamos clicar em New e nessa parte vamos adicionar o nome do domínio
5 – Com o nome do domínio selecionado vamos associar o endereço IP
6 – Pronto, a condição está criada, agora vamos ver como o servidor entende que deve processar essa solicitação
Ordem de resolução
Vou tentar enumerar o processo de resolução através do processo de contional forwarding para ficar mais claro.
1 – Você digita algum nome para ser resolvido na zona da empresa parceira
2 – O resolver não encontra informações para resolver e a consulta é transferida para o servidor. O servidor percebe que não tem a informação na sua base, somente os nomes de sua organização
3 – Então ele checa na aba forwarders para encontrar algum forwarder configurado
4 – É encontrado um nome de domínio com um endereço IP associado para o servidor autoritativo para esse nome
5 – A consulta é então encaminhada para esse servidor que responde com autoridade e devolve a resolução para o seu servidor
6 – O servidor responde para o cliente que então pode acessar o recurso, com mais rapidez que se utilizasse o processo de recursão
Conclusão
Usamos em casos de fusões de empresas que se tornam parceiras e estão separadas fisicamente, onde os usuários necessitam resolver nomes na intranet do outro local e vice versa
Agiliza o processo nesse caso, pois o servidor que tem um conditional forwarding configurado não faz uso da recursão, pois já conheçe qual o servidor autoritativo para o nome de destino, isso funciona como um atalho nesse caso
No último artigo explicamos o processo de resolução de nomes de acordo com os tipos de pesquisas como recursive e iterative. Agora vamos entrar no processo de forwarders (encaminhadores).
Forwarder
A figura abaixo ilustra o processo de encaminhamento de pesquisa.
O servidor DNS configurado como Forwarder recebe as consultas externas encaminhadas dos servidores DNS internos e faz a pesquisa na internet ao invés dos próprios servidores que originaram a pesquisa.
O que significa que os DNS servers que encaminham a consulta não utilizam os Root Hints nem a internet em um primeiro momento, esse trabalho fica somente para o Forwarder que devolve o resultado para os servidores solicitantes.
Perceba na ilustração que você não expõe os servidores internos na internet para resolver nomes externos, eles continuam resolvendo os nomes locais do domínio. O Forwarder criará também um grande cache de informações de consultas externas, que agiliza as consultas futuras, o que pode ainda reduzir o trafego na internet para resolução de nomes depois que já foram resolvidos uma vez.
Quando aqueles 2 servidores DNS internos estão configurados para encaminhar resoluções externas e recebem uma solicitação de resolução eles trabalham da seguinte maneira:
1. O cliente envia uma consulta para resolução de “www.portaltecnologia.net” para os servidores configurados na sua interface, que no caso são os dois do exemplo acima na intranet.
O servidor da início na consulta pesquisando suas zonas e seu cache e percebe que não é autoridade para o domínio.
2. Ele consulta então a aba Forwarders e encontra um servidor DNS encaminhador e envia uma consulta recursiva para ele (aquela que só aceita a resposta completa e não referência do resultado)
3. Os servidores aguardam a resposta do Forwarder antes que consultem os Root Hints e façam consultas interativas eles mesmos
Sobre o uso de Encaminhadores – Forwarders
São indicados quando se há link WAN de baixa velocidade na resolução de nomes
Pode ser usado um servidor DNS da internet como Forwarder, exemplo o do seu ISP
Útil porque cria um grande cache de nomes externos que pode ser usado para consultas futuras
Aumenta a segurança, pois os servidores expostos, com as portas DNS abertas, serão somente os encaminhadores, que não contém informações das zonas locais
Podem ser usados na borda entre um firewall e sua rede interna
Forwarders em modo Exclusivo
Você pode “forçar” para que seus servidores DNS internos usem apenas encaminhadores, fazendo com que eles não consultem os root hints ou qualquer outro servidor.
Para isso basta usar a opção: “Do not use recursion for this domain” (Não usar recursão para este domínio).
Nesse caso se o servidor configurado como Forwarder não conseguir resvolver uma consulta ele retornará um erro.
Então a consulta ficaria assim:
Cliente consulta nome externo nos DNS servers configurados no protocolo TCP/IP
Servidores consultam cache e zonas
Uma consulta recursiva é enviada para o Forwarder
Forwarders em modo Não-Exclusivo
Nesse modo quando um servidor envia uma consulta para um servidor DNS configurado como Forwarder e este não consegue resolver a consulta, os próprios servidores utilizam de consulta interativa, que comentamos no artigo anterior, exemplo: root hints, para resolver um nome.
Então a consulta nesse caso ficaria assim:
Cliente consulta nome externo nos DNS servers configurados no protocolo TCP/IP
Servidores consultam cache e zonas
Uma consulta recursiva é enviada para o Forwarder
Não resolvendo os servidores que encaminharam a consulta agora fazem consultas interativas para tentar resolver o nome
Vamos ver as formas básicas de pesquisa DNS, quando um cliente deseja acessar algum recurso ou servidor através de seu nome, e se um cliente deseja acessar um endereço externo, como por exemplo: www.portaltecnologia.net. Como o servidor da continuidade nessa busca para entregar o resultado para o cliente.
Consulta básica DNS
A figura abaixo ilustra uma pesquisa básica de um computador na sua rede que solicita acesso a um recurso do servidor através do seu nome. Vamos supor que você está usando um programa interno que consulta os recursos através do nome do servidor.
O cliente pergunta para o servidor DNS configurado em seu protocolo TCP/IP, “Qual o endereço IP de servidor.portaltecnologia.local?”, o servidor retorna o número correspondente e assim a conexão é criada.
Nessa etapa de pergunta o cliente também envia algumas informações, sendo:
Um nome de domínio DNS específico, declarado como nome de domínio totalmente qualificado (FQDN)
Um tipo de consulta específica, que pode especificar um tipo de registro de recurso ou um tipo especializado de operação de consulta.
Uma classe específica para o nome de domínio DNS. Para servidores DNS do Windows, isso deve ser especificado como a classe Internet (IN).
O cliente faz essa consulta através do serviço DNS client chamado de “resolver”, ou resolvedor se preferirem. Sempre que me referir ao cliente DNS vou usar resolver, que é como está na documentação do produto.
No exemplo acima, o servidor precisa procurar um registro (RR – Resource Record), em seu banco de dados conhecido como Host (A), que mapeia nome nome para endereço IP. O cliente pergunta algo como: “Você tem um recurso (A) para o nome servidor.portaltecnologia.net?”. O cliente, recebendo a resposta, recebe o endereço IP do computador solicitado através do nome.
Resolvedor Local
O processo de consulta de nomes se dá em duas partes, vamos começar falando do resolvedor local, o cliente DNS originando a consulta.
O resolvedor (cliente DNS) deseja procurar por um endereço externo, vamos supor http://www.portaltecnologia.net. Ele vai seguir alguns passos agora, vamos a eles:
Consulta seu cache de resolvedor local: Primeiro ele consulta o seu cache para saber se esse nome já havia sido resolvido anteriormente. Sempre que um nome é resolvido ele é gravado localmente em um cache, o que otimiza a consulta no caso de precisarmos usá-la novamente, tornando-a mais rápida.
Arquivo Hosts: Vamos supor que não há nada gravado no cachê local, o que ele faz agora? Ele passa a consultar o arquivo hosts. Esse é um arquivo de texto encontrado no seguinte local: C:\WINDOWS\system32\drivers\etc (caso o C:\ seja a unidade que o Windows foi instalado).
Quando o resolvedor não consegue resolver o nome nessas etapas ele passa a consulta para o servidor DNS, configurado no protocolo TCP/IP na interface de rede. Esse processo é conhecido como “Recursive Query” (pesquisa recursiva). Servidores DNS fazem pesquisas “recursiva” e “interativa” (Recursive e Iterative Query). Na recursiva o cliente só vai aceitar a resposta completa, seja ela positiva ou negativa, mas nenhum apontamento ou referência.
Ilustração do processo de pesquisa DNS:
Q = Question – Pergunta
A = Answer – Resposta
Processo de Recursão:
Servidor DNS – Recursive e Iterative Query
Quando a pesquisa chega ao servidor ele executa alguns passos, vamos enumerá-los pra tentar tornar o processo mais claro.
Vamos iniciar da parte que o cliente faz a consulta recursiva para o endereço www.portaltecnologia.net para o servidor DNS local configurado em sua interface de rede. Ele abre o browser e digita o endereço.
O servidor DNS recebe a consulta e enumera as zonas que ele tem autoridade no domínio (as que foram criadas nesse servidor como primárias). Se ele for autoridade ele já responde nessa etapa com uma resposta autoritativa. Ele será autoridade quando estamos, por exemplo, pesquisando o nome “servidor.portaltecnologia.local” e esse servidor DNS tem a zona “portaltecnologia.local” criada.
Vamos continuar supondo que ele não é autoridade para esse domínio. Ele vai pesquisar agora no seu cache de servidor. A medida que o servidor vai resolvendo nomes ele armazena os resultados em um cache, semelhante ao cliente (resolver). Se houver o registro no cache a resposta é dada nessa parte, vamos supor que não há ainda a resposta, para dar seguimento a pesquisa.
Como ele não encontrou o resultado, o servidor DNS vai tentar outras maneiras de pesquisa para resolver o nome para o cliente, fazendo uso do processo conhecido como Recursão (Recursion). Onde ele aciona outros servidores DNS para auxiliá-lo nessa pesquisa. (nesse artigo não vamos citar os encaminhadores – Forwarders, fica para o próximo).
Nesse momento ele utiliza uma lista de servidores chamada de Root Hints (Dicas de Raiz) para fazer pesquisas Iterativas, onde agora, nesse tipo de pesquisa ele aceita referências, partes da resposta, ao contrário da pesquisa recursiva que só aceita a resposta completa sem apontamentos. Os Root Hints contém uma lista de resource records usados pelo DNS server para contatar os servidores autoritativos para o domínio root na internet, sendo que o internet root name server responde nesse momento apontando para o servidor autoritativo abaixo dele no namespace, sendo no caso o .net, que é um top-level domain.
Quando o servidor DNS autoritativo responsável pelo .net recebe essa pesquisa Iterativa ele responde com o número IP apontando para o servidor que ele conhece, responsável pelo domínio “portaltecnologia.net”.
Agora o servidor DNS envia outra consulta iterativa para o DNS server responsável por “portaltecnologia.net”, onde este responde com o endreço IP do host “www.portaltecnologia.net”.
Agora o servidor DNS local retorna para o cliente o endereço IP de www.portaltecnologia.net, e o usuário consegue abrir uma conexão e visualizar a página.
Nesse caso, a reposta para o cliente foi positiva, mas poderiam haver outras, no caso de não conseguir resolver o endereço, seriam elas:
Authoritative Answer (Resposta autoritativa) – Quando é resolvido pelo servidor DNS que é autoridade pelo domínio consultado, como exemplo citado acima onde o usuário está tentando acessar o “servidor.portaltaltecnologia.local” através do servidor que hospeda a zona “portaltecnologia.local”.
Positive Answer (Resposta Positiva) – Contém a resposta correta para um nome pesquisado.
Referral Answer (Resposta com Referência) – Não contém a resposta, mas sim uma referência de onde a resposta pode ser pesquisada. Ela será retornada para o cliente se o servidor DNS local não estiver com a recursão habilitada. Nesse caso o cliente faz a pesquisa nos servidores que estão sendo passados pra ele como referência.
Negative Answer (Resposta Negativa) – Aqui encontra-se duas possibilidades para uma resposta desse tipo. Primeira, o servidor reportou que o nome pesquisado não existe no Namspace. Segunda, o nome pesquisado até existe, mas o registro está incorreto.
Dicas
Recursão é o processo que o DNS server contata outros DNS Servers que possam auxiliar na resolução de um nome pesquisado
O arquivo pré-configurado de Root Hints encontra-se em Windows\System32\Dns, e está nomeado como Cache.dns
Quando você adiciona uma entrada manual no arquivo hosts, ela é automaticamente carregada no cachê do resolvedor local
O cachê é o processo que guarda os nomes pesquisados para tornar uma consulta futura mais rápida
Ipconfig /flushdns – Limpa o cachê DNS
Não se esqueça que antes do resolver consultar o servidor DNS ele consulta o cachê local e o arquivo hosts
Recent Comments