Archive for maio \20\UTC 2010

BPOS, BPOS, BPOS…

maio 20, 2010

Comentei em algum post antigo que iniciaria uma série sobre BPOS – a plataforma online da Microsoft. Chegou a hora! Iniciarei a série hoje, com um post bem detalhado com informações sobre como começar usar a solução. Postarei até o fim do dia.

Enquanto isso, seguem alguns links com informações úteis sobre o BPOS.

Exchange Online:
Exchange Online Padrão (em Português): Word | XPS
Exchange Online Dedicado (em Português): Word | XPS

Descrições do Serviço Exchange Online:
Exchange Online Padrão (em Português): Word

Office Communications Online:
Office Communications Online padrão (em Português): Word | XPS
Office Communications Online dedicado (em Português): Word | XPS

Descrições do Serviço Office Communications Online:
Office Communications Online padrão (em Portugês): Word

SharePoint Online:
SharePoint Online padrão (em Português): Word | XPS
SharePoint Online dedicado (em Português): Word | XPS

Descrição do SharePoint Online Service (em Português):
SharePoint Online padrão (em Português): Word

Office Live Meeting (em Português):
Office Live Meeting Standard (em Português): Word | XPS
Office Live Meeting Dedicado (em Português): Word | XPS

Abraços.

Anúncios

Atualizar a lista de Mailbox desconectados – Exchange 2007 e 2010

maio 14, 2010

 

Muitas vezes, necessitamos atualizar a lista de mailbox desconectados no Exchange. Aqui está como fazer isso:

1. Inicialmente, vamos listar os databases com o Get-MailboxDatabase cmdlet.

[PS] C:\> Get-MailboxDatabase

Name                Server        StorageGroup            Recovery
----                ------        ------------            --------
Mailbox Database    Server1       First Storage Group     False
Executive Database  Server1       Second Storage Group    False
Mailbox Database    Server2       First Storage Group     False
Partner Database    Server2       Second Storage Group    False

2.  Execute um Clean up no database.  Para isso execute esse cmdlet:

[PS] C:\> Clean-MailboxDatabase “Server1\Mailbox Database”

[PS] C:\> Clean-MailboxDatabase “Server2\Partner Database”

Após essas etapas, a lista de mailbox desconectados estará atualizada.

Dica relâmpago: Como colocar um remetente permitido ou domínio permitido no Content Filter do Exchange

maio 11, 2010

 

Um pequeno problema que enfrentei e gostaria de compartilhar com vocês é a configuração de allowed senders e allowed domains, no Content Filter do Exchange. Para resolver esse problema, basta setar os parâmetros abaixo, via Shell do Exchange:

Set-ContentFilterConfig -BypassedSenders picafumo@dominio.x.y

Set-ContentFilterConfig -BypassedSenderDomains dominio.x.y

Configurando o NLB do ISA Server 2006 e como alterar o modo de funcionamento do NLB de Unicast para Multicast

maio 11, 2010

 

Por Carlos Monteiro

Introdução

Antes de começarmos com o processo de troca do modo de funcionamento do NLB do ISA 2006 de unicast para multicast, vamos apresentar algumas informações conceituais sobre o mesmo.

De uma forma simples, o NLB é uma tipo de tecnologia de balanceamento de carga entre servidores, não exclusiva para Microsoft Windows. NLB é parte da família Windows Server 200x e é usado para distribuir o tráfego de rede para até 32 hosts. O NLB usa um algoritmo distribuído de tráfego de entrada para todos os nós, em um cluster NLB Windows. Assim, o NLB pode ser usado para fornecer failover e balanceamento de carga.

NLB Unicast ou Multicast

Network Load Balancing (NLB) pode operar em dois modos: Unicast ou Multicast.

Unicast
O modo de operação padrão é o Unicast. No modo Unicast, NLB altera o endereço MAC do adaptador de rede onde o NLB está ativado. Todos os nós do cluster usam o mesmo endereço MAC. O tráfego de rede irá para todos os nós, e será encaminhado para o controlador de filtro NLB.
Multicast
No modo de Multicast, o NLB atribui a cada adaptador de rede ativado um endereço Layer-2-Multicast. O endereço MAC original de cada nó permanecerá inalterado.
Ambos os métodos possuem seus prós e contras. A vantagem do modo Unicast é que ele funciona na maioria dos ambientes de rede, integrando com quase todos os roteadores e switches. Uma das desvantagens, é que todos os hosts no cluster NLB devem ter o mesmo endereço IP e endereço MAC.
Uma vantagem do modo Multicast é que todos os nós do cluster mantêm o seu endereço MAC original. Uma das desvantagens é que Multicast requer uma configuração adicional no switches, necessitando que seja criada uma entrada ARP estática no switch ligando o endereço IP (VIP Virtual = Endereço IP Virtual) para o endereço MAC do cluster compartilhado.
Observação:
A capacidade de suporte Multicast no switch depende do fornecedor do mesmo. Há também algumas informações adicionais sobre Multicast que você deve conhecer antes de habilitar o NLB Multicast na rede.

ISA Server e NLB

O ISA Server depende da configuração NLB do Windows Server 2003 que estende as características NLB para o ISA Server 2006, com o ISA Server 2006 Enterprise Edition.

Ativando NLB

Para ativar o NLB no ISA Server, os seguintes passos devem ser executados:

– Ter dois ou mais ISA Servers 2006 Enterprise instalados e configurados como membros de um único Array;

– Protocolo NLB instalado nas interfaces de rede que irá suportar o NLB, em ambos os ISA Servers;

O assistente de configuracao do ISA Server deverá ser utilizado para a criação do NLB. O assistente de configuração do Windows não será (e não deverá) ser utilizado.

Para configurar o NLB, basta abrir a console de gerenciamento do ISA Server, é ir em Arrays, “Nome do Array”, Configuration e Networks. Em Networks, clicar com o botão da direita do mouse e em Configure Load Balances Networks:

clip_image002

Figura 1: Configuração do NLB no ISA Server Enterprise.

O assistente de configuração do NLB é aberto.

clip_image004

Figura 2: Assitente de configuração do NLB no ISA Server.

Na guia de seleção de redes, basta selecionar a rede que será configurado o NLB.

clip_image006

Figura 3: Seleção da interface de rede para configuração do NLB.

Após a seleção, basta configurar o IP virtual que será utilizado pelo NLB.

clip_image008

Figura 4: Configuração do IP Virtual do NLB.

Clique em Next para configurar o NLB com o Ip Virtual.

clip_image010

Figura 5: Ip Virtual configurado no NLB.

Clique em Finish para finalizarmos a configuração do NLB.

clip_image012

Figura 6: Tela de finalização do NLB.

O ISA Server pede para as informações sejam salvas e os serviços sejam reiniciados.

clip_image013

Figura 7: ISA Server solicitando que as informações sejam salvas e os serviços sejam reiniciados.

Após essa etapa, os serviços de NLB são instalados no ISA e as etapas de configuração dos mesmos são realizadas.

clip_image015

Figura 8: Serviços do NLB sendo configurados.

Após a configuração dos serviços, os mesmos entrar no estado de execução, e o NLB está ativo.

clip_image017

Figura 9: Serviços do NLB ativos.

Alterando o modo de funcionamento do NLB para Multicast

Por padrão, o modo de funcionamento do NLB no ISA Server é Unicast.
O ISA Server 2006, com o hotfix (KB942639), é a primeira versão do ISA Server que o NLB pode ser alterado de Unicast para Multicast NLB.
A fim de permitir o uso de Multicast no ISA Server 2006 Enterprise, todos os servidores ISA precisam estar executando o hotfix KB942639, ou ISA Server 2006 Service Pack 1. Antes dessa atualização o NLB do ISA Server 2006 era suportado apenas em modo Unicast, o que nem sempre é ideal, dependendo do ambiente de rede.
Antes de começarmos a alterar o modo NLB, deverá ser realizado um backup full do ISA Server 2006, para fins de emergência.
Em primeiro lugar, todas as configurações necessárias para o NLB deverão ser anotadas, porque o processo de troca do modo Unicast para Multicast necessita uma reconfiguração do NLB.

clip_image010[1]

Figura 10: Registrando as informações do NLB.

Em grandes ambientes, múltiplas configurações de NLB podem existir, portanto, é recomendável que todas sejam registradas.

Em seguida, o NLB do ISA deverá ser desabilitado, usando a MMC do ISA. Isso pode ser feito clicando com o botão direito do mouse, e em seguida, Disable Network Load Balancing Integration.

clip_image018Figura 11: Desabilitando o NLB no ISA Server.

Clique em OK.

O ISA Server informa que as informações deverão ser salvas e os serviços deverão ser reiniciados.

clip_image013[1]
Figura 12: ISA Server solicitando que as informações sejam salvas e os serviços sejam reiniciados.

Nesse momento, vamos realizar o download e executar o utilitário NLBCLEAR em todos os nós do NLB do ISA Server. O NLBCLEAR limpa todas as informações do NLB no computador local. O download do NLBCLEAR pode ser feito do site da Microsoft em http://support.microsoft.com/kb/938550/en-us. Execute o RemoveAllNLBSettings.cmd através do prompt de comando, sem nenhum parâmetro.

clip_image019
Figura 13: Usando o NLBCLEAR.

Poderá haver um pequeno delay para que as alterações tenham efeito. É recomendado que os nós do NLS sejam reiniciados.

ARP cache

A tabela ARP de todos os nós deverá ser limpa. Para isso, execute o comando abaixo, via prompt, em todos os nós:

Arp –d *

FSMO Schema Master

ISA Server 2006 salva suas configurações em um banco de dados ADAM. ADAM é o banco de dados Active Directory Application Mode da Microsoft. Um Configuration Storage Server (CSS) central hospeda a configuração do ISA, e todos os membros do array usam esse CSS. Se o ambiente existir múltiplos CSS, o primeiro servidor é o CSS. O update do ISA Server para suporte à Multicast altera o esquema do ADAM. Dessa forma, o Schema Master deve ser contactado para esse update. Caso existam múltiplos CSS no ambiente, será necessário determinar qual hospeda o Schema Master FSMO role.

Existem alguns métodos para determinar quem hospeda o Schema Master role. Um deles é utilizar o script FINDCSSFSMO.VBS, de Jim Harrison. Jim administra um website chamado www.isatools.org. A ferramenta para determinar o Schema Master pode ser baixada através do link http://isatools.org/tools/findcssfsmo.zip.

Execute o script

cscript findcssfsmo.vbs [/server:NameOfCss]

ADSIEDIT

Outra forma de determinar o hospedeiro do Schema Master é usando o ADAM ADSIEDIT, que está instalado em cada Configuration Storage Server.

Inicialmente, estabeleça uma conexão no CSS através da porta 2171, então, navegue pelo objeto NTDS Settings, de cada nó do ISA Server.

clip_image020
Figura 14: usando o ADSIEDIT para localizar o Schema Master

Uma terceira forma de determinar o ADAM Schema Master é utilizar o MMC com a Snapin ADAM Schema. Através de um prompt de commando, registre a MMC com o seguinte commando:

Regsvr32 adam-schmmgmt.dll

clip_image021
Figure 15: Registrando a DLL do Schema Management.

Após o registro, abra a MMC e adicione a Snapin ADAM Schema e conecte no servidor ADAM, na porta 2171.

clip_image022
Figure 16: Snapin Schema MMC.

Após a conexão ser estabelecida, clique com o botão da direita do mouse no objeto ADAM Schema, que o Schema Master poderá ser visualizado.

clip_image023
Figure 17: Determinando o Schema Master com a Snapin Schema Master

Alterando o NLB para Multicast

Após localizar o servidor que hospeda a função de Schema Master, podemos executar o script KB938550.WSF, que pode ser baixado em http://support.microsoft.com/kb/938550/en-us, com a seguinte sintaxe, para alterar o NLB da rede especificada de Unicast para Multicast:

CSCRIPT KB938550.WSF /array:ISA-array-name /NLB:Muticast /Net1:name-of-the-ISA-network

clip_image024
Figure 18: Alterando o NLB de Unicast para Multicast.

Multicast com IGMP

É possível configurar o NLB do ISA Server para trabalhar com Multicast via IGMP (Internet Group Management Protocol). IGMP é baseado no protocolo IP e torna possível usar o Multicast IPv4, com a ajuda dos grupos Multicast. IGMP é usado para ajudar a integrar o protocol Multicast com diferentes ambientes de rede.

A sintaxe para habilitar o Multicast com o IGMP é semelhante ao Multicast tradicional:

CSCRIPT KB938550.WSF /array:ISA-array-name /NLB:IGMP /Net1:name-of-the-ISA-network

clip_image025Figure 19: Alterando o NLB de Unicast para Multicast com IGMP.

Após habilitar o NLB para trabalhar com Multicast, deverá ser recriados os NLBs no ISA Server, conforme o procedimento inicial do artigo. É recomendável que os nós do NLB sejam reiniciados.

Conclusão

Nesse artigo, foi possível verificar a configuração do NLB, no ISA Server 2006 Enterprise, e como alterar o modo de funcionamento de Unicast para Multicast. Como referência, indico o http://support.microsoft.com/kb/938550/en-us para mais informações e download dos executáveis / patchs.

No mínimo curioso: o Bug do Twitter

maio 11, 2010

 

Nós estamos (profissionais de TI, curiosos e demais), desde o fim dos anos 90 até hoje, debatendo sobre a questão de segurança na TI. A Microsoft sempre foi criticada, muitas vezes com razão, mas vejam que até nos dias de hoje, grandes e estúpidas falhas podem acontecer. A bola da vez foi o Twitter.

Terra Tecnologia: A história do bug: como uma banda derrubou o Twitter
11 de maio de 2010 11h47

John Herrman

Por um tempo ontem, um bug no Twitter deixava qualquer um forçar qualquer pessoa a seguir suas contas. Era um truque hilariamente simples, e igualmente bizarro, de deixar a Twittess de queixo caído. Melhor ainda? Este bug foi descoberto por acidente, por um usuário turco do Twitter. Foi isso o que aconteceu.

A dica inicial foi para o Gizmodo americano via outro usuário turco do Twitter, chamado Güntekin. A primeira mensagem dele para a gente parecia, francamente, ridícula:

Um cara turco chamado Bora Kirca descobriu acidentalmente que se você tuitar "accept nomedousuário", por exemplo billgates, então o Bill Gates iria seguir você. É muito estúpido, mas é verdade.

Estúpido mas, sim, verdade. Funcionou. O Gizmodo americano postou isso. O Twitter enlouqueceu, o número de seguidores (e seguidos!) de todo mundo caiu para zero, e a conta do Twitter do Bora foi suspensa. Mas como ele descobriu isso?

Por acidente? Ah, é mesmo? Güntekin explica:

(Bora) gosta de uma banda chamada "Accept" e para mostrar que gosta, ele tuitou "accept pwnz"; mas em vez de ver o tweet, ele viu que o usuário "pwnz" o estava seguindo.

Ele contou para a namorada, e juntos eles começaram a fazer o que qualquer pessoa teria feito: eles fizeram famosos os seguirem. Então eles postaram sobre isso neste site aqui (NSFW), em turco. Dentro de algumas horas, isto estava acontecendo no Twitter:

Se disserem que estou seguindo mais de uma pessoa, eu fui hackeado. Eu sou um tuitador completamente monógamo – eu sigo apenas Sarah Killen.

Tuitadores proeminentes estavam sendo, uhm, "hackeados". Então, através do Güntekin e de pessoas como ele, o bug foi descoberto pelo Ocidente.

o twitter está sendo hackeado por um hacker turco. haha eu tenho 0 seguidores. (tweet de "aplusk", o ator Ashton Kutcher, que foi retwitado mais de cem vezes)

Como é que é?
Certo, então obviamente foi assim que o bug foi encontrado, mas por que ele estava lá, afinal? Era tão claro e simples – digite "accept nomedousuário" e você ganha um novo seguidor – que sua existência era difícil de acreditar. Por que digitar um comando assim faria alguma coisa, quanto mais rasgar um buraco na delicada infraestrutura do Twitter?

Comandos de texto existem no Twitter desde o começo, e muitos ainda funcionam. Digite "STATS" e você receberá o número de seguidores e seguidos que você tem; digite "FOLLOW nomedousuário" e você irá segui-lo; digite "RT nomedousuário" e você retuita a última mensagem do usuário. Tudo isto está documentado.

O que não está documentado é o comando ACCEPT, que fez este truque funcionar. Mesmo assim, ele obviamente existe. O leitor Rhainor explica o que ele faz:

Ele era para ser usado por pessoas que protegem seus tweets. Se você tentar seguir alguém que deixou os tweets privados, em vez de segui-los instantaneamente, ele envia um pedido ao usuário ("nomedousuário" quer seguir você). Para permitir que ele siga você, você aceita o pedido ¿ na minha experiência, clicando um botão, mas para as pessoas que raramente o usam, o comando via texto faz sentido.

A resposta do Twitter
Por enquanto, o Twitter não pode fazer muita coisa além de esperar: esperar os engenheiros deles limparem a bagunça, e descobrirem exatamente o que aconteceu, e como evitar isso. Nós entramos em contato, mas nos falaram que eles estavam "investigando" nossas perguntas, e isso é compreensível. A repsosta oficial deles é escrita como um relatório de bug:

Nós identificamos e resolvemos um bug que permitia a um usuário "forçar" outros usuários a segui-los. Nós estamos trabalhando agora para desfazer todo abuso do bug que ocorreu. Os números de seguidores e seguidos estão agora em zero; nós sabemos disso e isso logo será resolvido.

Parece óbvio que este bug estava aí faz um tempo, e era questão de tempo até que alguém o descobrisse. Também parece óbvio que o Twitter deveria ter notado o bug antes de liberar a função "ACCEPT" no site principal.

Por horas, milhares de pessoas conseguiram obter controle das contas no Twitter de outras pessoas com um truque tão fácil que até mesmo o cara mais noob conseguiria fazer. E eu acho que, por algum tempo antes de se tornar público, o bug fez pessoas como o Bora adicionar seguidores sem querer e sem saber. O Twitter foi exposto. Várias contas poderiam – e foram – de fato hackeadas: alguém agiu em nosso nome, com nossas identidades públicas do Twitter, sem nossas senhas.

No fim, o Twitter vai arrumar isso tudo, e eles vão limpar nossa lista de seguidos (ou nós vamos). Mas a preocupação permanece: e se isso fosse um pouco pior? E se um comando desse acesso a outras contas do Twitter além de forçar um follow? O que aconteceu foi uma inconveniência; o que poderia ter acontecido seria um desastre.

E foi assim que uma banda alemã de heavy metal destruiu o Twitter, mais ou menos.

No site do Gizmodo, pelo atalho http://tinyurl.com/27ka5co, você vê as imagens dos tweets e um clipe da "Accept", a banda que o turco Bora procurava.

fonte: http://tecnologia.terra.com.br/noticias/0,,OI4424809-EI12884,00-A+historia+do+bug+como+uma+banda+derrubou+o+Twitter.html

Carro do Google View Street em Ribeirão Preto

maio 5, 2010

 

Hoje, da janela do prédio que trabalho, foi possível ver o Stilo do Google Street View filmando as ruas de Ribeirão Preto.

Afinal, o que é esse Google Street View? O mundo inteiro tem comentando sobre esse novo projeto, que é um subproduto do Google Maps e Google Earth. Ele proporciona aos usuários fazer um tour – de 360° na horizontal e 290° na vertical – pelas ruas de algumas cidades do mundo, de países como Estados Unidos, Reino Unido, Holanda, França, Itália, Espanha, Austrália, Nova Zelândia, Japão e agora o Brasil.

A foto não é boa, mas dá para verificar que é o próprio.

foto_google_street_view

 

Tem um pessoal em Belo Horizonte que conseguiu filmar o carro.