Syntax Highlighter

viernes, 19 de agosto de 2011

[Video] Usando el DotNetNuke Azure Accelerator

videoAyer 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.

DNNAzureAcceleratorVideo400

miércoles, 17 de agosto de 2011

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”:

NewBlogPost

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.

RegisterBlog

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):

NewBlogAccount

NewAccountConfig

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”.
    AdminBlog
    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.
    MetaWeblogOptions
  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.

AccountSuccess

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).

BlogEntry

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.

Entrada de post publicada como borrador

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.

viernes, 12 de agosto de 2011

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.
Dashboard fix
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

office_365Despué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:
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:
  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.
    Eliminar Alias en BPOS
    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.

jueves, 4 de agosto de 2011

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

SQLAzure_200_thumb[1]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:

Upgrading from 05.06.03 to 06.00.00_thumb[2]

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):

Stored Procedure “GetFile”

Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

Stored Procedure “GetFileById”

Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

Stored Procedure “GetAllFiles”

Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

Stored Procedure “GetFiles”

Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

Creating PK on “PortalLocalization”

Table 'PortalLocalization' already has a primary key defined on it.

Stored Procedure “GetVendorsByEmail”

Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

Stored Procedure “GetBanner”

Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

Para solucionarlo, puedes seguir una de estas dos propuestas:

Hope this helps,

David Rodriguez

DNN 6.0 upgrade package fix available for Azure

SQLAzure_200When 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:

Upgrading from 05.06.03 to 06.00.00 on Azure
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:
Stored Procedure “GetFile” Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.
Stored Procedure “GetFileById” Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.
Stored Procedure “GetAllFiles” Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.
Stored Procedure “GetFiles” Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.
Creating PK on “PortalLocalization” Table 'PortalLocalization' already has a primary key defined on it.
Stored Procedure “GetVendorsByEmail” Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.
Stored Procedure “GetBanner” Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server.

You can follow one of these solutions:


Hope this helps,
David Rodriguez

DotNetNuke Azure Accelerator 6.0 listo para descarga!

DNN6 WheelDespués de un duro trabajo corrigiendo los paquetes de instalación de los módulos opcionales de DNN6 para que funcionaran con SQL Azure, el nuevo acelerador de DotNetNuke 6.0 ya está disponible en Codeplex con una serie de nuevas e interesantes características.
La mejor característica de todas, por supuesto, es que permite publicar DotNetNuke 6.0 en windows Azure. ¿Quieres saber más? Sigue este enlace al proyecto DNN Azure Accelerator:

Nuevas características de esta versión

  • Incluye un paquete de distribución modificado de DNN6 con las correcciones a los módulos opcionales para que sean compatibles con SQL Azure (revisa el documento al respecto en Codeplex para más detalles)
  • El rol SMB creará, la unidad VHD dinámicamente la primera vez que se acceda a la aplicación en la nube, siempre que ésta no exista, con lo que ya no hará falta subir una unidad VHD preconfigurada on-premise
  • Decrementado el tamaño de la subida de paquetes de 272Mb a 37Mb (despliegues más rápidos!!)
  • Después de la creación del VHD, el rol SMB descargará desde el Azure Storage el paquete de distribución descomprimiéndolo dentro de la unidad
  • Usarás el asistente oficial de instalación y configuración de DotNetNuke la primera vez que accedas desde tu navegador
  • Modificado el método de carga de archivos para que funcione correctamente en conexiones con bajo ancho de banda (eliminada la utilidad Accelcon.exe de la solución)
  • Ahora puedes seleccionar qué paquetes de servicio quieres subir a almacenamiento desde el asistente del acelerador
  • Puedes recompilar tus propios paquetes de servicio y ponerlos dentro de la carpeta “/packages” para que el asistente los procese y los suba a Azure

Algunas capturas de pantalla

Usando el asistente para crear instancias de DotNetNukeUsing the wizard to create the DotNetNuke instances
Seleccionando módulos opcionales en la primera ejecución Selecting non-core modules on first Azure instance run
Ejecutando el asistente de instalación desde mi iPad Sonrisa Running the installation Wizard from my iPad
El módulo de blogs de DNN 6.0 funcionando en Windows AzureDNN6Azure

DotNetNuke Azure Accelerator 6.0 released!

DNN6 WheelAfter a hard work fixing the DNN6 optional modules in order to work on SQL Azure, the new accelerator is available at Codeplex with a list of new interesting features.

The best feature, of course, is that allows DNN 6.0 to run on Windows Azure. Do you want to know more? Follow this link to the DNN Azure Accelerator Project:

http://dnnazureaccelerator.codeplex.com 

New features in this release

  • Includes a modified DNN6 distribution package with the SQL Azure fixes for non-core modules (see the documentation for a review of them)
  • The SMB role will create the VHD dynamically on the first run if the cloud drive does not exists, so there will be no need to upload a huge blob
  • Decreased the upload size from 272Mb to 37Mb (deployments will be faster!!)
  • After the VHD creation, the SMB role will download from the Storage the distribution package and unzip it to the VHD drive
  • You will use the official DNN installation wizard to create and configure the DNN instance on fist run from your browser
  • Changed the upload method in order to work on low bandwidth connections (removed Accelcon.exe utility)
  • Now you can select the service packages that you want to upload from the accelerator wizard
  • You can build your own service packages and put them inside the /packages folder. The wizard will process them for you.

 

Some screenshots

Using the wizard to create the DotNetNuke instancesUsing the wizard to create the DotNetNuke instances

Selecting non-core modules on first Azure instance run
Selecting non-core modules on first Azure instance run

Running the installation Wizard from my iPad Sonrisa
Running the installation Wizard from my iPad

The DNN 6.0 blog module running on Windows Azure
DNN6Azure

Related Posts Plugin for WordPress, Blogger...