Un paseo por las nubes

Certificate error when deploying DotNetNuke on Windows Azure

After a busy January I’m back again to write some pending entries that I have promised to some people. There are lots of things to tell after the DNN-Cloud session in the DNN Europe Task Force Meeting 2012, things like: how to upgrade a DNN version on Windows Azure, how to do backup and restore operations, how to move an instance from on premise to Azure and vice versa, etc. so let start one by one.

To begin, let’s see how to solve a typical error when deploying DNN on Windows Azure, since at least 4 people have asked to me how to fix it in the past two weeks. The error message appears when you deploy the package on a service, and means that the certificate specified in the service configuration file is not configured on the Windows Azure service:

“The certificate with thumbprint ‘XXXXXXXXXX’ is missing for hosted service ‘YYYY’. Please install the certificate for this hosted service.”

This is because you didn’t upload correctly the certificate, which is used to encrypt communications while using RDP or Windows Azure connect (Virtual Network).

NOTE: in future versions of DNN Azure Accelerator this problem will be fixed using another method for uploading the package, using the Windows Azure publishing settings. Meanwhile, you have to upload manually the certificate to Azure as specified below.

What certificate?

The error refers to the certificate used in the DNN Azure Accelerator to configure RDP. In fact, there is a text indicating that you have to upload this certificate to the hosted service on Azure, but actually there is not much help on how to do this, because although currently the Accelerator automatically generates the certificate in a “.cer” file in the wizard folder, it must be imported into Windows Azure as a “.pfx” file.

How to export the certificate in PFX format?

To export the certificate in PFX format from the DNN Azure Accelerator wizard RDP step, follow these steps:

1. Click “View…” to see the certificate that has generated the wizard
   
2. Go to the tab “Details”. In the certificate properties, we can see the “Thumbprint” of this certificate, which is precisely the one referred by the error and stored in the service configuration file.
   
3. Click the “Copy to File…” to open the export wizard indicating that you want to export the private key. This is mandatory to export in PFX format.
   
4. In the next step, select the format “PFX” and activate the check boxes for “Include all certificates in the certification path if possible” and “Export all extended properties”. Uncheck the box “Delete the private key if export is successful”, as means to delete it from your local computer certificates storage instead of the exported file.
   
5. In the following steps specify a password to be used while importing into Azure and finally a filename for the certificate.
   

With this we have exported the PFX file.

How to import the certificate on Azure?

This step is very well documented in numerous websites and in Windows Azure’s help, but here again to not have to open another page and for printing purposes –remember to save the trees!:

1. Open the Windows Azure Administration console and access the hosted service settings, selecting the service certificates folder you want to configure.
   
2. Press the “Add Certificate…” button to upload the “PFX” file that we have exported typing the password used before.
   

Once that is done, we can see that the certificate was successfully uploaded and that in the certificate details the “Thumbprint” is also there.

I closed the Accelerator and now I do not know how to re-export the certificate

It may happen, or at least that’s what happened to those who asked me about this problem, you forget to export the certificate in PFX format when using the DNN Azure Accelerator. Is there another way to export if I closed the assistant and/or deleted the “.cer” file that was created in the wizard folder?

There are several methods to accomplish that, but for simplifying the shortest is:

1. In a command line console, type “certmgr.exe” to open the certificates management console in the folder “Personal\Certificates”
2. If you remember the “FriendlyName” that you used in the DNN Azure Accelerator, select it. If not or not be sure of which certificate you used on the wizard, you will have to open one by one and select the one with the property “Thumbprint” which matches the error message –the property is on the Details tab page.
   
3. Right-click on “All tasks>Export…” to start the export process mentioned in the previous section

With this, once we have exported and loaded the certificate in the same way as indicated in the previous steps, we can deploy our service without problems.

Hope this helps. More tomorrow!

Error de certificado al desplegar DotNetNuke en Windows Azure

Después de un mes de enero muy ajetreado ya estoy de vuelta a escribir algunas entradas pendientes que tengo para el blog. Hay mucho que contar después de la sesión de DNN-Cloud en el DNN Europe Task Force Meeting 2012 y que tengo posts pendientes de publicación: cómo hacer upgrades de las instancias en Azure, cómo hacer backups, cómo mover una instancia onpremise a Azure y viceversa, etc. así que empezamos poco a poco.

Para empezar, vamos a ver cómo solucionar un error típico al desplegar DNN sobre Windows Azure, ya que al menos 4 personas me han preguntado cómo solucionarlo. Se trata del mensaje de error que aparece al desplegar el paquete sobre un servicio indicando que no se encuentra el certificado indicado en el archivo de configuración del servicio imposibilitando la ejecución del despliegue:

“The certificate with thumbprint ‘XXXXXXXXXX’ is missing for hosted service ‘YYYY’. Please install the certificate for this hosted service.”

Esto es debido a que no ha subido correctamente el certificado al servicio que vamos a desplegar, que es usado para encriptar las comunicaciones RDP así como posibilitar la configuración de Windows Azure Connect con las instancias.

NOTA: en próximas versiones del DNN Azure Accelerator se solucionará este problema ya que el método de publicación será distinto usando el fichero de configuración proporcionado automáticamente por Windows Azure.

¿A qué certificado se refiere?

El error se refiere al certificado que se usó en el DNN Azure Accelerator para configurar el paso de RDP. De hecho, hay un texto indicando que te asegures de subir este certificado al servicio, pero lo cierto es que no hay mucha ayuda sobre cómo realizar este proceso, ya que si bien actualmente el Accelerator genera automáticamente el certificado en un fichero “.cer” en la carpeta, éste debe ser importado en Windows Azure en formato “.pfx”.

¿Cómo exportamos el certificado en formato PFX?

Para exportar el certificado en formato PFX desde el mismo asistente, seguiremos los pasos siguientes:

1. Pulsar el botón “View…” para ver el certificado que ha generado el asistente
   
2. Vamos a la pestaña “Details”. En las propiedades del certificado podemos ver la huella (“Thumbprint”) de este certificado, que es precisamente a la que se refiere el error y que se almacena en el fichero de configuración del servicio.
3. Pulsa el botón “Copy to File…” para abrir el asistente de exportación indicando que quieres exportar la clave privada –esto es obligatorio para poder exportar en formato PFX.
   
4. En el paso siguiente, selecciona el tipo de certficado “PFX” y activa las casillas correspondientes a: “Incluir todos los certificados en la ruta de certificación si es posible” y “Exportar todas las propiedades extendidas”. No marques la casilla “Eliminar la clave privada si la exportación tiene éxito”, ya que se refiere a eliminarla de tu equipo local en vez del fichero exportado, con lo que no podrás repetir este proceso a menos que vuelvas a importar el certificado exportado.
   
5. En los pasos siguientes especificamos una contraseña que usaremos para la importación en otros equipos así como en Azure, y finalmente un nombre de archivo para el certificado.
   

Con esto hemos exportado el fichero PFX.

¿Cómo importamos el certificado en Azure?

Este paso está muy bien documentado en infinidad de sitios web así como en la ayuda de Windows Azure, pero para que el lector no tenga que estar abriendo más páginas –y yo pueda imprimir este procedimiento cuando me haga falta- se resume en:

1. Abrir la consola de administración de Windows Azure y acceder a la configuración de los servicios hospedados, seleccionando la carpeta de certificados del servicio que queremos configurar.
   
2. Pulsamos el botón “Add Certificate…” para subir el fichero “.pfx” que hemos exportado especificando la contraseña
   

Una vez realizada esta operación, podemos ver que el certificado se ha subido con éxito y que en los detalles del certificado se muestra la huella (“Thumbprint”) del mismo.

Cerré el Accelerator y ahora no sé cómo volver a exportar el certificado

Puede ocurrir –o al menos eso fue lo que le pasó a los que me preguntaron por este problema- que te olvides de exportar el certificado en formato PFX. ¿Hay alguna otra forma de exportarlo si ya cerré el asistente y/o eliminé el archivo “.cer” que se crea en la misma carpeta del Accelerator?

La respuesta es que hay varios métodos, pero para simplificar expongo la siguiente:

1. En una línea de comandos, ejecutar “certmgr.exe” para abrir la consola de administración de certificados en la carpeta “Personal\Certificates”
2. Si nos acordamos del “FriendlyName” que pusimos al crear el certificado con el DNN Azure Accelerator, lo seleccionamos. En caso de no acordarnos o no estar muy seguros de qué certificado usamos en el Accelerator, tendremos que ir abriendo uno por uno y seleccionar el que tenga en la pestaña “Details”, propiedad “Thumbprint” el que coincida con el del error en cuestión.
   
3. Pulsamos con el botón derecho del ratón seleccionamos “Todas las tareas>Exportar…” para iniciar el mismo proceso de exportación comentado en el apartado anterior

Con esto, una vez que hemos exportado y cargado el certificado del mismo modo que se ha indicado en los pasos anteriores, podremos desplegar nuestro servicio sin problemas.

Espero que sirva de ayuda. ¡Mañana más!

Adiós 2011. Bienvenido 2012

Vaya, vaya. No sé ni cómo pero ya ha pasado un año desde que escribí una entrada similar a esta para despedir el 2010. Después de releer la entrada me parece casi mentira que todo lo que me ha pasado en este 2011 haya sido comprimido en un sólo año. Parece que el lema de “pasar a la acción” haya sido uno de los mejores objetivos que me he puesto en mi vida, porque efectivamente, toda acción tiene repercusión, y vaya que si la tiene.

2011 ha sido un año…lleno de acción

Ha sido un año duro, de muchas horas –quizás me quede corto- de trabajo, de noches, fines de semana, festivos…pero hay un refrán que dice que “sarna con gusto no pica”. Nada mejor que hacer lo que más te gusta para que las horas se te pasen volando. Será porque de pequeño en vez de astronauta quería ser arquitecto de software. Vale, ahí me he colado, este concepto no existía aún, pero algo así le expliqué a mi madre cuando bajaba la palanca de la luz para que me desenganchara del MSX. Jugaba  con él, y también hacía con los amigos una base de datos de novi@s en BASIC

Después de un año 2010 en el que había perdido la ilusión, después de toda esta acción ha venido esa famosa repercusión, y la mayoría en forma de buenas noticias y recompensas. No sólo he recuperado esa ilusión perdida, sino que me ha servido para darme cuenta de que nunca es tarde para ser lo que realmente quieres ser.

“Si te sirve de algo, nunca es demasiado tarde para ser quien quieres ser. No hay límite en el tiempo. Empieza cuando quieras. Puedes cambiar o no hacerlo. No hay normas al respecto. De todo podemos sacar una lectura positiva o negativa. Espero que tú saques la positiva. Espero que veas cosas que te sorprendan. Espero que sientas cosas que nunca hayas sentido. Espero que conozcas a personas con otro punto de vista. Espero que vivas una vida de la que te sientas orgulloso. Y si ves que no es así, espero que tengas la fortaleza para empezar de nuevo.”

The Curious Case of Benjamin Button

The Curious Case of Benjamin Button

Gracias a los amigos, a los de siempre y a los nuevos, que ponen la salsa para un viaje inolvidable. Gracias a la familia, por no poder dedicarles todo el tiempo que quisiera y aún así seguir estando a mi lado con el mismo amor. Gracias de nuevo a todos por estar ahí, por compartir este año, por formar parte de mi vida.

Y de nuevo, gracias en especial a Carmen, mi esposa, mi amor y mi compañera, por andar este nuevo camino juntos, ya que sin ti, no podría haberse hecho realidad.

Para acabar y despedir este año 2011, abajo os dejo otro vídeo muy especial, lleno de emoción, realizado en uno de los sitios más bonitos de la Tierra: Tenerife, mi tierra. Os deseo un feliz y PRÓSPERO año 2012 a tod@s.

Un abrazo y hasta mañana.

David Rodríguez

The Mountain - http://www.facebook.com/TSOPhotography

[Tip] Un huevo de pascua llamado “dnndev.me”

Hoy toca compartir una utilidad muy interesante de esas que se encuentran en la red y que nos facilitan la vida a los desarrolladores que trabajamos con entornos web.

¿Conocías el dominio “dnndev.me”?

El dominio dnndev.me es un dominio registrado en Internet por nuestro amigo Ian Robinson que apunta a la dirección de loopback 127.0.0.1. Y no sólo este dominio, sino que cualquier subdominio *.dnndev.me también lo hace.

Para hacer una prueba, abre una consola de comandos y haz un ping a “<loquetedelagana>.dnndev.me” y comprobarás que siempre responde tu dirección local.

¿Y para qué sirve esto?

Pues para personas que como yo, que trabajamos en desarrollo con más de 30 sitios web en el IIS, cada uno con un binding distinto, con diferentes versiones, etc. editar el fichero de hosts (c:\windows\system32\drivers\etc\hosts) se vuelve una tarea muy tediosa.

De esta manera, puedes configurar en tu IIS un binding en el sitio web, por ejemplo, http://miproyecto.dnndev.me en vez de usar http://localhost/miproyecto o editar el fichero de hosts para introducir http://miproyecto.dev

Gracias a Ian Robinson (ver post original) y a Joe Brinkman por su aportación en esta simple y genial idea.

P.D. no es una inocentada!

Happy coding!

[WebCast] DotNetNuke 6–Framework para reducir costes

Nada más y nada menos que de la mano de Toni Coll, autor y editor del único libro en español sobre desarrollo sobre la plataforma DotNetNuke, este miércoles 14 de diembre a partir de las 09:30 (GMT+1) vamos a tener el placer de poder conocer a fondo las posibilidades de DotNetNuke y entrando en detalle en la administración del CMS (atención para administradores de DNN!!).

El evento aparte de ser presencial, también se retransmitirá en directo en formato webcast, disponible para su registro en la web de eventos de Microsoft. El registro es completamente gratuito. No dejes pasar esta ocasión.

Os dejo más detalles del evento y el enlace para el registro. Un saludo y happy codding!

Registro en línea

DOTNETNUKE 6 - FRAMEWORK PARA REDUCIR COSTES
Descripción:
DotNetNuke es el proyecto Open Source desarrollado con la tecnología Microsoft .NET líder a nivel mundial. Este CMS permite la creación de potentes aplicaciones web, con miles de extensiones disponibles en su Market Snowcovered.

Agenda:

9:30 – 9:40 Bienvenida y presentación
9:40 – 11:00 Introducción y administración del CMS
11:00 – 11:15 Descanso
11:15 – 12:50 Ediciones comerciales y desarrollo
12:50 – 13:00 Preguntas y Despedida

Ponente:

Toni Coll -Autor y editor del único libro en español, cofundador de la única Comunidad en España, propietario y CEO de 2P Systems (DotNetNuke Affiliate Certified Partner).

Perfil de los participantes:
Directores de empresas TIC, responsables TIC de empresas turísticas, profesionales del sector TIC.
Estudiantes de los últimos cursos de la carrera de Informática.

Windows Azure Camps en Tenerife

Siguiendo con la ola de eventos de desarrollo en nuestra isla, esta vez tenemos la gran ocasión de poder contar con David Salgado en un día dedicado al desarrollo sobre la plataforma Windows Azure.

¿Y en qué consiste la jornada?

En que nos vamos de acampada. ¿Qué? Bueno, más o menos La acampada es en el hotel Silken (el hotel Atlántida en la avenida 3 de Mayo, en Santa Cruz de Tenerife). La idea es que Mr. Salgado haga una introducción a Windows Azure, para luego comenzar con laboratorios de desarrollo totalmente prácticos, enfangándonos de barro cantando alrededor del fuego.

Se repartirán cuentas evaluación de Windows Azure a los asistentes para que puedas comenzar a hacer tus pinitos en desarrollo en la nube.

¿Qué tengo que llevar?

Pues como es totalmente práctico, tendréis que traer vuestro propio portátil con algunas cosas instaladas. Habrá algún USB con los requisitos por si alguien se le olvida, pero intentar venir preparado, porque si no, te vas a perder la mitad del laboratorio con las instalaciones.

Requisitos:

Para los laboratorios más genéricos

Windows Vista SP2, Server 2008 SP2, Server 2008 R2 o Windows 7

IIS con ASP.NET habilitado:

• .NET Framework 4.0
• Visual Studio 2010
• SDK de Windows Azure
• SQL Server 2008 Express
• SQL Server Management Studio

Para los laboratorios de federación:

• Runtime de Windows Identity
• SDK de Windows Identity

Y si estás interesado en el de PHP:

• Eclipse con herramientas de Azure

¿Cuándo es?

¡Mañana! La fecha es el 1 de diciembre de 2011. ¿A qué estás esperando?

Regístrate aquí

[Evento] Windows Phone Roadshow en Tenerife

¡Sí! ¡El Windows Phone Roadshow en Tenerife! ¿No te habías enterado? Seguro que sí, pero por si aún queda algún rezagado ahí va la buena noticia.

El próximo sábado 26 de noviembre en el salón de actos de la Facultad de Física (Universidad de La Laguna), el Tour del año pasa por nuestra isla, el Windows Phone Roadshow. Gracias a TenerifeDev, la ULL, Microsoft, Intelequia, SDM Programas y Plain Concepts se mostrarán las capacidades de Windows Phone 7.5 Mango y cómo explotarlas desarrollando aplicaciones y juegos.

Si eres desarrollador o estás estudiando para serlo, te interesará conocer el mundo de las plataformas móviles Microsoft de la mano de Josué Yeray, Rafael Serna y Alberto Díaz, expertos en desarrollo con esta nueva plataforma. No te lo puedes perder. Si aún no te has enterado, gran parte del futuro del desarrollo de aplicaciones se encuentra en las plataformas móviles.

¡Habrán muchas sorpresas, regalos y…algún teléfono para los más atentos!

El registro es totalmente gratuito, así que no te puedes perder esta pedazo de ocasión. No olvides circular esta información a quien pudiera interesarle.

Regístrate aquí

Agenda del evento:

09:00-09:30       Registro
09:30-10:30       Por qué Windows Phone?
10:30-12:00       Plataforma de desarrollo de aplicaciones y Juegos
12:00-12:15       Descanso
12.15-13:15       Datos, Servicios y "Live Tiles" (Ventanas Vivas)
13:15-14:00       Capacidades avanzadas de Windows Phone
14:00-15:00       Descanso
15.00-16:00       Multitarea en Windows Phone
16:00-16:15       Descanso
16:15-17:15       Desarrollo paso a paso y publicación de "Zombsquare"
17:15-17:45       Cómo comercializar tus aplicaciones y juegos en el Marketplace
17:45-18:00       Recursos, Ayudas e Iniciativas

DNNWorld, DNN Azure Accelerator 6.1 y Windows Azure

La semana que viene comienza en Orlando la DotNetNuke World Conference 2011, la reunión anual donde se congregan los mayores expertos alrededor del CMS donde estaré personalmente.

Este año el número total de de sesiones de la conferencia asciende a 34, bastante para dos días y para ponerlo difícil a los que nos parecen interesantes todas ellas. Los que no podáis asistir podéis registraros para ver el KeyNote en directo de Shaun Walker a través de este enlace.

Respecto a las sesiones sobre la nube y DotNetNuke, nos encontramos con estas tres sesiones específicas en la que me podréis encontrar por si tenéis alguna cuestión que resolver:

1) Leveraging Azure Cloud Services.- sesión para desarrolladores por Philipp Becker, en el que se verá como ejemplo cómo usar las colas de Azure para en procesamiento asíncrono de correos electrónicos del portal.

2) DotNetNuke on Azure Cloud Servers.- sesión de interés general (desarrolladores, administradores, etc.) donde se verá en detalle cómo desplegar instancias de DotNetNuke sobre Windows Azure usando el DNN Azure Accelerator. Bruce Chapman será el encargado de impartir la sesión en la que he estado involucrado personalmente, preparada con la última versión del Accelerator.

3) File System Abstraction and Folder Providers in DotNetNuke 6.0.- sesión dedicada a desarrolladores donde se mostrará cómo extender el sistema de ficheros de DNN con almacenamiento en la nube, como puede ser Azure Storage. Un ejemplo de esto último es el Intelequia DNNFolderProviders.

La agenda completa de la conferencia la podéis encontrar en este enlace, para que podáis decidir qué track os gusta más. Si vais a estar por allí, enviadme un twitt a @davidjrh y quedamos.

Pero esta no es la única novedad de este post.

DotNetNuke Azure Accelerator 6.1

Esta semana, aprovechando la publicación de la versión 6.1 de DotNetNuke, he publicado en CodePlex una nueva versión del Azure Accelerator que reune una serie de nuevas funcionalidades para facilitar el despliegue sobre Azure, en concreto sobre habilitar RDP y Azure Connect sin tener que descargar el código fuente de la solución sino desde dentro del mismo asistente (para más información sobre esto, podéis echar un vistazo a mis dos últimos posts sobre cómo modificar las credenciales de RDP sin Visual Studio y cómo conectar una Azure Cloud Drive a tu equipo).

La lista de nuevas características de esta versión son:

• Incluye la distribución OFICIAL de DotNetNuke 6.1 (nótese que a partir de ahora los módulos que no forman parte del core ya no se incluyen en la descarga y que se instalan a través del mismo portal con el catálogo de extensiones en línea)
• Añadido nuevo paso en el asistente para configurar el acceso RDP (Escritorio Remoto) a todos los roles sin la necesidad de usar Visual Studio 2010
• Los certificados X509 para el acceso RDP se pueden generar a través del mismo asistente
• Moificada la validación de los controles de la interfaz de usuario con un Error Provider (no más ventanas emergentes)
• Añadida validación de contraseñas con la misma política que Azure en el asistente, para que no de problemas al acceder a la base de datos
• Añadidas validaciones para los nombres de los containers de Storage a través de expresiones regulares
• Añadidas cajas de texto para indicar el nombre y tamaño del VHD inicial con el que se desplegará el gestor de contenidos
• Añadidos paquetes de servicios pre-compilados para despliegues con RDP habilitado o sin él
• Añadido un nuevo paquete “Single and Small”, donde todas las instancias son de tamaño Small, todos son webroles y el servidor SMB es la instancia 0
• Todos los paquetes han sido compilados usando el SDK 1.5 de Azure, con lo que se pueden usar todas las características que incluye
• Añadido nuevo paso en el asistente para configurar la Red Virtual (Azure Connect) y permitir así la creación de redes virtuales entre Azure (tus instances de DNN en la nube) y otras máquinas on-premise como tu mismo PC, con lo que puedes acceder a ellas a través del entorno de red de Windows
• Una vez desplegado el servicio, seguirás usando el asistente de instalación oficial de DNN para crear y configurar tu instancia durante la primera ejecución desde tu navegador
• Recuerda que puedes crear tus propios paquetes personalizados de servicios y ponerlos dentro de la carpeta “/packages” del Accelerator para usarlos con el asistente

Os dejo con algunas capturas de los nuevos pasos del asistente y el enlace a la descarga de la nueva versión.

Nos vemos en Orlando.

http://dnnazureaccelerator.codeplex.com

Evento Desarrollando WebApps en la nube: Materiales

A continuación os dejo los materiales del evento de TenerifeDev “Desarrollando WebApps en la nube”. Felicidades a todos los que se llevaron obsequio de nuestros patrocinadores PluralSight y Telerik.

Imágenes del evento

TenerifeDev - Desarrollando WebApps en la nube VER PRESENTACIÓN DESCARGAR TODO

Vídeo completo de la sesión

Slides

Conectar una Azure Cloud Drive directamente a tu equipo

Llevo un rato dándole vueltas a la cabeza a ver qué título le ponía a esta entrada en el blog, porque el amplio abanico de posibilidades que se me están ocurriendo es muy grande. Podría simplemente haberlo titulado “Editando los contenidos de un VHD en Azure desde tu escritorio”, pero es que también “Haciendo un backup en Azure Storage con Drag and Drop” también es válido. Por supuesto, “Cómo actualizar el contenido de tu sitio DNN en Azure desde tu explorador de Windows” es de dónde ha nacido la idea.

Y es que desde mi última entrada sobre cómo editar los contenidos de un VHD en Azure y pensando que aún así debería haber un método más fácil para actualizar los contenidos de un VHD, empecé a barajar la idea de usar el actual servidor SMB del DNN Azure Accelerator mezclado con Windows Azure Connect.

¿Qué es Windows Azure Connect?

Hace tiempo que ya escribí una entrada sobre este servicio de Windows Azure –aún en CTP y gratuito de momento- pero por simplificar, resumámoslo en que es un componente para poder crear redes virtuales entre “tu mundo” y Windows Azure. Con ello consigues, por ejemplo, ver las máquinas que están en la nube como si estuvieran en tu red local: les puedes hacer un ping, puedes ver el equipo a través de la red si tiene habilitada su regla en el firewall...¿cómo? ¿qué puedes ver los equipos en Windows Azure por la red y ver sus ficheros?

Y ahí está el quid de la cuestión. Si ya en el mismo DNN Azure Accelerator los web roles acceden por la red para publicar los contenidos del worker role SMB, ¿por qué no podría conectarme desde mi equipo a esa misma unidad compartida para modificar los contenidos a través de una red virtual creada por Windows Azure Connect?

La respuesta es: ¡Y por qué no! Sí, por supuesto que se puede. Y esta entrada trata de explicar los pasos para configurarlo de forma manual.

¿Qué necesito?

Para poder conectar tu equipo a una unidad VHD en Azure, necesitarás lo siguiente:

• Una suscripción activa a Azure sobre la que vas a desplegar tanto los servicios de computación (servidor de ficheros) como el almacenamiento. Puedes crearte una en http://www.windowsazure.com.
• Un servidor worker role que monte la unidad VHD y la comparta, habilitando el tráfico SMB (puerto 445). La forma más sencilla es montar el paquete DNN Azure Single and ExtraSmall del DNN Azure Accelerator. Si quieres construirte tu propio servicio te recomiendo le eches un vistazo a este post de Dinesh Haridas.

Pasos a seguir

1) Habilitar en la suscripción el servicio Windows Azure Connect. Como ahora mismo aún está en CTP, deberás solicitar su activación a través del menú de “programas BETA” en la consola de administración de Windows Azure. La parte buena es que mientras está en CTP, este servicio es gratuito.

2) Usar el “Relay” de Connect más cercano a tus servicios. Para ello, pulsa sobre el botón “Relay Region” e indica la región más cercana. Supuestamente también usarás la misma región para desplegar tu servidor más adelante.

3) Instalar el cliente de Connect en tu equipo local (o desde donde quieras acceder a tu unidad compartida en la nube). Para ello, accede desde la sección “Red Virtual” de la consola de administración de Azure, y selecciona la suscripción. pulsa sobre el botón “Instalar extremo local”, siguiendo las instrucciones en pantalla.

Una vez instalado, podrás ver en el área de notificación de la barra de tareas de Windows el icono correspondiente al servicio.

4) Obtener un token de activación de Azure para el servidor SMB que se desplegará en Azure. Para ello, pulsamos el botón “Obtener Token de Activación” de la misma consola de Windows Azure. Copiamos el “guid” que nos devuelve en el portapapeles porque lo vamos a usar en el paso siguiente.

5) Desplegar el servidor SMB en Azure conectado con Windows Azure Connect. Tal y como se comentó anteriormente, una forma rápida es usar el paquete DNN Azure Single and ExtraSmall del DNN Azure Accelerator. Sin embargo, el paquete que está compilado e incluido dentro de la descarga, no tiene habilitado Windows Azure Connect –sí lo estará en la próxima versión del Accelerator. Mientras tanto, puedes descargar la última versión del código fuente y abrirlo en Visual Studio 2010, modificando las propiedades de Red Virtual del paquete antes de volver a generarlo.

6) Una vez que hemos desplegado el paquete en Azure (hay un excelente video al respecto, por lo que me voy a saltar esa parte), volvemos a la sección de Red Virtual de la consola de administrador de Windows Azure para habilitar la interconexión entre nuestro equipo y el rol desplegado, creando un nuevo grupo. En la imagen siguiente se muestra un ejemplo donde conecto con dos servidores SMB distintos ubicados en dos servicios distintos (realmente 2 instancias de DotNetNuke en Azure):

7) Con esto, ya deberíamos ver el equipo remoto en la nube ejecutando un simple ping. Para ello, copiamos la dirección IPv6 del equipo remoto de la misma consola de administración, y en una consola de comandos de DOS escribimos ping <direccionIPv6>.

No os asustéis por el ping de la imagen. En el momento de la captura estaba conectado a través de una red 3G y me estaba dando más del doble de tiempo de conexión.

NOTA: en caso de que no haya respuesta de ping, puede ser que nuestro equipo local no tenga habilitada la regla en el firewall. Para ello ejecutamos el comando siguiente:

netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6

Para resolver más problemas de conectividad, puedes consultar el enlace siguiente: http://msdn.microsoft.com/en-us/library/gg433016.aspx

8) Mapear la unidad de red a nuestro equipo local. Para ello, abrimos en el explorador de Windows la ventana de “Conectar nueva unidad de red...”, introduciendo la ruta: \\<IPv6>.ipv6-literal.net\<carpeta>, donde <IPv6> es la dirección remota a la que hemos hecho ping en el paso anterior sustituyendo el carácter “:” por “-“ (es la nomenclatura para el comando “net use”), y <carpeta> es el nombre del recurso compartido. Las credenciales usadas son las mismas que usamos al desplegar el servicio en Azure (ver fichero de configuración del servicio desplegado).

Opcional: yo he usado el archivo c:\windows\system32\drivers\etc\host, añadiendo un alias para la IPv6 con un nombre más común. Así sé qué unidad es de cada servidor sin tener que recordar la IPv6. También hay que tener en cuenta que esta IPv6 puede cambiar al reiniciarse el servidor por cualquier motivo, por lo que éste último paso 8 habría que repetirlo de nuevo. Una opción podría ser crear una aplicación cliente que detectara estos cambios y que hiciera un “remap” de las unidades automáticamente.

Conclusiones

El resultado es el poder modificar el contenido del VHD directamente desde nuestro equipo. Las posibilidades se me amontonan en la cabeza. Siempre hay que tener en cuenta que trabajaremos con nuestro ancho de banda a Internet –que por cierto, va impresionantemente bien con una conexión lenta-, por lo que para operaciones “grandes” de copia/pega de archivos sobre la misma unidad, compresión masiva de carpetas, etc. es recomendable conectarse al servidor SMB vía escritorio remoto. 

Respecto al DNN Azure Accelerator, comenzaré a trabajar para poner un paso en el asistente para no tener que volver a recompilar el paquete en Visual Studio, tal y como hice con el paso de configuración RDP. En breve estará disponible.

Algunas reflexiones

• Sabiendo que la facturación del espacio consumido por los VHD (Page Blobs) es por “espacio ocupado” (las páginas vacías del VHD no se cobran), ¿te has parado a pensar que podrías tener unidades virtuales en Azure Storage de 1Tb (1.000Gb) cada una en la que Microsoft sólo te cobraría por el espacio utilizado? Si borras ficheros del disco (y lo mantienes desfragmentado), te baja la factura
• ¿Qué tal funcionarán los sistemas de backups tradicionales con una unidad de red montada de este modo? Está claro que aquí el cuello de botella lo impone el ancho de banda de tu conexión a Internet, pero normalmente los programas de copias de seguridad realizan modificaciones incrementales ==> Esto tengo que probarlo
• Tal y como comentó Joe Brinkman, actualizar tu web de DotNetNuke se convierte en cosa de niños simplemente copiando y pegando archivos a través del mismo explorador de Windows:
  
• ¿Qué tal funcionaría una instancia ExtraSmall si sólo es para servir ficheros a través de la red?

Ya sólo faltaría algún método de alta disponibilidad para el servidor SMB...pero eso también está a punto de llegar...

Espero que sea de utilidad. Para mí lo es...¡y mucho!

Modificar las credenciales RDP en los roles de Azure sin Visual Studio

Uno de los principales problemas que se ha encontrado la gente al gestionar una aplicación en Azure es el no poder habilitar de una forma sencilla la conexión a escritorio remoto. ¿A qué me refiero con sencilla? Pues a no tener que descargar Visual Studio 2010 sólo para generar el paquete con las credenciales de acceso y generar el certificado X509 con el que se encriptan las mismas.

Y es que aunque Visual Studio nos automatiza mucho esta tarea, hay perfiles “no desarrolladores” (por ejemplo, nuestros compis de IT) que no suelen tener instalado Visual Studio en sus equipos, aunque posiblemente sí se tengan que encargar del depliegue y gestión de roles en Azure (¿ha llegado ese momento?).

Para ello usaremos:

• Utilidad makecert.exe, para generar los certificados
• Consola de comandos de PowerShell

NOTA: el paquete “cspkg” a desplegar en Azure estará “compilado” como que tiene RDP habilitado (es decir, que el fichero de definición del servicio tiene importado los espacios de nombres de RemoteAccess, etc.). Aquí lo que se trata es de poder usar otras credenciales que las que se crearon en tiempo de compilación, así como otro certificado.

Generando manualmente el certificado X509

1) Crear un certificado a través de línea de comandos con la utilidad “makecert.exe”, haciendo exportable la clave:

makecert.exe -r -pe -a sha1 -ss My -len 2048 -sky exchange -n "CN=Azure Deployment" mycertificate.cer

Es importante indicar el parámetro “-sky exchange” ya que si no nos encontraremos con el error “The remote desktop certificate with thumbprint ‘xxx’ does not have a type of key exchange and cannot be used for decryption” al intentar usar este certificado en Azure.

2) Exportar el certificado en formato “PFX” para subirlo y asociarlo al servicio en Azure. Para ello:

1. Abrimos el gestor de certificados desde una consolad e comandos tecleando “certmgr.msc”
2. Localizamos el certificado que acabamos de generar y pulsamos el botón “Exportar” para abrir el asistente de exportación
   
3. Seguimos las instrucciones del asistente, exportando la clave privada así como todas las propiedades extendidas del certificado
   
4. Finalmente introducimos una contraseña que usaremos en el momento de importarlo en Azure y un nombre de fichero “.pfx”

3) Importar el certificado en Windows Azure a través de la consola de administración de Azure. Importamos el certificado pulsando botón derecho sobre el servicio y agregando el fichero y su contraseña que hemos generado:

Generar la contraseña encriptada

El siguiente paso, es generar la contraseña que deseemos para nuestras credenciales RDP. Una de las formas más sencillas, para los amantes de PowerShell, es a través de la consola usando los pasos siguientes:

1) Abrir una consola de comandos PowerShell, a través de Inicio>Accesorios>Windows PowerShell (ejecutar como “Administrador” pulsando el botón derecho sobre el icono)

2) Ejecutar los comandos siguientes pulsando Enter después de cada línea:

[Reflection.Assembly]::LoadWithPartialName("System.Security")
$pass = [Text.Encoding]::UTF8.GetBytes("<Password>")
$content = new-object Security.Cryptography.Pkcs.ContentInfo –argumentList (,$pass)
$env = new-object Security.Cryptography.Pkcs.EnvelopedCms $content
$env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient(gi cert:\CurrentUser\My\<Thumbprint>)))
[Convert]::ToBase64String($env.Encode())

Recuerda cambiar el valor "<Password>” por la contraseña que desees. También debes modificar el valor “<Thumbprint>” por la huella del certificado que generaste en la sección anterior. La forma más sencilla de encontrar este valor es en el panel de control de Windows Azure, seleccionando el certificado y viendo las propiedades en la barra lateral derecha:

3) Copia esa información en el Notepad, eliminando los caracteres de nueva línea.

Introduciendo los valores en el fichero de configuración del servicio

Finalmente, con los valores anteriores, abrimos el fichero de configuración del servicio (.cscfg) y modificamos los valores solicitados:

Indicar que la fecha de expiración de la cuenta debe estar en formato ISO 8601 “yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fffffffK”.

Conclusión

Como hemos visto, hemos realizado todo el proceso sin tener que tocar Visual Studio. Del mismo modo, todo este proceso puede automatizarse programáticamente a través de .NET, creando una simple utilidad para facilitar las labores a nuestros compañeros.

Un ejemplo de esta implementación, es el nuevo paso en el asistente del DNN Azure Accelerator en el que se simplifica la generación del certificado, se solicitan estas credenciales y se encriptan en un sólo paso (idéntico al que está en Visual Studio 2010!!).

Os dejo con dos capturas de pantalla como avance. Lo subiré a CodePlex en breve:

Espero que sirva de ayuda.

Un saludo a todos.

[Evento] Desarrollando aplicaciones web en la nube

AVISO: Cambio de hora a las 16:00 GMT+0 y con posibilidad de verlo por webcast en directo. Ver detalles más abajo.
Si tienes problemas con el enlace del correo de confirmación del webcast, usa este (se abre a las 15:30) https://www.livemeeting.com/cc/_XML/wwe_uk/join?id=1032496233&role=attend&pw=97480C47

Tras la breve pausa veraniega, volvemos a retomar las charlas en TenerifeDev sobre tecnologías .NET. Vamos a comenzar con una charla sobre el desarrollo de aplicaciones web sobre Windows Azure usando el gestor de contenidos DotNetNuke.

Si alguien asistió a la charla en la TLP2k11 o al CMS Azure RoadShow de Julio que no se preocupe, porque esta vez nos centraremos en aspectos más técnicos: cómo crear una extensión para DotNetNuke con Visual Studio 2010 –o sea, una aplicación sobre DNN-, cómo desplegarla en Azure y/o distribuirla e incluso cómo llegar a ganar dinero con ello. 

Por supuesto veremos algunas de las mayores novedades de DNN 6.0 (C#, jQuery, acelerador para Windows Azure, etc.) y como no, sortearemos algunos regalos de nuestros patrocinadores. Recordar que en la última charla Telerik repartió licencias de su suite de controles para ASP.NET y Windows Phone 7. Felicidades a C. Martin y Marcos G.D. que fueron los agraciados. Pluralsight no se quedó atrás y repartió 1 mes de regalo de toda su oferta de cursos en línea a todos los asistentes.

Os dejo los detalles de la charla. No podéis faltar.

P.D. la de Windows 8…en breve, cuando a Alberto deje de caérsele la baba

Evento TenerifeDev - Desarrollando aplicaciones web en la nube
Fecha y hora: 7 de octubre de 2011, de 16:00 a 17:30 GMT+0
Lugar: Salón de grados de la Escuela Técnica Superior de Ingeniería Informática (ETSII)
Descripción: DotNetNuke es un proyecto open source, la plaforma de gestión de contenidos para la construcción de sitios y aplicaciones web basada en Microsoft .NET más ampliamente adoptada a nivel global. Las organizaciones usan DotNetNuke para desarrollar y desplegar rápidamente sitios web interactivos y dinámicos, intranets, extranets y aplicaciones web. Con el soporte para granjas de servidores y el DotNetNuke Azure Accelerator, se presenta sobre Windows Azure como una solución de gestión elástica de contenidos en la nube.
Ponente: David Rodríguez

URL para registro del webcast en directo: 

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032496233&Culture=es-ES

Modifying the VHD contents on Azure

Now that a new DNN upgrade package has been released, perhaps you are interested in how to modify your DNN instance to upgrade the contents to the latest release.

Some people are doing this work downloading the full VHD, updating it locally and the uploading it again to Azure Storage. I don’t use this method, but I’ll explain how to do it and how I do it.

Downloading, modifying, uploading

If you want to download the VHD and make the changes on your development environment, you will need a tool that can download/upload PAGE BLOBS.

Method 1: Use a graphical tool

Cerebrata is working on a specific tool for this task that is name Azure Page Blob Manager. You can check it here (is still in beta and you can download and use it)

Features

As the name suggests, this utility is specifically designed to manage Windows Azure Page Blobs. At a very high level here is what you can do with this utility:

• You can view the contents of a page blob mounted as an Azure Drive. This is probably the neatest feature of this utility. Basically this utility creates an empty VHD on your computer and then downloads the occupied pages of the page blob and then mounts the VHD on your computer as a drive so that you can see the files contained in the page blob.
• You can upload VHDs in Windows Azure Blob storage as page blobs.
• You can download page blobs.
• You can view the total size of the page blob and also the space currently occupied by the page blob (which would tell you how much are you being charged for this particular page blob).
• You can see how many pages in the page blob are occupied (blue boxes in the screenshot below). Each box below represents 1/400^th of the total page blob size. Clicking on the blue box will tell you how many bytes are occupied.
• This utility will list the page blobs only.

Method 2: use a command line tool

You can also download/upload the VHD using a command line tool like “AccelCon.exe” that was included in the original DNN Azure Accelerator package (developed by Slalom Consulting). This tool is not included on the latest build so you can download it from this link:

• https://intelequia.blob.core.windows.net/downloads/AccelCon.zip

You can upload the VHD as a page blob using this command line syntax:

accelcon.exe /u /v ".\DotNetNuke.vhd" "azure-accelerator-drives/dotnetnuke.vhd"

Method 3: Why to download the VHD?

If you enable RDP, you can copy/paste contents and many other things. When I need to upgrade the contents (i.e. when a new upgrade release is delivered), I usually:

1. connect via RDP to one instance
2. navigate to Codeplex and download the upgrade package (web navigation is enabled inside the roles)
3. extract the update into the drive.

I usually copy the contents to another folder (for backup purposes) and execute and create a copy of the database (T-SQL: create database … as copy of …), so I can repeat/regress the process quickly is something fails. I do all this work via RDP. In order to enable RDP, at this moment you need to recompile the package (see documentation), but I highly recommend it for this and other purposes.

Some new features will be announced respect to this on the next release of the DNN Azure Accelerator, so stay tuned :)

Modificar el contenido de un VHD en Azure

Ahora que ha salido un nuevo paquete de actualización de DNN, quizás estés interesado en cómo modificar tu instancia de DNN en Azure para actualizar los contenidos a esta última versión.

Según tengo entendido, mucha gente está realizando esta operación descargando localmente una copia del VHD, actualizándolo en el entorno de desarrollo y volviendo a subir de nuevo el VHD a Azure. Personalmente no use este método, pero explicaré cómo realizarlo y luego los pasos que sigo yo para actualizar mis instancias.

Descargar, modificar, subir

Si deseas realizar el trabajo mediante la descarga local del VHD realizando los cambios en tu entorno de desarrollo, necesitarás una herramienta capaz de descargar/subir PAGE BLOBS. A diferencia de los blobs normales –block blobs-, las VHD usan otro tipo de blobs que normalmente no todas las herramientas que trabajan con Azure lo soportan.

Método 1: Usa una herramienta de interfaz gráfica

Cerebrata está trabajando en una herramienta específica para esta tarea llamadaAzure Page Blob Manager. Puedes descargarla aquí (todavía está en beta y puedes descargarla y usarla).

Características

Esta utilidad está específicamente diseñada para administrar Page Blobs de Windows Azure. A muy alto nivel, esto es lo que puedes hacer con esta herramienta:

• Puedes ver los contenidos de un page blob montado como una Azure Drive. Probablemente este es uno de las mejores características de esta utilidad. Básicamente esta utilidad crea un VHD vacío en tu equipo local y descarga las páginas ocupadas del page blob para finalmente montar el VHD localmente como una unidad para que puedas ver los ficheros que contiene el page blob.
• Puedes subir VHDs a Windows Azure como page blobs.
• Puedes descargar page blobs.
• Puedes ver el tamaño total del page blob así como el espacio ocupado actualmente por el page blob (que te debería indicar cuánto te están facturando actualmente por este page blob en particular).
• Puedes ver cuántas páginas están ocupadas en el page blob están ocupadas (las cajas azules en la captura de pantalla). Cada caja representa 1/400avo del total del tamaño total del page blob. Pulsando sobre una caja azul te dirá cuántos bytes están ocupados.
• Esta utilidad sólo listará los page blobs.

Método 2: usa una herramienta de línea de comandos

También puedes descargar/subir el VHD usando una herramienta de línea de comandos como “AccelCon.exe” que fue incluida en el paquete original de DNN Azure Accelerator (desarrollada por Slalom Consulting). Esta herramienta no está incluida en el último distribuible así que la he puesto a descarga en este enlace:

• https://intelequia.blob.core.windows.net/downloads/AccelCon.zip

Puedes subir el VHD como un page blob usando esta sintáxis:

accelcon.exe /u /v ".\DotNetNuke.vhd" "azure-accelerator-drives/dotnetnuke.vhd"

Método 3: ¿Por qué descargar el VHD?

Si habilitas RDP (escritorio remoto), puedes copiar/pegar contenidos y muchas otras tareas. Personalmente, cuando necesito actualizar los contenidos por un cambio de versión de DNN, normalmente::

1. conecto vía RDP a una instancia
2. navego a Codeplex y descargo el paquete de actualización (se puede navegar desde dentro de los roles)
3. descomprimo la actualización dentro de la unidad

Normalmente copio los contenidos a otra carpeta en la unidad (para backup) y creo una copia de seguridad de la base de datos (T-SQL: create database … as copy of …), de manera que pueda repetir/deshacer rápidamente la operación si algo va mal. Todo esto vía RDP. Para habilitar RDP, actualmente necesitas recompilar el paquete a desplegar en Azure para introducir los credenciales y el certificado con el que se encriptan (ver documentación), pero es algo altamente recomendable para ésta y otras tareas.

En breve se anunciarán nuevas carcterísticas del DNN Azure Accelerator respecto a estas tareas de actualización, así que permanece en sintonía.

Un saludo.

[Video] Usando el DotNetNuke Azure Accelerator

Ayer Joe Brinkman, cofundador de DotNetNuke Corp. publicó un video muy detallado de cómo desplegar DotNetNuke sobre Windows Azure usando el DNN Azure Accelerator.

El vídeo es altamente recomendable para todos aquellos que quieran profundizar sobre cómo realizar un despliegue de DotNetNuke sobre Windows Azure. Se explica detalladamente durante 25 minutos los detalles y el paso a paso, además de realizar una introducción a la arquitectura desplegada.

Sin más, os dejo con él. Saludos y buen fin de semana.

Crear entradas en el blog de DotNetNuke con Microsoft Word

Una de las interesantes posibilidades del blog de DotNetNuke es la de poder publicar entradas a través de una aplicación especializada como puede ser Windows Live Writer. Con la misma tecnología subyacente, se puede usar el mismo Microsoft Word (versión 2007 o superior) para publicar estas entradas. Por petición de varios conocidos pongo el paso a paso de cómo se configura.

1) Crear una entrada de blog con Word

Para realizar esta tarea, usamos el menú Archivo>Nuevo… y de la lista de plantillas seleccionamos “Artículo de blog” para luego pulsar el botón “Crear”:

2) Registrar la dirección del blog

Si es la primera vez que escribimos una entrada, nos saldrá una ventana indicando si queremos configurar la conexión con el blog. Pulsamos la opción de “Registrar ahora” para configurar la conexión con DotNetNuke.

De la lista de proveedores de blog, seleccionamos “Otros” (como podéis ver, se puede usar Word para muchos tipos de blog, aunque hay un estándar denominado MetaWebLogAPI para este tipo de comunicaciones que es el que usa DotNetNuke):

En esta ventana hay que introducir los datos siguientes:

1. URL de publicación del blog. Para obtener esta dirección, tenemos que iniciar sesión en nuestro sitio web de DotNetNuke e ir al módulo de blogs. Una vez allí, seleccionamos desde el módulo de administración del blog el enlace “Configurar mi blog”.
   
   que nos lleva a la pantalla de configuración del blog donde aparece la URL. Cópiala y pégala en la caja de texto.
   
2. Nombre de usuario: es el nombre de usuario de tu sitio de DotNetNuke con el que estás publicando entradas en el blog (date cuenta que con DNN se permiten distintos blogs por usuario)
3. Contraseña: la contraseña asociada
   NOTA: deja las opciones de imágenes como aparece de forma predeterminada, es decir, usando “Proveedor de mi blog”

Una vez realizados estos pasos, ya tienes configurada la conexión con DotNetNuke. Esta configuración será recordada para la próxima vez. Puedes configurar varias cuentas de blog ideal para escribir el artículo una vez y publicarlo en diversos sitios web.

3) Escribir el artículo

El interfaz de usuario del tipo de entrada de blog es algo distinta de la de un documento, pero con opciones suficientes para escribir casi cualquier entrada (digo “casi”, porque las opciones de Plugins que tiene el Windows Live Writer me parece más completa).

4) Publicar

Una vez escrito el artículo podemos pulsar el botón de “Publicar” para que automáticamente se publique la entrada en el blog. Como opciones adicionales, podemos publicar la entrada como borrador, añadir/quitar categorías, etc.

Otra opción interesante es la de poder editar una entrada existente, pulsando el botón “Abrir existente…”, que nos permite seleccionar de una lista las entradas que actualmente están publicadas en nuestro blog de DotNetNuke.

Espero que os haya sido útil.

DotNetNuke 6.0: Fix para el módulo de Dashboard en Azure

Esta es una entrada corta en el blog para aquellos que tengan DNN 6.0 en Azure y no puedan acceder al módulo de Dashboard. Hay un procedimiento almacenado que seguía sin ser compatible con SQL Azure en este módulo ya que acceder a “sysfiles”.

Como ya sabrán, en SQL Azure al ser un servicio multi-tenant no hay información sobre los ficheros físicos de SQL, por lo que esta sintaxis genera un error.

ALTER procedure [dbo].[Dashboard_GetDbFileInfo]
AS
    
    SELECT 
        CASE LOWER(RIGHT(filename,3))
            WHEN 'mdf' THEN 'DATA'
            WHEN 'ldf' THEN 'LOG'
            ELSE 'UNKNOWN'
        END as FileType,
        Name,
        size*8 as Size,
        filename
    FROM sysfiles


GO

Para solucionarlo, modificamos el procedimiento almacenado de la siguiente manera, para que sirva tanto en entorno SQL Azure como on-premise:

ALTER procedure [dbo].[Dashboard_GetDbFileInfo]
AS
    
IF ServerProperty('Edition') = 'SQL Azure' 
    BEGIN
        SELECT 
            'DATA' as FileType,
            db_name() as Name,
            (8.0 * SUM(reserved_page_count)) as Size,
            'c:\...\Not_accesible_on_SQL_Azure.mdf' as Filename
        FROM sys.dm_db_partition_stats    
    END
ELSE
    BEGIN
        EXECUTE sp_executesql N'SELECT 
            CASE LOWER(RIGHT(filename,3))
                WHEN ''mdf'' THEN ''DATA''
                WHEN ''ldf'' THEN ''LOG''
                ELSE ''UNKNOWN''
            END as FileType,
            Name,
            size*8 as Size,
            filename
        FROM sys.files'
    END

GO

Una vez modificado el procedimiento almacenado, ya podemos acceder al módulo de Dashboard para comprobar todos los parámetros de nuestra instancia de DotNetNuke.

Espero que sirva de ayuda (o por lo menos para acordarme yo mismo de esto).

Un saludo.

Migración manual de BPOS a Office 365: dos cosas que deberías saber

Después de tanto hablar de DotNetNuke y Azure, me veo en la necesidad de compartir unos comentarios sobre la migración manual que hemos realizado en nuestra empresa desde BPOS a Office 365, la suite de productividad de Microsoft en la nube.

Antes de empezar, recordar que la migración de BPOS a Office 365, desde el punto de vista del usuario/cliente, realmente es automática y que simplemente hay que ceñirse a cumplir los requerimientos de la nueva versión O365 después de haberlo planificado con Microsoft. Esta planificación se realiza una vez que el equipo de soporte de Microsoft se ponga en contacto con el contacto técnico cliente y tiene el plazo de un año para actualizar los equipos cliente a los nuevos requerimientos. Desde el punto de vista del servidor, no hay que realizar nada ya que es la propia Microsoft la que se encarga de la migración de buzones, sitios de Sharepoint, etc.

El principal problema es que parece que Microsoft está dando fecha para principios de 2012 como comienzo de estas migraciones de BPOS a 365, con lo que si no hay alternativa habría que esperar a este hito en el calendario.

¿Y entonces qué significa eso de Migración Manual?

A los que nos gusta estar a la última, ya sea por capricho o por necesidad de mostrar la última tecnología a nuestros clientes demostrando que usamos los mismos productos que vendemos, se nos antoja que al estar disponible Office 365, queremos usarlo en nuestro día a día y no sólo para las demos.

¿Es posible migrar nuestros servicios de BPOS a Office 365 sin tener que esperar a 2012? La respuesta es sí. Pero –todo tiene un pero- la migración recae en el lado del cliente y no está soportada por Microsoft. Tengo que comentar que realmente con lo de “soportada” se refieren a que no les puedes solicitar algo como “mígrame este buzón” o cosas así, pero sí que dan soporte a los problemas surgidos durante una migración manual, como ha sido nuestro caso. Mis más sinceras felicitaciones al equipo de soporte por su eficacia y buen hacer.

¿Cómo se realiza una migración manual de BPOS a O365?

Hay varios métodos, desde el más manual hasta alguno automatizado con herramientas de terceros como MigrationWiz. Como el número de buzones que teníamos que migrar era relativamente bajo, decidimos que podíamos hacerlo de forma manual siguiendo el paso a paso descrito en el siguiente enlace:

• How to Manually Migrate from BPOS to Office 365

No voy a repetir aquí cada uno de los pasos a realizar, sino que más bien voy a destacar las incidencias más importantes que tuvimos y su resolución, ya que para la segunda ni siquiera encontré solución en los foros de 365.

A destacar…

El elemento más destacable, es que el proceso de migración manual, se haga como se haga, implica un “micro-corte” en el servicio. Esto es debido a que cuando inicias el asistente de creación de entradas DNS en Office 365, éste comprueba internamente si el dominio está dado de alta en BPOS. Si es así, te obliga a eliminar el dominio primero de BPOS para luego darlo de alta en 365, con lo que el corte durará lo que tardes en realizar estos pasos y se repliquen las entradas MX de los registros DNS. Cualquier correo entrante durante ese periodo de tiempo no podrá ser entregado (con los salientes no hay problema).

Esto en teoría puede llegar a tardar hasta 72h. En la práctica a la hora y media, más o menos, ya casi está completamente operativo. Es por ello que es ideal elegir un momento de menos actividad para realizar esta migración manual.

Dos cosas que deberías saber…

Si te decides a realizar esta migración manual, quisiera compartir estas dos incidencias y su resolución, ya que han tenido que ser resueltas a través de soporte creando tickets en el servicio:

1. Una vez replicados los registros MX de los DNS, cualquier correo entrante es devuelto con el mensaje de error “Relay Access Denied” (smtp;550 5.4.1 Relay Access Denied). Este error es debido a que al eliminar el dominio de BPOS, la información relacionada al dominio en los servicios de antispam no son eliminados (FOPE – Forefront) e impide que cualquier correo dirigido al dominio se reenvíe correctamente. Para solucionarlo, a fecha de hoy la única alternativa es poniéndose en contacto por teléfono con el servicio de soporte de FOPE en el teléfono de USA +001-866-676-6546, pulsando las opciones 1,1,2,2 y solicitar que eliminen los remanentes del dominio. Aconsejo crear un ticket de servicio primero desde BPOS porque te van a pedir confirmación por escrito vía ticket para que quede documentado.
   Para más información sobre este error, ver estos enlaces:
   • http://www.cgoosen.com/2011/07/moving-from-bpos-to-office365-550-5-4-1-relay-access-denied/
   • http://community.office365.com/en-us/f/160/p/7682/31381.aspx#31381
2. Una vez que comienzan a llegar los correos a Office 365, los correos con origen desde BPOS llegan al antiguo servicio de BPOS en vez de al O365. Este error sí que nos trajo de cabeza…y a los de soporte BPOS también. Resulta que cualquier mensaje que cuyo origen fuera de alguien que también usara los servicios BPOS en la región EMEA (ojo, que los de soporte de USA sí entraban correctamente en O365) llegaban a nuestros antiguos buzones de BPOS en vez de a los de O365. ¿Cómo era posible si ya había pasado casi 1 semana y las entradas DNS supuestamente se habían replicado correctamente?
   Después de indagar mucho y no encontrar nada relacionado, la técnico de soporte de BPOS tuvo buenos ojos en detectar que se habían quedado los alias en los usuarios en el servicio de BPOS y me dijo que probara a eliminarlos. Esto quiere decir que, aunque elimines el dominio de BPOS, los alias de los usuarios de dicho dominio también han de eliminarse manualmente, ya que no se hace de forma automática. Una vez eliminados los alias del anterior dominio, los correos comenzaron a entrar correctamente en O365.
   
   Esta incidencia entiendo que se da porque parece que el servicio de BPOS (y supongo que el de O365 de forma similar) usa un servicio de directorio global –o por lo menos uno por cada región: EMEA, etc.- y los alias de las direcciones se resuelven internamente en el momento de construir los mensajes de correo, por lo que si había un alias de un dominio anterior, se traduce como que se redirija al buzón antiguo. Curioso.
   EDIT 15/08/2011: Lo mismo pasa con las listas de distribución (parece que son globales dentro de este servicio de directorio dentro de EMEA). Elimina todas las listas de distribución de BPOS referidas al dominio migrado, ya que si no los correos desde BPOS a estas listas de distribución se quedarán igualmente dentro de BPOS.

Después de una semana trabajando con Office 365, tenemos que decir que estamos muy satisfechos con la migración y con las nuevas características. A mí me gusta una que puede parecer una chorrada, pero ver cómo pueden trabajar varias personas a la vez sobre un mismo documento Word es alucinante a la vez que productivo.

Espero que esta información sirva de ayuda.

Un saludo.

Disponible fix para el paquete de actualización a DNN 6.0 en Windows Azure

Al intentar actualizar en Windows Azure una instancia de DotNetNuke desde la versión 05.06.03 a la 06.00.00 usando el paquete oficial de actualización, te encontrarás con el siguiente error:

En el enlace siguiente puedes descargar un documento con la vista detallada de estos errores http://dnnazureaccelerator.codeplex.com/releases/view/71164#DownloadId=266857

El resumen de los mismos son referidos a incompatibilidades con SQL Azure del paquete de actualización (el de primera instalación funcionaba sin problemas):

Para solucionarlo, puedes seguir una de estas dos propuestas:

• Usar el paquete corregido en vez del paquete oficial, que he puesto a descarga en  http://dnnazureaccelerator.codeplex.com/releases/view/71164#DownloadId=266856
• Aplicar el siguiente script T-SQL después de aplicar el paquete oficial de actualización

Hope this helps,

David Rodriguez

DNN 6.0 upgrade package fix available for Azure

When trying to upgrade a DotNetNuke instance from 05.06.03 to 06.00.00 on Windows Azure using the official distribution upgrade package, you will encounter the following error:

A detailed view of these erros can be found at http://dnnazureaccelerator.codeplex.com/releases/view/71164#DownloadId=266857

The summary of SQL Azure incompatible issues are:

You can follow one of these solutions:

• Use the fixed upgrade package instead the official package, that is available for download at http://dnnazureaccelerator.codeplex.com/releases/view/71164#DownloadId=266856
• Apply the following T-SQL script fix after the official upgrade package has been applied

Hope this helps,

David Rodriguez