No dia 07/05/2012 foram anunciados duas novidades, na realidade foi uma extensão no tempo de gratuidade e uma alteração.

A extensão no tempo de gratuidade foi com o Barramento de Serviços, que pode será utilizado sem custo até o dia 31/05/2012, após esta data o serviço será cobrado da seguinte forma:

• 100 horas de transmissão por $0.10 (aplicado quando utilizado o recurso de Transmissão de Barramento)
• 10.000 mensagens por $0.01

Maiores detalhes sobre o modelo de cobrança do Barramento de Serviços pode ser visto neste link: Barramento de Serviço.

A alteração é relacionada ao SQL Azure, e que foram duas:

• No campo “Tipo de serviço” no detalhamento da sua conta,  inclui agora o termo "Redundância geográfica”, isso para enfatizar que sua conta de armazenamento é duplicada em um datacenter deslocado da sua região para garantir uma proteção adicional contra perda de dados.
•   A segunda foi quanto ao nome dos recursos do SQL Azure, que aparecem em sua cobrança (Lembrando que os valores dos recursos não foram alterados, mantendo-se os valores anunciados em 14/02/2012).

E passam a seguir a seguinte nomenclatura:

Para detalhes adicionais sobre os valores dos serviços do SQL Azure consulte o seguinte link: http://blogs.msdn.com/b/windowsazure/archive/2012/02/14/announcing-reduced-pricing-on-sql-azure-and-new-100mb-database-option.aspx

É isso pessoal qualquer dúvida entre em contato com o suporte do Windows Azure ou se preferir podem me mandar uma mensagem ou comentar o post.

PS: Todas as informações contidas neste post foram extraídas de comunicado feito oficialmente pelo time de Windows Azure.

Boa sorte e sucesso a todos!

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Este post na verdade foi criado para servir de suporte para outros posts que necessitam desta informação, portanto ele será simples, rápido e direto.

Para identificar o ID da subscription você deve seguir 4 passos após logar no Portal do Desenvolvedor.

1. Clique em “Storage Services, Storage Accounts & CDN”;
2. Clique no ítem “Hosted Services (XX)”;
3. Clique na Subscription que deseja consultar o Id;
4. Localize o campo “Subscription Id” e copie o valor apresentado conforme imagem abaixo.

É isso pessoal, boa sorte e sucesso.

Grande abraço.

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Um recurso bem interessante existente desde a versão 1.3 do SDK do Windows Azure, é a capacidade de acessarmos remotamente as roles através do Remote Desktop.

Para utilizarmos este recurso precisaremos de um certificado PFX que contenha uma Chave Privada.

O primeiro passopara chegarmos ao certificados PFX é gerarmos um certificado ‘self-signed’ (auto-assinado), para isso abra o seu ‘IIS’ e dentro do grupo ‘IIS’ abra o ítem “Certificados do Servidor”.

Clique em “Criar Certificado Autoassinado”, entre com um nome para o certificado e clique em ok. Você terá uma tela parecida com a seguinte.

Neste momento um certificado do tipo X509 acabou de ser criado e Agora iremos gerar o certificado PFX, para isso selecione o certificado que acabou de ser gerado, clique em “Exportar…”, neste momento você deve definir um local onde ele será armazenado e uma senha que será utilizada posteriormente. Ao exportar você terá uma tela como a abaixo em seu processo.

O próximo passo é importar o certificado PFX gerado para o “Console de Gerenciamento Microsoft”, para que possamos utilizá-lo em nosso projeto. Clique no “Menu Iniciar” e pesquise por “certmgr.msc”, abra o aplicativo e expanda as pastas “Pessoal/Certificados”.

Após expandir as pastas clique com o botão direita em uma área em branco no quadro do lado direito e clique em “Todas as tarefas/Importar”, efetue os passos para a importação e no final do processo você deverá ter uma tela parecida com a apresentada abaixo:

Pronto agora temos o nosso certificado do tipo PFX criado e instalado, bastando agora consumi-lo em nosso projeto ativando o recurso de “Remote Desktop” em nossa aplicação.

Para iniciar a configuração do “Remote Desktop” abra o seu projeto, clique com o botão direto sobre a sua role e clique em “Package”.

Uma nova tela aparecerá, clique em “Enable Remote Desktop for all roles”.

Na tela a seguir selecione o certificado que acabamos de criar….

…defina um usuário e uma senha e clique em OK e depois OK novamente, agora é só aguardar os pacotes de deploy com o seu projeto e seu arquivo de configuração serem gerados.

Antes mesmo de seguirmos para efetuar o deploy, observe os arquivos “ServiceConfiguration” e “ServiceDefinitionFile” e verifique as ‘tags’ que foram incluídas pela configuração do Remote Desktop. Como exemplo observe um dos meus arquivos de configuração.

Agora que já temos os pacotes para o deploy, devemos fazer o upload em nosso projeto no Portal do Desenvolvedor e instalar o certificado PFX.

Para isso vá até o Portal do Desenvolvedor, localize seu ambiente de host e clique em Add certificate…“, escolha o certificado PFX que criamos e entre com a senha definida.

Agora basta fazer o deploy da sua aplicação para efetuarmos o teste.

Tendo o deploy concluído, para executar o “Remote Desktop” basta selecionar uma das instâncias do seu projeto e clicar no ítem “Connect” que está na Ribbon do Portal do Desenvolvedor no canto superior esquerdo, como apresentado na figura abaixo.

Quando executado uma mensagem será exibida para efetuarmos o download de um arquivo com extensão RDP, faça o download e execute-o.

Nesta tela clique em “Conectar”.

Entre com o usuário e senha definidos anteriormente, quando configuramos o Remote Desktop no VIsual Studio…

…e por último, por utilizarmos um certificado self-signed, a seguinte mensagem será exibida. Clique em “Sim” para prosseguir.

Pronto! Está feito o acesso remoto, agora basta consultar seus arquivos de log, verificar o que foi instalado ou não com a Startup Task (caso tenha utilizado), diagnosticar eventuais  falhas e executar demais procedimentos que haja necessidade.

É isso! Mesmo sendo longo, espero que tenham aproveitado e efetuado o seu acesso remoto, qualquer dúvida no processo desde a geração dos certificados aé a configuração do Remote Desktop fiquem à vontade para questionar ok?

Grande abraço e sucesso a todos!

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Dando sequência ao primeiro post da série referente ao MEP, hoje veremos quais as opções de customização e o veremos em funcionamento em nossa role.

Para iniciarmos, abaixo temos uma tabela onde mostrarei todas as opções de customizações existentes, seus valores padrão (default), uma descrição do seu funcionamento e exemplo de como podemos customizá-lo.

• ServiceLocation
  Opções: East Asia, North Central US, North Europe, South Central US, Southeast Asia, West Europe
  Valor Default: South Central US
  Descrição: Especifica o local de onde será feito o MEP. A dica é utilizar o mesmo local de onde efetuou o deploy para evitar cobranças extras e ganhar tempo no processo de deploy

• EnableAntiMalware
  Opções: True, False
  Valor Default: True
  Descrição: Habilitar ou desabilitar o MEP
• EnableRealtimeProtection
  Opções: True, False
  Valor Default: True
  Descrição: Habilita ou desabilita o ‘scanning’ em tempo real, assim como varreduras no disco
  • EnableWeeklyScheduledScans
    Opções: True, False
    Valor Default: True
    Descrição: Habilita ou desabilita a opção de “quick scanning” periódico para verificação de malwares ativos no sistema
    • DayForWeeklyScheduledScans
      Opções: 0-7
      Valor Default: 7
      Descrição: Define quando o ‘scan’ será agendado, as opções variam de diário ou um dia da semana específico sendo: 0 para diário, 1 para domingo, 2 para segunda-feira, …7 para sábado.
      • TimeForWeeklyScheduledScans
        Opções: 0-1440
        Valor Default: 120
        Descrição: Define o horário que o ‘scan’ será agendado, medidos em minutos, tendo como início à 0 hora. Exemplo: 60 para 01:00AM … 240 para 04:00AM … 1380 para 11:00PM.
        • ExcludedExtensions
          Opções: Extension1|Extension2|Extension3 (…)
          Valor Default: Nenhum
          Descrição: Monta uma lista com os tipos de extensões que desejamos manter fora do ‘scanning’. Exemplo: Se definirmos como valor log|txt todos os arquivos com extensão .log e .txt não passarão pelo ‘scanning’.
          • ExcludedPaths
            Opções: Path1|Path2|Path3 (…)
            Valor Default: Nenhum
            Descrição: Monta uma lista com os paths (caminhos/endereço) de arquivos e pastas que devem ficar fora do ‘scanning’.Exemplo: Se definirmos como valor e:\approot\worker.dll | e:\approot\temp estaremos determinando que o arquivo worker.dll, que está em e:\approot\, assim como todo o conteúdo da pasta temp, em e:\approot\, está foram do scanning.
            • ExcludedProcesses
              Opções: Process1|Process2|Process3 (…)
              Valor Default: Nenhum
              Descrição: Monta uma lista com os processos que devem ficar fora do ‘scanning’, porém ainda devemos nos atentar que, neste caso, somente os arquivos abertos pelo processo em si não estarão no ‘scanning’, para que o arquivo referente ao processo também entre no ‘scanning’ devemos utilizar a configuração ExcludedPaths.

Conhecidas todas as opções agora basta acessar o arquivo “ServiceConfiguration.csfg” e efetuá-las da maneira que desejar, abaixo está uma imagem do código com as configurações e uma pequena lista explicando os valores definidos.

ServiceLocation: “South Central US” – Mesmo local onde criei meu ambiente de ‘host’

EnableAntiMalware: “True” – Habilitar o MEP
EnableRealtimeProtection: “True” – Habilitar a proteção em tempo real
EnableWeeklyScheduledScans: “True” – Habilitar o agendamento semanal
DayForWeeklyScheduledScans: “0” – Define que o ‘scan’ deve ser diário
TimeForWeeklyScheduledScans: “480” – Deverá ser executado todo dia às 08:00AM
ExcludedExtensions: “log|txt” – Todos arquivos com extensão .log e .txt não passarão pelo ‘scanning’
ExcludedPaths: Mantive o valor default
ExcludedProcesses: Mantive o valor default

Feitas essas configurações, ative o recurso “Remote Desktop” na sua ‘solution’ e efetue um novo deploy.

Feito o novo deploy acesse remotamente a role em que o MEP foi ativado e verifique no canto inferior direito o ícone do mesmo.

Clique duas vezes sobre o ícone e uma janela será aberta, nela será possível verificar as configurações ativadas na sua solution e executar algumas tarefas.

Veja imagem abaixo do acesso remoto da minha aplicação.

Abraço e sucesso a todos!

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

No post de hoje irei mostrar como instalar e configurar um certificado SSL em sua aplicação no Windows Azure.

Para isso basta seguir os seguintes passos:

• Obter um certificado SSL através de uma “Certificate Authority”;
• Configurar certificado SSL em sua aplicação;
• Instalar o certificado no Windows Azure;
• Efetuar o deploy em sua aplicação e testar.

Obetendo um certificado SSL
Um certificado de segurança deve ser emitido através de uma “Certificate Authority” como por exemplo a GoDaddy e a VeriSign.

Para solicitar um certificado para uma destas “Autoridades” acesse o “Gerenciador do Serviços de Informações da Internet (IIS)”, dentro do painel “IIS” acesse “Certificados de Servidor”.

Clique em “Criar Solicitação de Certificado” conforme assinalado abaixo e preencha as informações solicitadas.

Ao final um arquivo TXT será gerado que deverá ser encaminhado para a empresa responsável parecido com o representado na imagem abaixo.

Para mais informações e uma lista sobre “Certificate Authorities” acesse: Windows Root Certificate Program – Members List (All CAs) – última atualização março/2011.

Após solicitar o certificado, você receberá como resposta da “Certificate Authoritie” escolhida um arquivo do tipo X.509 v3 de extensão “.CER”, com ele em mãos volte ao “Gerenciador do Serviços de Informações da Internet (IIS)” e clique em “Concluir solicitação de Sertificado”, selecione o arquivo e clique em ‘OK’ conforme apresentado abaixo.

Neste momento seu certificado está instalado no IIS da sua máquina local. Este certificado conterá uma chave privada e para podermos utilizá-lo em nosso projeto devemos exportá-lo, para isso basta selecionar o seu certificado e clicar em “Exportar…”.

Defina o local onde será salvo o arquivo com extensão “.pfx” e entre com uma senha que será utilizada toda vez em que formos instalá-lo.

Configurando o certificado e endpoint em seu projeto
Para trabalhar com certificados SSL em seu projeto, é necessário executar basicamente dois passos, primeiro configurar os certificados incluíndo um nome e sua respectiva assinatura (thumbprint) e na sequência configurar um Endpoint.

Para efetuar a configuração acesse as propriedades da role e acesse a aba “Certificates”,  adicione os certificados necessários com seu respectivo Thumbprint ou ‘Assinatura Digital’ (que pode ser encontrado nas propriedades do seu certificado na aba ‘Detalhes’).

No exemplo abaixo segue exemplo de configuração, no meu caso eu costumo utilizar o próprio nome do certificado para uma fácil identificação.

Você ainda pode efetuar ou visualizar estas configurações diretamente no arquivo “ServiceConfiguration.csfg”.

Efetuada a configuração dos certificados clique na aba “Endpoints’” e adicione um novo endpoint clicando em “Add Endpoint”.

Entre com as informações para ‘Name’, altere ‘Protocol’ para “https”, ‘PublicPort para “443” e por último vincule o certificado referente à url do seu projeto.

Assim como o certificado o Endpoint também pode ser configurado diretamente no arquivo “ServiceDefinition.csfg”, veja a representação abaixo.

Instalando os certificados no Windows Azure

Para instalar o certificado no Windows Azure acesse o “Portal do Windows Azure”, clique em Hosted Services, selecione a pasta “Certificates” do seu projeto, por último clique em “Add Certificate”, após selecionar o seu arquivo ‘.PFX’ e entrar com a senha previamente definida você terá uma estrutura parecida com a representada abaixo.

Após instalado os certificados gere os pacotes da sua solution e faça o deploy da sua aplicação.

Teste

Acesse a URL da sua aplicação utilizando o protocolo HTTPS, veja exemplos abaixo, onde testei em 2 browsers – Internet Explorer e Chrome.

É isso pessoal, qualquer dúvida ou sugestão estou à disposição. =)

Grande abraço e sucesso a todos!

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Este fim de semana efetuei algumas modificações e inclusões em um projeto chamado “Azure Facts – Cloud Computing Journal” e um dos updates foi a inclusão do “Microsoft Endpoint Protection for Windows Azure”.

No último mês de março (2012) o time de Windows Azure disponibilizou um plugin  que nos permite incluir uma proteção antimalware em nossas VMs do Windows Azure.

Nesta primeira parte irei apresentar o MEP (Microsoft Endpoint Protection)  e como habilita-lo em seu projeto com a configuração default.

Funcionalidades do MEP:

• Proteção em tempo real monitora, detecta e bloqueia os malwares.
• Escaneamento agendado: escaneia periodicamente aifim de detectar malware no sistema, incluindo programas “maliciosos”.
• Ações contra malware: quando detectada algum malware deleta ou coloca em quarentena os arquivos e limpa todas as entradas “maliciosas” do registro.
• Atualizações:  instala a última ‘assinatura de proteção’ também conhecido como “virus definitions”, garantido a segurança.
• Proteção ativa: reporta metadados sobre detecção de problemas e recursos suspeitos para a Microsoft, garantindo uma rápida resposta para o problema e habilitando uma entrega em tempo real de uma altualização através do Dynamic Signature Service (DSS).

Download MEP:

  Para podermos habilitar e configurar o MEP em nossas VMs devemos antes de mais nada efetuar o download do agente e instalá=lo em sua máquina local. Para isso faça o download e instale o “Microsoft Endpoint Protection for Windows Azure” através deste link  http://www.microsoft.com/download/en/details.aspx?id=29209#overview, confira a imagem abaixo.

Instalação local do MEP:

Efetuado o download execute o arquivo ‘eppplugin.msi’, leia e aceite os termos e por fim siga com a instalação que é bem simples.

O MEP é uma extensão para o SDK e seus arquivos pós instalação podem ser encontrados em ‘C:\Program Files\Windows Azure SDK\v1.6\bin\plugins\Antimalware’.

Ainda vale destacar que o MEP ainda está em fase CTP, portanto ainda não está em fase final e foi devidamente testado para a versão 1.6 do SDK.

Ativando o MEP em seu projeto antes do deploy:

Feita a instalação agora basta ativar o MEP, para isso basta incluir a tag abaixo dentro do arquivo “ServiceDefinitioncsdef” conforme indicado na figura.

<Import moduleName="Antimalware" />

Em nosso exemplo eu incluí o MEP apenas na Worker Role para melhor demonstrar a configuração.

Uma vez incluída o antimalware em suas ‘Roles’, as configurações ‘default’ serão incluídas no arquivo “Service Configuration” do seu projeto.

Feito! Agora basta efetuar o deploy que o MEP será habilitado em todas as instâncias da minha Worker Role.

Na sequência deste post trarei mais detalhes sobre o MEP, aboradaremos todos as opções de configuração e ainda veremos como tirar proveito das informações coletadas pelo ‘Diagnostics’.

Boa sorte e sucesso a todos!

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Algumas pessoas me perguntaram como poderiam manter sincronizados seus bancos de dados com instâncias em outros locais, seja em um outro Datacenter do Azure ou ainda em um SQL Server local de forma automatizada, para essa tarefa, o Windows Azure possui o SQL Azure DataSync.

Com o DataSync podemos criar grupos de sincronização utilizando 2 ou mais databases, estejam eles no SQL Server ou no SQL Azure (sendo que ao menos 1 é obrigatório que pertença ao SQL Azure). No decorrer dos passos vocês verão que conseguiremos definir, por exemplo, quais as bases de dados que farão parte do grupo, os critérios de sincronismo utilizando filtros, a periodicidade que irá ocorrer, entre outros.

Partindo da idéia de que você nunca utilizou o DataSync ou é a primeira vez que o utilizará nesta máquina (lê-se máquina esta que você está utilizando neste momento), dividiremos este processo em três partes: Configuração do DataSync (I e II) e Instalação do agente.

No meu cenário utilizarei um banco de dados padrão criado na instalação de WordPress no SQL Azure e faremos o sincronismo dele com um banco de dados novo no meu SQL Server local.

Então vamos colocar a “mão na massa”!!!!!!

Pré-requisitos para o SQL Azure DataSync

• Possuir um LiveId ativo no Windows Azure, esta subscrição pode ser paga ou free. Confira através deste link http://www.windowsazure.com/pt-br/pricing/free-trial/
• Possuir uma conta ativa no SQL Azure com ao menos 1 servidor e um database criado e configurado.
• Se for trabalhar com base de dados local você deverá ter instalado ao menos 1 SQL Server 2005 SP3.

Valores para o SQL Azure DataSync

Na versão Preview (versão disponível até o momento que finalizei este post) não existe custo, porém, futuramente na v1.0 pode ser estipulado algum tipo de cobrança como, por exemplo, os custos já conhecidos de transferências de informações no Azure.

Configuração do SQL Azure Data Sync – Parte I

Antes de iniciarmos toda a parte de criação e configuração gostaria de apenas deixá-los informados do porquê ter dividido em Parte I e Parte II. Esta divisão ocorreu pois entre estas partes teremos a etapa de instalação de um “agente” na nossa máquina local com algumas configurações. Essa divisão ficará mais fácil para você entender em que parte do processo você se encontra.

Neste exemplo, criaremos um grupo de sincronismo bem simples onde teremos, neste cenário, apenas uma base de dados no SQL Azure e outra em meu ambiente local, que sincronizará toda a minha base de dados do SQL Azure para a minha base de dados no meu ambiente local.

Então, para iniciarmos, acesso o portal do desenvolvedor (www.windows.azure.com) e clique no menu Data Sync localizado no menu do lado direito do portal.

Na área central do seu portal aparecerão as opções do DataSync. A primeira coisa que faremos será “Provisionar“ um novo servidor. Clique na caixa “Servidor de Visualização de Sincronização de Dados de Provisão” (conforme imagem abaixo), em seguida serão apresentados os termos de uso, LEIA COM ATENÇÂO e, concordando com os termos, assinale a caixa concordando e clique em avançar.

Em seguida, selecione qual subscription irá vincular o Server do Data Sync.

Nesta próxima tela, selecione em qual região o Server deverá ser criado.

Feitas as ecolhas que já estamos acostumados a fazer sempre que inciamos um novo serviço no Windows Azure, iniciaremos as configurações específicas para o Data Sync. Nessa etapa, como representado na imagem abaixo, defina um nome para o Grupo de Sincronismo, este nome deve ser único.

Neste passo temos que fazer duas configurações. Como estamos criando nosso primeiro Grupo de Sincronização escolheremos a segunda opção “Adicionar um novo banco de dados do SQL Server ao grupo de sincronização” e definiremos qual a “Direção de Sincronização”.

Para o nosso tutorial, que tem como cenário um banco de dados do SQL Azure e outro no SQL server, as opções são:

• Sincronizar PARA O Hub: Toda atualização que seja efetuada na base de dados do SQL Server será feita no SQL Azure.
• Sincronizar DO Hub: Toda atualização que seja efetuada na base de dados do SQL Azure será feita no SQL Server.
• Bidirecional: A atualização será feita em ambos de acordo.

Nesta fase, incluíremos um Banco de Dados do SQL Server em nosso Grupo de Sincronismo, para isso será necessário instalar um agente, portanto, selecione a opção “Instalar um novo Agente” e clique em “Avançar” .

Aqui chegamos ao fim da primeira parte e partiremos para a instalação do “Agente”. Uma nova tela aparecerá com 3 etapas para a instalação, sendo que na primeira, realize o download do agente, na segunda dê um nome ao agente e na terceira, clique em ‘”Gerar Chave do Agente” para ser utilizada na configuração do cliente.

Gere a chave e anote o valor para ser utilizado nos próximos passos.

Instalação do SQL Azure Data Sync Agent

Para instalar, você precisa ter realizado o donwload do “agente”, conforme os passos acima, ou atraves da URL http://www.microsoft.com/download/en/details.aspx?id=27693 (conforme imagem) e inicie a instalação.

Prossiga com a instalção padrão…

Chegará em um ponto onde você deverá entrar com as credenciais de Administrador, seja de uma rede que você faça parte ou simplesmente administrador da sua máquina.

Caso você não entre com informações corretas receberá notíficações como:

• “Service SQL Azure Data Sync…Verify that you have sufficient privileges to install system services.”
• “…This may indicate a problem with this package. The error code is 2203”.
• “You need to be an administrator to install this product”.

Para que isso não ocorra entre com as informações de Domains\User ou simplesmente localcomputer\localuser (que nada mais é do que o [Nome da máquina]\[Nome do usuário]), algo como Escritorio\Lucas (nome fictício para exemplificar).

Configuração do SQL Azure Data Sync Agent

Primeiramente, acesse o Microsoft SQL Azure Data Sync Agent Preview.

Após carregar o SQL Azure Data Sync Preview, aparecerão apenas duas opções disponíveis, clique em “Submit Agent Key Configuration”, insira a chave gerada (conforme mencionado acima) e clique em ok.

Submetida a chave gerada, agora é o momento em que incluiremos as credencias do SQL Server. No meu exemplo, utilizo uma autenticação via Windows e entrei com as informações do meu Server e o nome do meu banco de dados (Database). Após inserir as informações, clique em “Test Connection” para validar as informações e clique em “Save”.

Feita a configuração, efetuaremos o teste de comunicação entre o agente e o serviço do SQL Azure DataSync, para isso selecione o banco de dados e clique em “Ping Sync Service”.

Após receber a mensagem de sucesso, basta clicar em ok.

Configuração do SQL Azure Data Sync – Parte II

Feitas as configurações do agente que resultaram na seleção da base de dados do SQL Server do meu ambiente on premises, agora é hora de efetuarmos as demais configurações no SQL Azure Data Sync.

Efetuado o passo 1 (instalação do agente), clique no botão “Obter Lista de Banco de Dados” para que o Data Sync faça a comunicação com o agente e retorne a lista com todos os bancos de dados que foram configurados (em nosso exemplo apenas um banco de dados foi mapeado).

Selecione o banco de dados na lista apresentada na “Etapa 3” e clique em “Concluir”.

”

Nesta etapa incluiremos nosso banco de dados existente no SQL Azure, para isso basta clicar na caixa apresentada abaixo (observe que logo abaixo existe uma representação dos meus bancos de dados locais configurados).

Uma nova janela será aberta para que você insira as informações de Servidor e as Credenciais de Acesso:

• Nome do servidor do SQL Azure: [NomeDoServidor].database.windows.net
• Nome do Banco de Dados do SQL Azure: [NomeBancoDeDados]
• ID de Usuário: [IdDeUsuário] – Usuário definido no SQL Azure
• Senha: [Senha] – Senha referente ao ID mencionado acima que pode ser gerenciado no SQL Azure

Antes de clicar em “Adicionar” efetue o teste de conexão para verificar suas credencias de acesso ao SQL Azure clicando no botão “Testar”, sendo bem sucedida clique em “Adicionar”.

Na tela a seguir, você definirá os critérios que serão sincronizados em cada banco de dados configurado, selecionando tabelas e critérios de linha, caso queira sincronizar apenas algumas linhas com critérios específicos.

No próximo passo defina a periodicidade do sincronismo, no meu exemplo defini sendo a cada 30 minutos e caso haja conflitos de informações quem terá a prioridade (Hub ou Cliente).

Enfim chegamos em nossa última etapa e para finalizá-la basta simplesmente clicar em “Implantar”…

…e você terá uma tela parecida com a abaixo!

Por último, caso queira acompanhar, você ainda tem a opção de acompanhar os “Logs”. Para isso clique em “Verificar Log” e visualize de acordo com sua necessidade aplicando filtros.

Finalizando o sincronismo, meu banco de dados do SQL Server ficou assim:

Espero que este post seja útil. Caso tenham alguma dúvida ou sugestão, fiquem à vontade em comentar.

Um grande abraço e sucesso.

=)

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
 Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Continuando a série de posts com dicas contendo sugestões para as dúvidas mais frequentes levantadas no dia-a-dia, esse post trará minha visão de alguns clients que você poderá utilizar para gerenciar seu storage do Windows Azure.

Gerenciadores de storage

Abaixo estão os nomes de clients que utilizo ou ao menos já testei para gerenciar meu storage, com seus respectivos links para mais informações e download. Lembrando que todos os 3 são free ou possuem uma versão gratuíta (ao menos até o momento em que escrevi este post):

• Azure Storage Explorer – http://azurestorageexplorer.codeplex.com/

• CloudBerry Explorer for Azure Blob Storage – http://www.cloudberrylab.com/free-microsoft-azure-explorer.aspx

• ClumsyLeaf CloudXplorer – http://clumsyleaf.com/products/cloudxplorer

Azure Storage Explorer

Para mim, este é o gerenciador mais completo. Com ele conseguimos manipular todas as informações referentes a Blobs, Tables e Queues, bem como visualizar seus conteúdos, modificar propriedades e gerenciar diversos storage accounts através de abas.

Para melhorar ainda mais a experiência no manuseio de Blobs e torná-la mais eficiente, recomendo que baixem o patch que torna possível o upload de pastas inteiras que o MVP André Dias disponibilizou (http://azurestorageexplorer.codeplex.com/SourceControl/list/patches).

Em geral, só perde em um ponto para o CloudBerry (citado logo abaixo) que é na facilidade com a manipulação de Blobs, mas que não acaba com a minha predileção.

CloudBerry Explorer for Azure Blob Storage

Para quem estiver trabalhando somente com Blobs esté é o client mais intuitivo, simples e completo para se usar. É muito fácil criar containers, mover, renomear e copiar dados do Azure para um ambiente on premises e vice-versa, além de uma conta do Azure para outra.

Ainda possui um ítem bem bacana chamado “Capacity Report” que apresenta a quantidade de espaço utilizado graficamente. Vale a pena ter na máquina.

ClumsyLeaf CloudXplorer

É possível manipular, visualizar e criar estruturas em uma interface bem parecida com o que já utilizamos no Windows Explorer, é funcional, mas ainda fico com o CloudBerry Explorer for Azure.

Façam o download dos 3 clients, testem e tirem suas próprias conclusões. Caso conheçam outros, aceito as sugestões.

Grande abraço e sucesso! =)

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

Conforme mencionei no post anterior “Adicionando um Co-admin a uma subscription” a intenção deste post é mostrar como é simples mover um Server do SQL Azure de uma subscription para outra.

Pontos importantes a serem apresentados:

Para executarmos esta ação é necessário que o Live-Id que irá efetuar a transferência seja ao menos Account manager, Service administrator e/ou Co-administrator em ambas as subscriptions;

A transferência de um Server de uma subscription para outra, fará com que o custo e limites utilizados nas respectivas Subscriptions sejam alterados, como por exemplo na subscription de destino acusará o custo e consumo de um Server e suas respectivas Base de Dados;

A mudança do Server é apenas lógica e não física, o Server somente deixa de estar vinculado com a Subscription XPTO* e passa a estar com a Subscription ABC* ele continuará existindo na mesma Região e Datacenter quando criado;

Toda aplicação que utilizam as bases de dados deste Server continuarão funcionando normalmente.

* Nomes fictícios das Subscriptions para serem utilizadas como exemplo.

Mão na massa: 

Para efetuar a transferência é muito simples, para acessar o SQL Azure dentro do Portal do Desenvolvedor e selecionar o Server que deseja efetuar a transferência.

Feito isso clique no botão “Move Server…” e uma nova janela ira ser exibida, apresentando o nome do Server e uma List Box com todas as Subscriptions vinculadas ao seu Live-Id.

Selecione a Subscription de destino e clique em OK, como mostrado na figura abaixo.

O processo demora alguns pouquíssimos segundos e então você já terá o Server vinculado à outra subscription com todas as informações desde o nome do Server, como Datacenter e obviamente todos os Databases que já existiam. Veja a representação na imagem final abaixo.

É isso pessoal… boa sorte e sucesso a todos!

Grande abraço!!! =)

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR

A idéia deste post nasceu depois de decidir escrever/demonstrar sobre como associarmos uma base de dados do SQL Azure à uma subscription diferente da que estamos usando.

Nos últimos dias várias pessoas me perguntaram algo como: “Lucas! Mas se por exemplo eu tiver uma base de dados no SQL Azure utilizando uma conta da minha empresa, como eu faço para portá-lo na conta de produção do meu cliente?”

A resposta para esta questão é bem simples, veremos no próximo post o como utilizar o recurso “Move Server…” diretamente no Portal do Desenvolvedor e que tem a necessidade da existência de um Co-Administrador.

Antes de iniciarmos as explicações (que por sinal é bem simples), temos que ter em mente que neste pequeno artigo teremos dois “personagens”:

• Service administrator: é o owner da subscription;
• Co-administrator: “personagem” adicionado por um Service administrator ou por outro Co-administrator;

Então vamos lá.. a idéia de se ter um co-administrador em uma subscription do Windows Azure é a de que mais de uma pessoa possa acessá-la (subscription) porém cada qual com seu Live-Id, com isso não existe a necessidade de se compartilhar credenciais e senhas.

Quando comparadas os direitos e permissões de um “co-administrator” com um “Service administrator”, a única diferença entre eles é a de que um co-administrador não tem a permissão de remover um “Service administrator” de uma subscription.

Mão na massa:

Adicionando um Co-administrator

Para definirmos um ou mais co-administrators devems após logar no Portal do Desenvolvedor clicar no menu “Hosted Services, Storage Accounts & CDN” e em seguida logo acima clicar em “User Management”.

Você terá uma tela como a abaixo:

O próximo passo é clicar em “Add new Co-Admin” na Ribbon, uma nova tela abrirá e então bastará inserir um Live-Id válido (Obs: para se adicionar um Co-Admin não é necessário que este Live-Id possua algum tipo de Trial ou Paga de propriedade dele) e escolher em sua lista em qual ou quais Subscriptions deseja conceder os direitos.

Após adicionar você terá uma tela como a abaixo, listando o Service administrador e seus respectivos Co-administradors, no meu exemplo apenas 1.

Removendo um Co-administrator

Agora para retirar os direitos de um Co-administrator é ainda mais simples, basta selecionar o Live-Id que perderá os privilégios, clicar em “Manage Co-admin” na Ribbon, uma janela abrirá listando as subscriptions vinculadas a este Live-Id e que você possui autorização para retirar.

Para retirar basta desmarcar a Check box e clicar em ok! Como na figura abaixo.

E é isso pessoal, extremamente simples gerenciar Co-administrators.. boa sorte e até o próximo post. “Move Server…” =)

Abraço e sucesso a todos!

Lucas A. Romão – Windows Azure MVP
LinkedIn: http://br.linkedin.com/in/lucasromao
MSN: lucas_romao@hotmail.com
Blog: http://laromao.wordpress.com | Twitter: @LucasRomao
Comunidade Azure Services Brasil | Twitter: @AzureServicesBR